[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Has your data been saved!



>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 
know. :-)

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
it though!
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