btrfs-fähige Backup-Lösung

14

Da btrfs in diesem Monat die Produktion in Oracle EL 14 erreicht hat (zusammen mit der Arbeit mit fsck und dem Scrubben von Linux 3.2), dachte ich darüber nach, meine aktuelle Backup-Lösung neu zu entwerfen, um sie zu nutzen. Beachten Sie, dass ich darüber nachdenke, dies für kleine Datenmengen mit weniger als 10 TB zu tun, die relativ statisch sind (weniger als 1% werden täglich geändert). Kurz gesagt, eine SMB / SOHO-Backup-Lösung.

Was die Sicherung tun soll:

Erstellen Sie einen LVM-Snapshot von ext [234] / XFS / JFS auf dem Produktionsserver
rsync/ Geänderte Daten an btrfs auf dem Sicherungsserver übertragen
Snapshot des btrfs-Dateisystems
Löschen Sie alte Schnappschüsse, wenn der verfügbare Speicherplatz knapp wird

Vorteile:

Alle Dateien leicht verfügbar, keine Dekomprimierung oder Loop-Montage erforderlich
Vergangene Schnappschüsse auch leicht verfügbar ...
... damit ich sie als schreibgeschützte Samba-Freigaben freigeben kann (mit Unterstützung für Schattenkopien)
Snapshots benötigen dank Copy-on-Write nur minimalen Speicherplatz (Snapshot ohne Änderungen benötigt buchstäblich wenige KB auf der Festplatte)
Hohe Backup-Konsistenz: Prüfsummen für Dateien, Bereinigung aller Daten und integrierte Redundanz

Fragen:

Gibt es eine Sicherungslösung (in Form von Bacula, BackupPC usw.), die das Copy-on-Write-Dateisystem erkennt oder einfach erkennt?
Oder muss ich eine In-Home- rsyncLösung verwenden?
Was machen Leute mit ZFS-Boxen für Backups, um ihre Linux-Maschinen zu sichern?

— Hubert Kario
quelle

Kann nicht sehen cons! Eine davon ist, dass Btrfs-Snapshots nur Teilsicherungen entsprechen (keine physische Kopie pro Sicherung Ihrer Datei auf der CD). Dies könnte bei Problemen mit der Festplattenoberfläche von Bedeutung sein. Beachten Sie, dass Sie eine Duplizierung erzwingen können, wenn die native RAID1-Unterstützung in Btrfs enthalten ist.

— Vaab

1

@vaab: das ist a pro- mehr als zwei Kopien werden nicht wirklich benötigt, wenn Sie Prüfsummen haben und den FS aktiv schrubben, drei werden wahrscheinlich mit RAID6-Unterstützung geliefert. Wie gesagt, es handelt sich um ein Setup für ein dediziertes Backup-System, nicht um "Backup" -Kopien innerhalb des FS auf einem einzelnen Computer. Das wäre "RAID ist kein Backup" und "Snapshots sind kein Backup". cp -aund rsyncsind dafür ...

— Hubert Kario

Ich habe auch überlegt, auf btrfs zu sichern, aber ich habe nur darüber nachgedacht rsync -a --delete /home/user /mnt/butterfs/backups/ && snapper create- abgesehen davon , dass ich nach dem Sichern einen Snapshot erstellt habe, was meinen Sie mit COW-fähig?

— Unhammer

1

@unhammer: Bei Verwendung von rsyncwithout erhalten --inplaceSie mehrere Kopien derselben Daten im Remote-Dateisystem. (rsync kopiert normalerweise Daten in eine temporäre versteckte Datei und verschiebt sie dann über die alte Datei. Mit einem Copy-On-Write-Dateisystem erhalten Sie auf diese Weise zwei Kopien mit unveränderten Daten.)

— Hubert Kario

5

