>> On Thu, 23 Aug 2007 09:46:17 +1000, Stuart Lamble <adsm AT 
>> CAROUSEL.ITS.MONASH.EDU DOT AU> said:

> On 23/08/2007, at 7:29 AM, Nicholas Cassimatis wrote:
>> And a TSM DB Backup takes (at least) one volume, so with physical
>> cartridges, that's a whole tape.  With VV's, you're only using the
>> actual
>> capacity of the backup, which is more efficient on space.

> At the cost of some reliability. What happens if the particular tape
> the virtual volumes are on goes bad, and you're in a disaster
> needing a DB restore?

Once you've sent data to a VV, (which looks like just-a-file to the
target server) you can then copy it like any other file.

Choose your exposure:

  (tape-failure-rate) * 1/number-of-db-tapes

vs.

  ( tape-failure-rate ) ^ 2

or, if you're neurotic (like me) you can do

  ( tape-failure-rate ) ^ 3

with both onsite and offsite copy pools :)

By the time you take 3592 volume failure rates cubed, you're in
planetcracking asteroid risk levels, A.K.A. No Longer The Risk
Amelioration Target.



> Well, why not do what we're doing soon? We currently have some 1200
> LTO2 tapes, and are in the process of migrating from LTO2 to LTO4;
> (some of) the LTO2 tapes will be kept in the silo for database [..]

There's someone I know who's used exactly that kind of logic to keep
themselves on 3590 J volumes (as in, to this very day.)  To me,
keeping old tech around just-because seems a poor tradeoff.  You build
additional complexity into your system by maintaining separate device
groups, you waste silo slots on "measley" 200G volumes...  Worst,
you're using the less reliable, older devices to manage your family
jewels.

For me, the ability to make copies of the DB backups swamped every
other reliability-related concern.


- Allen S. Rout