David,

If you set up your management classes correctly, this is something
you can do. Keep in mind that you will need a log backup to go
along with the set backup in order for the SQL Server to properly
recover the database after a restore. Because of that, you will
need to make sure your log and set backups are bound to the
same management classes or management classes with similar settings.
Both set and log backups are uniquely named and both will be "expired"
upon a new "full" backup. Because it this, you will need to make sure
the management class settings for log and set backups are set to
remain for as long as you desire (RETONLY).

Thanks,

Del

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/19/2004
11:44:53 AM:

> Guys,
>
> To begin, a familiar story for many of you I'm sure - we have a customer
> who has MSSQL databases, and wants TDP backups going back a month or so.
> Easy, bread and butter stuff. Happy with this, they want their backups
> from every Friday to be retained for 4 weeks, and from every 4th Friday
> to last for 7 years. As the TDP stores the SQL backups in a backup
> copygroup, we don't have that level of flexibility easily built in to
> the tool to provide what is essentially more of an 'archive' type
> request.
>
> The normal response at this point is to 'use different node names -
> ABC123_WEEKLY or ABC123_MONTHLY', and this is indeed what I have done
> frequently before. However, I can't help feeling this isn't quite
> perfect, having to make our non TSM savvy client (on a remote site) faff
> around with different node names and explain to them why TSM has to be
> handled in this way. It's not that big a deal really, but I'm aiming for
> simplification here.
>
> Now, my question is whether anyone is achieving the fulfilment of such
> requirements in another way, for example using 'set backups'. According
> to the docs,
>
>         'set backups are intended to be used in unusual one-of-a-kind
> situations [...] Because set backups are always uniquely named (like log
> backups), they do not participate in expiration due to version limit
> [...] The reason for using a set backup is if you do not want the backup
> to be part of your normal expiration process.'
>
> Sounds like a possibility - anyone using these already?
>
> We've a similar requirement coming in for Informix backups - again, from
> what I've seen of ONBAR so far, having out-of-sync weekly/monthly/yearly
> backups could be a challenge when using the same node name. With Oracle
> backups, we've managed to overcome this by customising the RMAN backup
> piece tags, and expiring manually from RMAN based upon these to identify
> logs, weekly and monthly backup pieces etc - works very smoothly indeed.
>
> Your thoughts, especially on a Friday afternoon, are always much
> appreciated :O)
>