Ich habe in der letzten Woche intensiv nach etwas Ähnlichem gesucht. Ich habe keine Lösung für alle 4 Schritte gefunden. Es gibt zahlreiche Blogs von Heimanwendern, die den ' rsync to btrfs' -Typ von Backups ausprobieren , und alle wichtigen Btrfs-Wikis beschreiben, wie Btrfs-Snapshots ausgeführt werden.

Es gibt auch einige Leute, die versuchen, Btrfs-Schnappschüsse auf unterschiedliche Weise zu drehen . Sie sind jedoch die erste Person, die Snapshots basierend auf dem Speicherplatz drehen möchte. Ich spiele selbst mit btrfs-snap , das eine Reihe von stündlichen, wöchentlichen und monatlichen Schnappschüssen erstellt, und es ist nett und einfach.

Das Dirvish- Projekt scheint viele Ihrer Anforderungen zu erfüllen. Einige Entwickler versuchen, Dirvish in Btrfs zu integrieren . Das Dirvish-Projekt scheint jedoch etwas ins Stocken geraten zu sein .

Zu diesem Zeitpunkt sind Sie der Kurve voraus.

— Stefan Lasiewski
quelle

Nun, ich möchte nur eine Backup-Lösung, die so schmerzfrei ist wie BackupPC: Wenn der Speicherplatz knapp ist, werden nur alte Daten (alte Snapshots) gelöscht. Obwohl ich befürchtet hatte, dass ich der Kurve voraus bin, ist es nicht so, dass ZFS seit einigen Jahren nicht mehr bei uns ist ...

— Hubert Kario

3

Laut Avi Miller (sein Vortrag während LinuxConf.AU) wird an einem BTRFS-Senden / Empfangen gearbeitet. Es ist schneller als rsync, da es keine Verzeichnisse durchsuchen muss, um Änderungen in Dateien zu finden. Ich weiß jedoch nicht, ob es ein voraussichtliches Veröffentlichungsdatum gibt.

Es gibt jedoch ein in btrfs-progs eingebautes Dienstprogramm, das jede Datei auflistet, die sich zwischen snapshots / etc. Geändert hat. Btrfs subvolume find-new

— ausborgen
quelle

2

Ich möchte Backup zu Btrfs, nicht aus ...

— Hubert Kario

2

Ich arbeite an einem Betriebssystem-Backup-System, das BackupPC ähnelt. Ich habe darüber nachgedacht. Was mich davon abgehalten hat, das zu implementieren, ist, dass Sie keine festen Verbindungen zwischen Subvolumes herstellen können. Sie können auch nur Momentaufnahmen von Subvolumes erstellen -> Ein Subvolume pro Backup-Client. Daher kann die Deduplizierungsfunktion auf Dateiebene nicht gleichzeitig mit diesem Ansatz ausgeführt werden. Und diese Deduplizierung auf Dateiebene spart normalerweise viel Platz. Möchten Sie nur einen Server sichern?

Wenn btrfs eine Deduplizierung auf Blockebene hatte, kann dieses Problem wahrscheinlich vermieden werden, aber das ist normalerweise auch unerträglich langsam ...

Dann würde ein solcher Ansatz natürlich eine enge Integration in ein Dateisystem (btrfs) mit sich bringen, so dass dies eine optionale Funktion sein sollte.

Ich frage, weil ich darüber nachdenke, eine solche Kuh-Funktion hinzuzufügen, aber ich weiß nicht, ob ich das tun soll, weil die oben genannten Nachteile vorliegen.

Edit: UrBackup unterstützt Backups wie in der Frage beschrieben jetzt mit Linux-Kerneln> = 3.6 (mit Cross-Volume-Reflink-Unterstützung). Sehen Sie, wie es eingerichtet wird.

— UrOni
quelle

1

Die subvolumenübergreifende Reflink-Kopie (ein Semi-Hardlink von cp --reflink) ist entweder bereits implementiert oder wird in naher Zukunft implementiert. Online-Deduplizierung in FS ist entweder langsam (lessfs) oder benötigt große Mengen an RAM (ZFS) so je nach wäre es wirklich eine schlechte Funktion in Backup - Software sein. In jedem Fall wird die BTRFS-orientierte Backup-Software ein großes Publikum haben, sie sollte doch die nächste ext3 sein.

