ViPR 2.2 - EMC ViPR native backup and restore service

Table of Contents

EMC ViPR native backup and restore service

Learn how to use the EMC ViPR Controller native backup and restore service to create a backup set of the ViPR Controller nodes. The backup set can be scheduled using the ViPR UI, or created through REST API calls, or the viprcli CLI.

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 2.2.0.0.1043 must be restored to 2.2.0.0.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

Schedule backups using the ViPR UI

You can use the ViPR UI to schedule a daily backup of the ViPR Controller internal databases, and upload backups to an external storage location.

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.

Procedure

  1. Select Settings > Configuration > Backup.
  2. 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.

    Example: ftps://10.233.95.162/my-vipr-backup/

    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.
  3. Save.

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 at root > Preferences from the main ViPR UI page.

Back to Top

Summary of REST API for EMC ViPR backup and restore service

This is a summary of the REST API for the EMC VIPR backup and restore service.

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.

Back to Top

Summary of viprcli options for native backup

You can create, delete, list, and download a backup using viprcli.

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

Back to Top

Back up EMC ViPR internal databases with command line or REST API

You can use POST /backupset/backup/ or the viprcli CLI to back up the ViPR internal databases.

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 System > Health > Services.
  • 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.

Procedure

  1. 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
  2. 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 filepath
    When you run viprcli to generate a backup set, you should run viprcli on a standalone Linux or Windows machine, not a ViPR Controller node.
Back to Top

Restore a backup

Use the restore command to restore a backup created by the EMC ViPR backup service.

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.

Procedure

  1. 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.
  2. Shut down the entire old ViPR Controller instance.
  3. 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.
  4. 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.
  5. Restore the backup by running the following command as the root user:
    /opt/storageos/bin/restore backup_ZIP_filepath
    Example: /opt/storageos/bin/restore /tmp/vipr-2.2-1-20150114200225.zip
    You 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.
  6. Verify that the health of the system, and of all services, is good (in the ViPR UI under System > Health).
  7. 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
    
    
  8. 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.)
Back to Top

Considerations when recovering data after restoring a ViPR backup

There are some best practices you should consider when recovering user data that was created or modified after the latest backup.

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:

  1. Restore the ViPR backup.
  2. Recreate tenants and users.
  3. Add the physical assets.
  4. Add or modify the virtual assets as required. Be sure to configure virtual arrays and virtual pools exactly as before.
  5. 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.

  6. For resources without ingestion support, provision volumes and file systems as necessary.
  7. If resources were deleted or modified since the backup, perform those same operations again.
Back to Top