Text item: Body.822
Regarding all the discussion, confusion, and no doubt disappointment about
include/exclude etc, the thing to remember about ADSM is that it isn't
organized to track backup events. It tracks files, keyed by
nodename/filespacename/filename. Anytime a file arrives at the server
matching those three values, the new file becomes part of that set,
retaining no memory whatsoever about the event that sent it or the other
files that arrived with it. (This is about backup, not archive).
Someone has said he uses seperate nodes for the weekly, monthly etc.
backups. This works because the three key values don't match. If you
don't want to use and pay for seperate nodes, you could try renaming the
filespaces in the server. For example, if the real filespaces are /, /usr,
etc, rename them to /daily, /daily/usr, etc, then run the weekly with the
different include/exclude options on the client. New filespaces will be
created in the server named /, /usr etc. After the weekly backup is done,
rename them to /weekly, /weekly/usr etc and rename the /daily* back to the
real names.
The trick for the developers is to add event memory to ADSM to provide very
longterm point in time restore without ruining the current structure, and
at the same time exploit the current structure to provide short term point
in time restore. I sure hope they are working on this for the next
version.
Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.
_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Re: Different includes/excludes
02-19-1997 11:16 AM
Date: Wed, 19 Feb 1997 11:16:00 -0600
From: Mattice Dave <dmattice AT shl DOT com>
Subject: Re: Different includes/excludes
To: ADSM-L AT vm.marist DOT edu
If the following message Andy Raibeck says:
> - If you change the management class on an INCLUDE statement, all existing
> backup versions of files affected by that INCLUDE will be re-bound to that
> management class (i.e. you can't have Monday - Friday's backups bound to
> one management class, and Saturday's backup bound to another -- all backup
> versions of the same file must be bound to the same management class).
Does this mean that I cannot change the management class
on a "dsmc" command line to indicate that on one day the files
in directory "/abc" are to be kept for 1 week and that on another
day the same files in "/abc" are to be kept for 4 weeks?
We have a requirement to perform weekly backups that are kept
for 6 weeks, monthly backups that are kept for 12 months and
annual backups that are kept for ten years. I thought for these
backups, monthly and yearly, separate management classes
would work. If not, how are other site dealing with this?
Thanks,
Dave Mattice
MCI Systemhouse
----------
From: Andy Raibeck
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Different includes/excludes
Date: Tuesday, February 18, 1997 2:11PM
Dave Sanders asks:
> A client would like to have a seperate include/exclude list during the
week
> vs. during the weekend. I know there have been discussions about this in
> the past,,, but could someone refresh the topic??
Some issues/problems you can run into:
- Backup versions of files that were included but are subsequently
excluded
will be expired the next time incremental backup runs. In other words,
the
exclusion is for all backup versions, not just for any that might have
been
created while using that version of the include/exclude list.
- If you change the management class on an INCLUDE statement, all
existing
backup versions of files affected by that INCLUDE will be re-bound to
that
management class (i.e. you can't have Monday - Friday's backups bound
to
one management class, and Saturday's backup bound to another -- all
backup
versions of the same file must be bound to the same management class).
In general, I wouldn't recommend flip-flopping include/exclude lists
around,
although I don't have the specifics of your particular situation.
Andy Raibeck
ADSM Level 2 Support
|
