About Block Storage for VPC snapshots

Single volume snapshots

A snapshot is a copy of your volume that you take manually in the UI or from the CLI, or create programmatically with the API, or Terraform. You can take a snapshot of a boot or data volume that is attached to a running virtual server instance. A "bootable" snapshot is a snapshot of a boot volume. A "nonbootable" snapshot is of a data volume. You can take snapshots as often as you want. However, you can't take a snapshot of a volume that's in a degraded state.

Do you want to automatically create snapshots of your Block Storage for VPC volumes? With Backup for VPC, you can create backup policies to schedule regular volume backups. For more information, see About Backup for VPC.

The first time that you take a snapshot of a volume, all the volume's contents are copied. The snapshot has the same encryption as the volume (customer-managed or provider-managed). Snapshots are stored and retrieved from IBM Cloud® Object Storage. Data is encrypted while in transit and stored in the same region as the original volume.

When you take a second snapshot, it captures only the changes that occurred since the last snapshot was taken. As such, the size of the snapshots can grow or shrink, depending on what is being uploaded to IBM Cloud® Object Storage. The number of snapshots increases with each successive snapshot that you take. You can take up to 750 snapshots per volume in your region. Within this limit, you can take and keep an hourly snapshot for 30 days, plus some extra snapshots. Deleting snapshots from this quota frees up space for more snapshots. A snapshot of a volume can't be greater than 10 TB.

You can create a virtual server instance with a boot volume that was initialized from a snapshot. The instance profile of the new instance is not required to match the instance that was used to create the snapshot. You can also import a snapshot of a data volume when you create and attach a new data volume to the instance. You can specify user tags for these snapshots.

You can create a volume from a snapshot at any time. This process is called restoring a volume, and it can be performed when you create an instance, modify an instance, or when you create a stand-alone volume. For more information, see Restoring a volume from a snapshot. You can also restore a fully provisioned volume by using the fast restore feature after initial provisioning.

Snapshots have a lifecycle that is independent from the source Block Storage for VPC volume. You can delete the original volume and the snapshot persists. However, do not detach the volume from the instance during snapshot creation. You need to wait until the snapshot becomes stable before you detach, otherwise you can't reattach the volume to an instance. Snapshots are crash-consistent. If the virtual server stops for any reason, the snapshot data is safe on the disk.

The cost for snapshots is calculated based on GB capacity that is stored per month, unless the duration is less than one month. Because the snapshot is based on the capacity that was provisioned for the original volume, the snapshot capacity does not vary.

With IBM Cloud® Identity and Access Management, you can set up resource groups in your account to provide user-access to your snapshots. Your IAM role determines whether you can create and manage snapshots. For more information, see IAM roles for creating and managing snapshots.

You can share a snapshot with another account and allow the other account to create volumes with that snapshot. To do so, set up cross-account authorization with the Snapshot Remote Account Restorer role, and share the CRN of the snapshot with the other account. The other account's user with Snapshot Remote Account Restorer role can use the CRN to create a volume in the console, from the CLI, with the API, or Terraform.

Before you take a snapshot, make sure that all cached data is present on disk, especially when you're taking snapshots of instances with Windows and Linux® operating systems. For example, on Linux operating systems, run the sync command to force an immediate write of all cached data to disk.

For customers with special access, data isolation is provided to store snapshots that you created from your dedicated hosts. With data isolation's extra security, your data is encrypted at rest with a unique key and access to your data is protected by a private firewall.

Fast restore snapshot clones

By using the snapshots fast restore feature, you create and keep a clone of the data in a zone within your VPC region. In other words, your data is fully available when the volume is created because it is already in the VPC region and not in Object Storage. In contrast, when data is not restored from a fast restore snapshot clone, volume data is copied from Object Storage when the volume is attached to an instance over time. The fast restore feature can achieve a recovery time objectiveThe maximum duration of time within which an application should be restored after any type of disaster. (RTO) quicker than restoring from a regular snapshot.

The fast restore feature can be enabled in the UI, from the CLI, with the API, or Terraform. In the CLI, API, and Terraform, the responses show clones. The UI shows fast restore snapshot clones as fast restore snapshots, but they are the same thing.

