IRT #1, there are valid reasons for doing this (dump to disk first). At
many sites, the dump file on disk is retained for only a few days (i.e.
next 2 dumps), consequently restoral is faster as the speed of the disk
subsystem generally can outperform the tape library (tape libraries are
usually spec'd on capacity, the throughput just can't match a disks).
Yes this is more expensive and disks are certainly not as cheap as tape
- although some places have opted for cheaper storage (e.g. SATA-RAID
attached to SAN) for dump volumes to offset some of this cost. Part of
the reason for doing this is that tape volumes are sometimes required to
be stored offsite (due to legal or DR requirements) even on a daily
basis.....getting the tape back onsite can take longer than to restore
the tape. A third reason is that the disk dump can be mounted as an
archive database for offline dbcc checks, etc.
Additionally, some sites have gone to SAN dumps - in which a BCV or
other snapshot utility images the data devices - which are then either
written to tape directly within the SAN frame (or attached) or are
mounted on another server which does the backup....depends on how you
want to look at, SAN utilities can be viewed as a third party (or would
they be the mythical "second party")....how well it would be supported
depends on the SAN vendor. For example, some vendors can record just
the changed blocks as part of a snapshot - and consequently can provide
an almost incremental backup capability. Only problem is that generally
when restoring SAN based backups, the system has to be down. There are
ways around this via the mount/unmount device - but few people separate
their devices well enough to support this. One advantage of the SAN
dump is speed - the IOs never leave the frame - no CPU processing and no
HBA bandwidth issues.
Much has been said, I'll address what is left.
1. You DO know that if you dump db to disk, then have whatever copy the
dump file to tape, upon recovery bing demanded, you will have to restore
the dump file, then load db from dump file. Are you sure you want to do
this ? Why not dump the db to a tape or tape silo or tape library in
the first place and cut out the two-step backup as well as restore. Yes
you will have two volume types.
2. I have used SQL BackTrack, Legato, etc. Not the "new" TSM. By far,
the best is NetBackup which has a Sybase "Knowledge Module" which lets
it understand sybase tran and db dumps; and you need to set up
BackupServer to see it. You dump db/tran to NetBackup; it returns an
image file name (which you record along with your db dump records) which
you reference when you load db/tran. Simple and clean from the Sybase
DBA side, and enterprise-scale on the common offsite volume side.
3 AFAIK, TSM supports MS/Oracle but does not support Sybase. Which
means as per (1) you may be better off maintaining a separate Sybase
tape library. Or live with the two-step backup/restore.