ADSM-L

FW: Requirement for ADSM to store only one copy of a file

1996-01-04 03:28:03
Subject: FW: Requirement for ADSM to store only one copy of a file
From: Andrew Mark Raibeck <raibeck AT CONNIX DOT COM>
Date: Thu, 4 Jan 1996 03:28:03 -0500
Terry Moore asks:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter follows =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Once a long time ago in a land far away (or so it seems now), I spoke
with an IBMer who was selling the virtues of ADSM at a seminar.  We
talked about the need to make ADSM smart enough to recognize that
100 people were backing up the same file (e.g. WINWORD.EXE) and to
have the server keep only a single copy of that file with all 100
user's pointing to it.  He indicated that we would likely see this
in a future version, but I haven't seen discussion of such a feature.

We would really like to be able to use our ADSM backups to rebuild
a PC after a hard disk crash, but don't feel that we can afford to
have 4,000 copies of Windows' EXE, DLL, etc. files bogging down our
MVS server.  Currently, we exclude these files in order to keep from
running into problems.

Anyone else out there have a need for this feature?
Anyone from IBM care to comment on directions?
Or am I missing the boat completely?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter ends =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My own thoughts on this: I agree that this would be a desirable feature. =
But I don't know how other products implement it. ADSM currently doesn't =
inspect the contents of a file. I suppose it's possible that two =
different files could have the same name, size, and modification =
date/time. Maybe not WINWORD.EXE, but perhaps something like MYDOC.TXT. =
This might not be as far-fetched as it sounds. I have no idea how other =
vendors provide a solution to this.

The other issue is that you might want to store certain clients' data in =
one storage pool, and another client's data in a different storage pool. =
If they happen to have duplicate files, and you keep only one copy, then =
the backup can exist in only one storage pool. So any implementation of =
this feature would have to be optional, perhaps at the management class =
level.

In the long run, most of your client data will wind up on tape, anyay, =
which is cheap (relatively speaking). And as tape densities increase =
further, the number of tapes required to house all this data will =
shrink. So except for the initial time it takes to get a full backup of =
a client, this may or may not be as big an inhibitor as it seems. Just =
another way of looking at things.

Andy Raibeck