We’re big fans of the phrase “trust, but verify.” It’s useful in many situations, including, you guessed it, checking the integrity of your backed up data and your recovery plan.
It’s great to have a backup plan for all your data. Whether it's your WordPress site, your MySQL database or your whole server, making sure that your data is being backed up correctly, on schedule, and completely is critical. It’s important to trust your service, whether you use SnapShooter or a combination of shell scripts, that your data is getting to where it should be.
Another critical, somewhat overlooked part of a disaster backup plan is the recovery part of that plan. As GI Joe would say, just knowing you’re doing it is half the battle. You’ve got to be able to make sure that you can easily, and hopefully somewhat painlessly, recover your data and re-institute it in your production environment.
That recovery check-in can take several forms. For us, we often will go to our backup provider, be it BackBlaze B2, Amazon S3 or Filebase, and download a recent backup. Once it's down (and be patient, this could take a while,) we will unpack the data, and make sure that everything unpacked and expanded correctly. If you’ve got a test environment, or a Docker or Kubernetes container around, it would be good to restore that data to make sure everything came back correctly and all the data ended up where you expected it to be. Like we said at the beginning, trust your data but always verify that it works as expected.
lease don’t do this on production. We’ve seen it happen and it’s not good. You ended up restoring a more recent backup over your older backup. Like we said, not good.
With recent data center issues, the ever-changing landscape of cloud storage and the changes in your own app, servers, code and databases means you should always be checking your backup and recovery plans. Trust. But Verify.