In this section we discuss volume Backup operations.
Backup is to back up the volume to a different location (backup device) that can be restored in the future through the restore operation.
Backup VS Snapshot
At first glance, the backup function seems to be similar to snapshot and can save the current state of volume for later recovery. However, there are differences in the use and implementation of the two, specifically in:
Snapshot relies on the source volume, cannot exist independently, and backup does not rely on the source volume, even if the source volume does not exist, you can restore.
Snapshot and source volume are usually stored together and managed by the same volume provider, while backup is stored in a separate backup device with its own backup scheme and implementation, which is not related to volume provider.
The above two points determine that backup has a disaster tolerant function, while snapshot provides convenient backtracking functions in the volume provider.
Configure Cinder-backup
The backup feature of Cinder is provided by the Cinder-backup service, and Devstack is not enabled by default and needs to be enabled manually. Similar to Cinder-volume, Cinder-backup supports a variety of backup backend through the driver architecture, including POSIX file systems, NFS, Ceph, GlusterFS, Swift, and IBM TSM. The supported driver source files are placed in the/opt/stack/cinder/cinder/backup/drivers/
In this section we will study backup operations with NFS as backend.
In the experimental environment, the NFS remote directory hosting volume backup is/backup_mount on Mount point on the 192.168.104.11:/backup Cinder-backup service node.
It needs to be configured in/etc/cinder/cinder.conf.
Then manually start the Cinder-backup service.
/usr/bin/python/usr/local/bin/cinder-backup--config-file/etc/cinder/cinder.conf
Everything is ready, let's look at the process of the backup operation
Send a backup request to Cinder-api
Cinder-api sending messages
Cinder-backup Performing backup operations
Let's discuss each step in detail below.
send a backup request to Cinder-api
The customer (which can be an OpenStack end user, or another program) sends a request to CINDER-API: "Please backup specified volume.
Here we will backup volume "Vol-1", currently backup can only be executed in the CLI.
This is because VOL-1 has been attach to instance and needs to use the--force option.
Cinder-api received a request for backup volume. The log file is in/opt/stack/logs/c-api.log.
Cinder-api sending Messages
CINDER-API sends a backup message. CINDER-API does not print the log that sends the message, only the source code to view the/opt/stack/cinder/cinder/backup/api.py, the method is create.
Cinder-backup performing backup operations
Cinder-backup after receiving the message, complete the backup operation with the following steps, the log is/opt/stack/logs/c-vol.log.
Start the backup operation, Mount NFS.
Creates a temporary snapshot of the volume.
Create the container directory that holds the backup.
Compress the temporary snapshot data and save it to the container directory.
Create and save sha256 (encrypted) and metadata files.
Delete the temporary snapshot.
After Backup is complete, we can view the contents of the container directory
There are three files, according to the previous log we can know:
BACKUP-00001, compressed backup file.
Backup_metadata,metadata file.
Backup_sha256file, encrypt files.
You can view the current backup by Cinder Backup-list.
In addition we can check the usage of cinder backup-create.
Here is the--incremental option, which means you can perform an incremental backup. If you have done normal (full-volume) backups before, then you can significantly reduce the amount of data that needs to be backed up by incremental backups, which is a good feature. Operations and log analysis for incremental backups are left to everyone to do exercises.
The above is the analysis of volume backup, and the next section we discuss how to restore the volume of the backup through the restore operation.
Backup Volume operation-5 minutes a day to play OpenStack (59)