Léa-Linux & amis :   LinuxFR   GCU-Squad   Zarb.Org   GNU
Archive de la liste aide - [Aide] Attic Backup
Bonjour Marcel, et LaListe

Je ne connaissais pas. Ca présente bien à première vue. Merci pour
l'information.
Merci de nous raffraîchir l'esprit.

Je ne sais donc rien, mais je dirai tout.

1.
En cherchant, on voit qu'on oppose les nouveaux venus (new-generation
hash-backup tools) :

- Attic
- obnam
- zbackup
- Vembu Hive
- etc

Qui fournissent de "l'encrypted incremental-forever with no
server-side processing and a convenient CLI interface, and it does let
you prune old backups."



contrairement aux "vieux" :
- duplicity
- duplicati
- rsnapshot
- rdiff-backup
- Ahsay
- etc

"All other common tools seem to fail on one of the following points
- Incremental forever (bandwidth is expensive in a lot of countries)
- Untrusted remote storage (so i can hook it up to a dodgy lowendbox VPS)
- Optional: No server-side processing needed (so i can hook it up to
S3 or Dropbox)"


Pour autant, ça suscite des débats:

"Sorry, but "Untrusted remote storage" and "No server-side processing"
are exactly the opposite of what I need.

If the original box is ever compromised, I don't want the attacker to
gain any access to the backup. If you use a dumb storage like S3 as
your backup server, you need to store your keys on the original box,
and anyone who gains control of the original box can destroy your S3
bucket as well. Ditto for any SSH-based backup scheme that requires
keys to be stored on the original box. A compromised box could also
lie about checksums, silently corrupting your backups.

Backups should be pulled from the backup box, not pushed from the
original box. Pushing backups is only acceptable for consumer devices,
and even then, only because we don't have a reliable way to pull data
from them (due to frequently changing IP addresses, NAT, etc).

The backup box needs to be even more trustworthy than the original
box, not the other way around. I'm willing to live with a significant
amount of overhead, both in storage and in bandwidth, in order not to
violate this principle.

The backup box, of course, could push encrypted data to untrusted
storage, such as S3. But only after it has pulled from the original
box. In both cases, the connection is initiated from the backup box,
not the other way around. The backup box never accepts any incoming
connection.

Does Attic support this kind of use case? The documentation doesn't
seem to have anything to say about backing up remote files to local
repositories. I don't see any reason why it won't be supported (since
rsync does), but "nominally supported" is different from "optimized
for that use case", and I suspect that many of the latest generation
of backup tools are optimized for the opposite use case."


Voilà, voilà, débats à suivre:
https://news.ycombinator.com/item?id=8621372




2.
Pour mes DebianBox, j'ai trouvé ceci, avec des commentaires en fin
d'article. Il y a du pour, du contre {performances diminuant dans le
temps, problématique de backup de serveurs multiples avec chiffrement
on optimisé} , et des références à d'autres solutions.
https://debian-administration.org/article/712/An_introduction_to_the_attic_backup_program


Autre article de fond sur la comparaison (récente 2015) de solutions de backup
http://changelog.complete.org/archives/9353-roundup-of-remote-encrypted-deduplicated-backups-in-linux


Je n'ai pas tout lu, mais j'ai compris qu'on oppose les nouveaux venus


3.
Il me reste à lire
http://librelist.com/browser/attic/2015/3/31/comparison-of-attic-vs-bup-vs-obnam/


http://peterjolson.com/full-system-backup-using-attic-backup-to-nfs/

http://librelist.com/browser//attic/2014/11/11/backing-up-multiple-servers-into-a-single-repository/#e96345aa5a3469a87786675d65da492b


--P

Serveur hébergé par ST-Hebergement et Lost-Oasis / IRC hébergé par FreeNode / NS secondaire hébergé par XName
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons