[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Has your data been saved!
- To: <lux!everyone>, <lux!wanda>
- Subject: Has your data been saved!
- From: Owen Rowley <acad!lux!owen>
- Date: Fri, 16 Mar 90 09:37:48 PST
>From wanda@megalon Thu Mar 15 18:14:16 1990
The hard drive on my Sun 386i crashed yesterday, along with month
of work. Yet, thanks to the gang over at MIS and the extra effort on
their part, they recovered all my files.
Thanks for going that extra mile, especially, Owen, Donna and Max for
sticking in there.
No problem.. that's my job..
Tenacity is a strange trait, sometimes its a pain in the A*%
other times it comes in handy :-)
Many people in tech have been sensitized to the issue of backups
after hearing of Wanda's near-tragedy, here are a few things they
can consider in order to help insure that their work won't have to
be re-done in the event of a machine related catastrophe.
We have experienced disk failures on SUN 386i machines in alarming numbers.
Release cycle is the period when we can least afford to take chances,
and is also the time of our greatest vulnerability. (time constraints,
high frustration levels, Murpheys Law, added to the general tension that we
have come to accept as normal)
As most of us know, with Unix anything you want to do, can often
be accomplished by a variety of methods. The trick is in figuring
which method is appropriate for your circumstances. Please don't hesitate
to ask for an analysis of your groups backup strategy, I would be happy to
help confuse you with more unique Unix philosophy than you ever cared to
Some groups use an NFS mounted partition from a central machine
to hold "working" directorys for all of the members of the group.
Regularly scheduled backups can then be done on that partition, which
effectively absolves the user from the task of time slicing between
backups and accomplishing their appointed tasks.
Every SUN system has "cron" which allows you to run *jobs* at specified times
or with specified frequency.
I suggest that the command /etc/dump be used rather than tar-bar-cpio or
snap. Dump offers the users the most in the way of options, and a really
nifty restore facility as well. (dump was written by K McKusick and the
Berkeley team during "their" release cycle for the Fast file system because
they were loosing too much work during their normal 16 hour work day,
they were motivated to do it right :-)
The number of options to dump makes it a bit arcane if you're not used to
I will be sending another e-mail out to the tech alias detailing
specific /etc/dump command formulas , If you are using Unix systems
and are not on the tech alias, let me know and I will include you on the
distribution for that mail.
LUX .. owen