Feature request: Multiple targets for a single profile

[wxcafe]

Hi,

I was wondering if it would be possible to get multiple targets for a single profile? for example:

duplicity::profile {'conf_file':
  full_if_older_than => '2W',
  max_full_backups => 3,
  volsize => 500,
  cron_enabled => true,
  cron_hour => '03',
  cron_minute => '00',
  gpg_encryption => false,
  targets => ["sftp://user1:[email protected]//srv/backups/$hostname", "sftp://user2:[email protected]//srv/backups/$hostname"],
}

which would back objects declared with duplicity::file to the two different remote servers.

Seeing as this is unsupported I tried doing it with two profiles (that have the two different targets) and duplicating the duplicity::file objects, but that breaks ( Duplicate declaration: Exec[restore /etc/] is already declared at [...]; cannot redeclare, the Exec gets declared with the path, not the name of the duplicity::file object). It would also be a lot easier not to have to duplicate every single duplicity::file object for all my servers...

Thanks

[goetzk]

I'm considering the same behaviour so had a quick browse around too.

As best I can tell duplicity itself doesn't support multiple upload targets and I didn't see a way to work around that via duply.
http://duplicity.nongnu.org/vers8/duplicity.1.html
http://duply.net/Documentation

I'm not sure the best way to add this but I suspect the module would have to check if targets is defined then re invoke duplicity::profile twice. file would have to change from using path to profile+path in its identifier.
Is that roughly your understanding too?

[tohuwabohu]

I understand the desire for multiple targets as a way to improve resilience in case the primary backup server crashes.

The tricky bit is as @goetzk mentioned that neither duplicty nor duply support this as a first class use case which means any possible solution would have to work around other issues

• Same profile twice with different targets (e.g. system-target1 and system-target2): doubles the time to take a backup and increases disk space footprint of the local cache. Also now restoring becomes challenging, do you always pick backup1? Or the most recent snapshot? I guess a variant of this is what wxcafe already has in place right now.
• One profile, swap target dynamically and run backup twice: this may leave duplicity in a weird state if you swap between different 'external states' forth and back; similar downsides as the one above

Another option could be to set up replication on the primary and push the updates out to the secondary, perhaps triggered via a post-update script. Alternatively, may be there is a smart way to just grab the files from the local cache and upload them to the other server.