vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Snapshots require IBM Cloud® Identity and Access Management (IAM) permissions for role-based access control. Table 1 describes these roles as they pertain to snapshots actions.



Table 1. IBM Cloud® Identity and Access Management roles for snapshots.

 Snapshot action IAM role 

 Create snapshots Administrator, editor 
 Delete snapshots Administrator, editor 
 Create volume from a snapshot<br><br>[1] Administrator, editor, operator 
 List snapshots Administrator, editor, operator, viewer 
 View snapshot details Administrator, editor, operator, viewer 







 Snapshot lifecycle states 

Table 2 describes the snapshot states in the snapshot lifecycle.



Table 2. Snapshot lifecycle states

 Snapshot status Explanation 

 Stable The snapshot is available for restoring a volume. 
 Waiting Snapshot information is being retrieved. 
 Pending While the snapshot is being created, the percentage completed displays. 
 Failed The snapshot failed to br created, the volume can't be restored from a snapshot. 
 Suspended Snapshot is temporarily unavailable. 
 Updating You changed something about the snapshot and it is being updated. 
 Deleting The snapshot is [deleting](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-managesnapshots-vpc-delete). 
 Deleted The snapshot was deleted and is not available to restore volumes. 







 Managing security and compliance 

The Snapshot for VPC service is integrated with the IBM Cloud® Security and Compliance Center to help you manage security and compliance for your organization. For snapshots, you can set up a goal that checks whether snapshots are encrypted by using customer-managed keys. By using the Security and Compliance Center to validate the snapshot resource configurations in your account against a profile, you can identify potential issues as they arise.

Because snapshots are created from Block Storage for VPC volumes, Block Storage for VPC goals provide an extra level of security.
Snapshots require IBM Cloud® Identity and Access Management (IAM) permissions for role-based access control. Table 1 describes these roles as they pertain to snapshots actions.



Table 1. IBM Cloud® Identity and Access Management roles for snapshots.

 Snapshot action IAM role 

 Create snapshots Administrator, editor 
 Delete snapshots Administrator, editor 
 Create volume from a snapshot<br><br>[1] Administrator, editor, operator 
 List snapshots Administrator, editor, operator, viewer 
 View snapshot details Administrator, editor, operator, viewer 







 Snapshot lifecycle states 

Table 2 describes the snapshot states in the snapshot lifecycle.



Table 2. Snapshot lifecycle states

 Snapshot status Explanation 

 Stable The snapshot is available for restoring a volume. 
 Waiting Snapshot information is being retrieved. 
 Pending While the snapshot is being created, the percentage completed displays. 
 Failed The snapshot failed to br created, the volume can't be restored from a snapshot. 
 Suspended Snapshot is temporarily unavailable. 
 Updating You changed something about the snapshot and it is being updated. 
 Deleting The snapshot is [deleting](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-manage&interface=uisnapshots-vpc-delete). 
 Deleted The snapshot was deleted and is not available to restore volumes. 







 Managing security and compliance 

The Snapshot for VPC service is integrated with the IBM Cloud® Security and Compliance Center to help you manage security and compliance for your organization. For snapshots, you can set up a goal that checks whether snapshots are encrypted by using customer-managed keys. By using the Security and Compliance Center to validate the snapshot resource configurations in your account against a profile, you can identify potential issues as they arise.

Because snapshots are created from Block Storage for VPC volumes, Block Storage for VPC goals provide an extra level of security.
Snapshots require IBM Cloud® Identity and Access Management (IAM) permissions for role-based access control. Table 1 describes these roles as they pertain to snapshots actions.



Table 1. IBM Cloud® Identity and Access Management roles for snapshots.

 Snapshot action IAM role 

 Create snapshots Administrator, editor 
 Delete snapshots Administrator, editor 
 Create volume from a snapshot<br><br>[1] Administrator, editor, operator 
 List snapshots Administrator, editor, operator, viewer 
 View snapshot details Administrator, editor, operator, viewer 







 Snapshot lifecycle states 

Table 2 describes the snapshot states in the snapshot lifecycle.



Table 2. Snapshot lifecycle states

 Snapshot status Explanation 

 Stable The snapshot is available for restoring a volume. 
 Waiting Snapshot information is being retrieved. 
 Pending While the snapshot is being created, the percentage completed displays. 
 Failed The snapshot failed to br created, the volume can't be restored from a snapshot. 
 Suspended Snapshot is temporarily unavailable. 
 Updating You changed something about the snapshot and it is being updated. 
 Deleting The snapshot is [deleting](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-manage&interface=clisnapshots-vpc-delete). 
 Deleted The snapshot was deleted and is not available to restore volumes. 







 Managing security and compliance 

