Wanda,
I agree, but backing up everything just because it is there is a
very
expensive issue.
In most companies, IT in one form or another is 'charged back' to a
client department, but to keep down spending on IT, the decision is made,
either by IT or the client department management, to not backup
"everything".
TSM is the only backup solution I have run across that does not
re-backup
things that have not changed, and this is why I support it in deference to
other
backup solutions whenever possible.
As I have told clients I consult for, and both management and
internal
clients I have worked for, is "we can back up everything, you just have to
pay
for it". And when the price tag comes out, they don't like the answer.
The compromise is not normally between IT and the end clients, it is
between the client and the budget. IT just gets stuck in the middle.
Other options are:
1. Use a central terminal server and thin client desktops
that do not
have or need disks on the desktop. (Sun has/had a Cashing file system that
worked great, Wise sells Winterm terminals that use a central terminal
server,
there is also the Linux Terminal Server Project to do this with open source
software. It is possible, it works, but lots of folks don't like it for
their
own reasons)
2. I have had some clients where their answer to backups is
to not backup. They put everything on RAID5 systems or mirrors, automate the
checking on
these systems and don't worry about it. (I do not condone this behavior, I
have
just observed it.)
3. Use an operating system that keeps data backed up. I
only know of one, and it is not considered an option by most companies.
Check out AT&T/Lucent/Bell Labs OS called Plan9
(http://cm.bell-labs.com/plan9dist/). It has an interesting method where
when you change a file, it is effectively backed up. And to retrieve it,
just do a change directory to last Tuesday at 3PM if you want to. ...
Interesting in concept, but probably not practical for most of our
institutions. BTW, they migrated, like HSM, off to optical media. I guess
we could emulate this if we had a big HSM system that was used instead of
large disk farms. But Plan9 was DESIGNED with backup as part of its
architecture from what I can tell. It was not retrofitted like every other
OS I have seen (including NT, IBM's VM, *NIX(in all its flavors), MVS, MVT,
IBM's mainframe DOS, CRONOS, and others).
A Backup Story:
Once upon a time I worked for a large oil company supporting their
exploration
department as a unix desktop admin. We purchased some 9G disk drives (huge
in their day) for a few high dollar exploration geophysicists. We also
installed an tape drive on each of these peoples desktop, with instructions
on how to use it, and who to call if there was a problem, or if they needed
tapes, or handholding, etc.
The drives were pretty reliable. But we still suggested users put a tape in
at the end of the day and we (as the admins) would provide a script to run
on
their Sun workstations to tar their files off to tape.
As is normal, users ignore their admins (as we ignore our doctors advice
about
eating and drinking sensibly) and a disk died. We replaced the disk, then
asked
the user for their backup tapes, as we were glad to restore the data for the
user.
The most recent backup was 6 months old. This $100K/year user almost got
fired
over this, as it contained ALL his previous 6 months of effort.
We did get back about 60% of his data, with a $20K recovery fee from a data
recovery
company.
WHY this story? He saved the company millions of dollars in data. Because
it scared
the rest of our user community into asking 'how do I back up my data?' or
'do you
have a tape I could use to backup my data?' etc. It was just an expensive
way to
get there.
We did do central backups of all computer room based data, databases, etc.
But not
the desktops. Why? There was no maintenance window we could have agreement
on to
backup the desktops, and if we did, there was insufficient bandwidth to
centrally
back them up.
Another story of it could be done, but we were told it was not worth the $$$
money.
... Time to go change a tape ... Jack
-----Original Message-----
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 14, 2002 10:11 AM
To: [EMAIL PROTECTED]
Subject: Re: Keeping an handle on client systems' large drives
This is always a trade off between what is
practical-possible-available-affordable and the backup coverage you need.
But I would like to put in a word AGAINST the "if they don't save it in the
right place they don't get it backed up" philosophy.
I'm not criticizing you guys specifically here, this is just MY point of
view on one "backup philosophy" issue that resurfaces continually here on
the list.
Partial backups + user rules has always been the "accepted" solution for IT
support, because backing up "everything" in the environment is hard, and
it's expensive. So backing up "just the network drives" or "just the xxxxx
directory" is the accepted tradeoff, and you teach your users "if you don't
put it on the xxxxx directory you won't get it back".
But, really, when that happens, who wins?
If a user spends two days working on a powerpoint presentation, and
accidentally trashes it, and it isn't backed up because they didn't save it
in the right place --who pays, in the long run? Who are these people, and
why does your company/installation have them working in the first place?
My argument is that if you can afford to lose that person's time, you have
too many people working for you. Most sites I deal with are trying to run
VERY lean on staff, and especially with engineering and software development
sites, the professionals are VERY EXPENSIVE PEOPLE.
Has anyone in your company ever really figured out what it costs when a
software developer/engineer has to recustomize a workstation with a bunch of
software development tools on it when the hard drive crashes? Have you ever
tried to rebuild from scratch a workstation that is running multiple
versions of programmer development kits, when you only have backups of the
data files? Do you know how many hours it takes and how much that person's
time is worth? What it costs to miss a deadline?
Doesn't productivity matter? Or are all the staff in your company useless
drudges whose time has no value? (think carefully before answering that one!
:>)
HOW DOES IT MAKE ECONOMIC SENSE TO SCRIMP ON BACKUP/RECOVERY SUPPORT, AND
WASTE PEOPLE TIME INSTEAD?
My position is that instead of choosing to educate users to work around our
backup support limitations, we should be EDUCATING MANAGEMENT to actually
LOOK at how important their people time is to the company's welfare.
I do realize that we have come to this state because in too many companies,
IT infrastructure is considered an "overhead expense" instead of a critical
resource, and IT managers eventaully get beaten down in the budget battles
and eventually give up trying to keep up with organizational growth.
But keep repeating this over and over, to EVERYONE in your installation:
"EVERY TIME you buget money to buy storage, YOU MUST INCLUDE the cost of
backing it up." Period.
Thus endeth my soapbox speech for the day. Time for lunch..
Wanda Prather
Hot Diggety! Seay, Paul was rumored to have written:
>
> What you have to do is revisit what you are saving and put in exclude.dirs
> for all directories that contain software that can be rebuilt from a
common
> desktop image (hard drive replacment). Have your users save their
documents
> in specific folders and only back them up. Then they just have to
customize
> their desktop configure their node name in the dsm.opt and restore the
stuff
> that is backed up.
>
> This is the trade-off.
Makes sense. Basic education + cost saving vs expense from a brute force
approach. The trick is to have education that works well for a wide range
of users, with differing expertise, and to also clearly communicate
expectations ("if you save anywhere else, you won't get it back!").
Now that sounds like I also have to train them to not just blindly click
whenever an application offers them a default directory (often within app
area) to store documents in.
Perhaps a small data area carved out on the hard drive, like say, 5 GB
partition for user documents as Z: or whatever, and similiarly for other
platforms (/userdocs/<user> as a symlink from ~user/docs or whatever), to
provide a consistent and easy-to-use area for end user, yet predictable area
for mass-deployed *SM configurations to use.
