I have Del- and to me they were silent on the inactivation (it's quite
different than Oracle/RMAN). The question on the management class
parameters was because the TSM Admins determined that they didn't need
to follow the Redbook's recommendations on unlimited/unlimited and I am
unable to provide hard cold reasons why they should follow the Redbook.
What they gave me:
Created Policy Domain XXXXXXXX, Set up management class "Standard". For
now (until business side gets back to us with retention) set up the MC
with 0 days between backups, 7 versions of each file kept, 30 days to
keep inactive versions, 1 deleted version, keep last file f! or 60 days.
Set up separate collocation group for XXXXX.
My comments regarding:
How does this MC affect backup of the SQL transaction logs (since it is
backup and not archive)? I am concerned that the 7 versions existing &
1 deleted may cause issues doing a point-in-time restore (i.e.- the log
that needs to be restored rolled off TSM & now the point in time
recovery fails).
Regarding metadata being retained on disk vs. on tape. We may not be
able to query database objects for restore if the metadata is on tape.
This is another concern I have regarding only one STANDARD management
class.
What I asked for:
I have relied heavily on the IBM Redbook Backing up Microsoft SQL Server
with IBM Tivoli Storage Manager (SG-24-6148-01) and its recommended
setup
1. I suggest you collocate by node or filesystem, depending on size
of filesystems & maxsize of the tapes--but if you can meet the
business-side's RTO ! without collocation, then whatever works.
2. Separate storage pools (stgp) be set up to backup the SQL server
environment. (Redbook pg 81)
2.a Dedicated disk storage pools for the primary stgps for the SQL
DB servers & the TDPs
DRSQLDBDISK- primary pool for DB Data
DRSQLLOGDISK- primary pool for DB logs
DRSQLDISKCOPY-copypool for DRSQLLOGDISK & DRSQLMETADISK)
DRSQLTAPECOPY- copy pool for DRSQLDBDISK in tape library
REUSEDELAY=2
DR_DRIMVDL- DR offsite tapes REUSEDELAY=2
DRSQLMETADISK-this is for metadata when using VSS. However, a
system utilizing transaction log backup without using VSS staging was
not illustrated in the Redbook, so it's unclear we'd need this for the
legacy backup solution.
The documentation discusses ! when working with VSS backups another
separate disk stgp be set up for the metadata. The problem with this is
that in the Redbook team's test environment, they assume all clustered
servers would be utilizing VSS-either staging, offloaded or hardware. I
think that this is something we should look into-given the projected
data volume and the RTOs-perhaps even the backup window. We could do the
staging or off-loaded now-we just need to install the IBM TSM for Copy
Services. And some more configuration.
3. Separate Policy Domain (PD) (Redbook ppg 83 & 84)
3.a Management Class (MC)
*DRSQLDAILY- for the daily & weekly backups with retention policy based
on date- VEREXISTS=nolimit VERDELETED=nolimit RETEXTRA=35 RETONLY=90
**Default MC
*DRSQL_LONG- monthly backups & archives (shouldn't need to include meta
& logs if the archive/(full) backup is done correctly-right? I would
also suggest that the scheduled job! s use dates in the name of the
backup & for the archives, so we don't run into issues with version
retention & for clarity) VEREXISTS=2 VERDELETED=1 RETEXTRA=400
RETONLY=400
*DRSQL_LOGS- for the transaction logs VEREXISTS=nolimit
VERDELETED=nolimit RETEXTRA=35 RETONLY=90
*DRSQL_VSSLOCAL- for local (on the SQL server or the proxy) VSS backups-
retention policy enforced by version & not time- VEREXISTS=3
VERDELETED=3 RETEXTA=nolimit RETONLY=nolimit
*DRSQL_VSSFULLTSM -daily VSS backups sent to TSM-retention policy based
on time= VEREXISTS=nolimit & RETEXTRA=35 RETONLY=35
I am concerned about PIT recovery since I don't know what their
"tweaking" will do to our ability to recover. The business side is
willing to pay for what we need, but the "service provider" is unwilling
to provide what we ask for......
If I could bother with one more stupid question... I am vague on how/if
the transaction log "space" empties-- For example, I have a difffull
running every night, then backup the logs and every 2 hours a backup of
the logs occurs-- If I get a notification (SNMP) that the drive
designated for the SQL logs is 95% full -- Do I have to worry about it?
thanks!
lisa
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Del Hoobler
Sent: Thursday, September 04, 2008 6:50 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] inactivate TDP SQL transaction logs?
Lisa,
For Data Protection for SQL, you do not need to schedule
an inactivate logs. "log" backups are stored as backups,
and are inactivated automatically on the next "full"
backup of the associated database. I encourage you to read the
"Backup overview", "Backup strategies", and
"Recommended Tivoli Storage Manager policy settings" sections
of the Data Protection for SQL Installation and User's Guide
for more details.
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/
com.ibm.itsmfd.doc/dpsql.htm
Thanks,
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 08/28/2008
04:27:24 PM:
> [image removed]
>
> inactivate TDP SQL transaction logs?
>
> Laughlin, Lisa
>
> to:
>
> ADSM-L
>
> 08/28/2008 04:28 PM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> When I setup TDP for Oracle and used RMAN jobs , the transaction logs
> were archives ( & archive deletes) and you needed to also schedule an
> RMAN job to inactivate the logs and synchronize between RMAN and
> TDP/TSM. It's been a while and my details may be fuzzy; but it
doesn't
> seem that there is an equivalent in MSSQL. And the logs are backed up,
> not archived. Should I be scheduling inactivate jogs and do I have to
> worry about duplicate transaction log names and a limit on the number
of
> versions kept for the backups of the transaction logs? Sorry if I am
> slightly incoherent-we go live on a project over the weekend, and (as
> usual) the backups were an afterthought, so I am kind of short on
sleep
> right now. I know you guys have been there & done that.
>
> thanks!
> lisa
