| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2024-11-05 |
Block Storage, snapshots, cross-regional copy, fast restore, backup, restore volume |
vpc |
{{site.data.keyword.attribute-definition-list}}
{: #snapshots-vpc-faqs}
The following questions often arise about the {{site.data.keyword.block_storage_is_short}} snapshots offering. If you have other questions you'd like to see answered here, provide feedback by using the Open doc issue or Edit topic links at the end of the topic. {: shortdesc}
{: faq} {: #faq-snapshot-1}
Snapshots are a point-in-time copy of your {{site.data.keyword.block_storage_is_short}} boot or data volume that you manually create. To create a snapshot, the original volume must be attached to a running virtual server instance. The first snapshot is a full backup of the volume. Subsequent snapshots of the same volume record only the changes since the last snapshot. You can access a snapshot of a boot volume and use it to provision a new boot volume. You can create a data volume from a snapshot (called restoring a volume) and attach it to an instance. Snapshots are persistent; they have a lifecycle that is independent from the original volume.
{: faq} {: #faq-backup-snapshot}
Backup snapshots, also called backups, are scheduled snapshots that are created by using the Backup for VPC service. For more information, see Backup for VPC.
{: faq} {: #faq-snapshot-2}
A bootable snapshot is a copy of a boot volume. You can use this snapshot to create another boot volume when you provision a new instance.
{: faq} {: #faq-snapshot-fr}
A fast restore snapshot is a clone of a snapshot that is stored within one or more zones of a VPC region. The original snapshot is stored in {{site.data.keyword.cos_full_notm}}. When you perform a restore, data can be restored faster from a clone than from the snapshot in {{site.data.keyword.cos_short}}.
{: faq} {: #faq-snapshot-3}
You can take up to 750 snapshots per volume in a region. Deleting snapshots from this quota makes space for more snapshots. A snapshot of a volume cannot be greater than 10 TB. Also, consider how your billing is affected when you increase the number of snapshots that you take and retain.
{: faq} {: #faq-snapshot-4}
The maximum size of a volume is 10 TB. Snapshot creation fails if the volume is over that limit.
{: faq} {: #faq-snapshot-5}
Snapshots are stored and retrieved from {{site.data.keyword.cos_full_notm}}. Data is encrypted while in transit and stored in the same region as the original volume.
Snapshots retain the encryption from the original volume, IBM-managed or customer-managed.
{: faq} {: #faq-snapshot-6}
Restoring a volume from a snapshot creates an entirely new boot or data volume. The new volume has the same properties of the original volume, including encryption. If you restore from a bootable snapshot, you create a boot volume. Similarly, you can create a data volume from a snapshot of a data volume. The volume that you create from the snapshot uses the same volume profile and contains the same data and metadata as the original volume. You can restore a volume when you provision an instance, update an existing instance, or create a stand-alone volume by using the UI, CLI, or the volumes API. For more information, see Restoring a volume from a snapshot.
For best performance, you can enable snapshots for fast restore. By using the fast restore feature, you can create a volume from a snapshot that is fully provisioned when the volume is created. For more information, see Snapshots fast restore.
{: faq} {: #faq-snapshot-performance}
Performance of boot and data volumes is initially degraded when data is restored from a snapshot. Performance degradation occurs during the restoration because your data is copied from {{site.data.keyword.cos_full}} to {{site.data.keyword.block_storage_is_short}} in the background. After the restoration process is complete, you can realize full IOPS on the new volume.
Volumes that are restored from fast restore clones do not require hydration. The data is available as soon as the volume is created.
{: faq} {: #faq-snapshot-7}
Deleting a volume from which you created a snapshot has no effect on the snapshot. Snapshots exist independently of the original source volume and have their own lifecycle. To delete a volume, all snapshots must be in a stable state.
{: faq} {: #faq-snapshot-8}
Yes, you can use Backup for VPC to create a backup policy and plan. In the plan, you can schedule daily, weekly, or monthly backup snapshots, or more frequent backups with a cron-spec expression. For more information about scheduling backup snapshots and how it works, see the Backup for VPC overview.
{: faq} {: #faq-snapshot-9}
Snapshots have their own lifecycle, independent of the {{site.data.keyword.block_storage_is_short}} volume. You can separately manage the source volume. However, when you take a snapshot, you must wait for the snapshot creation process to complete before you detach or delete the volume.
{: faq} {: #faq-snapshot-pricing}
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 space is based on the capacity that was provisioned for the original volume, the snapshot capacity does not vary. Deleting snapshots reduces cost, so keep fewer snapshots to keep the cost down. For more information about billing and usage, see How you're charged.
Creating consistency group snapshots does not incur extra charges other than the cost associated with the size of the member snapshots.
Pricing for snapshots is also set by region. When you use the fast restore feature, your existing regional plan is adjusted. Billing for fast restore is based on instance hours. So the fast restore 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.
{: faq} {: #faq-snapshot-tags}
Depending on the action that you're performing, you can add user tags and access management tags to your snapshots. User tags are used by the backup service to periodically create backup snapshots of the volume. Access management tags help organize access to your {{site.data.keyword.block_storage_is_short}} snapshots. For more information, see Tags for {{site.data.keyword.block_storage_is_short}} snapshots.
{: faq} {: #faq-snapshot-dr}
You can use your snapshots and backups to create volumes when an emergency occurs. You can also create copies of your snapshot in other regions and use them to create volumes there. However, the snapshot and backup services do not provide continual backup with automatic failover. Restoring a volume from a backup or snapshot is a manual operation that takes time. If you require a higher level of service for automatic disaster recovery, see IBM's Cloud disaster recovery solutions.
{: faq} {: #faq-snapshot-cross-regional-limits}
You can copy a snapshot from one region to another region, and later use that snapshot to restore a volume in the new region. Only one copy of the snapshot can exist in each region. You can't create a copy of the snapshot in the source (local) region.
{: faq} {: #faq-snapshot-consistency-group-snap}
A consistency group is a collection of snapshots that are managed as a single unit. It is used to create snapshots of multiple volumes that are attached to the same virtual server instance at the same time to preserve data consistency.
The snapshots are loosely coupled. The snapshots can be used to create new volumes. They can be copied to another region individually, and can be preserved after the consistency group is deleted. However, you can't copy a consistency group to another region or use the ID of the consistency group to create a virtual server instance.
For more information, see Snapshot consistency groups.