- Concept art via Pixar
So the guys at Pixar are sitting there, most of Toy Story 2 sitting in digital tatters around them with no working backups when Technical Director Galyn Susman realises she has a working copy on her home computer which she copied so she could work at home and look after her new baby.
So they rush off and pick up this miraculously lucky backup and ferry it back to Pixar protected like a newborn. In the end they were lucky. But not everyone is when it comes to backing up data and systems. (You can see the whole story over at Kottke)
The thing is, if the Pixar crew had tested their backups they would have avoided all this hassle. After all testing doesn’t take long. You can always do other things while you wait for copying and transferring to finish.
Speaking of which, we’re nearly finished, just need to make sure that those files you backed up actually restore. After this you should go back and test your jobs, make sure they are all running like clockwork.
Setting up your restore data
It pays to stay mindful of your system and operational requirements while you are restoring as you don’t want to overwrite live files.
If you’re restoring data:
Create a test area, separate from your live files, where you can dump your restore files that won’t interfere with live or production data or applications.
If you’re restoring Exchange, SQL, Hyper-V or other apps and data:
Create some test data in the app and then restore this into your app. This serves two purposes – when you are backing up it won’t tax open files and it won’t affect live or production systems.
Testing your data
Open up BackupAssist and select the test data or files that you set up earlier. Restore by following the restore process for the type of backup you are restoring (see our whitepapers for more details on restoring) to a new location on your drive. Check the Restore Report for success and warnings. Lastly, open the files that you restored just to make sure they are working correctly.
The Restore Report
By its nature, restoring is an interactive process and if something goes wrong you’ll be there to see it. Notifications will pop up or you’ll receive an error report. It’s not scheduled like backups where you might not notice because they actually operate at some ridiculous hour early in the morning.
The main purpose of the Restore Report is to catalogue any errors you might have had so you’ll know what is going wrong and where.
That’s it! You’re ready to roll having now tested a backup end-to-end.
That was the last from us for now on this little series but we want to hear your stories about testing.
Do you test your backups and/or restores?
Ever wish you had – i.e. set up a job then something failed?
Drop a comment and start a discussion or come across to Twitter, Facebook or Spiceworks and chat with us socially.
