Date: Sun, 16 Apr 1995 09:52:39 -0700 From: pascal@netcom.com (Richard A Childers) To: dale@northcoast.com, questions@FreeBSD.org Subject: Re: restoring whole system from tape Message-ID: <199504161652.JAA02086@netcom5.netcom.com>
next in thread | raw e-mail | index | archive | help
"... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504161652.JAA02086>