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.
Viele Grüße,
Thomas
--
OrbiTeam Software GmbH & Co. KG
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
On 2015-01-06 20:53, Thomas Güttler wrote:
Am 06.01.2015 um 09:46 schrieb Thomas Koch:
ich wollte mal kurz in die Runde fragen, ob schon jemand Erfahrung mit dem (Python basierten) Attic Backup gemacht hat.
[...]
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.
Ich verwende schon seit etlichen Jahren rsnapshot [1] für Backups. Das funktioniert aber nur sinnvoll (bezüglich Platzbedarf) bei Backups auf Medien/Dateisysteme, die Hardlinks unterstützen.
Was ich an rsnapshot besonders schön finde, ist die Lesbarkeit der gesicherten Dateien ohne spezielle Tools. Man muss nur gegebenenfalls das Backup-Dateisystem mounten und kann dann die Daten aus dem passenden Verzeichnis lesen.
Falls jemand von euch Attic _und_ rsnapshot kennt: Was wären denn Vor- und Nachteile von Attic gegenüber rsnapshot? Eine Websuche hat nichts Hilfreiches ergeben.
Eine Sache, die ich gefunden habe, ist die direkte Unterstützung von verschlüsselten Backups bei Attic.
Laut der PyPI-Seite ist Attic noch im Beta-Status. Wie so oft bei Open-Source-Software kann die Software trotzdem sehr stabil sein, aber bei Backup-Software wäre ich besonders vorsichtig.
Viele Grüße Stefan
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
Hallo *,
seit einiger Zeit benutze ich `obnam http://obnam.org/`_. Es scheint stabil zu funktionieren, legt verschlüsselte Backups an und dedupliziert „chunkweise“. Es läuft einigermaßen schnell (was immer Ihr mit dieser Aussage anfangen könnt) und hat bei den glücklicherweise wenigen Gelegenheiten, als ich es gebraucht habe, die Dateien problemlos restauriert.
Es ist allerdings m.W. nur für Linux verfügbar.
Viele Grüße, Detlef
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
Am 07.01.2015 um 21:24 schrieb Stefan Schwarzer sschwarzer@sschwarzer.net:
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.
Der Artikel (incl. der Comments!) ist sehr aufschluss- und hilfreich... http://linuxcommando.blogspot.de/2008/09/how-to-find-and-delete-all-hard-lin...
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?
Irgendwann war die Config im Eimer und die Ziel Platte lief immer sofort voll. Die Fehlersuche war zeitraubend und nicht erfolgreich. Kann meine Dummheit gewesen sein.
Aber bestehende Backups manuell zu löschen, um aktuelle Backups ans laufen zu bekommen, kann es auf Dauer nicht sein. Da Erwarte ich smarte Lösungen. Man darf nicht naiv sein, aber konzeptionelle Schwächen sind keine Seltenheit. Also gerne mal den Überlauf simulieren. Geht gut in einem kleinen Test ZielImage.
Die Qualität von Software zeigt sich im Sonder-, Fehlerfall. Im Idealfall funktionierenden Code zu erzeugen ist keine Kunst an sich sondern Minimalanforderung.
-- 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
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/
participants (6)
-
Armin Stroß-Radschinski -
Detlef Lannert -
Hartmut Goebel -
Stefan Schwarzer -
Thomas Güttler -
Thomas Koch