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
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: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
Alex Paschal <AlexPaschal AT FREIGHTLINER DOT COM>@VM.MARIST.EDU> on 03/30/2001
10:48:45 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.
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
|
