Tool für inkrementelles /home Backup auf SMB

[rollmoped]

Ich suche eine Möglichkeit, Backups von den Home Verzeichnissen auf mehreren Mint Maschinen auf ein SMB Laufwerk im Netzwerk zu erstellen. Das SMB Laufwerk möchte ich nicht mounten, falls möglich. (Denn wenn es mal nicht zur Verfügung steht, und somit nicht gemountet werden kann, schreibt das Backup Tool sonst die interne Platte auf dem Mount-Point voll und das müsste ich dann auch noch verhindern.)
Die Updates sollten inkrementell und nicht verschlüsselt sein. Sehr schön wäre es, wenn sie zum Beispiel als Tarball abgespeichert würden. Und wenn es eine grafische Oberfläche vom Backup-Tool gibt, wäre es auch sehr begrüßenswert.

• Timeshift ist natürlich schon eingerichtet, aber sichert nur den Systemzustand lokal ab und nicht die Home-Verzeichnisse.
• mintBackup wäre zwar eine Idee, aber es unterstützt leider keinen Zeitplan für automatische Backups, sondern muss immer manuell angeschmissen werden.
• Ich würde ja Deja Dup benutzen, aber das scheint nicht wirklich zuverlässig bei der Wiederherstellung zu sein. Außerdem weiß ich nicht, ob es SMB Shares unterstützt.
• Restic wäre auch eine Idee, aber anscheinend setzt es zwingend voraus, dass das Backup verschlüsselt wird, was ich nicht möchte.
• Das sinnvollste Tool scheint mir bisher Back-In-Time zu sein, was die Stabilität angeht, aber ich befürchte, dass es mit dem rsync backend mit SMB-Laufwerken nicht gut klar kommt, was Links usw. betrifft.

Hat jemand eine Lösung parat oder komme ich nicht darum herum, mir selbst etwas zusammenzuscripten?

 

[JumpingCat]

Backup ist immer verschlüsselt.

Hast du dir mal Kopia angeschaut? Das läuft im Gegensatz zu restic aber eher im Userspace.

 

[Muffknutscher]

Moin, ich würde hier mal Bareos oder Borg Backup in den Raum werfen wollen. Bareos gibt es mit einer Web GUI, Konfig erfolgt aber via CLI. Borg hat meines Wissens nach keine GUI.

 

[frabron]

Ist SMB deine einzige Option? Wenn SSH eine Option wäre, würde ich definitiv Borg empfehlen, mit Pika/Vorta als Client User Interface.
Wie @JumpingCat schon schrieb, außer rsync ist das soweit ich das überblicken kann, eigentlich immer verschlüsselt.

 

[Shio]

• mintBackup wäre zwar eine Idee, aber es unterstützt leider keinen Zeitplan für automatische Backups, sondern muss immer manuell angeschmissen werden.

Warum nicht einfach per cronjob planen?

 

[gimmix]

Borg hat meines Wissens nach keine GUI

+1 für Borg Backup.

GUIs: Pika / Vorta
WebUI: BorgWarehouse

 

[Lotsenbruder]

Das SMB Laufwerk möchte ich nicht mounten, falls möglich.

Achtung Unwissenheit meinerseits:
Und trotzdem soll man drauf schreiben können?

 

[rollmoped]

Hast du dir mal Kopia angeschaut?

Das schaue ich mir gerade an. Es macht eigentlich keinen schlechten Eindruck.

