| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2024-10-24 |
Backup, backup service, backup plan, backup policy, restore, restore volume, restore data |
vpc |
{{site.data.keyword.attribute-definition-list}}
{: #backup-service-about}
Use {{site.data.keyword.cloud}} Backup for VPC to automatically create backups and manually restore {{site.data.keyword.block_storage_is_short}} volumes from backup snapshots. By using this service, you can prevent data loss, manage risk, and improve data compliance. You can ensure that your data is backed up regularly, and you can retain the backups while you need them. You can create and manage backup policies and plans in the console, from the CLI, with the API, or Terraform. {: shortdesc}
Backups and snapshot services are different than a disaster recovery (DR){: term} solution, where your data is continually backed up with automatic failover. Restoring a volume from a backup or a snapshot is a manual operation that takes time. If you require a higher level of service for disaster recovery, see IBM's Cloud disaster recovery solutions. {: important}
{: #backup-service-concepts}
You can create up to 10 backup policies in one region with the {{site.data.keyword.cloud_notm}} Backup for VPC service. You can create up to four plans per policy, and edit and delete them as needed. If you're undecided on the backup schedule or retention requirements, you can create a backup policy without a plan and add one later.
You can choose to back up individual {{site.data.keyword.block_storage_is_short}} volumes that are identified by tags. Or you can choose to create backups of all the {{site.data.keyword.block_storage_is_short}} volumes that are attached to a specific virtual server instance as members of a consistency group. When you configure backups for a consistency group, you can choose to include the boot volume or leave it out. When you create multi-volume backups, you add the tag to the virtual server instance.
When you request a backup 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 selected 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. It is recommended to run your automated backup-policy during off-peak hours to minimize any impact on performance.
An individual volume is backed up when a user-provided tag that is associated with a volume matches the tags for target resources in a backup policy. When you choose to back up all the Block Storage volumes that are attached to a virtual server instance, the user-provided tag is associated with the virtual server instance. When the scheduled backup is triggered by a backup plan, all resources with matching tags are backed up.
Backups require that the volume that you're backing up is attached to a running virtual server instance. Put another way, you can't back up an unattached volume. {: restriction}
If a volume has multiple tags, only one tag needs to match for a backup to trigger. You can add user tags to boot and data volumes at any time, when you create a virtual server instance or when you update the volume.
You must set a retention period for your backups. It can be based on the number of days that you want to keep the backups. Or it can be based on the total number of backups that you want to retain before the oldest ones are deleted. Or you can set it up by specifying both the time limit and the maximum number of backups that you want to keep. Planning for the retention and deletion of your backups can keep the costs down.
When the backup is triggered at the scheduled interval, a backup copy is created of your volume by the Snapshot for VPC service. When the first backup snapshot is taken, the entire contents of the volume are copied and retained in {{site.data.keyword.cos_full}}. Subsequent backups of the same volume capture the changes that occurred since the previous backup. You can take up to 750 backups of a volume.
Backup jobs that create or delete backup snapshots run according to the backup plan and the retention policy. You can view the status of the backup jobs in the console, from the CLI, with the API, or Terraform. If a job fails, the health status code shows the reason for the failure. You can also set up a connection to {{site.data.keyword.en_short}} and receive notifications to your preferred destinations.
Block storage backups, like block storage snapshots, have a lifecycle that is independent from the source {{site.data.keyword.block_storage_is_short}} volume.
You can copy a Block storage backup snapshot from one region to another region, and later use that snapshot to restore a volume in the new region. The cross-regional copy can be used in disaster recovery scenarios when you need to turn on your virtual server instance and data volumes in a different region. The remote copy can be created automatically as part of a backup plan, or manually later.
You can restore data from a backup snapshot to a new, fully provisioned volume. If the backup is of a boot volume, you can use it to provision a new instance. However, when you provision an instance by restoring a boot volume from a bootable backup snapshot, you can expect degraded performance in the beginning. During the restoration process, the data is copied from {{site.data.keyword.cos_full}} to {{site.data.keyword.block_storage_is_short}}, and thus the provisioned IOPS cannot be fully realized until that process finishes.
With the fast restore feature, you can cache snapshots in a specified zone of your choosing. This way, volumes can be restored from snapshots nearly immediately and the new volumes operate with full IOPS instantly. The fast restore feature can achieve a recovery time objective{: term} (RTO) quicker than restoring from a regular backup snapshot. When you opt for fast restore, your existing regional plan is adjusted, including billing. 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. The fast restore feature is supported only for individual volume backups, not for consistency group backups.
As an enterprise account administrator, you can view and manage the backup policies and plans for the subaccounts for compliance reporting and billing from one place. For more information, see the Scope of backup policy section.
{: #baas-comparison}
Backups are in effect, backup snapshots. In the console, backups appear in the list of {{site.data.keyword.block_storage_is_short}} snapshots. Backups are identified by how they were created, in this case, by backup policy. These terms are used interchangeably in the documentation, depending on the context.
The snapshots service is used to create backups, similarities and differences exist between backups and snapshots. Table 1 compares backups to snapshots.
| Feature | Account-level backup | Enterprise-level backup | Snapshot |
|---|---|---|---|
| Backs up {{site.data.keyword.block_storage_is_short}} boot and data volumes. |  |
|
|
| Manually restore a volume from a snapshot. | |
|
|
| Back up data by a schedule. | |
|
|
| Back up data immediately. | |
||
| Data is copied at a specific point in time. | |
|
|
| Set a retention period for automatic deletion. | |
|
|
| Take up to 750 snapshots per volume. | |
|
|
| Fast restore clone | |
|
|
| Cross-regional copy | |
|
|
| Multi-volume consistency groups | |
|
|
| Costs are based on GBs per month. | |
|
|
| {: caption="Comparison of backups and snapshots" caption-side="bottom"} |
{: #backup-service-benefits}
The {{site.data.keyword.cloud_notm}} Backup for VPC offers you the following benefits.
-
Prevent data loss - Protect your critical data by scheduling regular backups. Establish a data restoration plan to quickly restore your compromised volumes. Reduce technical and financial impacts from unplanned outages.
-
Protect against small-scale failures - Restore boot volume from a bootable snapshot if a host failure or malicious attack occurs.
-
Improve compliance - You can prevent issues that are related to compliance and regulatory requirements by ensuring that backups are in place and data can be restored easily.
-
Save costs - A backup policy retention plan means that backups are regularly deleted, reducing costs by not storing more data than needed.
-
Ease of management - IBM's backup service is easier to manage than a third-party backup service because it is fully integrated with your VPC resources.
{: #backup-service-policies}
A backup policy identifies the target resource types and lists the tags that are used to identify the resources to be backed up. The policy contains one or more backup plans that define schedules for automatic backup creation and data retention.
In a backup plan, you schedule the frequency of your backups. In the UI, you can choose daily, weekly, or monthly. Or you can use a cron expression to specify the frequency.
{: ui}
In a backup plan, you schedule the frequency of your backups. When you create a plan from the CLI, you can use a cron expression to specify the frequency.
{: cli}
In a backup plan, you schedule the frequency of your backups. When you create a plan with the API, you can use a cron expression to specify the frequency.
{: api}
In a backup plan, you schedule the frequency of your backups. When you create a plan with Terraform, you can use a cron expression to specify the frequency.
{: terraform}
You can specify the retention period or the total number of backups before the oldest is deleted. The interval for creating a backup and its retention period can be the same or they can be different. The default retention period is 30 days. You can also set the total number of backups to retain up to 750 per volume. When that number is exceeded, the oldest backups are deleted.
If you specify both the age and the number of backups, age takes priority in determining when to delete a snapshot. The count applies only if the oldest snapshot is within the age range.
Consider the following examples:
- Example 1 - You create a daily plan with a retention period of 14 days, and no maximum number of snapshots to keep. You're going to keep 14 backups and the oldest is going to be 2 weeks old.
- Example 2 - You create a weekly plan that has the retention period of 365 days, and the maximum count of 8. In practice, you're going to get a maximum of 8 snapshots in the chain, with the oldest being 8 weeks old.
- Example 2 - You create a monthly plan and set the retention period for 80 days with a maximum count of 10. In practice, you keep a maximum of 3 snapshots always. By the time when your 4th backup is taken, the first one meets the 80-day mark, and gets deleted.
You can create up to four plans per backup policy and modify the backup schedule and retention policy anytime. Your four plans can have different frequencies. For example, one can be daily. Another one can be weekly, or monthly. All plans apply to the volumes with tags that match the backup policy. Backups that are created by the backup plan inherit the parent volume resource group details.
You can view backup job status while backups are being created, modified, or deleted.
{: #backup-service-about-scope}
As an enterprise account administrator, you can manage backup plans and policies collectively across the child accounts under the enterprise account. Enterprise account users can see all the backup policies that were created by the Enterprise account. The Enterprise account user can see all the backup jobs that are initiated by the enterprise backup policy, even if the jobs run in the child accounts.
Users within each account in the enterprise can create, use, and collaborate on resources just as you can in a stand-alone account. For more information, see Working with resources in an enterprise.
While the Enterprise administrator sees the references of all the backup snapshots that are created by their policy, the child accounts see only the backups that are created in their account.
The users of the child account can see the backup snapshots that are created in their accounts by the enterprise-level policy. They can identify these backups by the CRN of the enterprise-level backup policy that created the backups. However, they have no visibility to the enterprise-level backup policy itself. Users of the child account can use the backups to create other volumes.
Authorized users in the child accounts can also create account-specific backup policies in their accounts.
{: #backup-service-about-tags}
Backup policies contain user tags for target resources that associate the policy with {{site.data.keyword.block_storage_is_short}} volumes or virtual server instances with the same user tag. To create backups, at least one user tag that is applied to a resource must match the tag in the backup policy. User tags are added by an authorized user in the account. Any user with the correct access role can list and delete user tags in the account on the condition that the tags are not attached to any resource.
In addition to user tags, tags can be access management tags and service tags. Only user tags are applied to backup policies. Access management tags are used to manage access to resources; only the account administrator can create access management tags. Service tags are a privileged construct that only authorized services can manage. Users are not authorized to attach and detach service tags on a resource, even if they have access to manage tags on the resource. Service tags are helpful to distinguish which snapshots were created manually or automatically by a backup policy. {: note}
If a volume, or virtual server instance has multiple tags, only one tag needs to match a backup policy tag. Based on the schedule in the backup plan, a matching tag triggers a backup. If multiple tags match backup policy tags, only one backup is created at the scheduled interval. If you have multiple resources with the same tag, backups are created for all the matching resources.
You can add up to 1,000 user tags for your resources. However, only 100 tags can be attached or detached in the same operation. Keeping the number of tags low can make it easier to track the number of backups that you're creating. For more information, see Applying backup policies to resources with tags.
When you decide on the tags to use for your target resources, make sure that other policies are not already using the same tags.
{: #backup-service-restore-concepts}
You can create a separate volume from a backup snapshot. This process is called restoring. It works the same way as restoring data from manually created snapshots. Restoring a volume from a backup snapshot creates a fully provisioned {{site.data.keyword.block_storage_is_short}} boot or data volume.
A volume can be restored when you create an instance, modify an instance, or when you create a stand-alone volume. Volume data restoration begins immediately as the volume is hydrated, but performance is degraded until the volume is fully restored. Restoring from a bootable snapshot is slower than using a regular boot volume.
The restored volume has the same capacity and volume profile as the original volume. For more information, see Restoring a volume from a backup snapshot.
Restoring a virtual server instance directly from snapshot consistency group identifier is not supported. However, you can restore a virtual server instance by restoring all of its boot and data volumes from the snapshots that are part of a consistency group.
{: #backup-service-fastrestore}
When you restore a block storage volume by using fast restore, a fully hydrated volume is created.
You can create a backup policy plan with fast restore zones, and add or remove zones later as needed. The fast restore feature caches one or more copies of a backup snapshot to the zones that you selected. Later, you can use these backup clones to create volumes in any zone within the same region.
For more information, see Restoring a volume from a backup snapshot.
{: #backup-service-crc}
You can copy a Block storage backup from one region to another region, and later use that snapshot to restore a volume in the new region. You can use and manage the cross-regional snapshot in the target region independently from the parent volume or the original snapshot.
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 backup snapshot can exist in each region. You can't create a copy of the backup snapshot in the source (local) region. {: restriction}
Creating a cross-regional copy affects billing. You're charged for the data transfer and the storage consumption in the target region separately.
{: #baas-vpc-iam}
Backups require IAM permissions for role-based access control. Depending on your assigned role as a backup user, you can create and administer backup policies. For more information, see IAM roles and actions for Regional Backup as a Service for VPC.
For more information, see the best practices for assigning access. For the complete IAM process, which includes inviting users to your account and assigning Cloud IAM access, see the IAM getting started tutorial. {: tip}
{: #baas-s2s-auth}
Specific IAM user roles are required to grant service-to-service authorizations. Service-to-service authorizations between the Backup service and Cloud Block Storage, Snapshots for VPC, and Virtual server for VPC are needed so the backup service can detect volume tags and create snapshots. For more information, see Establishing service-to-service authorizations.
{: #backup-service-limitations}
This release has the following limitations.
- You can create up to 10 backup policies per account.
- You can take a total of 750 backups per volume based on your backup policy, in your account and region. If you exceed this limit, no further backups are taken.
- The first backup and the entire volume backup cannot exceed 10 TB.
- You can't take a backup of a detached volume.
- You can't create a copy of a backup snapshot in the source (local) region.
- You can create a copy of a block storage backup in another region. However, only one copy of the backup snapshot can exist in each region.
- The fast restore feature is not supported for multi-volume backups of consistency groups.
- Consistency groups consist of the attached Block Storage volumes of virtual server instances, such as boot and data volumes. Instance storage volumes and virtual server instance configuration are not included.
{: #backup-next-steps}
Review best practices for creating a backup policy and the planning checklist. Afterward, you can create backup policies.