For the purposes of discussion, I am assuming that you run incremental
backup daily.
As long as the file continues to exist on the client machine:
- FileA, which changes every day, will have the 4 most recent backup
versions available. When the next backup version is created, the oldest
one will expire. Thus in this scenario, RETEXTRA is irrelevent. Note that
the latest backup version is always the "active" version, and all other
versions are "inactive". The active file will go inactive when the next
backup version is created.
- FileB will have one and only one version that never expires. Thus in
this scenario, RETEXTRA is irrelevent. Note that this version is always
"active", and that active versions do not expire.
If the file is deleted from the client machine:
- The next time incremental backup runs, it will detect that the file has
been deleted, and the active (latest) version will be made inactive.
- For FileA, since no new versions are being created, RETEXTRA will become
relevent. All but the most recent backup version are subject to RETEXTRA,
with each expiring 30 days FROM THE TIME IT WENT INACTIVE. The most recent
backup version is subject to RETONLY (which just so happens to also be 30
days), so it will expire 30 days from the time it went inactive.
- Same for FileB, though RETEXTRA is irrelevent since there is only the
one version. That version will be subject to RETONLY, just as FileA above.
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
IBM Tivoli Storage Manager support web page:
http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2006-05-02
08:34:22:
> We are running TSM 5.3.0.0 on aix 5.3 and the implementation was
> done by a consultant with the following retention policy in place :
> Version = 4
> Retain only version = 30 days
> Retain extra version = 30 days
>
>
> If we have two files A and File B file A changes every day but file
> B never changes after the initial creation day ...what happens to
> the backup copies in the TSM serv on day 30th, 32nd and 33rd....
>
> Appreciate any input
>
> Thanks,
> Ashok
>
> >q co
>
> Policy Policy Mgmt Copy Versions
> Versions Retain Retain
> Domain Set Name Class Group Data
> Data Extra Only
> Name Name Name Exists
> Deleted Versions Version
> --------- --------- --------- --------- --------
> -------- -------- -------
> SQL_DOMA- ACTIVE MDEFAULT STANDARD No Limit No
> Limit 30 30
> IN
> SQL_DOMA- ACTIVE SQLTRANS- STANDARD No Limit No
> Limit 30 30
> IN DISK
> SQL_DOMA- SQL_POLI- MDEFAULT STANDARD No Limit No
> Limit 30 30
> IN CY
> SQL_DOMA- SQL_POLI- SQLTRANS- STANDARD No Limit No
> Limit 30 30
> IN CY DISK
> STANDARD ACTIVE STANDARD STANDARD 2
> 1 30 60
> STANDARD STANDARD STANDARD STANDARD 2
> 1 30 60
> WIN_DISK- ACTIVE MDEFAULT STANDARD 4
> 1 30 30
> _DOMAIN
> WIN_DISK- WIN_DISK- MDEFAULT STANDARD 4
> 1 30 30
> _DOMAIN _POLICY
> WIN_TAPE- ACTIVE MDEFAULT STANDARD 4
> 1 30 30
> _DOMAIN
> WIN_TAPE- WIN_TAPE- MDEFAULT STANDARD 4
> 1 30 30
> _DOMAIN _POLICY
>
>
>
>
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Loon, E.J. van - SPLXM
> Sent: Tuesday, May 02, 2006 1:20 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] TDP for SQL tracing
>
>
> Hi *SM-ers!
> I added the trace parameters to the dsm.opt on a client running the DP
> for SQL Server client.
> I added the following lines:
>
> Tracefile d:\tdptrace\tdptrace.txt
> Traceflags stats, options, compress
> Tracemax 100
>
> The tracefile confirmed this:
>
> 05/01/2006 21:30:47.745 : Current trace classes enabled:
> CONFIG, COMPRESS, TIMESTAMP, PREFIX, STATS
>
> But it only contains the CONFIG output. No statistics, no compression
> info, nothing...
> What am I doing wrong???
> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines
>
>
> **********************************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no part of
> the e-mail or any attachment may be disclosed, copied or
> distributed, and that any other action related to this e-mail or
> attachment is strictly prohibited, and may be unlawful. If you have
> received this e-mail by error, please notify the sender immediately
> by return e-mail, and delete this message. Koninklijke Luchtvaart
> Maatschappij NV (KLM), its subsidiaries and/or its employees shall
> not be liable for the incorrect or incomplete transmission of this
> e-mail or any attachments, nor responsible for any delay in receipt.
> **********************************************************************
|
