vRops Backup
Backing up vRealize Operations Manager or vRops isn’t as straight forward as one could wish for – There are some general things that need to be done right, but more important is some of the vRops specific quirks that needs to be done right in order to have a working and valid backup, which should be the biggest concern with taking backups in the first place. No one likes an inconsistent backup. Before I start with the the actual guide lines for doing vRops backup, I’ll point you to a great PDF which describes how to do backup with Symantec Veritas Netbackup. The guide covers the whole vRealize Suite, for both backup and restore which is equally as important. Nothing worse than spending hours restoring only to get an inconsistent application up and running.
A guide can be found here – Configuring vRealize Suite 6.0 for Backup and Restore by Using Symantec NetBackup 7.6
vRops Backup guide lines
The first rule of vRops backup, do NOT quiesce the file system
The second rule of vRops backup do NOT backup during DT (Dynamic Threshold) calculations
The third rule of vRops backup obey the first two rules!
I just want to make sure that at least you understand the three lines above – Words to live by when setting up a backup schedule for vRops.
- No backup agents are supported – Always use vStorage APIs for Data Protection (VADP). This is the only supported method for backing up vRops.
- Do not quiesce the file system
- Use a resolvable host name and a static IP address for all nodes.
- Make sure all nodes are powered on and accessible during backup.
- Back up the entire VM. You must back up all VMDK files that are part of the virtual appliance. For Linux and Windows backup all disks that matters.
- Do not stop the cluster while performing the backup.
- Do not backup vRops during DT (Dynamic Threshold) calculations
- VMware Tools need to be the latest version. (This does not apply to the appliance, only Linux and Windows vRops installations)
Do not quiesce the file system
vRops does not support that the file system being quiesced. Either your backup software need to support disabling of file system quiescing or you can disable it in VMware Tools. Disabling it in VMware Tools is the safe way to do it, which is why I recommend you to use this method.
How to disable file system quiescing:
- Power off all vRops nodes. The proper way to shutdown a vRops Cluster, is to first shutdown the cluster and wait for the cluster to become offline. Then shutdown each node, in this order: Data node(s), Replica, Master.
- SSH to an ESXi host that has access to the vmx file of the vRops node(s). Edit the vmx file of the VM and set “disk.EnableUUID” to “false” or create it if not already in the vmx file. Exit saving the file. Do this for every vRops node.
disk.EnableUUID = "FALSE"
- Power on all vRops nodes. The proper way to power on a vRops cluster. Is in the following order: Power on Master and wait for it to come up, then power on replica and data node(s). In the admin UI bring cluster online.
- SSH to each vRops node and edit the “/etc/vmware-tools/tools.conf” – Add the following lines and exit saving the file.
[vmbackup] enableSyncDriver = false
The steps can also be found here in the vRops documentation:
Do not backup vRops during DT (Dynamic Threshold) calculations
vRops does not support that you backup vRops during DT (Dynamic Threshold) calculations. This happens every day at two AM, and there is no supported way of changing when the DT job will be executed. If backup is done while DT is running, you risk corrupting the vRops nodes and risk having data loss, which is not nice. Therefor it is best practice to backup vRops before the nightly DT gets executed, so that the backup job can be done before two AM. The other option is to do the backup at a time of day when DT is not running.
Closing notes on vRops Backup
The guide lines here describes the way to backup the vRops nodes, for diaster recovery purposes. Which you of cause should do. Lets say that our nodes are fine, but some one deleted or modified a setting in vRops. Restoring the entire cluster might seem a bit excessive and overkill. Not to talk about the data loss you might incur between when the last valid backup was run and when the error was found.
Therefor backing up the changes made to vRops is a good “best practice”.
Below I link to some other blogs that have write ups on the subject of backing up individual components of vRops.
How to Backup, Share, and Organize Dashboards – VMIgnite.com
How to backup all your customized work and settings in vROPS – VMIgnite.com
Lastly there is a link to the vRops documentation which mentions some of the mentioned guides on how to backup vRops.