Performing regular test restores is best practice. End of story. If you’re not doing it, you’re playing a dangerous game of chance when it comes time to recover.
This is important article for all BackupAssist users to read – for all owners and administrators of servers in general, for that matter! We’re going to take a look at why performing regular test restores and recoveries is a crucial element of any good backup strategy. Particularly examining one pertinent example where a small number of BackupAssist customers with unique environments inadvertently lost their backup history (but still maintained a safe most-recent backup) due to a rare VSS issue that has now been remedied.
In cases like this, test restores are vital!
A prime example – if you don’t test, you won’t know
Yes, many solutions (BackupAssist included) offer backup verification checks to show whether a backup is successful or not. But at the end of the day, no matter what solution you’re using, these are never 100% perfect. The only way to be truly sure that your backups are restorable is by actually restoring them.
A perfect case in point is an issue that a very small number of BackupAssist users have experienced from time to time. It came to our attention some time ago that some users doing System Protection backup in certain environments were finding their backup histories being inadvertently lost due to a rare VSS error. This malfunction of VSS occurs most commonly for users who utilize low-performance network destinations, for example:
- Low cost or under spec’d iSCSI targets
- Low cost or under spec’d NAS destinations using data containers
- Non-optimized network infrastructure
In a nutshell, what goes wrong is that the imaging engine experiences difficulty writing to the low performance destination. As a response to this difficulty, VSS deletes the backup history. In most cases, BackupAssist is then able to perform its backup, and does not report any error because it doesn’t know that VSS has just deleted the history – all it knows is that its attempt to write the backup worked just fine.
The point here is that while a very small percentage of users experienced this error, when performing System Protection backups to low performance destinations, those who did often didn’t realize they had lost their older historical backups until much later when try to perform a restore. They would then discover that they only had their newest backup to restore! If this were to happen during a disaster recovery scenario, it could be highly problematic.
Once BackupAssist’s developers become aware that things like this are happening, it’s all too easy to fix the problem. In fact, for this particular issue, we have solved it with a feature called Shadow Copy Protect Mode, which prevents this loss of older historical backups from happening.
But the take-home message here is that if you don’t perform regular test restores, both you and the developers of your backup software solution will not be aware of problems like this one.
For the record – if you’re concerned that this issue may affect you or if you believe your network or storage destination may fit the description above, or especially if you have in fact discovered your backup history has been lost, you can find more information here on both the problem and the solution.
While regular test restores are important for everyone, due to the issue outlined above if you believe your iSCSI target, NAS device using a Data container or network infrastructure may be low-cost, under spec’d or non-optimized, it’s particularly important that you perform a test restore as soon as possible to ensure this issue is not affecting you.
Even if that isn’t you, test restores are always best practice!
As we said above, backup verification is a fantastic tool that can give a very good indication of whether your backup was successful or not. But it can’t exist in a vacuum.
No matter which backup solution you use, performing manual test restores periodically is imperative to ensuring you’re fully prepared for a disaster. There are a lot of variables in backup and disaster recovery that can affect the recoverability of data. These variables not only include unexpected errors and conflicts on the server side of the equation, but also problems with the storage destination and potentially problems in transit too if you’re using an internet-related method of backup. Not to mention the possibility of HDDs being jostled if you’re manually moving them offsite.
Again, no matter what backup solution you’re using, no matter how much you’re paying for it, issues of this nature are always a possibility. The great news is, they’re almost always easily fixed if they’re spotted in a timely fashion. It’s mostly only when they go unnoticed until a live-disaster situation pops up that things get nasty.
Performing regular test restores is best practice. It’s just that simple.
When you perform test restores at regular intervals and you know everything works as expected, that’s when you can fully trust your backup verification tool to keep you updated in between.
How to perform a test restore
There are number of different methods you can use for performing manual test restores, and a lot of what works best for you is going to depend on the environment you’re operating and the infrastructure you have available. It’s worth checking out a couple of other articles we created a while back that dive into the subject in a little more depth:
The most important first step whenever you’re performing a test restore or recovery, is to ensure you have a test environment that won’t interfere with your live, production data. This will probably mean using an old server that you no longer run in production. However, if you don’t have anything that would work for this purpose, it’s also possible to hire test-servers specifically for disaster recovery testing.
Also remember to test your oldest backups, not just the new ones. This is especially important if you are doing incremental backups, because you want to check that you can restore using the incremental changes to your data since the last full backup.
Then it’s just a matter of performing the procedure of restoration in the same manner you would in a real-life disaster scenario.
To get detailed information on how to perform a restore, just go to the documentation page and select the type of backup you performed. On the webpage for that backup type, select the Restore tab. For example, Restoring from a System Protection backup
How regularly do you perform test restores? Has it saved your bacon?
Leave a comment below, tweet @BackupAssist or post to Facebook.
Share this article, because best-practices are a must for everybody.
