> This way you might be able to restore something
> from more than 90 days ago. Makes it harder to
> tell your clients exactly how back you can
> restore from. :-)
Well, that depends on what the "ago" means in "from more than 90 days ago".
If you mean "from more than 90 days since I made the first backup" then
yes, you are correct.
But if you simply want to allow your users to restore an older backup
version as far back as 90 days ago, then something like this would be the
ticket:
VEREXISTS=NOLIMIT
RETEXTRA=90
VERDELETED=NOLIMIT
RETONLY=180
Then what you have is a service that, as long as the file exists on the
client file system and as long as you do at least one backup a day, assures
that you can restore that file to the state it was in (within a 24-hour
granularity) up to 90 days ago. "24-hour granularity" is just a caveat to
account for multiple changes that might occur between daily backups. For
instance, suppose I change the file several times in the course of a day,
and do a daily backup. So the file goes through these transitions:
state1
state2
state3
state4
state5
DAY 1: DAILY BACKUP OF FILE
state6
state7
state8
DAY 2: DAILY BACKUP OF FILE
Now I can't restore the file as it was in states 1-4, 6, or 7, but I can
restore it as it was in states 5 and 8. Also, from the time the file
changes after state 5, I have 90 days in which I can restore it to state 5.
If the file is extremely critical, then I might want to back it up after
*every* change. So I might do this:
state1
DAY 1: SELECTIVE BACKUP OF FILE
state2
DAY 1: SELECTIVE BACKUP OF FILE
state3
DAY 1: SELECTIVE BACKUP OF FILE
state4
DAY 1: SELECTIVE BACKUP OF FILE
state5
DAY 1: SELECTIVE BACKUP OF FILE
state6
DAY 2: SELECTIVE BACKUP OF FILE
state7
DAY 2: SELECTIVE BACKUP OF FILE
state8
DAY 2: SELECTIVE BACKUP OF FILE
This is what the VEREXISTS=NOLIMIT buys you: After the backup of the file
in state 'n', you can restore that file to an older state from a backup
version taken any time between now and the last 90 days, regardless of how
often you back it up.
Note that in the latter scenario, you don't see any daily (scheduled)
backups of the file. That's because assuming you back it up manually
(SELECTIVE backup) every time you change it, when the scheduled incremental
backups run, it will see that the file has not changed since the last time
you backed it up, so it won't be backed up redundantly.
The VERDELETED=NOLIMIT means that once you delete the file, then the next
time your daily backup runs, it will detect that the file is gone from the
file system and mark the latest version as inactive. From that time, you
can still restore to an older state from a backup version taken within the
last 90 days, and the latest backup version will be kept for 180 days (from
the time it was inactivated), giving you *some* kind of fallback in case
someone decides after, say, 120 days, that they want the file back. Of
course, at that time you would only be able to get them the latest backup
version because all the others would have expired, but at least its
something. By the way, the RETONLY doesn't have to be more than 90 days, if
you want to impose a strict 90-day policy, then you can set RETONLY to 90
days as well. But RETONLY just provides a means of giving your users one
last "out" to restore a deleted file.
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
Patrick Boutilier <boutilpj AT STAFF.EDNET.NS DOT CA>@VM.MARIST.EDU> on
03/30/2001
11:41:32 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Confusion with retention values.
Makes sense. I did a query on the BACKUPS table and that shows the
deactivate
date. Too bad the clients didn't show the deactivate date. :-)
I always assumed that Retain Extra Versions = 90
meant that anything that was backed up 90 days ago would be deleted, not
90
days from the deactivation date.
This way you might be able to restore something from more than 90 days ago.
Makes it harder to tell your clients exactly how back you can restore from.
:-)
STATE LL_NAME BACKUP_DATE DEACTIVATE_DATE
------------------ ------------------ ------------------
ACTIVE_VERSION 36E54BF0.000 2001-03-20
ACTIVE_VERSION 36E54BF0.000 2001-03-20
INACTIVE_VERSION 36E54BF0.000 2000-12-08 2001-02-17
INACTIVE_VERSION 36E54BF0.000 2001-02-17 2001-03-20
Quoting Andy Raibeck <Andrew_Raibeck AT TIVOLI DOT COM>:
> By "keep versions for 90 days", I assume you mean the RETEXTRA setting.
> I
> think the confusion may come from thinking that this setting indicates
> how
> long to keep backup versions from the time they are created (?). This
> is
> not the case; rather, RETEXTRA indicates how long to keep the backup
> version after it goes in inactive. So if the next backup version after
> the
> one created on December 8 was taken, say, January 8, then the 90 day
> count
> for the Dec 8 version starts on Jan 8. Thus it would be eligible for
> expiration on April 8 (or thereabouts if I counted 90 days correctly).
>
> The idea is that if you are doing incremental backups on a daily
> basis,
> backing files up only when they have changed, then by setting RETEXTRA
> to
> 90 days, you are helping to ensure that users can recover a file up to
> 90
> days after they made a change that they want to undo.
>
> RETEXTRA also works in tandem with VEREXISTS. This means that there is
> not
> necessarily any guarantee that the file will be around for 90 days.
> For
> example, if the file changes every day and VEREXISTS is set to, say,
> 5,
> then on day 6 when the 6th backup is taken, the 1st backup taken on day
> 1
> will be expired regardless of the RETEXTRA setting.
>
> On the other hand, if VEREXISTS is set to 10 but the file changes only
> a
> monthly basis, then you will never have 10 backup versions at a time
> because any extra (inactive) versions older than 90 days will expire.
>
> So... if you want to provide a service that will almost always
> guarantee
> that your users can recover files up to 90 days after changing them,
> you
> could set VEREXISTS to 90 (or 91 if you want to "fudge" a day). Then
> even
> if the file changes daily causing your daily backups back it up every
> day,
> you'll have that 90 day restorability.
>
> Other food for thought: sometimes uesrs want multiple backups per day.
> In
> that case, if VEREXISTS is set to 90 and you make, say, 2 backups a
> day,
> then you'll only have 45 day restorability (2 backups per day,
> VEREXISTS=90
> means 45 days to restore the oldest version before it expires). If
> this
> goes on a lot in your shop, consider setting VEREXISTS to NOLIMIT. Then
> you
> can take as many backups as you need, and all the inactve versions will
> be
> around for 90 days after they go inactive.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Tivoli Systems
> Tivoli Storage Manager Client Development
> e-mail: araibeck AT tivoli DOT com
> "The only dumb question is the one that goes unasked."
>
>
> Patrick Boutilier <boutilpj AT STAFF.EDNET.NS DOT CA>@VM.MARIST.EDU> on
> 03/30/2001
> 06:43:04 AM
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Confusion with retention values.
>
>
>
> Hello,
>
> I have a Backup Copy group defined as where I keep versions for 90 days
> and
> keep
> deleted files for 90 days (at least that what I think it should do).
> However I
> see files hanging around for more than 90 days when I do some looking.
> For
> instance there is an inactive file called 3744c320.000 that was backed
> up
> on Dec. 08, 2000. This file is older than 90 days so it should be
> expired.
> So
> far I have only seen this with Netware servers. Any ideas? Thanks.
>
>
> ADSM Server = 3.1.2.90
>
>
>
>
> Copy Destination NETWAREDISK
>
> Frequency 0
>
> Versions Data Exists 9999
>
> Versions Data Deleted 9999
>
> Retain Extra Versions 90
>
> Retain Only Version 90
>
> Copy Mode Modified
>
> Copy Serialization Shrstatic
>
Staff Sig...
|
