The 'old' way of doing things MAY be able to restore that data, but you
cannot be sure. Perhaps the file did not exist when the monthly full
backup was done, or that state is not the one you need because the file
has been heavily changed in between.

*SM is deterministic: If you need to be able to restore up to one year old
backups and to any day's state within this year, just apply the following
settings to your backup copygroup:
VEREXIST=NOLIMIT VERDELETED=NOLIMIT RETEXTRA=365 RETONLY=365

You think, this approach is too expensive? Well, compared to the
'old' method, where you retain a lot of full backups, it is probably not.
But as Juraj Salak described, you can simulate the traditional, non
deterministic behaviour. But what worth is a service level agreement
stating "We MAY be able to restore a X month old state of a file"?

Eric Lindbeck writes:
 > Many thanks to everyone for their great suggestions!  Just one
 > follow-up question:
 >
 > In his reply, Steve Branch described the following situation:
 > "Say you have a  file that changes every day and you back it up every
 > day and maintain 3 backup copies (just an example). Initially you have
 > 3 good copies.  Then the user does something stupid to mess up the
 > file. If the user calls you right then and asks you to restore  from
 > backup you will be ok. Suppose the user doesn't call you thinking all
 > will be better tomorrow. You backup the file that is no longer any
 > good and one of your good backup copies ages off the system. The
 > next day the user tries to fix the problem and still doesn't call.
 > Since the file timestamp got updated again today the corrupt file is
 > again backed up tonight and another of the good copies ages off. If
 > the same thing happens the following day you will have nothing but
 > corrupt copies of that file in ADSM."
 >
 > Even maintaining an ambitious number of versions (5?, 10?, 20?) is not
 > enough to guarantee no data loss under the above circumstances.  It's
 > always possible that the file was corrupted on the day before your
 > oldest version was made.  As strange as it seems that users can work
 > with corrupt data and not even know it, I've seen it happen a number
 > of times.  In an extreme case, I had to go back over 2 months of
 > historical backups to find the last good version of a file.
 >
 > In the 'old' way of doing things, I could keep 1 full backup per month
 > in storage indefinitely.  Then, I could just go to our safe (or
 > off-site provider) and pull the full backup from 2 months ago, merge
 > the tape catalogs into the db, query the db for the file, and do the
 > restore.  What is the *SM method for recovering data in this sort of
 > situation?
 >
 > Thanks again!
 > Eric Lindbeck
 > SCT

--
Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de                       Fax: 
+49(251)83-31653