VMware Backup Best Practices: Backup Copy

Anna ZvizdaPre-Sales Engineer
Published:
Updated:
VM backups can be lost due to a number of reasons: accidental backup deletion, backup file corruption, disk failure, lost or stolen hardware, malicious attack, or due to some other undesired and unpredicted event. Thus, having more than one copy of your business-critical VM backups...
VM backups can be lost due to a number of reasons: accidental backup deletion, backup file corruption, disk failure, lost or stolen hardware, malicious attack, or due to some other undesired and unpredicted event. Thus, having more than one copy of your business-critical VM backups is vital for ensuring that your data can be recovered in case of a disaster. Having an extra copy of VM backups is especially important if your primary VM backups are stored in the same location as the production machines, as any incident in the production environment is more likely to affect your backups as well. With just one copy of VM backups you have a single point of failure, and a nightmare if you lose the backups along with production machines.
To ensure that your data is safe, it’s best to stick to the 3-2-1 rule: have three copies of data on two different media, one of which is offsite. So how do you make and maintain VM backup copies? And what should you pay attention to? In NAKIVO Backup & Replication, you can use Backup Copy jobs, which provide a simple and flexible way to create and maintain copies of your backups. Backup Copy jobs copy backups from one Backup Repository to another, without touching the source ESXi hosts. This way your source VMs are read only once, while backups can be copied to one or multiple locations.

Choose What You Want to Copy

The simplest and most reliable way to protect all your backups is to create and maintain a mirrored copy of your primary Backup Repository. Think of it as of Backup Repository replication: all backups and recovery points that appear in the Backup Repository A will be automatically sent to the Backup Repository B:
1.jpgHaving a mirrored copy of your primary Backup Repository provides a “set it and forget it” approach for protecting your backups – just create a Backup Copy job once and it will keep your secondary backup repository up to date with all backups and recovery points created by all jobs. The downside of this approach is that your backup copy will occupy a lot of space. To save storage space on your secondary Backup Repository and to speed up data transfer you can choose to copy backups made by particular jobs that back up your VIP VMs:
2.jpgAlternatively, you can create a Backup Copy job only for the most important backups:
3.jpgThe downside of this approach is that you’ll need to remember to create backup copies for any new VMs that you back up, so it’s best to use this approach only for special cases – like long term archival for backups of decommissioned VMs.

Set Backup Copy Compression Level

In addition to global data deduplication, NAKIVO Backup & Replication automatically compresses backed up data to reduce the amount of space that VM backups occupy on a storage. By default, the compression level in new Backup Repositories is set to “Fast”, so that your Backup jobs run faster. When creating a secondary Backup Repository you can set the compression level to “Best”, which uses more CPU but delivers better compression levels. This way the strongest compression algorithm will be used to compress backup data, resulting in smaller backups in your secondary Backup Repository.

Schedule Backup Copy Jobs

Once you’ve defined what backups you want to copy, you need to decide when Backup Copy jobs should run. The most apparent answer is to run Backup Copy jobs immediately after backup jobs. The advantage of such an approach is that the time window when you have just one copy of a VM backup is short. However, such an approach adds a network load so you may want to schedule backup copy jobs to run at different times. For example, you can set up a Backup Copy job to run every night on working days or set it up to run on weekends to send all backups made during the week to a secondary Backup Repository.

Set Retention Policy for Backup Copies

Each VM backup contains a number of recovery points, which are saved based on recovery point retention policy, i.e. how many recovery points you want to have and for how long you want to keep them. With Backup Copy jobs, you can choose to create a mirrored copy of each backup: all recovery points that are available in Backup Repository A will be copied to the Backup Repository B:
4.jpgAgain, this is the most reliable way to keep your data, but it consumes the most storage space. You can choose to set a different retention policy for your VM backup copies. This way, for example, you can keep several daily VM backups onsite, and keep (archive) weekly, monthly, and yearly copies of VM backups in a secondary Backup Repository for long term storage:
5.jpgAlso, you can use a fast storage for a subset of backups and use a slower but more reliable storage for long term archival.

Copy Backups Offsite

While you can keep the copies of your backups locally, having at least one copy of your most critical backups offsite can save you from a lot of trouble in case a local disaster wipes your infrastructure. When sending backup copies offsite, it is important to enable in-flight data encryption and encrypt the secondary backup repository if it’s location is less secure than your primary one:
6.jpgIf you don’t have a secondary site, you can send your backup to Amazon cloud, which provides one of the most reliable and affordable cloud services in the industry:
7.jpgBackup Copy jobs provide a powerful way to protect your backups and ensure that they are safe no matter what happens to production environment or primary backups.
 
4
3,510 Views

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.