How to back up a Scaleway Instance

Local or Block Storage: check yours first

An Instance's volumes are either Local Storage, on SSDs in the hypervisor that runs it, or Block Storage, attached over the network. Scaleway's docs list Local or Block for the Development range (DEV1 and GP1) and Block only for the rest, including PLAY2, PRO2, POP2, BASIC2-A, STANDARD3-X and BASIC3-X. The Instance's Storage tab shows what you have.

A snapshot restores only to a volume of its original type.

Snapshots and images

A snapshot is a point-in-time copy of one volume. An image bundles one snapshot per volume so a new Instance can start from it; creating the image is free, its snapshots are billed. Scaleway's docs say a snapshot "is not deleted when its source volume, Instance, or image is deleted", and deleting an image leaves its snapshots behind. Delete them separately, or they keep costing money.

Snapshots can be taken while the Instance runs; Scaleway suggests pausing heavy writes. Like any disk snapshot, the result is crash-consistent: databases recover as after a power cut, so keep dumps too. Scaleway documents no built-in snapshot schedule for Instances. Its own tutorial runs scw block snapshot create from a Serverless Job on a cron schedule, and nothing deletes old snapshots for you.

Create an image of the whole Instance

In the console: Compute > CPU & GPU Instances, pick the zone, open the Instance and, in its Images section, click Create image from Instance. From the CLI (install it as its GitHub README describes, then run scw init once with an API key):

scw instance server backup <server-id> zone=fr-par-1 name=web1-before-upgrade

It snapshots every attached volume and builds an image from them; without name, the name combines the server's name and the date. Wait until it is ready, then see which snapshots it holds, under root_volume and extra_volumes:

scw instance image wait <image-id> zone=fr-par-1

scw instance image get <image-id> zone=fr-par-1

Snapshot one volume

To snapshot only the data volume, or treat volumes differently, list the Instance's Block Storage volumes and snapshot one:

scw block volume list product-resource-id=<server-id> zone=fr-par-1

scw block snapshot create volume-id=<volume-id> name=data-2026-10-04 zone=fr-par-1

scw block snapshot wait <snapshot-id> terminal-status=available zone=fr-par-1

To make a bootable image from snapshots, give the root snapshot and the architecture (x86_64, or arm64 for Arm Instances such as BASIC2-A):

scw instance image create snapshot-id=<root-snapshot-id> additional-volumes.0.id=<data-snapshot-id> arch=x86_64 name=web1-2026-10-04 zone=fr-par-1

Restore from an image or a snapshot

Scaleway restores by creating something new, not by overwriting. To bring back the whole server, create an Instance from the image: choose it under My images at the Choose an image step of the creation wizard, or:

scw instance server create type=PLAY2-NANO image=<image-id> name=web1-restored zone=fr-par-1

Then move the old Instance's flexible IP to it, so DNS keeps working. Scaleway notes that attaching a flexible IP removes the Instance's previous public IP and interrupts open connections:

scw instance ip attach <flexible-ip> server-id=<new-server-id> zone=fr-par-1

To get files back without replacing the server, create a volume from the snapshot and attach it to the running Instance. The IOPS you pick (5000 or 15000) cannot be changed later:

scw block volume create name=data-restored perf-iops=5000 from-snapshot.snapshot-id=<snapshot-id> zone=fr-par-1

scw instance server attach-volume server-id=<server-id> volume-id=<new-volume-id> volume-type=sbs_volume zone=fr-par-1

On the Instance, find the new disk with lsblk -f, mount it read-only with mount -o ro, and copy what you need.

Export a snapshot as a QCOW2 file

A Block Storage snapshot can be written to a Scaleway Object Storage bucket as a QCOW2 disk image, which can then leave Scaleway like any other file. The bucket must be in the snapshot's region and not use SSE-KMS, and the snapshot must be between 1 GB and 1 TB:

scw block snapshot export-to-object-storage snapshot-id=<snapshot-id> bucket=my-exports key=web1-2026-10-04.qcow2 zone=fr-par-1

Then copy it to a bucket at another company with rclone, with remotes set up as in Scaleway Object Storage and copying a bucket between providers. The data passes through the machine running rclone:

rclone copyto scaleway:my-exports/web1-2026-10-04.qcow2 offsite:my-backups/scaleway/web1-2026-10-04.qcow2

