Am 2017-01-05 um 08:52 schrieb Jon LaBadie:

> When this has come up in the past, there was some reservation about
> situations where insufficient (v)tape remained on the last used tape.
> I think an option could be to save it to the holding disk.  It isn't
> needed after amdump is finished (unless dumps are intentionally being
> left on the HD in order to fill a tape), and an optional amount could
> be reserved for the metadata.  Possibly to be flushed on the next
> amdump run.

hmm, I don't get the point here.

I always have to deal around the size of my media and make sure that
DLEs fit onto it etc, right?

That metadata-tarball would have a predictable size, I assume, or at
least amanda could learn it from the last run(s).

That could go into the estimate and planning phase.

In Gene's example that is ~415 MB of indices.tar, right? So let it get a
few gigs for bigger installations, those will have bigger/more tapes as
well.

And for sure I would make adding that metadata-footer optional.

-

Thinking of storage definitions:

I think it would be cool to push that metadata to a *different* storage
than the data itself (or to both).

data -> tapes
metadata -> owncloud, S3 or similar ...

Although a plain rsync of the relevant amanda-dirs to somewhere else
would help as well and is rather easy to do.

In case of a fire or so I personally don't care much about the most
clever mechanisms used. Having valid backups on media is first prio then
... and as I have the amanda report mails on several machines it is
possible to find the tapes to restore from as well.

Sure, if I have my amanda-restore-live-DVD with latest indexes ... I
would use it :-)

That would be the ultimate tool, right? Generate a bootable iso with
up2date indexes everytime ... or let the live-media pull the pushed
indexes from owncloud/S3/etc ... ?

Sorry, I am dreaming ;-)

greets, Stefan

Reply via email to