ubuntuusers.de

Ich habe gerade nicht genug Zeit, das selbst nachzubilden. Von den Dingen ausgehend, an die ich mich von meiner früheren dirvish-Installation erinnern kann, passt das.

Seit mehreren Releases liegt dieselbe Version von dirvish in den Repos, insofern sollte sich nichts geändert haben. Da ich es seit vielen Jahren 1-2x wöchentlich für Backups benutze, kann ich die gesamte Anleitung aus eigener Praxis bestätigen. Ich bin sie trotzdem Schritt für Schritt durchgegangen und habe nichts entdeckt, das ich nicht genauso bis heute mache. Daher habe ich nur einen Absatz hinsichtlich der ersten Initialisierung eines Backups klarifiziert und die Links aktualisiert.

Hi!

Na, dann kann das ja wieder ins Wiki. Danke!

OT: könnte man das für Ubuntu Touch/Sicherung und Wiederherstellung verwenden, um ein Komplettbackup zu machen? Erscheint mir wesentlich einfacher als das, was im verlinkten Artikel steht (und bei mir zumindest nicht so richtig funktioniert...) - Na, ich versuch es mal, hab ja Zeit 😉

so long
hank

Im Prinzip müsste es mit jedem über ssh erreichbaren System mit rsync funktionieren (bzw. auch ohne ssh, dann über den rsync-daemon, wie auch im Artikel beschrieben). [WERBUNG] Das geniale an dirvish ist seine Umkehr des Prinzips der Backup-Software auf dem Quellsystem zur Backup-Software auf dem Zielsystem. So kann ein Rechner Backups mehrerer anderer im Netz machen, ohne dass auf diesen selbst dirvish installiert sein muss.[/WERBUNG]

Hi!

Artikel ist zurück im Wiki - Besten dank an V_for_Vortex! \o/

so long
hank

Ich danke Euch!

Hallo!

Scheint ein klasse tool zu sein. Bietet das auch einen "Pool", welches automatisch den benötigten Speicherplatz durch Hardlinks reduziert? Das wäre aus meiner Sicht der Vorteil von BackupPC, welches auch so arbeitet (Also Server greift auf Client zu und sichert diesen). Falls ja, wäre das noch wünschenswert für den Artikel 😉

Dirvish benutzt Hardlinks (bzw. das Hardlink-Feature von rsync) mit als konzeptionellen Kern. An und für sich macht es nichts anderes als das Ganze um eine Konfiguration und etwas Tooling zum Aufräumen und Automatisieren zu ergänzen. 😉

Stimmt, im Prinzip macht es folgendes:

cp -al letztes_backup neues_backup      # (hart-)verlinke das letzte Backup mit dem neuen Backup
rsync -a --delete original neues_backup # synchronisiere das neue Backup mit dem Original

Mit am praktischsten finde ich, dass die /etc/dirvish/master.conf nur die Mountpunkte der Backup-Medien („Banks“) definiert. Die Banks selbst beinhalten dann weitere Konfigurationsdateien für beliebige „Vaults“ ($BANK/$VAULT/dirvish/default.conf), die definieren, welche Verzeichnisse in die betreffende Vault gesichert werden sollen.

In der Praxis bedeutet das, dass allein das eingesteckte Backup-Medium entscheidet, was gesichert wird. Man muss es also nirgends mehr auswählen, sondern startet einfach Dirvish (dirvish-runall) und es sichert alles auf die gerade vorhandenen Medien, was laut diesen dorthin soll. Man kann allerdings die Vaults über die Option --vault auch direkt ansprechen.

War das verständlich oder zu konfus erklärt? ☺

edit: Noch etwas konfuser detaillierter erklärt.

V_for_Vortex schrieb:

War das verständlich oder zu konfus erklärt? ☺

Ja, war ausreichend erklärt. Also kein Pool, aber klingt trotzdem gut. BackupPC frisst ganz schön Leistung und braucht ewig. In Zeiten von Terabyte-Platten nicht mehr so zeitgemäß. Ich werde das mal lokal ausprobieren. Danke!

ChickenLipsRfun2eat schrieb:

BackupPC frisst ganz schön Leistung und braucht ewig.

Das ist bei dirvish (bzw. rsync) mit der Erstellung von Hardlinks m.E. leider nicht anders. Bei vielen Files (und damit Hardlinks) und wenig täglichen Änderungen gehen da auch ein paar Stunden drauf ...

dirkolus schrieb:

Das ist bei dirvish (bzw. rsync) mit der Erstellung von Hardlinks m.E. leider nicht anders. Bei vielen Files (und damit Hardlinks) und wenig täglichen Änderungen gehen da auch ein paar Stunden drauf ...

Der Unterschied ist, dass nicht aus allen bestehenden Backups ein Pool generiert wird, insofern dürfte es schneller sein als BPC. Wenn du 5 Geräte sicherst, packt BPC alle Dateien in einen Pool und hardlinkt diese bei doppeltem Auftreten, so dass jede Datei wirklich nur einmal physikalisch existiert. Das ist bei dirvish anders, so wie ich das verstanden habe. Da beschränkt sich die Hardlink-Geschichte auf einen Klienten.

dirkolus schrieb:

Das ist bei dirvish (bzw. rsync) mit der Erstellung von Hardlinks m.E. leider nicht anders. Bei vielen Files (und damit Hardlinks) und wenig täglichen Änderungen gehen da auch ein paar Stunden drauf ...

Ich mache wöchentlich ein Backup von vier Rechnern (1x der Backup-PC selbst, 2 zweitere über LAN, 1 weiterer über WLAN) auf eine herkömmliche HDD in einem USB-3.1-Dock. Das dauert in der Regel zwei bis zweieinhalb Stunden. Das sind extrem viele Dateien, darunter z.B. ein Minecraft-Server und seine täglichen, ebenfals hart verlinkten Backups der letzten 1-1½ Wochen.

Kurz mal reinschieben und kurz darauf warten ist es tatsächlich nicht, dirvish ist eher für den zeitgesteuerten oder zumindest nicht direkt überwachten Betrieb gedacht. Dafür benötigt es einmal eingerichtet nicht mehr als reinschieben, dirvish starten, irgendwas anderes machen, fertig. Ich starte es meistens vor der Morgentoilette und dem anschließenden Frühstück.

ChickenLipsRfun2eat schrieb:

Das ist bei dirvish anders, so wie ich das verstanden habe. Da beschränkt sich die Hardlink-Geschichte auf einen Klienten.

Genauer gesagt auf eine Vault. Hat eine Bank mehrere Vaults von einem Klienten, werden sie nicht untereinander verlinkt. Das kann man positiv und negativ sehen – klare Trennung der Vaults gegen mehr Platzverbrauch in der Bank. Wobei man bei Bedarf zusätzlich das Programm Hardlink über die ganze Bank laufen lassen könnte. Nebenbei ist auf diese Weise jedes Backup zwar inkrementell, aber letztlich für sich alleine ein von seinen Vorgängern unabhängiges Voll-Backup, was das eventuelle Wiederherstellen stark vereinfacht, so wie das durch dirvish-expire automatisierbare Löschen alter Backups nach einem gewissen Verfallszeitraum (per Default sechs Monate).

Man merkt, ich bin von dirvish seit Jahren ziemlich begeistert. 😀

edit: Ach ja, zum Resourcenverbrauch. Ich habe gerade mein typisches 4-Rechner-Backup gemacht und dabei mit htop auf CPU- und RAM-Belastung geschaut. Während des Backups einer Vault braucht dirvish fast durchgehend 0.0% CPU und 0.1% RAM des Systems. Nur beim etwa 1-2-minütigen Abschluss einer Vault geht die CPU-Last kurz auf 30-40% hoch. Der Rechner ist ein passiv gekühlter MSI Cubi 3 Silent Mini-PC mit einem Intel i3-7100U Quadcore-Prozessor mit 2,40 GHz und 16 GB RAM.

V_for_Vortex schrieb:

Man merkt, ich bin von dirvish seit Jahren ziemlich begeistert…

So ging es mir mit BPC. SSH am Klient einrichten, den Rest macht der alleine. Allerdings rödelt da die Platte wirklich stundenlang, da das was Hardlink macht integriert ist. CPU und RAM braucht es auch nicht viel, aber die Festplatten laufen ordentliche Runden. Durch meinen mittlerweile anderen Ansatz (lokaler Gitserver und parallel Nextcloud) muss ich aber nur noch den Server selbst (und das Handy) sichern. Aktuell mache ich das noch mit rsync und einem systemd-timer wie im Mittelalter 😉

Ich habe eine neue Rubrik „Tipps und Tricks“ mit einem ersten Tipp angelegt, den ich mir heute selber anlesen musste, um ein älteres Backup vor seinem Ablaufdatum per dirvish-expire zu löschen.

Hier die Änderungen: https://wiki.ubuntuusers.de/dirvish/a/diff/984470/984523/