ViPR 2.2 - EMC ViPR native backup and restore service
Table of Contents
The native backup and restore service is the only supported backup method. You should transition to the native method from other backup types (VM snapshot or other third-party solutions) that you may be using in previous versions of ViPR Controller.
The VIPR backup set is a near point-in-time copy of the persistent data (the Cassandra and Zookeeper data files, and the geodb database, which contains data related to multisite ViPR) on all the ViPR Controller nodes. Volatile data such as logs and binaries are not part of the backup set.
The backup set is generated as a set of files on local storage (/data/backup/). For protection, it is highly recommended that you configure an external server to automatically upload backups daily. Use the ViPR UI to specify the external server. Alternatively, you can manually copy backup sets to secondary storage the REST call GET /backupset/download, or with viprcli system download-backup.
ViPR retains the last 5 backups. The retention count is not settable.
Backup and restore must be between the same ViPR version (for example, version 188.8.131.52.1043 must be restored to 184.108.40.206.1043).
The restore target must have the same number of nodes as the backup (for example, a backup of a 2+1 configuration can restore only to 2+1; it cannot restore to 3+2).Back to Top
Before you begin
- This operation can only be performed by ViPR System Administrators.
- To upload backups to an external server, you need the URL of the server and credentials for an account with read and write privileges on the server. Specifying an external server is optional but is highly recommended.
- Recommended storage allocation for external server storage is 30% of the total disk space allocated for the ViPR VMs.
- Select .
- Enter values for the properties.
Option Description Enable Scheduler True turns on the scheduler. Backup Time Select the time of day when the backup runs. The backup runs once a day; you cannot change the frequency of the backup. The time of day is the time where the ViPR UI is running. External Server URL Specify the URL of an external file server. Supported protocols are ftp and ftps.
The filename format of the backup file that is uploaded to the external server is: vipr-version-nodeCount-datatime-nodeBitmap.zip. Example: vipr-2.2-5-20150121010002-1f.zip.
User Name User name for an account with read and write privileges the FTPS server. Password Password for the account.
After you finish
Backup and upload success and failure messages are logged in the Audit log. Email notification of failure is sent only to the address associated with the ViPR Controller root user; be sure to add a valid email address atfrom the main ViPR UI page. Back to Top
Details are in EMC ViPR REST API Reference.
- GET /backupset/
- Lists all backups.
- POST /backupset/backup/
- Creates a new backup. Note the following restrictions on the backupsetname, which might not be covered in
EMC ViPR REST API Reference:
- The backupsetname maximum length is 200 characters.
- Underscore (_) not supported.
- Otherwise, any character supported in a Linux filename can be used.
- DELETE /backupset/backup/
- Deletes a backup.
- GET /backupset/download?tag=backupsetname
- Downloads a specific backup.
- Below is an example using curl to download a backup.
- curl -ik -X GET -H "X-SDS-AUTH-TOKEN: token_value" "https://vipr_ip:4443/backupset/download?tag=backupsetname" > backupsetname.zip
- To obtain the token value refer to Authenticate with the ViPR REST API.
Restore, quota, and purge commands are not currently available through viprcli.
The EMC ViPR CLI Reference guide describes how to install and use viprcli.
- Create backup
- viprcli system create-backup -n backupname [-force]
- -force ignores errors and tries to create the backup. Returns success if backup is created, else returns failure and rolls back. Useful in the case of a single node crash.
- Delete backup
- viprcli system delete-backup -n backupname
- List all backups
- viprcli system list-backup
- Download backup
- viprcli system download-backup -n backupname -fp filepath
- Example: viprcli system download-backup -n 20140728155625 -fp C:\20140728155625.zip
Before you begin
- This task requires the System Administrator (SYSTEM_ADMIN) role in ViPR.
- Services on at least two nodes in a 2+1 deployment, or three nodes in a 3+2 deployment, must have a status of "Good". In the ViPR UI, go to .
- Not required, but it is better to back up when no database repair is in progress. If the backup is created during database repair, the backup data of each node will not be consistent. A database node repair after restore will take a long time, resulting in a longer overall time to recovery. Check the dbsvc log and look for "Starting background repair" (repair is in progress) and "Ending Repair" (repair is complete). Typical frequency of the database repair operation is 7 days.
- It is recommended that the load on the system be light during the time of backup, especially on operations related to volume, fileshare, export, and snapshots.
- On a ViPR Controller node, initiate a backup using one of these methods. Any method creates the backup in /data/backup/ on all ViPR Controller nodes. It is not necessary to run the command on each node:
Method Command REST API POST /backupset/backup viprcli viprcli system create-backup -n backupname
- Use one of these methods to generate a file containing the backup set, which you can copy to secondary media:
Method Command REST API GET /backupset/download?tag=backupsetname viprcli viprcli system download-backup -n backupname -fp filepathWhen you run viprcli to generate a backup set, you should run viprcli on a standalone Linux or Windows machine, not a ViPR Controller node.
Before you begin
- Credentials for root user are required. If root ssh is disabled, you will also need credentials for the local ViPR svcuser account.
- The target system must meet these requirements:
- On VMware, the target system must be a new deployment of the complete ViPR Controller vApp. On Hyper-V, the target system must consist of new deployments of all ViPR Controller nodes.
- The target system must be at the same ViPR version as the version of the backup set.
- You need a target system that contains the same number of ViPR Controller nodes as the system that was backed up. In other words, you should restore a 3+2 backup to a 3+2 deployment, and a 2+1 backup to a 2+1 deployment.
- The target system must have the same IP addresses as the backed up system. Therefore, the original system should be shut down before deployment of the target system; after the restore is successful, delete the original system.
- The size of /data on the target system must be equal to or greater than that of the backed up system.
- Note that a backup set created on a standalone VDC should not be used to restore after the VDC is added to a multi-VDC configuration.
- Total time required might be several hours.
- If the VDC that you are restoring is part of a multi-VDC configuration, first disconnect the VDC. Follow the procedure in Disconnect and reconnect an EMC ViPR VDC in a geo federation. If there are any version 2.0 or 2.1 VDCs in the federation, contact customer support and refer to KB article 000189026.
- Shut down the entire old ViPR Controller instance.
- Deploy the target ViPR Controller system through the Initial Setup steps in the UI. The dbsvc, geosvc, and controllersvc services must have started at least once.
Keep in mind that all system properties that you set during Initial Setup will be overwritten by the values in the backup that you restore in an upcoming step.
- Copy the backup ZIP file from the external server on which you store your backups, to a location on one of the newly deployed ViPR Controller nodes.
Note that remote login as root might be disabled. It may be necessary to log in initially as svcuser, then switch user to root.
- Restore the backup by running the following command as the root user:
/opt/storageos/bin/restore backup_ZIP_filepathExample: /opt/storageos/bin/restore /tmp/vipr-2.2-1-20150114200225.zipYou initiate restore on one node only. Restore on the other nodes happens automatically.Note that remote login as root might be disabled. It may be necessary to log in initially as svcuser, then switch user to root.
- Verify that the health of the system, and of all services, is good (in the ViPR UI under ).
- Check the node repair progress in dbsvc.log and geodbsvc.log. Look for "Current progress 100%". The restore is complete when dbsvc and geodbsvc repair progress is 100%. This might require several hours.
2014-04-30 08:21:56,031 [DBRepairPool_223] INFO DbServiceImpl.java (line 477) Starting background repair run - trying to get repair lock 2014-04-30 08:32:04,566 [DBRepairPool_223] INFO DbServiceImpl.java (line 482) Got lock: triggering repair 2014-04-30 08:32:04,576 [DBRepairPool_223] INFO RepairJobRunner.java (line 132) Run repair job for StorageOS. Total # local ranges 256 2014-04-30 08:32:41,840 [DBRepairPool_223] INFO RepairJobRunner.java (line 269) 1 repair sessions finished. Current progress 0% … 2014-04-30 14:00:06,812 [DBRepairPool_247] INFO RepairJobRunner.java (line 269) 256 repair sessions finished. Current progress 100% 2014-04-30 14:00:06,812 [DBRepairPool_247] INFO RepairJobRunner.java (line 175) Stopped repair job monitor 2014-04-30 14:00:06,813 [DBRepairPool_247] INFO RepairJobRunner.java (line 182) Db repair consumes 133 minutes 2014-04-30 14:00:06,813 [DBRepairPool_247] INFO DbServiceImpl.java (line 499) Ending repair
- When you have verified the health of the new system, delete the old ViPR Controller instance. (Do not power on the old instance; the old and new instances use the same IP addresses, and IP conflict issues will result.)
Details of a data recovery are dependent on the specific configuration. Use these high level steps as a guide when recovering resources that were added, modified, or deleted before a crash, but after the backup that you are restoring:
- Restore the ViPR backup.
- Recreate tenants and users.
- Add the physical assets.
- Add or modify the virtual assets as required. Be sure to configure virtual arrays and virtual pools exactly as before.
- For storage resources that support ingestion, ingest them into the ViPR configuration.
Refer to Ingest unmanaged block volumes into ViPR and Ingest unmanaged file system data into ViPR.
- For resources without ingestion support, provision volumes and file systems as necessary.
- If resources were deleted or modified since the backup, perform those same operations again.