You have most likely not heard of the concept of Schrödinger’s backup that has been coined in IT, but many people are running this experiment without even knowing it. It states: “The condition of any backup is unknown until a restore is attempted.” To give a little background if you have not heard of the thought experiment devised by Austrian physicist Erwin Schrödinger in 1935 called Schrödinger’s cat here is a brief summary of it. Schrödinger’s cat: a cat, a flask of poison, and a radioactive source are placed in a sealed box. If an internal monitor detects radioactivity (i.e. a single atom decaying), the flask is shattered, releasing the poison that kills the cat. So once the box is closed the cat can be thought to be both alive and dead until the box is open. If you do not test your recovery plan you are unknowingly running a Schrödinger’s backup experiment, as your backup can be thought of as both being a good backup and being bad backup.
NovaStor’s support team works with people every day that are running their own Schrödinger’s backup experiment. They configure the backups like they think they should, see the backups work without error and think everything is good. Then when disaster strikes they try to do a restore and restore the files they backed up or the application and it doesn’t restore what they think they backed up or don’t know how to properly restore the application. An all too common issue NovaStor’s support team sees are users that thought they backed up their QuickBooks, important documents, or other things that they regularly run and open. They restore the data they backed up and it does not restore what they think they backed up, and more often than not what they backed up was just the shortcuts to their important data. This is one of the many reasons that here at NovaStor we include free consultation, installation, and support with our server based products. We want to make sure that your backups are setup and the right data is selected.
Having the right data selected for backup and backups running regularly and correctly is still only part of the solution to know you have a good backup that can get you back up and running. You must document the procedure on how and where to restore the data and/or application that you are backing up. Restore documentation shouldn’t just contain information about the restore. It should also include hard copies of currently used versions of relevant software, serial numbers for any software, contact numbers for support, and support contract reference numbers. Any documentation should have a date of when it was last updated and tested, for wrong documentation can be worse than no documentation at all. All documentation should have a glossary page explaining the acronyms to ensure that the person reading the documentation understands what the person who wrote it was trying to say. The restore procedure should also periodically be tested, and the documentation that is created should be followed to the letter, and any changes needed to the documentation should be noted and updated. Think of it like a smoke alarm, you are supposed to test your smoke alarms when you change your clock for daylight savings time. Making sure that you are alerted that the building is burning down needs to be at the very least as important as knowing that if the building did burn down that you could restore your data.
A good article to read that goes into more detail about Schrödinger’s backup and what one team went through in order to prove their restore strategy works.