From owner-freebsd-questions Sun Apr 16 09:52:56 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA06332 for questions-outgoing; Sun, 16 Apr 1995 09:52:56 -0700 Received: from netcom5.netcom.com (pascal@netcom5.netcom.com [192.100.81.113]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA06326 for ; Sun, 16 Apr 1995 09:52:55 -0700 Received: by netcom5.netcom.com (8.6.12/Netcom) id JAA02086; Sun, 16 Apr 1995 09:52:39 -0700 Date: Sun, 16 Apr 1995 09:52:39 -0700 From: pascal@netcom.com (Richard A Childers) Message-Id: <199504161652.JAA02086@netcom5.netcom.com> To: dale@northcoast.com, questions@FreeBSD.org Subject: Re: restoring whole system from tape Sender: questions-owner@FreeBSD.org Precedence: bulk "... I backed everything up on tape (ft0) ... Then I restored all my old files (everything from / down) from tape. ... now I can't log in ..." "How can I get back into my system? Or, alternatively, what's the correct way to restore my system from tape?" I have been remiss in not posting this ... but I've been working with the ft(1) driver, also, evaluating backups, and I've seen some problems. Not with the ft(1) driver, so much as with the QIC-80 / DC2120 tapes that the ft(1) driver relies upon. To summarize : a perfect backup may be seriously flawed and useless. But, there are methods by which this may be objectively verified, and there are also methods by which this may be countered. To wit : I tried making a tar(1) tape, using ft(1). Being a somewhat untrusting soul, I subsequently extracted the tar(1) image into a proximate directory in the same filesystem and ran a diff -r against the two hierarchies, stripping out the string "^Common subdir" for the sake of convenience. There were lots of problems. Corresponding to the lots of problems were some error messages to /dev/console regarding retries and ECC errors. I mention this because it may not be habit of everyone here to watch their system con- -soles. ( Personally, I have a crontab entry which prints system uptime every half hour to /dev/console, so I can also track *when* errors occurred, and be better able to correspond between my own system operations and the errors. A tip of the hat to Tim Radzykewycz for this idea ... ) -=8=- 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. 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 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. Tapes that pass the dd(1) test without errors appear to be flawless, to the best of my testing abilities. ( Each test takes many hours and so I have not tested this every time on every backup I've made, until recently. ) 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. 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. 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. -=8=- Dale : try running dd(1) on your tapes to see if they had problems. This is not guaranteed to be the cause of your problem, but it may be ... -- richard Truth : the most deadly weapon known to civilization. Possession forbidden by employers, governments, and authorities, across the known universe. Violation of this regulation punishable by death. richard childers pascal@netcom.com