Billing for the fast restore feature is set at a flat rate based on instance hours. The feature is billed at an extra hourly rate for each zone that it is enabled in regardless of the size of the snapshot. Maintaining fast restore clones is considerably more costly than keeping regular snapshots.

For more information, see Restoring a volume with the fast restore feature.

Cross-regional snapshot copies

You can copy a snapshot from one region to another region, and later use that snapshot to restore a volume in the new region. This feature can be used in disaster recovery scenarios when you need to start your virtual server instance and data volumes in a different region. Or you can use the remote copy to create storage volumes in a new region to expand your VPC.

When you choose to create a cross-regional copy of a snapshot, you need to specify a single snapshot to be copied to the target region. The snapshot is created as normal, and stored in your regional Object Storage. When the snapshot is stable, a copy of the snapshot is created in the Object Storage bucket in the target region.

If the source snapshot is not encrypted with a customer key, the encryption of the copy remains provider-managed. If the source snapshot is protected by a customer-managed key, you must specify the customer-managed key that you want to use to encrypt the new copy.

Only one copy of the snapshot can exist in each region. You can't create a copy in the local (source) region.

The first time that you create a cross-regional copy, the snapshot is a full copy of the parent volume's data. Subsequent snapshots of the same volume contain only the changes that occurred since the previous snapshot was taken. The only exception to this rule is when you change the encryption type or the encryption key of the parent snapshot. When you change the encryption, the new remote copy needs to be a full copy of the parent snapshot, not an incremental copy.

You can use and manage the cross-regional snapshot in the target region independently from the parent volume or the original snapshot.

Creating a cross-regional copy affects billing. You're charged for the data transfer and the storage consumption in the target region separately.

When you create a snapshot or list details of a snapshot in the console, from the CLI or with the API, the system lists only the direct copies of the snapshot that you specified. If you create a copy of a copy, the second copy is not returned when you query the original snapshot.

Snapshot consistency groups

A snapshot consistency group contains snapshots of multiple Block Storage volumes that are attached to the same virtual server instance. You can include or exclude boot volumes. Instance storage is not included.

When you request a snapshot of a consistency group, the system ensures that all write operations are complete before it takes the snapshots. Then, the system generates snapshots of all the tagged Block Storage volumes that are attached to the virtual server instance at the same time. Depending on the number and size of the attached volumes, plus the amount of data that is to be captured, you might observe a slight IO pause. This IO pause can range from a few milliseconds up to 4 seconds.

The consistency group must have a unique name that can't exceed 64 characters. If you do not provide one, the system auto-generates a name for you. The snapshots in the consistency group are named by using the first 16 characters of the group name and 3-4 auto-generated characters, so their names are unique, too. Later, you can rename the member snapshots if you want to.

The snapshot consistency group has its own lifecycle, and it keeps references to the member snapshots. So if a member snapshot is deleted or renamed, the consistency group is also updated.

The snapshots in the group are loosely coupled. You can manage the snapshots within a consistency group the same way you manage any other snapshot. You can delete individual snapshots from the consistency group if you want to. You can keep individual snapshots after you decide to delete the consistency group.

You can use the members of the snapshot consistency group to restore volumes separately. Restoring an instance directly from snapshot consistency group identifier is not supported. You can create cross-regional copies of the members of the snapshot set separately, but you can't create a copy of a consistency group in another zone or region.

User tags for snapshots

User tags are uniquely identified by a Cloud Resource Name (CRN) identifier. When you create a user tag, you provide a unique name within your billing account. You can define user tags in label or key-value format. You can create user tags or add existing tags to snapshots.

You can create, view, and manage user tags with the UICLIAPITerraform, and remove them at any time.

Access management tags for Block Storage for VPC snapshots

You can use access management tags to organize access control by creating flexible resource groupings, enabling your storage resources to grow without requiring updates to Cloud Identity and Access Management (IAM) policies. You can create access management tags in IAM or with the Global Search and Tagging API, and then add them to new or existing snapshots.

For more information about managing tags for your account, see Working with tags.