• Leider kann es jedenfalls das SMB Share auch nur sehen, wenn es lokal gemountet ist (macht intern ein stat auf ein Verzeichnis zum Test ob es existiert, das mit der smb:// Adresse fehlschlägt).
• Und eigentlich wollte ich keine Fremdquellen für Pakete ins System holen.

Moin, ich würde hier mal Bareos oder Borg Backup in den Raum werfen wollen.

Schaue ich mir auch gerne danach an.

Ist SMB deine einzige Option?

In dem Fall, ja.

Warum nicht einfach per cronjob planen?

Ich würde gerne mintBackup in ein Skript einbetten, aber leider ist mintBackup selbst ein Skript, das nur eine GUI bereitstellt und keine Kommandozeilenparameter aufnimmt.

Und trotzdem soll man drauf schreiben können?

Das wäre ideal. Aber ich könnte auch damit leben, wenn es gemountet wäre. Dann müsste ich nur ein Skript schreiben, das sicherstellt, dass es da ist und die Sicherung abbricht, falls nicht.

 

[honky-tonk]

bei deja dup gabs mal nen bug, aber der ist behoben, sollte 1a funktionieren

wobei restic etwas mehr funktionsumfang hat, das kann ich sehr empfehlen

 

[Lotsenbruder]

Das wäre ideal. Aber ich könnte auch damit leben, wenn es gemountet wäre

Also ist es nicht möglich, oder?

 

[rollmoped]

@Lotsenbruder Theoretisch möglich wäre es schon, dass ein Programm selbst das SMB Protokoll sprechen kann und man somit das Share nicht erst mounten muss.

 

[Lotsenbruder]

@rollmoped Danke für deine Erklärung. 👍

 

[foofoobar]

• Restic wäre auch eine Idee, aber anscheinend setzt es zwingend voraus, dass das Backup verschlüsselt wird, was ich nicht möchte.

Das tut aber nicht weh.

• Das sinnvollste Tool scheint mir bisher Back-In-Time zu sein, was die Stabilität angeht, aber ich befürchte, dass es mit dem rsync backend mit SMB-Laufwerken nicht gut klar kommt, was Links usw. betrifft.

Du kannst auch ein Schleifenschaltungsgerät da drüber nutzen.

Sehr schön wäre es, wenn sie zum Beispiel als Tarball abgespeichert würden.

https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html
https://linuxconfig.org/how-to-create-incremental-and-differential-backups-with-tar

Und den Output von tar kann man auch in smbclient(1) pipen.

 

[rollmoped]

Danke für all die Antworten. Auch für die inspirierende Antwort von @foofoobar . Ich war schon fast dabei, anzufangen ein Bash Script zu schreiben.

bei deja dup gabs mal nen bug, aber der ist behoben, sollte 1a funktionieren

Ich habe mich jetzt in einiges eingelesen und zuletzt Deja Dup getestet. Tatsächlich unterstützt es das SMB Share auch direkt, ohne dass ich es mounten musste.
Eine Verschlüsselung der Backups ist optional. Zudem unterstützt es die Sicherung nach Zeitplan, wenn auch relativ rudimentär.
Trotz meiner anfänglichen Skepsis scheint es das richtige Tool zu sein. Ich bin sehr positiv überrascht.

 

[Donnerkind]

Restic wäre auch eine Idee, aber anscheinend setzt es zwingend voraus, dass das Backup verschlüsselt wird, was ich nicht möchte.

Ich reihe mich in den Chor der Borg-Sänger ein. Ich hatte vor Jahren mal Restic und Borg getestet. Beide funktionieren nach demselben technischen Prinzip – blockbasiert mit Deduplizierung –, nur mit ein paar Unterschieden im Detail. So kann Borg immer nur eine Verzeichniswurzel pro Snapshot, während Restic mehrere kann. Borg kann aber nur in lokale Verzeichnisse oder über ssh schreiben. Restic ist Meines Wissens multithreaded, was bei SSDs von Vorteil ist. Da ich auf langsame Festplatten sichere, war mir das aber weniger wichtig. Naja und Restic erzwingt im Gegensatz zu Borg eine interne Verschlüsselung der Repositorys. Das ist bei mir ebenfalls unnötig, weil meine Platten grundsätzlich mit LUKS verschlüsselt sind.

Ein weiterer Vorteil des blockbasierten Ansatzes: die Datendateien sind wenige und dafür groß, das macht eine Spiegelung sehr effizient. Nachteil: man muss das Repo mounten, um an die Nutzdaten ranzukommen. Man braucht also die entsprechende Software, wenn man an die Daten ran will.

Das wäre ideal. Aber ich könnte auch damit leben, wenn es gemountet wäre. Dann müsste ich nur ein Skript schreiben, das sicherstellt, dass es da ist und die Sicherung abbricht, falls nicht.

Da sich für Borg sowieso ein Wrapperskript anbietet, um die ganzen Einstellungen darin festzuhalten (welches Verzeichnis, Snapshot-Name, Retention-Regeln), könnte man da auch gleich eine Mount-Erkennung für die SMB-Freigabe rein machen.

Das tut aber nicht weh.

Naja, man muss es halt bei jedem Zugriff eingeben oder in einer Env-Variable ablegen. Das hatte mich schnell genervt.

Du kannst auch ein Schleifenschaltungsgerät da drüber nutzen.

Danke für den Lacher.

 

[foofoobar]

Ein weiterer Vorteil des blockbasierten Ansatzes: die Datendateien sind wenige und dafür groß, das macht eine Spiegelung sehr effizient. Nachteil: man muss das Repo mounten, um an die Nutzdaten ranzukommen. Man braucht also die entsprechende Software, wenn man an die Daten ran will.

Restic als Golang Compilat ist statisch gelinkt:

$ ./restic version
restic 0.18.0 compiled with go1.24.1 on linux/amd64
$ file ./restic
./restic: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=31dfeacd99c99440ffef3864eb01207f752903ad, stripped
$ ldd ./restic
    not a dynamic executable
$

Wahrscheinlich kann man das ootb aus einer initrd starten.
Oder halt in einer Live-CD die gerade rumliegt runterladen und ohne Install einfach starten.

Danke für all die Antworten. Auch für die inspirierende Antwort von @foofoobar . Ich war schon fast dabei, anzufangen ein Bash Script zu schreiben.

Da du noch in der Auswahl bist solltest du auf vernünftigen Support für sparse Files und extended Attributes achten. Und den Aufwand für ein Bare-Metal Recovery solltest du auch im Blick haben.

 

[Tanne]

Ich kann zu SMP leider nichts sagen, bin aber selbst grade dabei, eine Backup-Lösung mit Back in Time umzusetzen (hatte vor kurzem ebenfalls verschiedene Programme verglichen).

Backup ist immer verschlüsselt.

Nein, bei Back in Time muss man nicht verschlüsseln.

Neben einem automatischen Plan hat man da die Möglichkeit manuell ein Backup anzustoßen, sowie "sobald die Festplatte angeschlossen ist" . Und dann gibt es noch die Möglichkeut "wiederholend (anacron)", was ich aber nicht rausgefunden habe, was das ist.
Wenn man einen automatischen Zeitplan nimmt und ein extern anzuschließendes Gerät ist nicht verfügbar, dann macht es nichts und versucht es beim nächsten Mal wieder - das stand jedenfalls als Antwort in einem Videotutorial. Von daher würde ich nicht denken, dass es die Platte woanders vollschreiben würde.
EDIT: Für rsync (das Back in Time ja zugrundeliegt) kann man in Back in Time noch Optionen angeben, vielleicht findet sich da was, wie Du mit den Links umgehen kannst (Symlinks werden defaultmäßig als Link kopiert. Wenn man das entsprechende Häkchen setzt, wird dem Pfad gefolgt und die Datei, auf die verwiesen wird, kopiert). Ich hab die Einstellungen mal als Screenshot angehängt.

Es gibt sicher eine Möglichkeit, automatisch zu steuern, dass nur zum Zeitpunkt des Backups die Daten gemounted sind (ggf. Skript). Wenn man sich vor Ransomware-Angriffen schützen will, sollte das Backup schließlich nicht dauerhaft am Rechner verfügbar sein.

 

[foofoobar]

Neben einem automatischen Plan hat man da die Möglichkeit manuell ein Backup anzustoßen, sowie "sobald die Festplatte angeschlossen ist" . Und dann gibt es noch die Möglichkeut "wiederholend (anacron)", was ich aber nicht rausgefunden habe, was das ist.

https://github.com/bit-team/backintime/blob/dev/FAQ.md#how-does-the-repeatedly-anacron-schedule-work

Es gibt sicher eine Möglichkeit, automatisch zu steuern, dass nur zum Zeitpunkt des Backups die Daten gemounted sind (ggf. Skript). Wenn man sich vor Ransomware-Angriffen schützen will, sollte das Backup schließlich nicht dauerhaft am Rechner verfügbar sein.

Wenn man das sicher verhindern will braucht es eine entsprechende Server-Komponente die das sicher verhindert. (Tapes im Schrank hatten schon einen gewissen Charme)