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.