On Mon, 2014-04-28 at 13:30 -0600, YES NOPE9 wrote: > My question has to do with preventing slow deterioration of the data stor= ed. I apologize if this has been discussed and I missed it. =20 One strategy I use is to keep anything remotely important in git - MPLAB projects, schematics, PCB layouts, documents, anything that I want to be able to recover. I have a "remote" git repo on my LAN that I push changes to, and for things that I might want to share, I mirror them to gitorious. gitorious is public, perhaps too public for many since if you use git to the fullest, everyone can not only see your work, but all your mistakes. git knows when things change, and if I don't remember the change, git can tell me what changed. More importantly, if I should shoot myself in the foot (something I am inclined to do all too often), git can give me back the version before I screwed up. And unlike its predecessors, git is fast, so it doesn't interfere with the work if you develop the habit. > There are many ways to keep multiple copies of important data. How does = one insure that the data has not been corrupted and you are merely continui= ng to backup corrupt data. This may be data you do not look at for years. = Is there a file system that manages data integrity with some form of check= sum ? ( I mean checksum in the generic sense which could include polynomia= ls , etc. ) That's the beauty of git - it's whole business is knowing what changed. > I have wondered that about operating systems as well. Is there a techniq= ue for detecting that operating system files , applications and daemons are= not slowly corrupting. I have a old MacIntosh that is now forgetting how = to use DNS services after running for 2 hours. Rebooting it makes it smart= again. One of these times it will not reboot. I haven't got a good answer for binaries, but it ain't all that hard to re-install the OS if you have the configurations, so I keep the configuration files under git control, too, and automatically commit them each night on the crontab. =20 Of course, the real answer for the OS is an occasional image backup. Time consuming for sure, but far less time-consuming than trying to rebuild a system from scratch. -McD --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .