ADSM-L

Re: [ADSM-L] TDP for Exchange VSS backup destination issue

2009-04-30 08:01:40
Subject: Re: [ADSM-L] TDP for Exchange VSS backup destination issue
From: Del Hoobler <hoobler AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 30 Apr 2009 07:59:36 -0400
Hi Steve,

I can't 100% tell from the information below...
... but your conclusions look correct... i.e. when you do
a backup to BOTH... it is almost like creating two "backups"...
... one stored locally and bound to your "VSS_DISKONLY" management class
and another one stored on the TSM Server and bound to your "7_DAYS"
management class.
It sounds like the copy destination is getting set incorrectly in this
case.

Can you please open a PMR with IBM? The service team can examine the
traces and find out if the incorrect COPYDEST is being assigned.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 04/30/2009
01:26:26 AM:

> [image removed]
>
> TDP for Exchange VSS backup destination issue
>
> Steven Harris
>
> to:
>
> ADSM-L
>
> 04/30/2009 01:37 AM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> Hi All
>
> I have a corner case in the configuration of a TSM for Mail Exchange
client
>
> TSM server 5.5.0.2 on AIX, Client OS Windows 2008 X64, BA Client
5.5.1.10,
> Exchange 2007,  TDP for Mail 5.5.1
>
> This is a CCR Cluster and I'm attempting a VSS backup, on the Inactive
side
> of the cluster, going to both local disk and TSM.  The VSS provider is
the
> standard windows system provider, hardware snapshots are not involved.
>
> The config file has
>
> * VSS Backups
> VSSPOLICY * * FULL TSM 7_DAYS
> VSSPOLICY * * COPY TSM 4_WEEKS
> VSSPOLICY * * * LOCAL VSS_DISKONLY
>
> The  relevant management classes are
>
>  tsm: CV04>q co XCH_PROD ACTIVE 7_days type=backup f=d
>
>                  Policy Domain Name: XCH_PROD
>                     Policy Set Name: ACTIVE
>                     Mgmt Class Name: 7_DAYS
>                     Copy Group Name: STANDARD
>                     Copy Group Type: Backup
>                Versions Data Exists: No Limit
>               Versions Data Deleted: No Limit
>               Retain Extra Versions: 7
>                 Retain Only Version: 7
>                           Copy Mode: Modified
>                  Copy Serialization: Shared Dynamic
>                      Copy Frequency: 0
>                    Copy Destination: VTLP11
> Table of Contents (TOC) Destination:
>      Last Update by (administrator): $$CONFIG_MANAGER$$
>
> tsm: CV04>q co XCH_PROD ACTIVE vss_diskonly type=backup f=d
>
>                  Policy Domain Name: XCH_PROD
>                     Policy Set Name: ACTIVE
>                     Mgmt Class Name: VSS_DISKONLY
>                     Copy Group Name: STANDARD
>                     Copy Group Type: Backup
>                Versions Data Exists: 7
>               Versions Data Deleted: 7
>               Retain Extra Versions: 7
>                 Retain Only Version: 7
>                           Copy Mode: Modified
>                  Copy Serialization: Shared Static
>                      Copy Frequency: 0
>                    Copy Destination: TAPEP4
> Table of Contents (TOC) Destination:
>
> What I expect is that when a FULL  backup is done with /BACKUPMETHOD=VSS
> and /BACKUPDEST=LOCAL the VSSPOLICY statements will be looked at from
the
> bottom up, the retention periods in the VSS_DISKONLY copygroup will be
> applied and the destination ignored.
>
> For the case of  /BACKUPMETHOD=VSS  and /BACKUPDEST=TSM the 7_DAY class
> will be applied and the data sent to the VTLP11pool.
>
> These two cases seem to work correctly
>
> Now consider the case of  /BACKUPMETHOD=VSS  and /BACKUPDEST=BOTH.  What
I
> expect is that the local copy will be retained on disk and have the
> VSS_DISKONLY retentions applied.  The TSM copy should have the 7_DAY
> retentions applied and be sent to the VTLP11 Pool.  However what I
observe
> is that while the managenment class attributions are correct the TSM
copy
> is being sent to the destination described in the VSS_DISKONLY pool.
>
> I've been through the manual carefully, but there is nothing explicit
> there.
>
> I my expectation incorrect? or is the product not working correctly?
>
> Any input gladly appreciated.
>
> Thanks
>
> Steve
>
> Steven Harris,
> TSM Admin, Sydney Australia