— Hubert Kario

Eine weitere Sache: Sie können dieses Problem umgehen, indem Sie alle Server in einem Sub-Volume belassen - Sie können eine Kopie zwischen ihnen erneut verknüpfen (um sie zu deduplizieren), während die Snapshot-Fähigkeit erhalten bleibt. Sie müssen nur einen Snapshot erstellen, nachdem Sie die Deduplizierung durchgeführt haben. Sie können einen Snapshot erstellen, nachdem Sie nur einen einzelnen Server gesichert haben. Die Sicherungen belegen nicht mehr Speicherplatz, wenn Sie die Sicherungen einzeln ausführen. Alternativ können Sie alle Server sichern, deduplizieren und erst dann einen Snapshot erstellen. Auf diese Weise können Sie einige Server gleichzeitig sichern.

— Hubert Kario

Du hast recht. Daran habe ich nicht gedacht. Der Einfachheit halber können Sie dann auf die richtigen Schnappschüsse in einem anderen Volume verweisen. Ich habe auch einen Patch für Cross-Volume-Hardlink (oder --reflink) gesehen, aber es sah nicht so aus, als hätte er es geschafft / oder würde es zum Mainline machen. Ich werde das wirklich untersuchen! Jetzt machst du wahrscheinlich deine Backups über ssh. Mein Projekt ist auf lokale Netzwerke spezialisiert ... (automatische

— Erkennung

Ja, der Patch ist am Leben und funktioniert, leider nicht im Mainline, ich weiß nicht warum. Ich versuche, Chris Mason daran zu hindern. Für Ihr Projekt schreiben Sie mir bitte eine E-Mail, ich werde es gerne im Beta-Test testen (soweit es die Zeit erlaubt). Das hört sich sicher interessant an.

— Hubert Kario

Schließlich landete dieser Patch im Haupt-Linux-Kernel 3.6. Mit dem geräteübergreifenden Rücklink war es eigentlich nicht so viel Arbeit. Ich habe hier darüber geschrieben: urbackup.org/blog/?p=83 Der Code befindet sich im "nächsten" Zweig im Git-Repository. Ich teste es gerade.

— UrOni

1

Die btrfs-Wiki-Seite " Use Cases " listet einige Tools auf: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Es gibt einen Vorschlag für ein eingebautes Tool namens Autosnap :

Mit der Autosnap-Funktion können Sie btrfs so konfigurieren, dass regelmäßige oder ereignisbasierte Snapshots erstellt und die Snapshots automatisch weiter verwaltet werden.

Bei Autosnap geht es nicht nur um das Aufnehmen des Snapshots, sondern auch um das Verwalten der erstellten Snapshots. Ab sofort können Sie Autosnap so konfigurieren, dass die Snapshots basierend auf dem vom Dateisystem verwendeten Speicherplatz gelöscht werden.

Ab Oktober 2013 heißt es jedoch im Wiki : "Die Autosnap-Funktionalität ist derzeit nicht in der Upstream-Version von btrfs enthalten."

— ignis
quelle

1

Ich hatte ähnliche Frustrationen und habe am Ende ein paar Skripte erstellt, die ich Snazzer nenne . Zusammen bieten sie Schnappschusserstellung, Bereinigung, Messung und Transport über ssh (können aber ab heute auch lokale Dateisysteme senden / empfangen). Messungen sind nur Berichte über sha512sum und PGP-Signaturen von Snapshot-Pfaden. Es ist noch nicht fertig für die Veröffentlichung, aber ich würde mich über Feedback freuen, wenn jemand Zeit hat, es zu diesem frühen Zeitpunkt zu überprüfen.

CLI-nur an dieser Stelle, aber ich habe einige Zeit gedauert, um es einfach mit Subvolumes vielen Btrfs auf Systeme verwendet werden - in der Regel Ich habe getrenntes Subvolumes für /var/cache, /homeetc. , die von Snapshot- oder mehr / weniger ausgeschlossen kann es erforderlich sein aggressive Schnittpläne.

Ich befürchte, der Bereinigungsalgorithmus entscheidet nur über das Vorhandensein der Schnappschüsse und ihrer Daten. Es gibt nichts, was Sie bereinigen können, bis eine Einschränkung der Festplattennutzung erfüllt ist. Welche löschen Sie zuerst? Reduzieren Sie zuerst die Anzahl der Stunden- oder Tageszeitungen? Lassen Sie vielleicht den ältesten fallen, z. Jährliche? Unterschiedliche Bereitstellungen haben unterschiedliche Prioritäten. und ich kann nicht wissen, ob dies die einzige Sicherungsstufe ist (in diesem Fall sollten Sie bei rechtlichen / versicherungstechnischen Verpflichtungen die ältesten Sicherungen nicht löschen), oder nur eine Zwischenstufe (in diesem Fall haben Sie diese Jahrbücher wahrscheinlich an einem sicheren Ort archiviert anderswo).

Ich werde irgendwann ZFS-Unterstützung und / oder Interoperabilität hinzufügen. es ist hauptsächlich in posix-ish-Shell und Perl geschrieben, da ich im Moment keine Abhängigkeiten mehr haben möchte. Ich hoffe, dass irgendwann eine sauberere alternative Python-Implementierung parallel gepflegt wird.

— csirac2
quelle

Sofern Ihr FS nicht sehr groß ist und sich häufig ändert, gibt es kaum einen Unterschied zwischen dem Speichern eines Schnappschusses von vor einem Monat und dem Speichern eines Schnappschusses von vor einer Woche pro Tag für den gesamten Monat. BTRFS muss den Unterschied zwischen speichern aktueller Stand und sowieso der von vor einem Monat - ich behalte nur Tageszeitungen, aber weil sie komprimiert und unterschiedlich sind, kann ich sie leicht ein halbes Jahr zurückhalten - und dann die ältesten Garantien fallen lassen, um wenigstens etwas Platz

— freizugeben

Nun, ich habe eine nicht triviale Anzahl von VMs im Auge - einige mit großen transienten Dateien (dh Snapshots mit einzigartigen Ausmaßen), die, wie Sie vorgeschlagen haben, vom Bereinigen von Zwischen-Snapshots profitieren können. Obwohl es stimmt, dass das Bereinigen von Intermediates nicht so viel Speicherplatz freigibt wie das Löschen der ältesten, kann ich sagen, dass es ungefähr so effizient zu sein scheint, nur die minimale Anzahl von Snapshots zu behalten und dies mit einem COW-Dateisystem wie btrfs zu tun bekommt, aber ich

— weiß

@ csirac2 bist du der snazzer? Ich suche nach einer solchen Lösung. Ich bin an Snazzer interessiert, wenn es aktiv gewartet wird. GitHub scheint keine neuen Aktivitäten

— anzuzeigen

@MountainX Als ich nicht viel anfängliches Feedback zu Snazzer bekam, verlor ich die Begeisterung. Als ich anfing, es zu schreiben, gab es wirklich nur OpenSUSEs Snapper und eine Handvoll Shell- / Python-Skripte, mit denen ich BTRFS automatisieren konnte. Bis ich es mit der Welt teilen konnte, tauchten viele andere Optionen auf, und ich würde sagen, Btrbk scheint viel Schwung zu haben (das Fehlen automatisierter Tests [vielleicht jetzt behoben?] War jedoch besorgniserregend). Wenn ich alles noch einmal machen müsste, hätte ich wahrscheinlich mit dem sanoiden Autor zusammengearbeitet, um dort die BTRFS-Kompatibilität hinzuzufügen. Interessiert, Ihre Gedanken zu hören.

— csirac2