ADSM-L

Re: [ADSM-L] "Freezing" my Email backups and starting fresh

2008-01-16 15:35:36
Subject: Re: [ADSM-L] "Freezing" my Email backups and starting fresh
From: Del Hoobler <hoobler AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Jan 2008 15:35:06 -0500
FYI... Data Protection for Exchange does not support
directly reading from backup sets.
The same is generally true for any "API" applications.


Thanks,

Del

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

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/16/2008
03:26:29 PM:

> (Sorry for the old reply, I'm still catching up on email...)
>
> On Wed, Jan 09, 2008 at 10:22:03AM -0600, Wanda Prather wrote:
> > There are alternatives, including a backupset and an export tape.  The
> > problem I have with those:  the data is on the tape, but the older
backups
> > will continue to expire out of the TSM DB.  So, 6 months from now,you
don't
> > have anyway to figure out what is ON the backupset or EXPORT tape.
This way
> > you can query the DB to see what is in there, if your lawyers need
> > something.
>
> I would use a backupset.  TSM 5.4 allows you to generate a table of
> contents for that backupset that the client can query/load to do
> per-file browsing and restoring based off the backupset.  I'm not sure
> how well the backupset would work with application backup tools (if
> you're backing up with the Exchange TSM addon), but in terms of taking
> an archive-like backup from pre-existing backups without changing
> current/future backups, backupsets seem like the way to go.  The TOC can
> be stored either on tape or to a file devclass so it's always browsable
> even if the backupset media is offline.  (Or a TOC can be recreated
> later from a pre-existing backupset, if the TOC is lost or didn't exist
> when the backupset was taken.)
>
> Making the node/domain/copygroup changes you described have the benefit
> of storing all the active/inactive files for the node when you move it
> over (rather than just the files active at the point-in-time defined in
> the backupset.)  But that's a lot of configuration/policy/domain
> overhead for one client/one point in time.
>
> There's no right answer; only what works best for your situation and
> comfort level.  I like that TSM provides these alternatives.
>
> Dave