The whole idea of Backup copy jobs is to provide you with an identical copy of backups in case something is wrong with your hardware at your primary site where you store your backups (for fast restore times), or the whole main site is down. So you can have a synced backup at a remote site where you also can restore them to some host and run your environment there. Backup copy jobs are independent of Backup jobs. They have a different schedule and different possible settings. We'll look at some options in this post.
Nakivo Backup software can copy a whole backup repository to the remote site or you can pick just some backups from the primary repository, to be copied to the remote site. It's granular and completely independent of the main backup jobs.
It is possible to “chain” a backup job to copy job so both are working together. It is a new feature which has been added in Nakivo 6.1 and allows to trigger another job in a chain when the first job finishes. You can run Backup job that saves data locally and then triggers a Backup copy job to send backup copies to another location.
Before we dive into the backup copy jobs, let's talk about deduplication. Nakivo is efficient when it comes to deduplication. There is a global data deduplication, but there is also a compression of the backed up data so you can further reduce the amount of space that those backups are taking. The default value is set to fast compression, but you can change it to best for example, but you'll use more CPU. If you have new hardware and you have dedicated hardware you can probably do that.
The setting is on “per-repository” so you can have a primary repository with default (fast) compression, and then add another repository where you can set the compression level to “Best”, which uses more CPU but delivers better compression levels (and space savings).
As you can imagine, the backup copy jobs are created the same way as backup jobs. The thing is that you have to have at least one backup job in order to start creating backup copy jobs. If not, the menu will be simply grayed out.
What's the difference between Backup copy and Replica?
Yes, this question might arise. I think it's pretty obvious as the Replica is an exact copy of a VM, so it is registered on an ESXi host somewhere at the remote site, where it sits and wait to be powered on in case there is a problem at the main site.
The replica is “refreshed” on a regular basis so your RPO can stay low. Replication of VMs however “touches” the production VMs in terms of IO operations, so should make sure that replication jobs do not put too much “pressure” on your production storage, and production VMs.
Backup copy jobs, however, does copy already “cold” backup files so running VMs are not affected.
Backup Copy jobs can copy backups from one Backup Repository to another. It is as simple as that. The Backup Copy can be stored onsite, offsite and also in the Amazon cloud.
The Workflow:
Create a Backup copy job is simple. Basically, you just pick your backup job(s) and start an assistant which will guide you through. The only condition is that you have to have already some VMs backed up!
If you don't, then you'll perhaps see a menu like the one on the right-hand side… No possibility to create a backup copy job. The only reason why is because within this test installation I haven' backed up any VMs. We'll remediate that in a second, so we can run the assistant…
The assistant is pretty straightforward. After picking up your backup,
you then select the backup repository,
select the schedule and the job options.
The backup copy jobs has several options:
- Network acceleration – NAKIVO Backup & Replication will use compression and traffic reduction techniques to speed up data transfer. You will certainly want to use it when spanning a WAN environment.
- Encryption – you may want to encrypt your sensitive data during a transfer?
- Screenshot Verification – after a backup copy is completed, the VM will be recovered from the backup using Flash VM Boot (and will be disconnected from networks), a screenshot of the recovered VM will be made once the VM OS has booted, after which the VM will be discarded. VM screenshots will be included in email notifications (if they’re configured), and in job reports
Details on the option view below. You can click to enlarge.
More about Nakivo on ESX virtualization:
- Nakivo Backup and Replication v6 Released
- Nakivo Backup and Replication 6.0 Look and Feel
- Nakivo 5.8 allows being deployed on Western Diginal NAS to speed up backups
- Nakivo Distributed Deployment – How it works?
- TOP 5 Backup Software for VMware Infrastructure
- Nakivo Flash VM Boot and how to configure and use
- Nakivo Backup and Replication (NBR) Appliance
- Nakivo Backup Copy – Why would you use it? – [This post]
Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)
Thanks for the useful post.
Do you know if it is safe to use Backup Copy jobs to save to USB drives that are swapped regularly? Ie. A Backup Copy job runs tonight and saves to USB drive #1, then 24 hours later the backup copy job runs again but I have my USB drive #2 plugged in.
In other words, do copy jobs save the entire backup every time or are there smarts that only copy files that it thinks aren’t already on the destination?