Backup Central

As part of a major upgrade, I am considering moving some TSM DB backups
to FILE volumes. LTO4 tapes hold a terrabyte, and the incrementals, in
particular, are wasting a LOT of tape. I'm thinking of doing full DB
backups to tape, and incrementals to disk FILE volumes.

The manual says you can back up the TSM Database to either TAPE, or to
Virtual Volumes on another TSM server. It doesn't mention FILE volumes.
I seem to remember somebody long ago saying you should not consider
that. OK, so what's wrong with backing up the TSM Database to FILE
volumes?

This would be what I suppose might be safe:

Do not use a local filesystem. The FILE volumes used for DB backup
should reside on an NFS-mounted filesystem, which can also be mounted by
some other system. A separate physical location would be nice. This
should be on the same NFS server which you also use to back up the
Volume History and Device Config files. On all systems that can mount
this NFS filesystem, it should be mounted at the same mount point as on
the TSM server system. That is so the DB Backup volume names in the
Volume History File are still valid.

Are there any other pitfalls I am not forseeing here?

Having said that, though, I have not noticed any performance difference
between Virtual Volumes on another server, and a mounted NFS filesystem.
The network is the speed limitation. It's just that Virtual Volumes are
more complicated, and thereby more problem prone when a junior staff
member is the one called in a disaster to do a TSM DB restore, while I'm
camping in the mountains.

Roger Deschner University of Illinois at Chicago rogerd < at > uic.edu
Academic Computing & Communications Center
======I have not lost my mind -- it is backed up on tape somewhere.=====

On Jul 9, 2008, at 1:19 PM, Roger Deschner wrote:

As part of a major upgrade, I am considering moving some TSM DB
backups
to FILE volumes. LTO4 tapes hold a terrabyte, and the incrementals, in
particular, are wasting a LOT of tape. I'm thinking of doing full DB
backups to tape, and incrementals to disk FILE volumes.

The manual says you can back up the TSM Database to either TAPE, or to
Virtual Volumes on another TSM server. It doesn't mention FILE
volumes.
I seem to remember somebody long ago saying you should not consider
that. OK, so what's wrong with backing up the TSM Database to FILE
volumes? ...

What manual? What section?
The Backup DB command documentation (Admin Ref manual) stipulates a
sequential access device class, which obviously includes File type.

Richard Sims

Been there.
Done that.
Works peachy.

On Wed, Jul 9, 2008 at 1:19 PM, Roger Deschner <rogerd < at > uic.edu> wrote:

As part of a major upgrade, I am considering moving some TSM DB backups
to FILE volumes. LTO4 tapes hold a terrabyte, and the incrementals, in
particular, are wasting a LOT of tape. I'm thinking of doing full DB
backups to tape, and incrementals to disk FILE volumes.

The manual says you can back up the TSM Database to either TAPE, or to
Virtual Volumes on another TSM server. It doesn't mention FILE volumes.
I seem to remember somebody long ago saying you should not consider
that. OK, so what's wrong with backing up the TSM Database to FILE
volumes?

This would be what I suppose might be safe:

Do not use a local filesystem. The FILE volumes used for DB backup
should reside on an NFS-mounted filesystem, which can also be mounted by
some other system. A separate physical location would be nice. This
should be on the same NFS server which you also use to back up the
Volume History and Device Config files. On all systems that can mount
this NFS filesystem, it should be mounted at the same mount point as on
the TSM server system. That is so the DB Backup volume names in the
Volume History File are still valid.

Are there any other pitfalls I am not forseeing here?

Having said that, though, I have not noticed any performance difference
between Virtual Volumes on another server, and a mounted NFS filesystem.
The network is the speed limitation. It's just that Virtual Volumes are
more complicated, and thereby more problem prone when a junior staff
member is the one called in a disaster to do a TSM DB restore, while I'm
camping in the mountains.

Roger Deschner University of Illinois at Chicago rogerd < at > uic.edu
Academic Computing & Communications Center
======I have not lost my mind -- it is backed up on tape somewhere.=====

Used for years - and using it to rebuild my tsm server at a DR site -
never had any problem

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Wanda Prather
Sent: Wednesday, July 09, 2008 7:51 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: TSM DB backup to FILE vols - safely

Been there.
Done that.
Works peachy.

On Wed, Jul 9, 2008 at 1:19 PM, Roger Deschner <rogerd < at > uic.edu> wrote:

As part of a major upgrade, I am considering moving some TSM DB
backups
to FILE volumes. LTO4 tapes hold a terrabyte, and the incrementals, in
particular, are wasting a LOT of tape. I'm thinking of doing full DB
backups to tape, and incrementals to disk FILE volumes.

