ADSM-L

Re: [ADSM-L] MSSQL archives

2009-12-29 17:02:14
Subject: Re: [ADSM-L] MSSQL archives
From: Fred Johanson <Fred AT UCHICAGO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Dec 2009 15:58:10 -0600
Since we exclude all .BAK along with the rest of MSSQL, we set up .MON and 
attach that to a longterm mgmtc.  The dbas are supposed to archive the January 
.MON into a longer archmc.


________________________________________
From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Shawn 
Drew [shawn.drew AT AMERICAS.BNPPARIBAS DOT COM]
Sent: Tuesday, December 29, 2009 3:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] MSSQL archives

We rolled out several SQL TDP agents this year and I'm only realizing now
there doesn't seem to be a facility for long-term archiving.
I noticed that Differential and Full backups can be bound to separate
management classes (Unlike NDMP backups)

I *assumed* that Full backups could have different management classes from
each other.  (I.E. A special year-end Full backup, bound to management
class "07YEAR")

However, I just tested it, and it rebinds ALL of the previous Full backups
to the new management class.  Then when I run another backup to the
original MC, all the full backups, including the "07YEAR" backup gets
rebound to the default MC.

So, it seems my options are:
- Tell the SQL admins to perform a filesystem .BAK backup, just for the
Year-End archive.
- Configure an additional SQL node for each host to hold the year-end Full
backup.

Both seem pretty unappetizing.   Any other ideas?

Regards,
Shawn
________________________________________________
Shawn Drew



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

<Prev in Thread] Current Thread [Next in Thread>