|
| 1 | +--- |
| 2 | +page_title: "Migrating the management of Instance Block Storage volumes to SBS" |
| 3 | +--- |
| 4 | + |
| 5 | +# Migration |
| 6 | + |
| 7 | +This page describes how to migrate the management of your Instance's volumes from Block Storage legacy to SBS (Scaleway Block Storage). |
| 8 | +This documentation **only applies if you have created Block Storage legacy volumes** (`b_ssd`). |
| 9 | + |
| 10 | +Migration of local volumes is not supported, you will have to migrate your data manually. |
| 11 | + |
| 12 | +Find out about the advantages of migrating from the Instance API to the Block Storage API for managing block volumes in the [dedicated documentation](https://www.scaleway.com/en/docs/block-storage/reference-content/advantages-migrating-to-sbs/). |
| 13 | + |
| 14 | +## Migrate your implicit root_volume |
| 15 | + |
| 16 | +If your infrastructure includes a server with a root volume that must be migrated: |
| 17 | + |
| 18 | +```terraform |
| 19 | +resource scaleway_instance_server "server" { |
| 20 | + type = "PLAY2-PICO" |
| 21 | + image = "ubuntu_jammy" |
| 22 | + root_volume { |
| 23 | + volume_type = "b_ssd" |
| 24 | + } |
| 25 | +} |
| 26 | +``` |
| 27 | + |
| 28 | +In the snippet above, the `root_volume` type is explicitly configured as a `b_ssd`. This configuration must be removed to prepare for migration. |
| 29 | + |
| 30 | +```terraform |
| 31 | +resource scaleway_instance_server "server" { |
| 32 | + type = "PLAY2-PICO" |
| 33 | + image = "ubuntu_jammy" |
| 34 | +} |
| 35 | +``` |
| 36 | + |
| 37 | +You can now migrate your root_volume using the [Scaleway CLI documentation](https://www.scaleway.com/en/docs/instances/how-to/migrate-volumes-snapshots-to-sbs/#migrating-an-existing-block-storage-volume-to-scaleway-block-storage-management). |
| 38 | +After migration, the output when running `terraform plan` should be empty as the provider should have picked up that the volume is now managed by the Scaleway Block Storage API. |
| 39 | + |
| 40 | +## Migrate your explicit volumes |
| 41 | + |
| 42 | +If your infrastructure includes servers and explicit volumes. |
| 43 | + |
| 44 | +```terraform |
| 45 | +resource scaleway_instance_volume "root_volume" { |
| 46 | + size_in_gb = 20 |
| 47 | + type = "b_ssd" |
| 48 | +} |
| 49 | +
|
| 50 | +resource scaleway_instance_volume "volume" { |
| 51 | + size_in_gb = 20 |
| 52 | + type = "b_ssd" |
| 53 | +} |
| 54 | +
|
| 55 | +resource scaleway_instance_server "server" { |
| 56 | + type = "PLAY2-PICO" |
| 57 | + root_volume { |
| 58 | + volume_id = scaleway_instance_volume.root_volume.id |
| 59 | + } |
| 60 | +
|
| 61 | + additional_volume_ids = [scaleway_instance_volume.volume.id] |
| 62 | +} |
| 63 | +``` |
| 64 | + |
| 65 | +You can rely on Terraform to perform the migration which will be done in 2 steps. |
| 66 | +The first one will be a transitional state to migrate and is described in the next snippet. |
| 67 | +In this snippet, the `migrate_to_sbs` field will prevent the old volume state from being updated during the migration. |
| 68 | + |
| 69 | + |
| 70 | +```terraform |
| 71 | +resource scaleway_instance_volume "root_volume" { |
| 72 | + size_in_gb = 20 |
| 73 | + type = "b_ssd" |
| 74 | + migrate_to_sbs = true # Mark migration to avoid failure |
| 75 | +} |
| 76 | +
|
| 77 | +resource scaleway_block_volume "root_volume" { |
| 78 | + size_in_gb = 20 |
| 79 | + iops = 5000 # b_ssd is a 5000 iops volume |
| 80 | + instance_volume_id = scaleway_instance_volume.root_volume.id # block resource will handle migration |
| 81 | +} |
| 82 | +
|
| 83 | +resource scaleway_instance_volume "volume" { |
| 84 | + size_in_gb = 20 |
| 85 | + type = "b_ssd" |
| 86 | + migrate_to_sbs = true # Mark migration to avoid failure |
| 87 | +} |
| 88 | +
|
| 89 | +resource scaleway_block_volume "volume" { |
| 90 | + size_in_gb = 20 |
| 91 | + iops = 5000 # b_ssd is a 5000 iops volume |
| 92 | + instance_volume_id = scaleway_instance_volume.volume.id # block resource will handle migration |
| 93 | +} |
| 94 | +
|
| 95 | +
|
| 96 | +resource scaleway_instance_server "server" { |
| 97 | + type = "PLAY2-PICO" |
| 98 | + root_volume { |
| 99 | + volume_id = scaleway_block_volume.root_volume.id # Start using your new resource |
| 100 | + } |
| 101 | +
|
| 102 | + additional_volume_ids = [scaleway_block_volume.volume.id] # Start using your new resource |
| 103 | +} |
| 104 | +``` |
| 105 | + |
| 106 | +The first migration step should have created your new Block Storage volumes and updated the existing instance_volume resources. |
| 107 | +After confirming the migration is successful, you must remove the old Instance's resources manually. |
| 108 | +Terraform's scaleway_instance_volume resource cannot delete a volume that has been migrated to the Scaleway Block Storage API. Before applying the final step, check in the Scaleway [console](https://console.scaleway.com) or using the [CLI](https://cli.scaleway.com/block/#list-volumes) to confirm that your volume was successfully migrated. |
| 109 | + |
| 110 | + |
| 111 | +```terraform |
| 112 | +resource scaleway_block_volume "root_volume" { |
| 113 | + size_in_gb = 20 |
| 114 | + iops = 5000 |
| 115 | +} |
| 116 | +
|
| 117 | +resource scaleway_block_volume "volume" { |
| 118 | + size_in_gb = 20 |
| 119 | + iops = 5000 |
| 120 | +} |
| 121 | +
|
| 122 | +resource scaleway_instance_server "server" { |
| 123 | + type = "PLAY2-PICO" |
| 124 | + root_volume { |
| 125 | + volume_id = scaleway_block_volume.root_volume.id |
| 126 | + } |
| 127 | +
|
| 128 | + additional_volume_ids = [scaleway_block_volume.volume.id] |
| 129 | +} |
| 130 | +``` |
0 commit comments