11–20 of 152 posts
I think having a day for a whole year is a bit sparse. Some startups start and shutdown within a year. Apart from checking backups after any big code change related to backups, I think backups should be checked quarterly. It takes no more than couple hours most of the time, and as our wise said, "An ounce of prevention is worth a pound of cure"
This is every day at Facebook! https://code.facebook.com/posts/1007323976059780/continuous-...
I think having a day for a whole year is a bit sparse. Some startups start and shutdown within a year. Apart from checking backups after any big code change related to backups, I think backups should be checked quarterly. It takes no more than couple hours most of the time, and as our wise said, "An ounce of prevention is worth a pound of cure"
Check your backups daily. The whole process is automated and shouldn't cost much.
Earlier quoted context omitted.
Check your backups daily. The whole process is automated and shouldn't cost much.
Then we'll have a check your check your backups day where you make sure your automation isn't making sure the sky is blue.
[1] https://thatgeoguy.ca/blog/2013/12/26/encrypted-backups-in-d...
Quite another to test the backup's restorability.
Most of us back up. Very few test that the backup works as intended. I need to do better in the later.
Earlier quoted context omitted.
Then we'll have a check your check your backups day where you make sure your automation isn't making sure the sky is blue.
It's in there now. Row counts per table and checksums are written out with the backup for every table. If things don't match up, alarm in a loud and noisy way.