Duh! Thanks much for the clarification regarding "correct TSM behavior".
Not only was it a great explaination but I even understood it! It also
helped to explain it to the client in a way she understood. This 'LIST' is
the best! IBM should be paying the big bucks for the support TSM'ers get
from all of you!
Shannon Bach
e-mail sbach AT mge DOT com
Andrew Raibeck
<storman AT US DOT IBM.C To: ADSM-L AT
VM.MARIST DOT EDU
OM> cc:
Sent by: "ADSM: Subject: Re: Missing something
from 31 version profile
Dist Stor
Manager"
<[email protected]
.EDU>
06/17/2003 11:30
AM
Please respond to
"ADSM: Dist Stor
Manager"
Just to clarify regarding "correct TSM behavior":
The RETEXTRA and VEREXISTS work together to define retention for the
backup versions in terms of time and number of versions. When *either*
criterion is exceeded for a given backup version, then that version is
expired. For example, you have RETEXTRA=31 and VEREXISTS=31. If you create
31 versions in the same day, and then (still on the same day) you create
version 32, version 1 will expire, regardless of RETEXTRA, because the
VEREXISTS criterion has been exceeded. Likewise, if you create version 1
today, then create version 2 a week later, then never create another
version after that, then version 1 will expire 31 days after the creation
of version 2, since the RETEXTRA criterion has been exceeded. In this
latter case, you still had 31 day recoverability since the file apparently
underwent very little change.
A true 31 day recoverability would have VEREXISTS=NOLIMIT and RETEXTRA=31,
so that the *only* criterion by which the files are expired is time. But
with that said, assuming the files are backed up once a day (at most),
your existing criteria seem just fine.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Andrew Raibeck/Tucson/IBM@IBMUS
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/17/2003 09:20
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Missing something from 31 version profile
This is correct TSM behavior.
Based on your description, it sounds like you are attempting to provide
your customer with a service that will let them restore their database
files to anywhere in the past 31 days (as opposed to managing to a number
of versions). If a file hasn't changed, it isn't redundantly backed up.
Isn't that the point of what you are trying to accomplish by moving them
to incremental backups? Doesn't the oldest of the 23 versions go back 31
days? And if the file hasn't changed for the past 8 days, then wouldn't t
the backup taken 8 days ago reflect the most current version of the file
(minus any changes that might have occurred since last night's backup)?
If your goal is to keep 31 versions regardless of the number of days, then
set RETEXTRA to NOLIMIT. But that would appear to conflict with why you
are doing this to begin with.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Shannon Bach <SBach AT MGE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/17/2003 09:00
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Missing something from 31 version profile
I currently have a client who has an Incremental Backup scheduled each
night of all files on their server except 4 very big database files. Also
scheduled each night is an Archive, of the 4 database files excluded from
the incremental. These archives are kept for 31 days so they may go back
to any version for the past month. Besides these two schedules, they also
have weekly, monthly and yearly Archive scheduled of these same 4 database
files. I have been trying to persuade them that a nightly incremental of
these files can do everything the nightly and weekly archives can, with a
lot less repetitive data being stored and a big saving of system
resources.
I have set up a special Management Class and Backup Copy Group and added
an
Include of the 4 DB files to this special Management Class in the Client
Options file. I am running it with the Archives for 1 month, hoping to
convince them to totally give up their daily & weekly archive schedules.
Here lies my problem, for some reason I cannot get the incremental backup
to keep 31 versions of each file in the databases. Instead it seems to be
keeping 31 days of each file, dropping off the rest. So if a file did not
change 8 of the last 31 days, there are only 23 versions saved, the rest
drop off. The following are the Management Class, Copy Group, etc that I
have set up. I am missing a very important factor here but I can't seem
to
figure out what it is. I could sure use some of the great expertise of
the
List to point out what I'm missing.
Optionset Description Last
Update by Managing profile
(administrator)
------------------------- -------------------------
--------------- ----------------
XNODE_OPTIONS Options needed for XNODE BACHSC
NETWARE incremental
backups
Option: INCLEXCL
Sequence number: 1
Override: Yes
Option Value: INCLUDE VOL1:/DATA/SAMPLE1/*.MDB MGE_MC_31VERSIONS
Option: INCLEXCL
Sequence number: 2
Override: Yes
Option Value: Include VOL1:/SAMPLEl/*. mdb MGE_MC_31VERSIONS
Option: INCLEXCL
Sequence number: 3
Override: Yes
Option Value: Include VOL1:/Data/SAMPLE2/*.mdb MGE_MC_31VERSIONS
Option: INCLEXCL
Sequence number: 4
Override: Yes
Option Value: Include VOL1:/SAMPLE3/*.MDB MGE_MC_31VERSIONS
Option: INCLEXCL
Sequence number: 5
Override: No
Option Value: Exclude *:/QUEUES/.../*
Option: INCLEXCL
Sequence number: 10
Override: No
Option Value: Exclude SYS:/Apache/logs/ERROR_LOG
Option: INCLEXCL
Sequence number: 11
Override: No
Option Value: Exclude SYS:/Novonyx/suitespot/admin-serv/logs/*.TXT
Option: INCLEXCL
Sequence number: 12
Override: No
Option Value: Exclude SYS:/tomcat/33/logs/*.LOG
Option: INCLEXCL
Sequence number: 17
Override: No
Option Value: Exclude SYS:/SYSTEM/CSLIB/LOGS/SMLOGS/*.TMP
Option: SUBDIR
Sequence number: 50
Override: No
Option Value: YES
Option: VERBOSE
Sequence number: 51
Override: No
Option Value: YES
BACKUP COPY GROUP
MGE_PD_001:MGE_PS_001:MGE_MC_31VERSIONS:STANDARD - Properties
-------------------------------------------------------
Policy domain : MGE_PD_001
Policy set : MGE_PS_001
Management class : MGE_MC_31VERSIONS
Copy group : STANDARD
Copy type : Backup
Last update by : BACHSC
Last update date/time : 06/02/2003 08:00:08
Copy mode : Modified
Copy serialization : Dynamic
&Copy frequency : 0
Number of backup versions to keep
If client data exists : 31
If client data is deleted : 7
Length of time to retain extra backup version : 31
Length of time to retain only backup version : 60
&Destination storage pool : BACKPOOL00
================================================================================
MANAGEMENT CLASS
MGE_PD_001:ACTIVE:MGE_MC_31VERSIONS - Properties
------------------------------------------
Policy domain : MGE_PD_001
Policy set : ACTIVE
Management class : MGE_MC_31VERSIONS
Description : For XNODE server keep each
version mdb files 31 DAYS
Default management class? : No
Last update by : BACHSC
Last update date/time : 06/02/2003 09:18:47
Type of space management allowed : None
Eligibility for automatic migration : After 0 days of non-usage
&Backup version must exist : No
Storage pool destination for migration files : BACKCART01
The files are binding to MGE_MC_31VERSIONS, the Number of backup versions
to keep = 31 in the Copy Group, so I just can't see what's wrong. Any
help
would be much appreciated!
Thanks,
Brainless in Madison
e-mail sbach AT mge DOT com
|
