On 2017-10-19 11:06, Jean-Louis Martineau wrote:
On 19/10/17 08:48 AM, Austin S. Hemmelgarn wrote:
> On 2017-10-18 15:45, Stefan G. Weichinger wrote:
>> Am 2017-10-16 um 20:47 schrieb Austin S. Hemmelgarn:
>>
>>> While it's not official documentation, I've got a working
>>> configuration with
>>> Amanda 3.5.0 on my personal systems, using locally accessible
>>> storage for
>>> primary backups, and S3 for vaulting (though I vault everything, the
>>> local
>>> storage is for getting old files back, S3 is for disaster
>>> recovery). I've
>>> put a copy of the relevant config fragment at the end of this reply,
>>> with
>>> various private data replaced, and some bits that aren't really
>>> relevant
>>> (like labeling options) elided.
>>
>> A quick thank you at this point:
>>
>> thanks for providing this config plus explanations, I will try to set up
>> a similar config soon and take your example as a template.
>>
>> And maybe come back with some additional questions ;-)
>>
>> for example: what do you run as cronjobs, what do you do via manual
>> commands? amdump in cron, amvault now and then?
> Well, there's two options for how to handle it.
>
> Where I work, we use a very similar configuration to what I posted,
> and run amdump and amvault independently, both through cron (though we
> only vault full backups to S3 since we have a reasonably good level of
> trust in the reliability of our local storage). This gives very good
> control of exactly what and exactly when things get vaulted, and
> allows for scheduling vaulting separately from dumps (we prefer to
> only copy things out to S3 once a month and need to make sure the
> network isn't bogged down with backups during work hours, so this is a
> big plus for us).
The problem with the amvault command is that it do only according to the
command line, which can be difficult to get right.
If amvault fail, it's hard to find the correct arguments to vault what
was not yet vaulted.
With wrong arguments, some dump might never be vaulted, or some dumps
might be vaulted multiple time (on different amvault invocation).
To be entirely honest, I wouldn't exactly call `--latest-fulls`,
`--fulls-only`, or `--incrs-only` hard to get right. It's only really
tricky if you want to only vault subsets of the config. Add to that
that it's pretty easy to see what got vaulted if you have e-mail set up
right, and it really isn't too bad for most use cases.
Since you want to vault all full, I would set 'vault' in the local
storage, set 'dump-selection' in the cloud storage, but will not set
'vault-storage'
That way the vault are scheduled but are not executed because
vault-storage is not set. Amanda know they must be vaulted.
Every month, you can run: amdump CONF BADHOST -ovault-storage="cloud"
to do the vaulting.
We've actually been discussing migrating things to operate like I have
them set up on my home systems (albeit only vaulting fulls), as the
'once a month' part of vaulting is largely a hold-over from our old
(pre-Amanda) backup system which did fulls on the first of the month,
and archived them off-site the day afterwards.
>
> On my home systems, I also use a similar config, but I instead have a
> 'vault' option specified in the 'local' storage block that points to
> the 'cloud' and says to vault immediately after dump generation(so the
> line is 'vault cloud 0'). With this setup, amdump will run the
> vaulting operation itself after finishing everything else for the dump
> (and you actually don't need the 'vault-storage' line at the end I
> think), and you either end up vaulting everything, or have to limit
> things through the config with a 'dump-selection' line in your 'cloud'
> storage definition.
vault-storage is required, otherwise the vault are not executed.
Good to know, that could probably be better explained in the documentation.
