Date: Mon, 17 Apr 1995 02:39:59 -0400 From: steve2@genesis.tiac.net (Steve Gerakines) To: freebsd-hackers@FreeBSD.org Subject: Re: restoring whole system from tape Message-ID: <199504170639.CAA02176@genesis.tiac.net>
next in thread | raw e-mail | index | archive | help
> The problem is that neither tar(1) nor dump(8) report these errors, so if one > is merely reading a log collected from stdout(), or watching the screen, one > sees nothing but a flawless archival. The problem is that it is impossible for floppy tape drives to detect soft media errors (CRC errors) while writing. That's why the ecc is so involved and built into the standards. With the ecc you get up to three sectors with CRC errors or 1 CRC failure (a trashed sector that made it by CRC checks) on a tape segment. Any more than that and a segment is destroyed. This is one of the dangers or compressing an entire backup such as 'tar cvzf - / | ft "save me"'. If there is a failed tape segment decompression will fail and the rest of the backup is lost. If the files were compressed individually before being tarred it's possible to continue the restore at the next file. > However, the same test I've used in other Unix environments to verify media > afterwards works great with FreeBSD and ft(1), too. > > # ft | dd of=/dev/null If I have a backup that I positively absolutely cannot have fail (such as nuking my filesystem before upgrading), I use the compare option of tar instead of dd. > If there is interest I can post a very simple script I've written that uses > the archival method of your choice ( tar(1) or dump(8) ), creates a log of the > entire process to disk ( for time-motion-throughput analyses ), and, best of > all, does a dd(1) of the tape afterwards to verify the image. This is what I do as well. An example of doing this would be great. > For what it's worth, I'm not clear on whether such tapes are useless, or > only need to be reformatted. I purchased them preformatted, so they > should have worked. Don't count on it. :-( The "new" DC2120 tapes I've purchased often have lots of defects. That's not a problem so long as the detects on the tape match what is on the tape's bad sector map. If a tape has been preformatted and the bad map recorded and it picks up new errors while sitting on the shelf, the tape needs to be reformatted. The ecc code relies upon having an accurate bad sector map. > I'll post as I learn more on this topic - I would assume that there > are quite a few people whom have chosen the midrange archival solution of a > floppy controller tape drive, rather than a high-end SCSI tape drive. My advice to people is to save your pennies and avoid floppy tape drives if possible. While I think they do get the job done for a small personal system, if you can afford a better solution, floppy tape drives are not worth the lost time and aggravation. (If I could convince my wife that fast and convenient backups are worth the extra $$ I would have a SCSI tape too. :-)) > Pointers to more detailed reference materials with respect to QIC-80 tapes and > their low-level formatting mechanism(s) would be useful. Once I have read them > perhaps I can translate the technojargon into some fairly straightforward > behavioral descriptions. Any information you can dig up on tape formatting would be wonderful! For me this really the biggest grey area with these drives. When I last checked the QIC standards themselves made very little mention of formatting. There are lots of areas that the standards overlook, but this is the biggest. If you're looking for a simple project to start with, it should be fairly straightforward to write a "ftverify" command. The program would basically just read all segments on the tape and then update the badmap in the header segment. It's not formatting, but at least you can make sure your badmap is up to date. - Steve steve2@genesis.tiac.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504170639.CAA02176>