The method I use and recommend is to pick one of your critical files or directories, and once a month (I use the first weekday of the month) restore the file to a test location and verify that its contents are usable. In my case, I restore a Microsoft SQL database dump to my backup server, and try to restore the database from the dump. If MSSQL says it's ok, that's good enough for me.
(OTOH, I'm the paranoid one who uses two tapes every day: one changed by hand, and one changed by auto-loader, so I'm covered against human or mechanical failure.) > -----Original Message----- > From: Joshua Baker-LePain [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 06, 2001 10:53 AM > To: Ole Barnkob Kaas > Cc: [EMAIL PROTECTED] > Subject: Re: Verifying backups > > > On 6 Dec 2001 at 2:29pm, Ole Barnkob Kaas wrote > > > How do people verify their backups? Are there some nifty scripts or > > tools available somewhere. Restoring 20GB+ of data just to > find out that > > tar or dump has trashed some of the data is a tediuos task. > Especially > > because you know you have to do it again when the problem > is fixed to > > ensure that the data really is ok. > > Well, there's amverify, but all it does is generate a table > of contents > from the tape images -- if that succeeds, the tape is marked > OK. Note that > there is no comparison of the TOC to index files or file > system contents, > so this isn't exactly the best. > > > Checking the history of both tar and dump reveals so many > issues that > > one has to wonder if it is ever possible to guarantee a > safe backup on a > > Dump has its issues, yes. But a lot of people depend upon tar. > > > linux box. Some cron task that could do a file to file > compare or md5 > > compare would really help me sleep at night. > > Patches welcome. ;) > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University >
