Hi, Paul,

on Dienstag, 18. Mai 2004 at 23:43 you wrote to amanda-users:

PB> Don't forget that such a setup makes restores a PITA:

You are definitely right with this ;-)

This seem to be just some AMANDA-fantasies ...

PB> First you make "vtapes", just a set of large files with a
PB> strange name.  When you have collected enough of these files,
PB> and make a backup with amdump, and then you erase those "vtapes",
PB> and together probably their indexes (or jump through hoops to
PB> avoid this).

PB> Now you don't have a real index of the files on tape, only a list
PB> of hostnames-filesystems; even the dates are missing (because
PB> you put a lot of days on one tape).

PB> To restore, you first have to restore the image from tape,
PB> to get the "vtape" back, then you have to run restore again from
PB> that "vtape".
PB> In real life, you probably need to try a few times, because you're
PB> just guessing on which tape that file actually is.
PB> Those vtapes are probably quiet large.  First wait 2 hours for
PB> one 40 GB tape to read to disk, and then again an hour or so
PB> to restore from that vtape. And again, if you mistyped the name
PB> of the file, or if you want to see if the file was there a day
PB> earlier.

Sucks.

PB> Doing a backup to holdingdisk instead of vtapes avoids this
PB> backup-of-backup-images; amflush migrates the images from disk
PB> to tape instead, and keeps the indexes up to date.

We all like that, don't we?

PB> While creating backups should be easy, *restoring* from backups
PB> should be even more straightforward: it's then that you're working
PB> under high pressure (disk crash?  important file erased?  agry
PB> users waiting etc.)

Brrr ...

;-)

I would just suggest a conventional setup using the changer.

-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at