Kubernetes customers must not migrate their block volumes to the Block Storage API to prevent major disruptions to their Kubernetes service and block volume unavailability. You can identify your volumes by listing them and referring to the name
field, next to which you should see an output similar to k8s_base_node_2024-07-26
.
How to migrate existing volumes and snapshots to Scaleway's new Block Storage management
To enhance performance and reliability, Scaleway is transitioning the management of Block Storage volumes and snapshots from Compute to Storage.
To facilitate the transition to Scaleway’s new Block Storage management, two main approaches for migrating your volumes exist, each with its unique benefits and drawbacks:
-
Using the Instance API/CLI migration endpoint (Plan and Apply):
- Advantage: Migration can occur without service interruption, as the volume remains attached to the running Instance and fully accessible.
- Drawback: Only the volume’s representation is migrated to the SBS API; the data itself does not move. This means the migrated volume will not benefit from low latency or higher IOPS, as it retains the original
b_ssd
characteristics.
-
Using the snapshot export/import features:
- Advantage: The migrated volume will fully support low latency, and it is possible to modify the IOPS up to 15k. All existing data of the old volume will be copied to the new Block Storage Low Latency volume.
- Drawback: A snapshot must be manually created, exported, and imported. After importing, the snapshot must be converted into a volume, which must then be attached to the Instance. This process may require downtime.
Each method caters to different needs, balancing uninterrupted service against achieving maximum performance benefits. After migration, these resources will be managed under Storage instead of Compute.
Comparison of migration methods
Migration Method | Advantage | Drawback |
---|---|---|
Instance API/CLI migration | No service interruption, volume remains accessible | Data characteristics remain the same; no performance boost |
Snapshot export/import | Full support for low latency and customizable IOPS | Requires downtime; manual snapshot handling |
This guide offers step-by-step instructions to migrate your volumes and snapshots using either the Scaleway Command Line Interface (CLI) tool (recommended) or the Instances API. Alternatively, you can use the snapshot export/import feature to migrate your unified volumes and snapshots to Block Storage Low Latency volumes.
Before you start
To complete the actions presented below, you must have:
- A Scaleway account logged into the console
- An Instance using Block Storage volumes
- The easiest way to migrate your Block Storage volumes and snapshots is by using the Scaleway Command Line Interface (CLI) tool.
- If you encounter an error about quota limitations during the migration process, contact our support team for assistance.
To ensure continued access to managing your volumes, you must convert your unified volumes and snapshots into either local or Block volumes before the end-of-life date of June 2nd, 2025. After this date, unified volumes and snapshots will no longer be supported by any API.
Key migration deadlines:
- April 30th, 2025:
- Creation of new unified volumes via the Instance API will be disabled.
- Unified volumes will no longer be supported by the Instance API.
- June 2nd, 2025:
- Unified volumes and snapshots can no longer be managed via any API. Existing unified resources must be converted by this date to avoid loss of manageability.
Migrating using the Instance API/CLI migration endpoint (Plan and Apply):
During migration, unified snapshots will be converted into Block Storage snapshots and removed from Compute. If a unified snapshot is part of an image, it will be replaced by the corresponding Block Storage snapshot.
Migrating an existing Block Storage volume to Scaleway Block Storage management
This process applies only to Block SSD (b_ssd
) volumes.
When you migrate a volume, the volume and any snapshots created from it will be migrated as well.
- Use the following command to list your Block Storage volumes and retrieve the ID of the volume you wish to migrate:
$ scw instance volume listID STATE SERVER ID SERVER NAME369feb53-165f-437d-875e-188725df462b available
- Plan the volume migration using the
scw instance volume plan-migration <VOLUME_ID>
command. This command returns the volume and its snapshots that will be migrated, along with a uniqueValidationKey
required to start the migration.$ scw instance volume plan-migration 369feb53-165f-437d-875e-188725df462bVolume.ID 369feb53-165f-437d-875e-188725df462bVolume.Name vol-peaceful-davinciVolume.Size 25 GBVolume.VolumeType b_ssdVolume.CreationDate 2 weeks agoVolume.ModificationDate 2 weeks agoVolume.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Volume.Project 4a2e00bf-5126-43ce-9b09-be943c619139Volume.Server.ID 177c6ed5-e999-4cc7-b152-8ce56217579cVolume.Server.Name scw-naughty-robinsonVolume.State availableVolume.Zone fr-par-1Snapshots.0.ID a377afe5-a9a3-4706-b8c2-8d1c247a620fSnapshots.0.Name image-scw-quirky-torvalds_snap_0Snapshots.0.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.0.Project 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.0.VolumeType b_ssdSnapshots.0.Size 10 GBSnapshots.0.State availableSnapshots.0.CreationDate 2 weeks agoSnapshots.0.ModificationDate 5 days agoSnapshots.0.Zone fr-par-1Snapshots.1.ID 384799c2-c4dd-40ab-bd65-ed95cd7b4d5cSnapshots.1.Name snap-eloquent-edisonSnapshots.1.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.1.Project 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.1.VolumeType b_ssdSnapshots.1.Size 10 GBSnapshots.1.State availableSnapshots.1.CreationDate 2 weeks agoSnapshots.1.ModificationDate 5 days agoSnapshots.1.Zone fr-par-1ValidationKey 30d129ca895c4cd59f4c429e12dab300 - Execute the migration using the
scw instance volume apply-migration <VOLUME_ID> validation-key=<VALIDATION_KEY> zone=<VOLUME_ZONE>
command.$ scw instance volume apply-migration 369feb53-165f-437d-875e-188725df462b validation-key=30d129ca895c4cd59f4c429e12dab300 zone=fr-par-1✅ Success
The volume migration is complete. You can now manage the migrated volume from the Block Storage volumes section in the Scaleway console.
When you migrate a volume using the API, the volume and any snapshots created from the volume will be migrated.
- Plan the migration by sending a
POST
request to the Scaleway API:
curl --location "https://api.scaleway.com/instance/v1/zones/$SCW_AVAILABILITY_ZONE/block-migration/plan" \--header "Content-Type: application/json" \--header "X-Auth-Token: $SCW_SECRET_KEY" \--data "{\"volume_id\": \"$SCW_VOLUME_ID\"}"
This request returns the volume and its snapshots that will be migrated, along with a unique ValidationKey
required to start the migration.
- Confirm and execute the migration by sending another
POST
request:
curl --location "https://api.scaleway.com/instance/v1/zones/$SCW_AVAILABILITY_ZONE/block-migration/apply" \--header "Content-Type: application/json" \--header "X-Auth-Token: $SCW_SECRET_KEY" \--data "{\"volume_id\": \"$SCW_VOLUME_ID\",\"validation_key\": \"$SCW_VALIDATION_KEY\"}"
Migrating an existing Block Storage snapshot to Scaleway Block Storage management
This process applies to Block SSD (b_ssd
) or Unified (unified
) snapshots.
When you migrate a snapshot, the source volume of the snapshot and any snapshots created from this volume will also be migrated.
- Use the following command to list your snapshots and retrieve the ID of the snapshot you wish to migrate:
$ scw instance snapshot listID NAMEa377afe5-a9a3-4706-b8c2-8d1c247a620f snap-eloquent-edison
- Plan the snapshot migration using the
scw instance snapshot plan-migration <SNAPSHOT_ID>
command. This command returns the source volume of the snapshot and any related snapshots that will be migrated, along with a uniqueValidationKey
.$ scw instance snapshot plan-migration a377afe5-a9a3-4706-b8c2-8d1c247a620fVolume.ID 369feb53-165f-437d-875e-188725df462bVolume.Name vol-peaceful-davinciVolume.Size 25 GBVolume.VolumeType b_ssdVolume.CreationDate 2 weeks agoVolume.ModificationDate 2 weeks agoVolume.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Volume.Project 4a2e00bf-5126-43ce-9b09-be943c619139Volume.Server.ID 177c6ed5-e999-4cc7-b152-8ce56217579cVolume.Server.Name scw-naughty-robinsonVolume.State availableVolume.Zone fr-par-1Snapshots.0.ID a377afe5-a9a3-4706-b8c2-8d1c247a620fSnapshots.0.Name image-scw-quirky-torvalds_snap_0Snapshots.0.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.0.Project 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.0.VolumeType b_ssdSnapshots.0.Size 10 GBSnapshots.0.State availableSnapshots.0.CreationDate 2 weeks agoSnapshots.0.ModificationDate 5 days agoSnapshots.0.Zone fr-par-1Snapshots.1.ID 384799c2-c4dd-40ab-bd65-ed95cd7b4d5cSnapshots.1.Name snap-eloquent-edisonSnapshots.1.Organization 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.1.Project 4a2e00bf-5126-43ce-9b09-be943c619139Snapshots.1.VolumeType b_ssdSnapshots.1.Size 10 GBSnapshots.1.State availableSnapshots.1.CreationDate 2 weeks agoSnapshots.1.ModificationDate 5 days agoSnapshots.1.Zone fr-par-1ValidationKey 30d129ca895c4cd59f4c429e12dab300 - Execute the migration using the
scw instance snapshot apply-migration <SNAPSHOT_ID> validation-key=<VALIDATION_KEY> zone=<SNAPSHOT_ZONE>
command.$ scw instance snapshot apply-migration a377afe5-a9a3-4706-b8c2-8d1c247a620f validation-key=30d129ca895c4cd59f4c429e12dab300 zone=fr-par-1✅ Success.
The snapshot migration is complete. You can now manage the migrated snapshot from the Block Storage Snapshot section in the Scaleway console.
When you migrate a snapshot using the API, the source volume of the snapshot and any snapshots created from this volume will also be migrated.
- Plan the migration by sending a
POST
request to the Scaleway API:
curl --location "https://api.scaleway.com/instance/v1/zones/$SCW_AVAILABILITY_ZONE/block-migration/plan" \--header "Content-Type: application/json" \--header "X-Auth-Token: $SCW_SECRET_KEY" \--data "{\"snapshot_id\": \"$SCW_SNAPSHOT_ID\"}"
This request returns the source volume and any related snapshots that will be migrated, along with a unique ValidationKey
.
- Confirm and execute the migration by sending another
POST
request:
curl --location "https://api.scaleway.com/instance/v1/zones/$SCW_AVAILABILITY_ZONE/block-migration/apply" \--header "Content-Type: application/json" \--header "X-Auth-Token: $SCW_SECRET_KEY" \--data "{\"snapshot_id\": \"$SCW_SNAPSHOT_ID\",\"validation_key\": \"$SCW_VALIDATION_KEY\"}"
Migrating using the snapshot export/import features
To convert your unified volumes and snapshots, you can use the snapshot export/import features as an alternative solution for transitioning a Block Storage legacy volume into a Block Storage Low Latency volume.
The process below requires manual intervention and does not preserve the original volume’s ID. While this approach allows you to transition to a Block Storage Low Latency volume, it is only a workaround.
Follow the procedure below:
- Create a snapshot of your Block Storage legacy volume.
- Export the snapshot.
- Import the snapshot into a new Low Latency volume.
Going further
To learn more about managing your migrated Block Storage volumes and snapshots from the Scaleway console, refer to the Block Storage Quickstart Guide. Additionally, you can explore advanced features using the Scaleway Block Storage API.
If you encounter any issues during migration, contact Scaleway’s support team for assistance.