Cloudscale Logo

News

Back
2025
October
16
2025

Create New Volumes From Snapshots

Volume snapshots provide you with the option of, for example, reversing a failed server upgrade as if it never happened. You can now not only use a snapshot to revert the corresponding original volume to an earlier state, but you can also use it as a basis for creating a new volume. This means that volume snapshots can support you in various new areas of application and, under certain circumstances, save you a great deal of time.

Use snapshots flexibly

Create a snapshot of a volume in a matter of seconds, for example before a major upgrade or any other change to your server. If something goes wrong, you can just as quickly revert the server to the snapshot and thus to a previous, functional state. However, what if you simply want to check the content of a snapshot or only require a single file from it, e.g. the previous version of an important config?

A recent development is that you can also create new volumes from your volume snapshots where the new volume then contains the exact data that were "frozen" in the snapshot. In the above example, you could then attach the new volume to the corresponding server and mount it, which would enable you to access the required config file specifically.

It goes without saying that updates and their potential pitfalls are not the only use case for this new feature. An obvious example is, for instance, a 1:1 copy of a root volume. Previously you would have started your server from a live system and then copied the volume block by block, e.g. with dd. Now you can simply create a snapshot and then turn it into a separate new volume. This allows you to subsequently continue working flexibly, for example by downloading the content of the volume to a local archive. Or you can use it to create an image file for a custom image in "raw" format (however, direct use as a root volume for a new server is not possible at the moment).

Use via an existing API endpoint

To create a new volume from a snapshot, use the same API endpoint that was previously used to create a volume. Specify the volume_snapshot_uuid as a parameter in order to identify the desired snapshot as the basis for the new volume. In addition, the API will accept a name and, as an option, tags for the new volume; the other properties (such as size or cloud location) are based on the indicated snapshot.

The API request could look like this, for example:

curl -i -H "Authorization: Bearer YourApiTokenGoesHere" \
  -F name="my-volume-name" \
  -F volume_snapshot_uuid="351d461c-2333-455f-b788-db11bf0b4aa2" \
  https://api.cloudscale.ch/v1/volumes

As always, you will find all the required details in the extended section "Create a Volume" in our API documentation.

Please note that the snapshots are crash-consistent, also when creating volumes from them. This means that they contain an image of the original volume at exactly the point in time when the snapshot was created, as if the server had crashed at this moment. Depending on the specific circumstances, it may make sense to stop tricky services before creating a snapshot or to shut down the server completely in order to ensure that e.g. write caches are also contained in the volume and thus in the snapshot. When preparing a custom image, please also consider including "cloud-init" and keeping it as small as possible. You will only add any required free space when you create a new server with the image.

Points to note

Be aware that not just snapshots, but also volumes created from them are not a backup. They are not only in the same storage cluster as the original volume and will potentially also be affected in the case of technical issues, but we also use "Copy-On-Write" (COW) for rapid and efficient provision of snapshots and volumes, which means that different volumes and snapshots may depend on the same, shared data fragments. For solid backup, use snapshots and the volumes based on them as an interim step and then copy the data to a separate location, such as an archive that is maintained locally to you.

The COW mechanism that is used in the background does not, however, cause any limitations for handling your volumes and snapshots. Even if you have used a snapshot as the basis for a new volume, you can later delete the snapshot – or even the original volume as a whole – without this affecting the new volume.


Snapshots as the basis of a new volume will also support you when you do not need to revert a whole server. Maintain the content of your root volumes, for example, when you delete virtual servers, create a consistent 1:1 copy as a basis for a download or a custom image, or access previous data versions while leaving everything else in the new state. Simply start with a snapshot and keep all options open for yourself.

For moments that need to be saved,
Your cloudscale team

Back to overview