Automatically dumping the amanda configuration is complicated
* output of 'amgetconf build.config_dir' # default to /etc/amanda
* /etc/amanda/security.conf # in 3.4.2: output of 'amgetconf
build.security_file'
* Must check all includefile directive from $config_dir/amanda-client.conf
* ~/.amandahosts
* inetd / xinetd / systemd configuration
Then for each config:
* output of 'amgetconf CONF logdir'
* output of 'amgetconf CONF indexdir'
* output of 'amgetconf CONF infofle'
* output of 'amgetconf CONF tapelist' # if not in $config_dir
* output of 'amgetconf CONF diskfile' # if not in $config_dir
* The changer file of every changer
* Must check all includefile directive from:
o $config_dir/CONF/amanda-client.conf
o $config_dir/CONF/amanda.conf
o disklist file
* auth setting:
o ~/.ssh
o kerberos setting
o ssl:
+ amgetconf CONF ssl-dir
+ amgetconf --client CONF ssl-dir
* encryption keys
o amcrypt-ossl-asym
+ ~/.am_passphrase
+ ~/backup-privkey.pem
+ ~/backup-pubkey.pem
o amcrypt-ossl
+ ~/.am_passphrase
o amcrypt
+ ~/.am_passphrase
o amcryptsimple
+ ~/.am_passphrase
+ ~/.gnupg
This list is not exhaustive, I probably missed something.
What if there is symlink? Should we follow them?
I think the best is to have a script or an amanda application (like amgtar)
That application will get:
* a list of directories/files to backup
* a list of config (or an all config setting)
* it verify that all required files are in the listed directories/files
We could add setting in the dumptype to guarantee that this dle is
backed up after all other dle are put on tape.
Another solution is to backup that dle in a new configuration.
Where to put that dle?
* tape: It can be hard to recover, because you must know where it is
on tape
* cloud: If you know how to manually restore it.
* vtape: keeping it on the server is bad,
* vtape on nfs: I dislike nfs for backup, but I think it is a good use
here.
Jean-Louis
On 05/01/17 08:46 AM, Stefan G. Weichinger wrote:
> 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
Disclaimer
The information contained in this communication from the sender is
confidential. It is intended solely for use by the recipient and others
authorized to receive it. If you are not the recipient, you are hereby notified
that any disclosure, copying, distribution or taking action in relation of the
contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been
automatically archived by Mimecast Ltd, an innovator in Software as a Service
(SaaS) for business. Providing a safer and more useful place for your human
generated data. Specializing in; Security, archiving and compliance. To find
out more visit the Mimecast website.
