Nakivo has released new version of their flagship product Nakivo Backup and Replication 5.6. This new release brought in an interesting verification function which enables IT administrators to automatically check if the latest backup is fine (or not). If the VM can actually boot up.
In fact, a screenshot of the VM, after its boot from the backup repository (Flash VM Boot), is taken and embedded to the confirmation email. There are two time values you can configure. The first one allows to trigger the maximum boot time to wait for the VM to boot from backup, and the second value is to wait a certain time after the Guest OS start, before taking the screenshot. Nakivo listen to the OS hertbeat via VMware tools…. By default product waits 5 min before the screenshot is taken and 30 sec after the VM boots.
If your product has some kind of verification, let’s say checksum verification of the backup file. The Nakivo approach is rather clever as the verification is visual (via the report). The admin has just to look through the confirmation e-mail to see if the screenshot looks fine. VM booted or not.
How it works – Quote from Nakivo:
After each job run, NAKIVO Backup & Replication creates a recovery point in the backup repository. Once a VM backup is completed, NAKIVO Backup & Replication boots the VM from its newly created recovery point (that is, the VM is instantly recovered from the compressed and deduplicated backup repository via the Flash VM Boot feature). Note that networking on the VM is disabled to prevent any connectivity to the production environment. While the recovered VM is running, the VM backup remains in the read-only state, so it is no affected and all changes are stored in a temporary location on a datastore. Once the VM OS has booted, NAKIVO Backup & Replication makes the screenshot of the OS and then discards both the VM and the changes on the datastore. The screenshot is then included in job reports sent over email and in PDF reports that you can create ad hoc for any job.
Now there is no other verification behind the scenes, like to check different application or Windows services etc. Just visual screenshot is taken and then the VM is powered back off.
To setup the new function is easy as all you need to do is check a new checkbox Run screenshot verification after each job (by configuring this in backup job options) and then precise target cluster, datastore where the VM will boot (can be different from your production cluster for example) and there you can also configure simultaneous verification (by default 2 VMs are verified) to not to put too much pressure on your backup infrastructure.
View of the Pop Up:
- Target Container: A cluster, host, or resource pool where you want to boot VMs for screenshot verification.
- Target Datastore: A datastore that will host changes to the recovered VMs (they will be discarded once the verification is over).
- Verify not more than X VMs simultaneously: The maximum number of VMs that can be started on the Target Container simultaneously (if many VM backups finish at the same time, you might not want to run all of them on a single host at once).
- Recovery time objective: The amount of time allocated for verification of each VM backup. If a VM OS does not start within the specified amount of time, verification will be considered failed.
- Screenshot delay: The amount of time that the product should wait after Guest OS start before making a screenshot.
So when you specify that you want to have a report sent by e-mail concerning the result of your backup you’ll also get the screenshot of the VM. Usefull? I think yes as you can have VMs which might be backed up correctly and then the backup file might also gets verified for its integrity, but this doesn’t really tells you if the VM which will get recovered from the backup will actually boot or not.. -:). So yes, good point!
Check Nakivo Here.