30 ms·
A solid list. It's nice to have a restore step in there too, so one has both a validation that the backup is usable, and gives a "playground" where one can hav
by pstuart 7y ago
A solid list.
It's nice to have a restore step in there too, so one has both a validation that the backup is usable, and gives a "playground" where one can have a safe day old environment for testing/training/whatnot against production data.
- __jal 7y agoI don't consider that nice-to-have. That is essential. If you do not regularly test restoring, you do not know if you have backups. I normally overstate this just a little for effect, "If you don't test your backups you don't have backups", but that isn't precisely true. And yes, it frequently makes sense to base test/fixture data and whatnot on backup data flows, but unless you don't deal with any PII, you're hopefully not using that data without a sanitization step.
- JustSomeNobody 7y agoDo you restore to prod? Or to Non-Prod and compare to prod?
- johngalt 7y agoThank you. To anyone viewing my answer as a guide: a backup by itself is not a continuity plan. There are other important areas such as setting recovery metrics (RPO/RTO) and testing restores against those metrics. The world is rife with stories of unreadable backups and/or restorations that took days instead of hours.