>> On Thu, 3 Aug 2006 11:22:07 -0500, Mike <mikee AT MIKEE.ATH DOT CX> said:


> I have come to like TSM, but I do not have the budget for a 3494 or
> other tape changer, or for the software for that matter.

> Does this exist somewhere or someone have a better idea?

10 years ago I started working on something which I have come to
understand as grasping for TSM's features.  This is what I was
designing then, and for the dramatically lower performance domain you
discuss it remains sane.


+ Use TAR's 'newer' option to get incremental-like behavaior. Always
  record timestamps of when a run began, use them to calculate
  timestamps of later runs.  This is better than dump.

+ Always do verbose output, record all those outputs.  This is your
  TSM DB.

+ Record metadata about the run to decrease the number of the output
  listings you have to uncompress and grep to locate the instances of
  a file.

+ Since you're tarring to disk initially, you can get something like
  copy pools by dding your bzipped tar onto more than one tape.

+ Record metadata about which runs get copied to which tapes.


Then your DR operations involve a more conventional tarring up of the
metadata collection onto media.


You don't get progressive backups: you're still at some sort of
full/incremental/differential scheme. Explicitly using -newer dates
gives you a lot of flexibility, but you don't know what you really
have unless you do another full.

Same lack-of-progressive-backups problem on restore:  Must restore
many different backups to bring image up to date.

You get no retry flexibility.

You get no validation of data on tape (reclamation).

Your "database" queries will be long and I/O and CPU intensive; but
better than getting the TOCs of all the tars...



Personally, I wouldn't trust it farther than I could throw it.  And I
wrote it.


- Allen S. Rout
- Really, you can't afford -NOT- to do TSM.