Hacker News new | past | comments | ask | show | jobs | submit login

> also a good time to remind people that backups are not backups unless they're geographically diverse.

... and backups are not backups until you can reliably restore from them.




...and a DR plan isn't worth the paper it's written on unless you test it regularly (people leave, media gets corrupted... just like the military; do drills!)


Paper? You write on paper? My DR plan is in a file and backed up locally, and ... um ... oh oh.


... and a DR plan isn't worth anything unless you test the "people leave" part without any knowledge in their heads. your internal documentation and credential storage needs to be solid in case four people flying together all die abruptly in the same plane crash. the traditional "bus problem".


And that you regularly test that property.


But how do you test that reliably if the filesystem makes files disappear?

I.e., you'll have an original that misses some files, and a backup that misses the same files. A diff will show nothing.


Compare an older snapshot to current for unexpected changes? Though that is difficult (probably not practically possible in the general case) to automate because telling the difference between rare but expected changes and unexpected ones due to corruption could require quite some intelligence/intuition.

No backup+test stratergey can catch everything. You just have to be sure to catch everything that you practically can (and need to factor your time & effort and the importance of the data, into the judgement about that is practical to do and what is justifiable or unavoidable risk).


Unlikely to be the same files


In the general case, but in this case isn't unlikely at all: you have a ZFS pool that suffers from this bug, you back it up, the missing files doesn't show up neither in the original or in the backup.


And they are not backups unless DD is somehow involved.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: