Hi Alex,
The RETEXTRA and RETONLY values both start counting days from the
time the versions go inactive. So in your example, the version that
went inactive on day 4 (file was deleted) will be expired on day
10. Thus, with RETEXTRA and RETONLY both being 10, there is no
distinction between the expiration of any of the versions.
I can see the confusion because at the time the file is deleted on
the system, it isn't necessarily the *only* remaining version, so I
can see how RETONLY could lead you to think that it means "number
of days to expire after it becomes the only version". But no, the
counting starts from the time the backup version is marked
inactive. The RETONLY just gives you that little bit of additional
flexibility that says, "once I delete the file, keep the last
(latest) remaining version for x days from the time I deleted it".
Actually, it isn't from the time you deleted it, it's from the time
it was inactivated; which, if you do daily backups, could be called
"close enough"... :-)
If you want to leave your users with one last "out" to restore a
deleted file, then set RETONLY to something higher, say, like 20.
Then users have up to 20 days to restore the last remaining version
of a file that they deleted.
In the case of Patrick's question, he had this for his versions:
STATE LL_NAME BACKUP_DATE DEACTIVATE_DATE
------------------ ------------------ ------------------
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
The oldest version was created on 8 December 2000.
The next oldest version was created on 17 February 2001. Note that
that is the deactivation date for the oldest version, so that is
when the clock starts ticking. Thus the oldest version will be
expired 90 days after 17 February 2001, which would be around May
18th (if I counted 90 days correctly). Thus the user has up to 90
days to restore that older version, should she decide that restore
is necessary.
Similarly, the most recent version was created on 20 March 2001,
which is when the second oldest version was inactivated. At this
time, the user has up to 90 days to restore the prior version,
which will expire on June 18.
If you do daily incremental backups, you can consider that each new
backup represents a change to the file. With the 90 day RETEXTRA
settings, the user has up to 90 days to "undo" a change that was made
to the file and get it back to its prior state.
Of course, the file may change several times during the day, so the
"undo-ability" is only within a 24-hour granularity (again, assuming
daily backups), which is sufficient for most files. For more critical
files, you could do more frequent backups (i.e. multiple backups
in a 24-hour period) but this would require that VEREXISTS and
(optionally) VERDELETED have larger values, even maybe NOLIMIT, as
I discussed previously in this thread.
Now for the sake of discussion, let's assume that RETEXTRA worked the
way that Patrick thought, which is that inactive versions will
expire 90 days (in Patrick's case) from the date the backup was
created.
If it worked this way, then the 90-day clock would have started
ticking on 12 December 2000, so when the user changed it on
17 February 2001, she would only have until 12 March 2001 to change
her mind, which would be 23 days. Or, suppose the file was changed
on, say, the 20th of February instead of the 17th. In that case,
ther user would have only 20 days to restore the prior version.
Taking this a step further, suppose the original backup was taken on
8 December, but the next backup didn't occur until, say, 20 March
(because the file didn't change). In this case, if TSM worked so
that the clock started ticking from the date the backup version was
created, then the 8 December version would be expired as soon as
the 20 March backup was taken, giving the user *no* opportunity to
restore the prior version.
So... if you consider it in this light, the way TSM actually works is
more consistent since you have a predictable restorability. That is,
in Patrick's case, the user has up to 90 days to restore a file to
its prior state after changing it, regardless of when she changes it.
This is as opposed to the latter cases I just described above where
the restorability is not really predictable at all.
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: [EMAIL PROTECTED]
"The only dumb question is the one that goes unasked."
Alex Paschal <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 03/30/2001
10:48:45 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Confusion with retention values.
Andy,
Does RetOnly START counting days after the version becomes the only
version,
or does it count days from the day the version became inactive?
For example, lets say VerExists 3, VerDel 3, RetExtra 10, and RetOnly 10,
just to choose some arbitrary settings. File A is created on day 1 and
modified each day for 2 days thereafer, then deleted, so there are a total
of 3 versions.
File A(day1) goes inactive on day2, expires on day 12
File A(day2) goes inactive on day3, expires on day 13
File A(day3) goes inactive on day4 (day deleted)
On day 13, File A(day3) becomes the only version left on the *SM server.
Does RetOnly now start counting? If it counts from inactivation date, it
should expire on day 14, 10 days after deletion/inactivation. However, I
think it should start counting from the day it becomes the only version,
ie,
day13, and expire on day23.
Can you verify which way it works? If it works the way I think it should,
that could account for why Patrick is seeing files stay around longer than
his 90 days.
Thanks,
Alex Paschal
Storage Administrator
Freightliner, LLC
(503) 745-6850 phone/vmail
-----Original Message-----
From: Andy Raibeck [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 6:47 AM
To: [EMAIL PROTECTED]
Subject: Re: Confusion with retention values.
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: [EMAIL PROTECTED]
"The only dumb question is the one that goes unasked."
Patrick Boutilier <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 03/30/2001
06:43:04 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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
