Am 06.01.2015 um 09:46 schrieb Thomas Koch:

Hallo,

ich wollte mal kurz in die Runde fragen, ob schon jemand Erfahrung mit dem (Python basierten) Attic Backup gemacht hat.

Wir verwenden derzeit duplicity (http://duplicity.nongnu.org) und sind bei der Suche nach Alternativen auf Attic gestossen: https://attic-backup.org/

Ich nutze es (noch) nicht. Suche aber auch gerade ein Backupprogramm. Nach dem ersten Eindruck sieht aus wie eine kleine, gut gepflegte Anwendung mit aktiver Community. Es macht also einen guten Eindruck. Danke für den Hinweis. Gruß, Thomas -- http://www.thomas-guettler.de/

Am 06.01.2015 um 09:46 schrieb "Thomas Koch" <koch@orbiteam.de>:

Hallo, ich wollte mal kurz in die Runde fragen, ob schon jemand Erfahrung mit dem (Python basierten) Attic Backup gemacht hat.

Wir verwenden derzeit duplicity (http://duplicity.nongnu.org) und sind bei der Suche nach Alternativen auf Attic gestossen: https://attic-backup.org/

attic verwendet nicht nur Komprimierung sondern auch Deduplizierung (deduplication), um die Größe der Backup-Daten so klein wie möglich zu halten.

Ich kannte Attic noch nicht, das Folgende teile ich also ohne eigene Erfahrung mit Attic, aber ich suche auch derzeit auch Alternativen zu Duplicity. Mich interessieren also Antworten auf diese konkreten Punkte. Fokus beim Testen ist bei mir nicht nur Speed sondern die Qualität von Backup Tools bzw. der Archive. Ich habe früher die kommerzielle Lösung Retrospect eingesetzt, die konnte Mac, Win und Linux Systeme abdecken. Die ist aber seit EMC die gekauft hat nicht mehr zu gebrauchen. rsnapshot hat eine Weile auch seine Dienste getan. Es erzeugt selbst Hardlinks in Backup, failt aber wenn die Quelle bereits Hardlinks enthält. Es ist also "doofe" Simplifizierung zwischen Backup Generationen aber keine echte Deduplizierung. Was mich derzeit bei z.B. Attic interessiert: * Werden die Metadaten (z.B. Datum etc. ) der Instanzen bei Deduplizierung sauber erhalten? siehe [3] * Da gab es früher wohl Mankos bei Attic mit dem Datum. * Wie geht das Tool mit svn und git repos sowie mit offenen Dateien um (ohne LVM Snapshots etc.) . * Kann das Tool ACL über OS Grenzen hinweg sichern und zumindest bei gleichem Ziel wiederherstellen (gehört im weitesten Sinn zu Metadaten). * Kann man UserID in POSIX Manier in Sicherung und Wiederherstellung gut managen? * Wie geht Attic mit Hardlinks um? Duplicity multipliziert gerne mal die Größe der Backups, wenn die Quellen selber Subbackups mit Hardlinks enthalten. Thema Backup Encryption (offene Baustelle): * Kann ein Tool für jeden Owner getrennte Schlüssel beim Encrypten verwenden * Können Dateien von foo mit getrennten Schlüsseln von Ownern (z.B. root und foo gemeinsam verschlüsselt werden? Duplicity kann nur einen globalen Schlüssel. Da muss dann jedes Homedir global getrennt gesichert werden. * können root oder foo dann unabhängig entschlüsseln, * kann foo immer eigene Daten entschlüsseln, * Werden Gruppenschlüssel unterstützt? Das ist im Prinzip wie eine Schließanlage. Wichtig für ISO 27000 aus meiner naiven Sicht. * durch Zerstörung von Schlüsseln, können dann ggf. nur Teile eines Readonly Backups invalidiert werden ohne die Prüfsummen zu ändern (Umsetzung Datenschutz in Backups). Links ====== Attic sieht sehr interessant aus. Hier gibts ne kurze Review im Vergleich mit Obnam ... [1] http://librelist.com/browser//attic/2014/1/31/attic-vs-obnam/ und hier mit bup [2] http://anarcat.koumbit.org/2014-11-18-bup-vs-attic-silly-benchmark und hier einen üppigen Vergleich im Orchester. [3] https://wiki.archlinux.org/index.php/backup_programs interessantes Feature neben Speed ist aus meiner Sicht: Backups mountable as filesystems: Backup archives are mountable as userspace filesystems for easy backup verification and restores. Zum Testen von Backup Tools (Qualität, nicht Speed) hatte ich vor einiger Zeit Shell Scripte besorgt. Falls der testorientierte Ansatz interessiert: https://github.com/n8gray/Backup-Bouncer Kann man als Basis für eigen Tests ausbauen. LG Armin -- Armin Carl Stroß-Radschinski | developer@acsr.de | Twitter: @syncmitter Dipl. Designer FH | project-consultant | fon +49 171 21 94699 | IRC: acsr | Skype: astrossradschinski ACSR industrialdesign | Armin Stroß-Radschinski Landgrafenstraße 32 · 53842 Troisdorf · Germany | UST. ID Nr: DE154092803 (EU VAT ID) info@acsr.de | www.acsr.de | phone +49 2241 946994 · fax +49 2241 946996

On 2015-01-07 07:35, Armin Stroß-Radschinski wrote:

Am 06.01.2015 um 09:46 schrieb "Thomas Koch" <koch@orbiteam.de>: [...] rsnapshot hat eine Weile auch seine Dienste getan. Es erzeugt selbst Hardlinks in Backup, failt aber wenn die Quelle bereits Hardlinks enthält. Es ist also "doofe" Simplifizierung zwischen Backup Generationen aber keine echte Deduplizierung.

Das habe ich auch festgestellt, aber es hat mir gereicht. Offenbar ist es mit den "gängigen" Tools von der Laufzeit her sehr "teuer", Hardlinks in der Quelle auch im Ziel genauso abzubilden. Ich wollte mal eine ganze Platte mir `rsnapshot`-Archiven auf eine neue Platte kopieren, habe aber nach ca. 24 Stunden abgebrochen. Das Kopieren hatte ich sowohl mit `rsync` als auch mit `cp -axl` versucht. Ich kann es mir nur so erklären, dass die beiden Tools für jeden Hardlink die ganze Platte scannen, um diese Information nicht für _alle_ Dateien zwischenzuspeichern. Die `rsync`-Manpage enthält auch einen Hinweis dazu, allerdings nicht bei der `-H`-Option, sondern bei `-a`: -a, --archive This is equivalent to -rlptgoD. It is a quick way of saying you want recursion and want to preserve almost everything (with -H being a notable omission). The only exception to the above equivalence is when --files-from is specified, in which case -r is not implied. Note that -a does not preserve hardlinks, because finding multi‐ ply-linked files is expensive. You must separately specify -H. War eigentlich die eingeschränkte Behandlung von Hardlinks der Grund, warum du kein `rsnapshot` mehr einsetzt oder gab es einen anderen Grund beziehungsweise Gründe? Viele Grüße Stefan

Hi, Die Ursprungmail ist zwar schon 10 Monat alt, aber trotzdem: Am 06.01.2015 um 09:46 schrieb Thomas Koch:

Wir verwenden derzeit duplicity (http://duplicity.nongnu.org) und sind bei der Suche nach Alternativen auf Attic gestossen: https://attic-backup.org/

Von attic gibt es einen Fork "borg backup", offensichtlich weil der Maintainer von attic nicht bereit war, anderer Leute Fehlerbereinigungen zu übernehmen. Er möchte alles selbst programmieren. http://borgbackup.readthedocs.org/ -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/filmgesprach-zu-201ecitizenfour201c-in-her... Kolumne: http://www.cissp-gefluester.de/2010-11-it-sicherheit-im-unternehmen-eine-int...