bislang mache ich meine Backups mit einem rsync Einzeiler per SSH auf ein NAS. Das klappt prima und dauert bei rund 380 GB Daten (ohne VMs), wenn wenig Änderungen vorhanden sind, wenige Minuten.
Da mir schon länger im Kopf rum spuckt, ein versioniertes Backup einzurichten, um versehentliche gelöschte Daten nicht beim Backup auch dort zu löschen, habe ich mal etwas recherchiert und bin im Ubuntu-Wiki auf ein vielversprechendes Skript gestoßen.
Mit wenigen Daten macht das auch prima was es soll. Mit großem Datenbestand dauert jeder Lauf eine deutlich zweistellige Stundenzahl, wenn ich das über einen cifs-Mount mache.
Abend,
weiss jetzt nicht genau was Du willst, aber ich nehm fuer alles und schon immer rsnapshot durch ssh, nutzt hardlinks und haelt so Generationen mit ueberschaubarer Speichermenge vor. Im Hintergrund laeuft natuerlich auch rsync
Gruss Harry
stimmt, da war was. Jetzt klingelt der Begriff bei mir auch wieder.
Wenn ich nicht irre, muss man dazu aber rsnapshot installieren und die Konfiguration in einer config-Datei einrichten, sprich, man kann nicht so leicht verschiedene Syncs einrichten, oder sehe ich das falsch?
das geht problemlos. Erstens kannst Du für einen Speicherort mehrere Backups definieren, und wenn Du unterschiedliche Speicherziele oder komplexere Unterschiede haben willst, dann kannst Du rsnapshot einfach eine andere Konfigurationsdatei mitgeben.
Ich habe vor längerer Zeit mal einen Wrapper um Rsnapshot herum geschrieben, der diverse Dienste anhält und wieder startet, Verschlüsselung mit Veracrypt unterstützt und noch so dies und das, beispielsweise synce ich erst mal „ins Unreine“ und dann mit angehaltenen Diensten nochmal, so ist die Downtime geringer. Verwende ich auch privat. Aber auch Rsnapshot selbst kennt Hooks vor und nach dem Backup.
borgbackup ist eine gute Lösung. Ich muss dazu sagen, dass ich voll in Ruhe bin seit dem wir einen Proxmox Backup Server haben. Das ist sehr effektiv, optimiert ( Platz für Backup ist wenig ) und funktioniert einwandfrei.
Man kann auch flexibel verschiedene Strategien für unterschiedlichen Server einbauen. Z.B. für meinen Mailserver gibt es ein komplettes Backup pro Tag und wird 2 Monate lang aufgehoben, aber für den Xibo Server ( Darstellung von Informationen im Flur ) hebe ich nur die letzte Woche auf, und 4 wöchentliche ältere Backups ( ich weiss nicht, ob diesen Satz verständlich ist ).
versioniert ist wahrscheinlich übertrieben. Ich mache rsync in eine Richtung, und wenn was gelöscht wird, dann wird nur lokal, aber nicht beim Backup gelöscht. Meist ist beim Versionieren ja das das Problem.
Hi,
Borgbackup ist sensationell. Es gibt auch ein grafisches Frontend für Borg https://vorta.borgbase.com/ (Opensource Tool unter GPL). Da geht wirklich alles was man sich nur beim Thema Backup ausdenken und wünschen kann. Schau es dir mal an. Ich mache damit seit Jahren meine Backups vom privaten Rechner.
In der Schule nutze ich auch Proxmox Backup Server. Das Teil ist genial. Ich habe das übrigens auf meinem Proxmox installiert und als Datenspeicher mein NAS angeflanscht.
verstehe ich nicht.
Wenn man rsynct und in der Quelle wurde etwas gelöscht, dann wird das doch entweder im Backup auch gelöscht, oder man hat lauer altes Zeug im Backup, das man sich zurück auf den Rechner holt, wenn man das Backup zurückspielen muss.
Und was ist beim Versionieren das Problem?
Der Witz daran ist ja gerade, dass alte Daten in den älteren Versionen noch da sind, falls man was versehentlich gelöscht hat, aber man wirklich nicht mehr benötigtes auch nicht mehr im aktuellen Backup hat.
Ok, damit ist Borg Backup für mein Szenario schon mal raus, weil ich auf dem NAS natürlich Borg Backup nicht installieren kann. Oder verstehe ich da was falsch?
Edit:
Dasselbe gilt wohl auch für BackupPC
eine unter der GPL lizenzierte Open-Source-Backup-Lösung für Server, um Client-Rechner im lokalen Netzwerk automatisch zu sichern.
Da man das auch auf einem Server installieren muss.
Bleibt für ein einfaches, versioniertes Backup des PC auf ein NAS derzeit wohl nur noch rsnapshot. Alles andere ist irgendwas zwischen für das Szenario nicht geeignet oder um es nutzbar zu machen mit Spatzen auf Kanonen schießen.
Edit 2:
Die „grosse Einschränkung“ ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. rsnapshot kann Backups nicht auf entfernte Ziele speichern, das Backupziel muss also immer lokal sein
Kann doch nicht sein, dass man nicht irgendeine Möglichkeit findet, unter Linux vom eigenen Rechner ein rsync inklusive Versionierung über SSH auf ein NAS zu machen, bei dem für jedes neue Backup einfach ein neues Verzeichnis mit Timestamp angelegt wird und für alles, was unverändert ist, einfach ein Hardlink angelegt wird.
Das Skript im Eingangspost macht ja eigentlich genau das, nur leider halt nicht per SSH über’s Netz, sondern nur lokal gemounted.
Ich glaube du verstehst das falsch. Ohne jetzt in jedes Detail tu gehen. Vorta und Borg installierst dubauf deinem Rechner. Dann mountest du dein NAS auf den Rechner (NFS oder SFTP). Das geht in Vorta z.b. über Hookskripte, die vor und nach dem Backup ausgeführt werden können. Mir Vorta erstellst du dann auf der Freigabe im NAS ein Repository und da rein kommen dann die Backups. Su kannst dann je nach Wunsch einstellen wie viele Backups je Tag, Wiche, Monat, Jahr aufgehoben serden sollen. Schau es dir mal an und v.a. probiere es z.B. einfach mal mit einer USB Platte aus. Erst dann wirst du sehen, was da alles geht.
Ansonsten fällt mir für dich noch BackInTime als Backupprogramm ein. Das ist etwas weniger „exotisch“ als Borg und basiert auf rsync. Das Teil kann auch so ziemlich alles und hat die ssh Sicherung auf ein NAS mehr oder weniger schon eingebaut.
das gleiche gilt auch für BackupPC. Du mountest das Remote-System und sicherst dann den lokalen Mountpunkt. Ansonsten hat BackupPC einfach einen simplen SSH-Login und rsync/scp/sftp zur Datenübertragung genutzt und die Daten abzuholen. Das sollte ggf. auch für einfache NAS möglich sein.
Wobei grundsätzlich die Frage ist, wie performant so ein Versionierungsbackup mit den Hardlinks im Vergleich mit einem einfachen rsync ist.
Habe vorhin bei deutlichen Änderungen (v.a. auch mal wieder die Firefox- und Thunderbirdprofile gesynct) wieder ca. 380 GB per ssh auf’s NAS mit rsync synchronisiert. Nach wenigen Minuten war das durch.
Wenn zwar nicht alles kopiert, aber mit Hardlinks trotzdem extrem viel Infos geschrieben werden müssen, dauert das vermutlich immer sehr viel länger.
wir machen erst ein Backup auf eine interne Festplatte und davon dann eines per NFS auf ein NAS - jeweils mit Rsync und Hardlinks gegen das letzte Backup.
Auf das NAS dauert es ca. 25 % länger.
Da andere Platten mitspielen ist das natürlich kein wirklich guter Vergleich. Und wir mounten einen 2 TB großen Veracrypt-Container vom NAS, das hilft sicher auch nicht gerade.
Insgesamt würde ich sagen: Passt schon.
Und wenn Du wirklich Zeit sparen willst, dann lässt Du auf dem Zielsystem einen Rsync-Dämon laufen.
das teste ich gerade. Ein erster Lauf mit allen Daten dauert leider immer super lang. Aber erst dann kann man beurteilen, wie schnell dann weitere Durchläufe mit üblichem Maß an Veränderungen dauern, sprich ob das alltagstauglich ist.
jetzt weiß ich wieder, warum ich das Vorhaben, versionierte Backups zu erstellen, in der Vergangenheit wieder verworfen habe. Es funktioniert in meinem Usecase nicht. Ich meine sogar, dass ich schon damals Back in Time ausprobiert hatte.
Back in Time lief jetzt 38 Stunden (!!!) und zeigte seit 12 Stunden konstant 71%. Ich habe vorhin mal geschaut, ob überhaupt noch was passiert. Prozess schlief und Netzwerkverkehr ausgehend von meinem Rechner = Null.
Ich habe dann abgebrochen, Back in Time und die Erstellung des „Snapshot“ neu gestartet. Back in Time hat erkannt, dass eine unbeendete Sicherung da ist und diese fortgesetzt. Allerdings werden trotzdem alle Dateien, die bereits gesichert wurden und sich zu 100% nicht verändert haben (können), alle wieder einzeln so langsam durchgeackert, dass man in der Statuszeile jede Datei mitlesen kann.
Bei 380 GB ohne und 470 GB mit extrem großen Dateien (virtuelle HDs) läuft da also jeder Sicherungsdurchgang tagelang.
Übrigens mounted Back in Time das NAS im Gegensatz zu einem rsync-Einzeiler auf der Konsole, lokal im Benutzerhome unter .local/share/backintime, selbst wenn man Sicherung über ssh angibt und ich vermute, das genau das das Problem ist (oder die verwendeten rsync-Parameter, die man nicht beeinflussen kann).
Wie gesagt, bei einem simplen Einzeiler mit rsync auf der Kommandozeile laufen die 380 GB (und auch die 470 GB, wenn sich an den virtuellen Disks nichts geändert hat) in wenigen Minuten durch.
irgendwas ist da nicht in Ordnung. Ich habe gestern von einem Kollegen mit BackInTime ca. 1TB auf eine extrene SSD gesichert. Das lief ca. 2 Stunden. Habe ihm heute gezeigt, wie BIT funktioniert und diese (zweite) Sicherung lief genau 1 Minute!
Also wenn man das jetzt über Netzwerk mal mit dem Faktor zwei betrachtet passt das schon!?
das stimmt so nicht. Im Reiter „Einstellungen → Expert options“ (ganz unten) kann man eigene Parameter angeben. Bei mir ist da z.B. u.A. -S als Schalter drin, damit die VM-Files effektiver gesynct werden.
Dann stellt sich noch die Frage, ob du darauf geachtet hast, bei Exclude den MountPoint einzutragen, ansonsten sicherst du dich im Kreis.
Also ich sichere mit dem Tool meinen gesamten Rechner (als sudo gestartet), d.h. zwischen den Sicherungen verändert sich wirklich viel und kein Backup dauert mal länger als 10 Minuten!?
Ja. Nur was. Fakt ist natürlich, dass das NAS nicht super schnell ist. Bei vielen kleineren Dateien ist die Übertragungsrate über’s Netzwerk definitiv im (teils niedrigen) einstelligen MB-Bereich. Das lässt sich mit Sichern auf eine externe SSD nicht vergleichen, wo man einige hundert MB Schreibrate hat.
So weit war ich ja noch gar nie. Ich habe bis jetzt keine vollständige erste Sicherung mit BIT.
Wenn es helfen würde, die Dateien direkt auf dem NAS in den angefangenen Sicherungsordner zu kopieren, wäre das eine Option für einen schnelleren Erstsync. Ich denke aber, dass BIT zunächst mal alles von der Quelle kopiert/kopieren muss, um einen validen Anfangsstand zu haben?
Ich bin sogar relativ sicher, das BIT beim Fortsetzen der abgebrochenen Sicherung wieder angefangen hat, alles neu zu kopieren, obwohl es schon einmal kopiert wurde.
Ich meinte, dass man keine verwendeten Parameter wegnehmen kann. Aber -S hatte ich bislang auch beim rsync-Einzeiler nocht nicht drin. Guter Tipp.
das mit dem Mountpoint im Userhome wird nirgendwo erwähnt. Das habe ich nur zufällig entdeckt, als ich die Übertragunsgraten usw. angeschaut habe.
Ich nehme den jetzt mal in die Ausnahmen und teste, ob am Ende das das Problem ist.
Du meinst nicht nur /home/dein_userhome, sondern / ?
Ich versuche nur das userhome zu sichern, daher starte ich BIT nicht als root.