The manual says you can back up the TSM Database to either TAPE, or to
Virtual Volumes on another TSM server. It doesn't mention FILE
volumes.
I seem to remember somebody long ago saying you should not consider
that. OK, so what's wrong with backing up the TSM Database to FILE
volumes?

This would be what I suppose might be safe:

Do not use a local filesystem. The FILE volumes used for DB backup
should reside on an NFS-mounted filesystem, which can also be mounted
by
some other system. A separate physical location would be nice. This
should be on the same NFS server which you also use to back up the
Volume History and Device Config files. On all systems that can mount
this NFS filesystem, it should be mounted at the same mount point as
on
the TSM server system. That is so the DB Backup volume names in the
Volume History File are still valid.

Are there any other pitfalls I am not forseeing here?

Having said that, though, I have not noticed any performance
difference
between Virtual Volumes on another server, and a mounted NFS
filesystem.
The network is the speed limitation. It's just that Virtual Volumes
are
more complicated, and thereby more problem prone when a junior staff
member is the one called in a disaster to do a TSM DB restore, while
I'm
camping in the mountains.

Roger Deschner University of Illinois at Chicago
rogerd < at > uic.edu
Academic Computing & Communications Center
======I have not lost my mind -- it is backed up on tape
somewhere.=====

On Thursday 10 July 2008, Eric Bourgi wrote:
Used for years - and using it to rebuild my tsm server at a DR site -
never had any problem
Idem for us. We never used tape cartridges, but always a FILE class. If the
TSM server is running on AIX, we put the FILE class on rootvg and use mksysb
to backup the TSM database backup.
If the TSM server is running on windows, we use CBMR and/or copy the database
backup to a remote site.


Stef

Mm, I'm getting the list traffic again, how nice.

On Wed, 9 Jul 2008 12:19:37 -0500, Roger Deschner <rogerd < at > UIC.EDU> said:

Do not use a local filesystem. The FILE volumes used for DB backup
should reside on an NFS-mounted filesystem, which can also be
mounted by some other system. A separate physical location would be
nice. This should be on the same NFS server which you also use to
back up the Volume History and Device Config files. On all systems
that can mount this NFS filesystem, it should be mounted at the same
mount point as on the TSM server system. That is so the DB Backup
volume names in the Volume History File are still valid.

Are there any other pitfalls I am not forseeing here?


I've been carting around FILE volumes for some DB backups for a long
time. I've got some recommendations and pitfalls for you.

First: I recommend firmly against using NFS in the critical path for
your ongoing operations. Having the backups "elsewhere" is good, but
having them at all is critical on a minute-by-minute basis for the
running of your server. NFS outage degrading your offsite
preparation: bad. NFS outage killing your server because it can't
find the device to do an incremental to clear the log: production
outage. Bad bad bad.


Second: these are just files; they don't have any particularly
delicate nature, they're not sparse, they're not scary. I've tarred,
bzipped, folded spindled and mutilated them, and when you unfold and
unbzip, and untar them, they work just fine. This means you should
consider all the tools you might normally use for shoving or syncing
files around.

I'm currently working towards a centralized "DR" filesystem, which
gets regular updates from all the server instances, and then is in
turn synced -to- all the systems. That means, to a first
approximation, any of my TSM servers has enough of a roadmap to begin
recovery of all the instances.

That's just my example: but the advice is to use post-facto copies to
get your belt-and-suspenders versions, rather than worrying about the
devclass being remote immediately.


Third: some database lock problems can generate a cascade of backups,
over and over again. There are settings to help avoid this, but I
still get some situations where a box does
FULL-incr-incr-incr-incr-FULL, etc, etc, ad nauseam. If you're
writing to filesystems, this can be a serious impact on other things
sharing the space. Use distinct partitions as indicated for your
environment. This might mean one per TSM server, one for all of them,
or whatever.


Finally, consider wether you might be better off doing the remote
virtual volumes thing. I would be uncomfortable with my database
backup chain scattered amongst different device structures. It seems
to me that your contemplated config inherits the union of the
disadvantages, with only the intersection of the advantages, of the
various methods.

If you backup to a remote server, you can do all the fun "First to
disk, then copy all over hell's half-acre, then shove to tape" stuff
we're accustomed to doing with client data. Rational concerns about
exposure due to the egg/basket ratio ("All of my DB backups are on the
same tape!") can be addressed with a profusion of copy stgpools. This
also gives you a simple and consistent way to manage offsites of DB
backups, instead of needing one family of procedures for offsites of
client data, and a completely separate one for offsites of -your-
data.



- Allen S. Rout

On Jul 17, 2008, at 2:02 PM, Allen S. Rout wrote:

Having the backups "elsewhere" is good, but having them at all is
critical on a minute-by-minute basis for the running of your server.

For what it's worth, we rsync our DB backups to a computer offsite,
using ssh preshared keys.

--Jim