Hi Jerry!
Your thesis is, the users who use good and advanced tools
(which ADSM undoubtly is) should politely adopt their
needs to the abilities of that modern tool.
I fully agree with you that there is need, better - must,
to re-think what the real backup needs are
when moving from simple backup tools to ADSM.
Yes, typicall requirements to perform daily,
weekly, and monthly full backups arose mostly through adaptation
of real backup needs to plain abilities of
common backup tools.
New analysis of both data loss risks and
intended, planned restorations can show that ADSM´s backup approach
can fulfill the real needs much more efective
than regular full-backups.
But I cannot agree with your conclusion that:
> In my mind, the combination of an adequately defined
> management class that meets the customer's needs,
> coupled with a backup copypool, covers backup
> requirements.
If you are right, help me to define management classes
for following exemplary requirements, both chosen
from several existing in our development environment:
--R1) We develop and sell customized software.
Due to different reasons (on-line support,
warranty, further development at later time, ..)
we need to backup sets of files and keep them for
defined period of time.
You could argue, this is task for a SCM
(software configuration management) tool,
but there are some good reasons why to use
backup tool for this taks instead / in addition to SCM tools.
--R2) We use more small databases.
To cope with logical errors (people use this databasea,
and people are error-prone)
we keep N-backup versions of all databases.
The backup is only good if all files are
in consistent state.
What is the solution? I have till know not
found a reasonable solution with ADSM.
solution with:
DSMC SELECTIVE
---------------
is what approximately helps, but not fully.
The problems are:
--P1) "SELECTIVE" will not backup empty directories.
Some of our tools use empty directories as information
holders. (the name and tree structure and/or
extended attributes holds the information).
--P2) There is no parameter by SELECTIVE and also no
parameter in management class, which would guarantee
that actually active file version will be kept for
time period wanted. To fulfill this criterium,
you have to to define/use copy group with appropriate large
"Versions Data Exists, Versions Data Deleted, Retain Extra Versions"
parameters.
While (R1) raises irregulary, same files are backed up regulary
with INCREMENTAL. This has to be taken in account when defining
the backup copy group from above, too, and leads to
much, much more versions of files kept in ADSM´s backup than nessessary.
Our estimation is 20 to 30 times as much as nessesary.
--P3) How to restore such old data?
There is no way to achieve clean point-in-time restore in ADSM.
At the very best, you will receive after hours of waiting
more files restored than actually needed.
--P4) performance -- Though unnessesary, SELECTIVE
will backup all files, even if most of them are already
in its storage pools in correct revision.
solution with:
DSMC INCREMENTAL
----------------
shares (P2) and (P4) with SELECTIVE´s
solutions and adds
--P5) there is no way how to backup selected
files/directories only. In order to backup couple
of thousands files (our typicall number),
adsm has to traverse hundreds of thousands of
files. This costs much time, ressources, and
backups many files which should not be backed up at this time.
--P6) I am not sure at all how directories are treated.
As directories do contain information realted to files
concerned, I would like them to use same copy group
parameters as flat files do.
solution with:
DSMC ARCHIVE
----------------
Forget it.
--P7) Archive will not backup directories
--P8) Archive cannot be restored to another destination
(although "working as coded",it is useless in real scenarios).
--P9) Archive adds redundant files to storage pools and
costs such much CPU, network and storage ressources.
Simply - Archive is only an small add-on for archiving files,
not file/directory sets, and goes anyway "against
the major design features of ADSM" - just as your
hypothetical manager.
I have very clear imaginations how could ADSM cope with
this and another own flexibility limitations, but the new V3
while addressed very important problems
contributed very little to (R1) and (R2) solution.
Jerry, if you have a good ADSM-based solution for me,
I will adopt it, definitely abandon my "Father's backup tool"
which I still use in addition to ADSM
and send you an excelent slovak beer.
Juraj Salak
sal AT keba.co DOT at
>
> I have been lurking in the background on this thread, but I can no longer
> contain myself here.
>
> The basic problem that people are trying to address here is something that
in
> my estimation goes against the major design features of ADSM. That is it
> isn't designed to do weekly and monthly full backups - If it was - there
would
> be a "Full backup" option available from the backup options.
>
> When I see one of these threads start up, I believe there is a person
> somewhere - probably a manager, but I've been reading Dilbert again, that
> thinks that the only "safe" way to have a backup is to do full weekly,
monthly
> , or yearly backups. The beauty of ADSM is that the developers and
designers
> took the time to think "out of the box" and ask "Why?"
>
> In my mind, the combination of an adequately defined management class that
> meets the customer's needs, coupled with a backup copypool, covers backup
> requirements. Weekly and monthly backups of the same files just duplicates
> the same data over and over again - probably costing more in terms of time,
> tapes, and management, not to mention machine and network utilization. And
in
> my company, the critical resource is more and more the network - and anyone
> who thinks that it isn't being used in the middle of the night hasn't looked
> at it many years.
>
> There are only two arguments that I have heard for periodic backups that
have
> (some) merit. The first of these are legal requirements to keep a point in
> time backup. Never pays to argue with a lawyer (I know - I have a son in
Law
> School). This is where Archive comes into play. The second is the issue of
> the number of tapes that a client is spread across. This argument has some
> real concern, although it can be mitigated by using collocation. To a
certain
> extent here, this is a case of "pay me now, or pay me later". IN this case,
I
> am willing to take the extra time later, traded off against having a good
copy
> off site that is managed for me. I know not all will feel this way.
>
> As someone said on this list a while back - ADSM is not your Father's backup
> tool. I get concerned when people start trying to make it into one. I
will
> now get off of my soapbox, with the parting quote from StarTrek V - "Let go
of
> your pain".
>
> So let me have it - I can take it! :-)
>
> Jerry Lawson
> jlawson AT thehartford DOT com
>
|
