7 versions of each file kept, 30 days to keep inactive versions, 1 deleted version, keep last file for 60 Days
Is substantially different from VEREXISTS=nolimit VERDELETED=nolimit RETEXTRA=35 RETONLY=90 And I am worried about recovery..... > 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 Howard Coles Sent: Friday, September 05, 2008 10:20 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] inactivate TDP SQL transaction logs? First, Unlimited is excessive for everything. However, we have Unlimited set for # of versions, but we only keep the backups for 30 days for our regular node, 5 years for our monthly node, and 10 years for our quarterly nodes when it comes to SQL server. The key settings for SQL Server are unlimited versions then limit the # of Days, this way you can run regular log backups and actually recover. See Ya' Howard > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Laughlin, Lisa > Sent: Friday, September 05, 2008 9:38 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] inactivate TDP SQL transaction logs? > > 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
