Backup and disaster recovery (BDR) is an interesting technology to discuss with clients; when it is working well, there is little to discuss. However, when it is needed, such as in the event of a data loss event, it has to work perfectly—and, it needs to do so before that data loss event. Unlike other MSP technologies, sharing verification with your SMB clients that a BDR platform is working well allows for a natural, ongoing conversation about the BDR solution you provide, and keeps the importance of business continuity top of mind.
But what if your BDR platform’s backup verification isn’t able to provide enough information? What if it can’t capture issues that slip through the cracks? What if backups fail because the verification process missed something?
Unfortunately, the majority of BDR verification processes used today rely on a process known as single-screenshot verification. With single screenshot verification, the system will test to see if a backup restore point can produce a successful virtual machine. If the VM is successful, it will capture an image of the OS login screen, thereby proving the backup worked, presumably. If the backup failed, no image would be able to be taken, because it did not reach the OS login screen.
Shortcomings of Single-Screenshot Verification
1. If backups fail, it's not clear why.
It’s pretty clear that gaps exist in this process. First of all, if a backup fails, there is no information to understand why it failed. MSPs can only see the symptom of a problem, not the root cause. This means time is spent investigating the problem, and understanding where and how it was caused, if it was anomalous or systematic, and how it can be fixed. All of these steps are time-intensive, and if MSPs are responsible for verifying backups on tens, hundreds, or even thousands of restore points each day, it is quickly a system that cannot scale.
2. Issues could still exist despite a successful result.
Second, single-screenshot verification leaves the door open for false positives. For example, if a virtual machine crashes a few minutes after reaching the login screen, the MSP would have no idea there was an issue with the backup, because the single screenshot would seemingly indicate the backup was successful; there’s no way to differentiate between a normal and an abnormal boot process.
3. It doesn't account for non-standard boot processes.
Additionally, what if there are Windows updates that require an additional restart to take effect? Single-screenshot verification will display this as an error, instead of waiting for the update and restart to complete.
Luckily, there’s a new option, based on time-lapse screenshots that record the entire VM boot process. Known as Tru-Verify™, and only available with Continuity247®, Continuum’s NOC is able to view an entire video of the boot process. This allows for a more detailed look at the verification process and a better understanding of any issues that may occur—providing the NOC and the MSP a clearer picture and subsequently faster remediation times.
Tru-Verify can see things like disk corruptions, blue screens, boot errors, and if there were any windows updates causing the machine to hang after a restart. It automatically detects the best configuration for a test VM. With single-screenshot verification, the MSP has to guess and configure good settings for a VM. There is no chance for false positives with Tru-Verify, either, because if there’s an issue with virtualization, it will have a record of the issue and can differentiate between a normal and an abnormal boot.
If a picture is worth a thousand words, then video is surely worth a lot more. If you’re using a BDR platform that relies on single-screenshot verification, there is a lot of information you may be missing, and it could be slowing down your operational efficiency.