The Snapshot for VPC service is integrated with the IBM Cloud® Security and Compliance Center to help you manage security and compliance for your organization. For snapshots, you can set up a goal that checks whether snapshots are encrypted by using customer-managed keys. By using the Security and Compliance Center to validate the snapshot resource configurations in your account against a profile, you can identify potential issues as they arise.

Because snapshots are created from Block Storage for VPC volumes, Block Storage for VPC goals provide an extra level of security.
Regional snapshots in 3-tier architecture 

Block storage snapshots can be created in IBM Cloud® VPC Gen2. You can use this feature for a backup and restore of a 3-tier application. Block storage snapshots can also be used to scale out a 3-tier system with minimal changes to your application.

Zoom

![Block storage.](https://cloud.ibm.com/docs-content/v1/content/df269b100c3499f1efcbb7d030dce8dec25c539b/ha-infrastructure/images/ha-block-storage-arch.png)

Figure 1. Regional snapshots in 3-tier architectures

This architecture diagram shows a single zone 3-tier application that is spread across three different subnets. The same architecture can be extended to multiple zones (MZRs) as well.



1. Web tier that is running in web subnet and has only a bootable volume.
2. Middle tier that is running in application subnet and has only a bootable volume.
3. A database machine that is running in a separate DB subnet. Apart from the boot volume, you also have a secondary volume block storage that is attached to the virtual server instance that is hosting the database files.



All the three tiers are isolated with NACLs and SGs. Only the necessary ports that are needed for the data flow between the tiers are opened.



 Snapshots overview 

You can back up the data on your boot volumes and secondary storage block volumes that are attached to Virtual Server Instances by taking point in time snapshots. Snapshots can be taken both on bootable and secondary data volumes. If you experience accidental data deletion, you can create new data volumes from the backup snapshots and selected files can be copied over. If the snapshot was taken on a bootable volume, you can create another virtual server instance from the snapshot.

Snapshots of the volumes reside in regional IBM Cloud Object Storage buckets. To take snapshots, volumes must be attached to active virtual server instances.
For information about how to take backups of a PostgreSQL database, check out [Managing Backups](https://cloud.ibm.com/docs/databases-for-postgresql?topic=cloud-databases-dashboard-backups) from the Databases for PostgreSQL documentation.

The following node-specific guidance is provided to help plan your disaster recovery strategy.



 Backup considerations for each node type 

Consult the following chart to help you plan your strategy for taking backups:

Certificate Authority (CA)

Peers

Ordering service



Table 1. Considerations for node backup and restore - CA

 Backup Restore 

 CAs must be stopped and backed up following the instructions that are provided in this topic. You can restore a CA without impacting the peers or the ordering nodes ability to process transactions. 







 Scheduling snapshots 

It is a best practice to create a regular schedule for the snapshotting of your components. If possible, try to coordinate these snapshots with the other members of your network to ensure that the most recent snapshots can be used if necessary. Because no peer snapshots can be used that are more recent than ordering service snapshots, you are bound by your snapshots of the ordering service when attempting to restore.

Even though snapshots do not disrupt the functionality of your nodes, try to schedule snapshots during a time when the fewest transactions are being made. This ensures that differences in ledger heights between peers are kept to a minimum. In widely distributed networks, scheduling such a time might be difficult. Prioritize the proper ordering of snapshots over relative lulls in network activity.

For this example, we assume one backup every 24 hours and retain seven backups.

For the peer pods:



* CouchDB snapshot daily at 3:00 a.m.
* Peer snapshot daily at 3:05 a.m.



For the ordering node pods:



* Ordering node snapshots daily at 5:00 a.m. The two-hour gap allows sufficient time for all of the peers to be snapshotted from every organization before ordering nodes are snapshotted.
After the restoration process is complete, you can realize full IOPS on the new volume.

Volumes that are restored from fast restore clones don't require hydration. The data is available as soon as the volume is created. However, to achieve the best performance and efficiency when you provision multiple instances, boot from an existing image. Custom images that you provide are better than stock images for this purpose. Images have a maximum size of 250 GB.







 Restoring a volume with fast restore 

Restoring a volume by using a [fast restore](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-faqs&interface=uifaq-snapshot-fr) snapshot clone creates a fully provisioned volume at creation time.

With fast restore, you create and keep a clone of the snapshot in a zone within your region instead of an Object Storage bucket. When you restore data from a fast restore snapshot, the data is pulled from the clone within your region. Because the data is immediately available, no hydration is necessary. Performance levels are not affected. By using fast restore snapshots, you can achieve

recovery time objectives(RTO) quicker than by restoring from a regular snapshot.

You can also use the fast restore feature with the backup service. For more information, see [creating backup policies and plans](https://cloud.ibm.com/docs/vpc?topic=vpc-create-backup-policy-and-plan).

When you use fast restore, your existing regional plan is adjusted, including billing. Billing for fast restore snapshot copies is based on instance hours, regardless of snapshot size. For more information, see [Pricing](https://www.ibm.com/cloud/vpc/pricing).





 Restoring a volume from a snapshot in the UI 

You can create volumes from various pages in the IBM Cloud console. During the "create and attach" phase of virtual server instance provisioning, you can select a snapshot to restore the volume. Restoring from a bootable snapshot creates a boot volume that you use to provision the virtual server instance. The boot volume uses a general-purpose profile and is limited to 250 GB.
A list of snapshots is displayed with the name, status, size, encryption type, and when it was created. It also shows whether the snapshot was created by the user or a [backup policy](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about&interface=uibaas-comparison). The snapshots display in descending order, with the most recently created snapshot in first place.



You can see details for a snapshot, create a new snapshot, and manage snapshots from the Volume details page. For example, from the overflow menu (ellipsis), you can delete the most recent snapshot. For more information, see:



* [View details of a snapshot](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-viewsnapshots-vpc-view-snapshot-ui).
* [Create a snapshot](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-viewsnapshots-vpc-view-snapshot-ui).
* [Delete all snapshots](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-managesnapshots-vpc-delete-all-ui).







 Viewing all backup policies associated with a volume 

View all backup policies associated with a Block Storage for VPC volume. All policies that have the user tag that is applied to this volume are listed. To add volumes to a policy, add user tags to the volume that are in the backup policy's tags for target resources. When you remove tags from a volume that are in a backup policy, the volume is no longer be backed up.



1. Go to the list of Block Storage for VPC volumes. In [IBM Cloud console)](https://cloud.ibm.com/login), go to the menu !
Back up Select Volume Level Back up. 
 Volumes Add either a Device, Mountpoint, LVM, or BTRFS. In this example, add a Mountpoint and select the "/" mount point. 
 Destination Choose Local and input the location of the secondary volume to be used for the Veeam backup repository. For this example, the location input is /veeam_disk. 
 Advanced Select any options that you want. This example uses the default options. 
 Schedule Input the time schedule for the backup job to run. 
 Summary Select start job now (if wanted) and then select Finish. 



The backup runs at the scheduled time.





 Restoring 



* Original CentOS instance for VPC refers to a virtual server instance for VPC that successfully completed a volume backup to the secondary volume.
* New CentOS instance for VPC refers to a virtual server instance for VPC that was provisioned with CentOS with no secondary volume is activated the Veeam Linux Agent.





 Restoring files to original CentOS virtual server instance 

The following example shows how you can restore files from a volume backup to the original CentOS virtual service instance.



1. Log in to the CentOS virtual server instance. From the command line, start the Veeam configuration tool:

veeamconfig ui
2. Select Recover Files, and then select the Job Name of the backup you want to recover.
3. Select the Restore Point (creation timestamp of the backup). This selection mounts the backup into /mnt/backup. Each individual device and volume that is backed up is mounted inside of /mnt/backup.
4. When you recover your files, unmount the backup.







 Restoring files to new CentOS virtual server instance 

The following example shows how you can take a secondary volume that holds a Veeam backup repository and import the repository onto a new CentOS virtual server instance for IBM Cloud VPC.



 Detaching secondary volume from original instance 

The original CentOS instance for VPC needs to be shut down so that it doesn't have access to the secondary volume. The secondary volume can be detached through the IBM Cloud CLI:
Best practices for backups 

To ensure that you're using the VPC Backup Service most effectively and economically, consider following these best practices.



 General best practices 



* Assess the type of data that you have before you create backup policies. Critical data that changes more often might require more frequent backups than static data. Ask which data is most critical and which is to be archived.
* Keep costs down by retaining backups for only while you need them to prevent data loss. Plan timely backups to restore data that might be deleted or corrupted. Think about the type of events that might happen. Ask how much data you can afford to lose. The answers can help you decide on a backup interval.
* Ask how quickly you need to recover the data. Frequent backups that cover smaller incremental changes to your data afford quicker restoration. Run a test failover and volume restore to get an idea of the time it can take.
* For best performance, stagger your backup jobs by creating backup plans with different intervals. You can have up to four different backup plans per backup policy.
* For large volumes, consider a shorter retention period so that you don't exceed the 10 TB limit for all volume backups.
* If you have volumes in different regions, create separate backup policies for each region. You're limited to 10 backup policies per account in a region.
* Ensure that the volumes that you tagged for backups are attached to a virtual server instance. You can't back up detached volumes.
* Provide a unique name for your backup policy. If you have a convention for naming volumes, you might name a backup policy by using a similar convention. Backups that are created by a policy can also follow the convention. As the number of backups grow, a good naming convention can make them more identifiable.







 Best practices for user actions 



* Organize tags that you apply to volumes and specify in backup policies. Ensure that multiple policies aren't using the same tags for target resources because that might trigger duplicate volume backups. You need only one tag to match to trigger a backup.
* Determine what tags are already assigned to a volume from the list of Block Storage for VPC volumes.
For more information about how performance is affected during restoration, see [Performance impact when backup snapshots are used](https://cloud.ibm.com/docs/vpc?topic=vpc-baas-vpc-restorebaas-performance-considerations).

For best performance, use backups with fast restore. You can enable fast restore backup snapshots in multiple zones and use them to restore a volume that is fully provisioned when the volume is created. The fast restore feature can achieve a

recovery time objective(RTO) quicker than restoring from a regular backup snapshot. For more information, see [fast restore](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-aboutsnapshots_vpc_fast_restore).

To restore a volume, the backup snapshot must be in a stable state.

You can't simultaneously restore a boot and a data volume.



 Restoring from a bootable backup 

When you restore from a bootable backup snapshot, you create a boot volume that you use to provision another instance. The boot volume uses a general-purpose profile and is limited to 250 GB. Because the bootable backup snapshot is not fully provisioned, in the beginning the performance is slower than when you use a regular boot volume. For more information, see [Performance impact](https://cloud.ibm.com/docs/vpc?topic=vpc-baas-vpc-restorebaas-boot-perf).

You can restore a volume from a backup snapshot of a boot volume in multiple ways.



* You can restore a boot volume when you provision an instance to start the new instance.
* You can restore a boot volume as a stand-alone volume, and use it later to start a new instance. The restoration process starts when the boot volume is attached to the instance.







 Restoring from a nonbootable backup 

You can restore a volume from a backup snapshot of a data volume in multiple ways.



* You can restore a data volume when you provision an instance.
Backing up and restoring apps and data with PX-Backup 

PX-Backup is a Portworx proprietary backup solution that is compatible with any IBM Cloud Kubernetes Service cluster. You can use PX-Backup to back up and restore IBM Cloud Kubernetes Service resources, apps and data across multiple clusters. For more information on PX-Backup, see [Understanding PX-Backup](https://backup.docs.portworx.com/understand/).

To back up the data in your persistent volumes, you must have a storage class that supports snapshots in your cluster. Clusters with Portworx Enterprise have storage classes available that support snapshots by default. However, for clusters that don't have Portworx Enterprise, you must have a storage classes with snapshot support to back up your persistent volume data. The Block Storage for Classic driver, and the File Storage for Classic driver don't have storage classes that support snapshots. If you have workloads that use these drivers, you can use PX-Backup to back up your apps, but not the data in the persistent volumes. For more information see [Backing up and restoring cluster data with PX-Backup](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_backuppx-backup-and-restore).



 Installing PX-Backup on an IBM Cloud Kubernetes Service cluster 

Install PX-Backup on an IBM Cloud Kubernetes Service cluster in your IBM Cloud account. After you install PX-backup on one cluster in your account, you can use it to back up or restore data and apps for any cluster in that same account.

Before you begin:



* Make sure that your cluster meets the [minimum Portworx requirements](https://docs.portworx.com/start-here-installation/).
* [Install or update the IBM Cloud Block Storage plug-in in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-block_storageinstall_block).
* Provision and attach 320Gi of block storage to your cluster.
slcli block snapshot-delete
Usage: slcli block snapshot-delete [OPTIONS] SNAPSHOT_ID

Options:
-h, --help Show this message and exit.

Manual snapshots that aren't deleted in the portal manually, are automatically deleted when you reach space limitations. The oldest snapshot is deleted first.





 Restoring storage volume to a specific point in time by using a snapshot in the UI 

You might need to take your storage volume back to a specific point in time because of user-error or data corruption.



1. Unmount and detach your storage volume from the host to ensure the host is not connecting to the volume during the restore for any reason.



* [Unmounting Block Storage for Classic volumes on Linux® server](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-mountingLinuxunmountingLin)
* [Unmounting Block Storage for Classic volumes on Microsoft® server](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-mountingWindowsunmountingWin)



2. Go to the [IBM Cloud® console](https://cloud.ibm.com/login). From the menu, select Classic Infrastructure![Classic icon](https://cloud.ibm.com/docs-content/v1/content/14cf2f2f32b430cf4ed67ad14b3cecc010f91c45/icons/classic.svg).
3. Click Storage, Block Storage for Classic.
4. Scroll on the list, and click your volume to be restored. The Snapshots page displays the list of all saved snapshots along with their size and creation date.
5. Click Actions!