Imported back (in Object Storage, the file's menu, Import as snapshot), a QCOW2 file can start an Instance in any zone of its region. A whole-disk image is a good monthly or pre-migration copy, but too large to send every night.

What snapshots cost

Scaleway bills storage by the hour from creation to deletion, whether the Instance is running or not. Its public product catalog lists these prices for fr-par-1 as of October 2026 (its pricing pages refused automated requests):

Worked example: 40 GB snapshots taken every night and kept 7 days mean 280 GB held at any time, about €10 a month (280 × 0.000049 × 730). Snapshots nobody deletes keep adding to that.

Why snapshots on Scaleway are not enough

Scaleway's shared responsibility model leaves backups to you, to set up and to trigger, and says a snapshot "does not in any way constitute a permanent backup of your data".

• Local Storage can go with its hypervisor. Scaleway warns that after a disk or hardware failure on the hypervisor you may not regain access to the virtual machine or its Local Storage data, and that "Scaleway cannot be held responsible for the loss of your data".
• One account. Snapshots, images and exported QCOW2 files sit in the same Scaleway Organization as the Instance. A lost login, an unpaid invoice or a leaked API key reaches them all.
• One zone, one region. Snapshots and images live in the Instance's Availability Zone, and exports go to a bucket in the same region.
• No schedule, no retention. Anything automatic is a job you build, prune and watch.

The 3-2-1 rule asks for one copy off-site: here, storage at another company.

Add a copy outside Scaleway

Back up the data, not the disk: /etc, site and app files, crontabs and each database as a dump; the server backup checklist has the full list. Set up restic (0.17 or newer) as in the restic guide, with a root-only /etc/restic/env and password file and the repository in a bucket at another company, for example Amazon S3 in Frankfurt, then run restic init once:

RESTIC_REPOSITORY=s3:s3.eu-central-1.amazonaws.com/my-backups/scw-web1
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_CACHE_DIR=/var/cache/restic
AWS_ACCESS_KEY_ID=your-access-key-id
AWS_SECRET_ACCESS_KEY=your-secret-access-key

#!/usr/bin/env bash
# Nightly backup of a Scaleway Instance to a bucket at another provider.
set -euo pipefail
set -a; . /etc/restic/env; set +a

# 1. The database, streamed into restic. A failed dump creates no snapshot.
restic backup --tag db --stdin-filename app.sql --stdin-from-command -- mysqldump --single-transaction --routines --events app

# 2. Files. --one-file-system stays on the filesystem of each directory listed.
restic backup --tag files --one-file-system --exclude-caches /etc /var/www /home /root /var/spool/cron

# 3. Keep 7 daily, 4 weekly and 6 monthly snapshots of each; delete the rest.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

• --stdin-from-command stores the dump as /app.sql without writing it to disk; if mysqldump exits non-zero, restic creates no snapshot. Credentials go in root's option file, as in the mysqldump guide. For PostgreSQL, put sudo -u postgres pg_dump app after the --.
• If the data lives on an extra Block Storage volume, add its mount point to the file list.

sudo chmod 700 /usr/local/bin/offsite-backup.sh

30 2 * * * root /usr/local/bin/offsite-backup.sh >> /var/log/offsite-backup.log 2>&1

Or pull instead of push: a server at another provider copies the data over SSH with rsync and a dedicated SSH key, so the Instance holds no keys to your backup storage. Keep the restic password and bucket keys in a password manager too.

Restore onto a new server, and test it

Create a server with the same OS release, at Scaleway or anywhere else, install restic and put back /etc/restic/env and the password file. In a root shell with the file loaded (set -a; . /etc/restic/env; set +a):

restic restore latest --tag files --target /srv/restore

mysql -e 'CREATE DATABASE app'

restic dump --path /app.sql latest app.sql | mysql app

A single-database dump holds no users or grants, so recreate the app's user with CREATE USER and GRANT. Copy directories such as /etc/nginx from /srv/restore/etc, never all of /etc. Restoring a server from backup has the full sequence.

• Read the restic log for a week, then add an alert as in backup failure alerts.
• Once a month, start an Instance from your newest image and restore the restic copy to a throwaway server, open the site and time it, as in testing a restore. Instances bill by the hour, so the test costs little; delete the test Instance, its volumes and any snapshots afterwards.

Frequently asked questions

Does Scaleway back up Instances automatically?

No. Snapshots and images are taken when you ask. Scaleway's tutorial schedules snapshots with a Serverless Job running the CLI; old snapshots are not deleted for you.

What is the difference between a Scaleway snapshot and an image?

A snapshot copies one volume. An image holds a snapshot of every volume of an Instance and can start new Instances. Creating the image is free; its snapshots are billed.

Does scw instance snapshot create still work?

Scaleway's CLI guide says it is deprecated and no longer functions, because snapshots moved to the Block Storage API. Use scw block snapshot create with the volume's ID instead.

How much do Scaleway snapshots cost?

€0.000049 per GB per hour in fr-par-1 as of October 2026, about €0.036 per GB over a 730-hour month, billed until you delete the snapshot.

Can I download a Scaleway snapshot?

Yes, indirectly: export a Block Storage snapshot as a QCOW2 file to an Object Storage bucket in the same region, then download or copy that file. Snapshots must be 1 GB to 1 TB.