Backuplösung für Linux gesucht

[zelect0r]

Das habe ich auch nicht verstanden mit dem KlickiBunti.
Naja, eigentlich ist es ja TappiBunti

 

[areiland]

Keine beliebte Meinung in der Linux-Welt (zumindest meiner Erfahrung nach), aber dieses Beharren auf Konsole-only Lösungen ist im besten Fall Ignoranz und im schlechtesten Fall toxisches Gatekeeping.

Kann man sehen wie man will, für mich macht gerade das Vorhandensein von cleveren Konsolenanwendungen einen der Reize von Linux aus. Konsole muss ja nicht unbedingt bedeuten, dass man nur mit Befehlszeilen hantiert, sondern kann auch bedeuten, dass man ein richtiges Tool hat, das halt textbasiert arbeitet. Mein Musikplayer ist z.B. auch eine Konsolenanwendung, weil ich den tatsächlich nur benötige, um aus meinen Verzeichnissen mit den Songs eine Playlist zusammenzustellen, die ich dann abspielen lasse. Dafür brauche ich keine grafischen Elemente und auch nix was dann irgendwo auf der Oberfläche zappelt oder Einblendungen besitzt. Also hab ich meinen textbasierten Player, der halt in einem Konsolenfenster läuft.

Mit dem MC hab ich auch meinen Hauptdateimanager als Konsolenanwendung.

Sowas hat immer den unglaublichen Vorteil, dass das auch unter Linux wahnsinnig Ressourcen spart.

 

[foofoobar]

@zelect0r ja, mit UI sollte es schon sein. Ich hab zwar keine Angst vor der Konsole, aber Gefrickel liegt mir nicht. Im 21. Jahrhundert kann man als Durchschnittsnutzer immerhin eine halbwegs anständige grafische Benutzeroberfläche erwarten. Auf dem Smartphone schreit ja auch niemand "Klickibunti!" und wer ernsthaftes Interesse daran hat, daß Linux mehr Akzeptanz in der breiten Masse findet, sollte als Entwickler darauf achten. Keine beliebte Meinung in der Linux-Welt (zumindest meiner Erfahrung nach), aber dieses Beharren auf Konsole-only Lösungen ist im besten Fall Ignoranz und im schlechtesten Fall toxisches Gatekeeping.

Also sich den Backup und dessen Parameter jedes mal neu zusammen zu klicken und zusätzlich einen nicht cron-fähigen Backup zu nutzen ist aus meiner Sicht extrem kontraproduktiv und fehlerbehaftet.

Aber tröste dich, vieles was hier als Lösungsansatz diskutiert wird besteht oft aus zwei Teilen, nämlich einen Tool ohne GUI welches den eigentlichen Backup und Restore macht und einem Frontend mit Klick-Klack welches dieses lediglich ansteuert und nix mit der eigentlich Backup-Logik zu schaffen hat.

Und für den quick&dirty Restore von einzelnen Files ist aus meiner Sicht die Variante wo man sich den Backup per FUSE-FS mounten kann die benutzerfreundlichste Variante die man sich nur vorstellen kann weil der User dann die Tools (Filemanager, cp) nutzen kann mit denen er auch sonst mit seine Files handhabt. So kann man direkt auch Archive aus dem Backup auspacken ohne den Kram vorher auf die "lokale" Platte kopieren zu müssen.
Und von solchen Anforderungen aus einem Backup nur bestimmte Files oder Dirs aus einem Dir mit 100K Einträgen rauszufischen fange ich besser erst gar nicht an, gerne werden in solchen Fällen typische GUI-Elemente komplett unbedienbar bzw. das artet dann zu tagesfüllender Beschäftigung aus: "Software, kann man nix machen"
Hast du dich schon mal gefragt warum Snapshots wie bei ZFS oder WAFL so beliebt sind?

Und für den Fall eines Bare-Metal-Recoverys ist ein GUI-Monolith mit seinen Abhängigkeiten auf einem Rescue-Medium auf einer Konsole eine wacklige Angelegenheit. Da passieren dann gerne solche Dinge das das fancy GUI Tool zum Restore auf dem BMC nicht läuft weil irgentwelche 3D-Features dort fehlen, oder ähnlicher typischer Computer-Kack.

Ich würde das mit den toxischen Gatekeeping an dieser dieser Stelle sogar umdrehen wollen und behaupten das die vermeintliche Notwendigkeit dieser typischen Windows-GUI-Monolithen ein Ergebnis von toxischen Gatekeeping ist, da wird man schneller als einem liebt ist zum Diesel-Dieter.

Wie schon geschrieben, Veeam schau ich mir mal an und Vorta geb ich zumindest mal ne Chance. Gibt es irgendwelche Einschränkungen hinsichtlich Formatierungen der Zielfestplatte auf die das Backup abgelegt werden kann? Meine 2. SSD ist derzeit in 2 x 1 TB Partitionen unterteilt. Eine mit ext4 für die Steam-Bibliothek und die andere ist noch als NTFS, weil da noch 2 Komplettsicherungen der Haupt-SSD liegen, die unter Windows erstellt wurden. Sind zwar jeweils "nur" knapp 80 GB die ich auf ne externe Platte schieben kann, aber ich frag lieber mal vorher, bevor ich mir zuviel Aufwand mache.

Alles was auf rsync basiert braucht als Zielmedium ein Filesystem mit vollständiger Unix-Semantik.

 

[Capet]

@Bruehwuerfel schau dir doch mal Vorta an!
Schaue mir das gerade mal an.

Nutze ich auch schon längere Zeit und bin sehr damit zufrieden, sichere aber auch ausschließlich meine Daten, nicht den Rest des Systems. Zwei Repositories sind im Einsatz. Eines liegt auf meinem NAS, das zweite (verschlüsselt) auf einem Cloudspeicher.

 

[fischfilet]

und wer ernsthaftes Interesse daran hat, daß Linux mehr Akzeptanz in der breiten Masse findet, sollte als Entwickler darauf achten.

Ich weiß nicht was du hast. Für die breite Masse gibt es Distros wie Ubuntu, Mint oder Zorin. Bestimmt noch mehr. Die Akzeptanz wie du es nennst ist für Linux nicht da, weil es kaum Geräte gibt, die mit Linux vorinstalliert sind. Die 0815-Anwender fressen das, was ihnen vorgesetzt wird, also Windows, und kaum einer weiß, dass es ne Alternative dazu gibt.
Und derselbe 0815-Anwender ist jetzt auch keiner, der höchste Prio auf ausgefeilte Backupsoftware &
-strategien setzt. Der kopiert wenn überhaupt seine wichtigen Dateien auf ne externe Platte, einem USB-Stick und/oder in die Cloud.
Es ist also hanebüchener Unsinn zu schreiben, dass die Akzeptanz von Linux nicht da sei, nur weil die breite Masse keine GUI für ein Backuptool finden könne.

 

[zelect0r]

und zusätzlich einen nicht cron-fähigen Backup

Vorta ist tatsächlich nicht Crontab-Fähig und die Sheduling-Option innerhalb dessen sehr spartanisch.
Du kannst zwar bspw. Wöchentlich etwas erstellen, aber dann auch keine Uhrzeit mehr setzen, sondern diese ist dann von deinem ersten manuellem Backup abhängig.
Finde ich auch etwas dumm!

 

[foofoobar]

Ich weiß nicht was du hast. Für die breite Masse gibt es Distros wie Ubuntu, Mint oder Zorin. Bestimmt noch mehr. Die Akzeptanz wie du es nennst ist für Linux nicht da, weil es kaum Geräte gibt, die mit Linux vorinstalliert sind.[ .... ]
Es ist also hanebüchener Unsinn zu schreiben, dass die Akzeptanz von Linux nicht da sei, nur weil die breite Masse keine GUI für ein Backuptool finden könne.

Alleine für Restic findet google gleich mehrere GUIs: https://www.google.com/search?q=restic+gui

Wahrscheinlich fehlen dem TO einfach diese typischen not-all-in-one Windows-Monolithen, dabei ist es eigentlich total geil das man ein und das selbe Backup-Tool mit verschiedenen Oberflächen kombinieren kann.

Wer die Wahl hat hat die Qual :-)

Und rear macht diverse Backup-Tools Bare-Metal-Recovery fähig, selbst solche Exoten wie TSM :-)

 

[sedot]

@Bruehwuerfel
Das Ubuntu Wiki hat eine relativ lange Liste mit GUI Programmen, womöglich sind dort zusätzliche Optionen für dich dabei.
https://wiki.ubuntuusers.de/Datensicherung/#Grafisch

 

[RMS_der_Zweite]

In dem Fall bringt dir aber ein if …; then auch nichts mehr, weil es ebenso nur auf den Exitcode schaut.

Doch, das verhindert an der Stelle dass er nach fehlgeschlagenem Mount das Backup trotzdem unter dem mount point neu aufbaut, wodurch es dann wieder aufs root FS geschrieben würde.

 

[Donnerkind]

Doch

Ach stimmt, in dem Fall wird das erwartete Ergebnis des Kommandos geprüft, nicht dessen Exitcode.

 

[andy_m4]

Ich hatte mir zu Anfang das Backup erstmal zerschossen indem ich das "cd" vergessen hatte und er durch --delete dann eben mein cwd repliziert und das Backup im Image komplett gelöscht hat. ^^

Deswegen macht man ein Backup ja auch so, das der Backup-Prozess lediglich Leserechte auf die zu sichernden Daten hat und Schreibrechte überhaupt nur auf den Zielpunkt. Und idealerweise ist der Zielpunkt auch ein "Append", so das vorhandene Backups nicht versehentlich überschrieben werden.

 

[foofoobar]

Deswegen macht man ein Backup ja auch so, das der Backup-Prozess lediglich Leserechte auf die zu sichernden Daten hat und Schreibrechte überhaupt nur auf den Zielpunkt.

Und wie implementiert man das konkret?

Und idealerweise ist der Zielpunkt auch ein "Append", so das vorhandene Backups nicht versehentlich überschrieben werden.

Welche Tools schweben dir da vor?

 

[andy_m4]

Und wie implementiert man das konkret?

Na im einfachsten Fall fürs Backup einen eigenen User anlegen und dementsprechend an den die Rechte vergeben.
Bei meinem ZFS-Beispiel macht man das so, das der zfs-send darf aber eben sonst nix Anderes.

Welche Tools schweben dir da vor?

Um bei dem ZFS-Beispiel zu bleiben: zfs-receive in den Backup-Pool. Der legt das als neuen Snapshot an. Etwaige Bestandsdaten werden nicht angerührt.

 

[mchawk777]

Veeam schau ich mir mal an und Vorta geb ich zumindest mal ne Chance.

Ich fasse es mal sehr kurz zusammen:
Reicht Dir ein Dateibackup, hast Du unter Linux viele Möglichkeiten, die hier auch im Thread genannt wurden.

Willst Du einen Funktionsumfang wie die von Dir genannten Backup-Programme - vor allem mit Fokus auf Image-System-Backups kommst Du an Veeam nicht vorbei. Jedenfalls nicht, wenn Du diese Backups im laufenden Betrieb anfertigen möchtest. Das ist leider so.

 

[andy_m4]

Jedenfalls nicht, wenn Du diese Backups im laufenden Betrieb anfertigen möchtest. Das ist leider so.

Nur mal so aus Interesse:
Durch welche Magie stellt denn Veeam sicher, das "laufender Betrieb" kein "Problem" ist?

 

[mchawk777]

Durch welche Magie stellt denn Veeam sicher, das "laufender Betrieb" kein "Problem" ist?

Das musst Du leider Veeam fragen.
Ich kenne nur die entsprechende Aussage - und in Anbetracht, dass es in dem Punkt keine wirkliche Alternative gibt... 🤷‍♂️

Wenn, dann würde ich Veeam in dem Punkt auch erst mal testen wollen, indem ich z. B. mit Clonezilla ein Backup vom ausgeschalteten System erstelle.
Dann das Backup im laufenden System mit Veeam - und im Anschluss ein Recover mit Veeam durchführe.
(Das Clonezilla-Backup ist eher als konservativer Schritt zu sehen - hätte ich ein Spiel- und Testsystem, würde ich das ggf. auch unter den Tisch fallen lassen.)

Meine Linux-Maschinen sind ja Raspis, auf denen Veeam eh nicht läuft - NAS, bei denen ein Dateibackup genügt - und Proxmox VMs/Container, bei denen Proxmox das Backup (regelmäßig) anfertigt, aber halt auch bei ausgeschalteter VM/LXC.

Wobei: Bei Sachen wie pi-hole, Ad Guard oder auch Unbound u. a. genügt ja ein Backup vom Ausgangszustand, wenn man startet - oder nach einem App-Update.
Der Rest der Daten aktualisiert sich ja von selbst.

Bei Immich sieht das wieder anders aus. 😅

 

[fischfilet]

Durch welche Magie stellt denn Veeam sicher, das "laufender Betrieb" kein "Problem" ist?

Ich meine das hatte foofoobar hier angedeutet, ich zitiere mal:

Braucht allerdings für online Images out-of-tree-kernel-module.

Die KI sagt dazu: Veeam sichert ein Linux-System im laufenden Betrieb vor allem über ein eigenes, proprietäres Kernel-Modul, das direkt im Betriebssystem des Linux-Hosts installiert wird.
(Und gibt diese Quelle an)

 

[andy_m4]

Das musst Du leider Veeam fragen.

Na wenn ich die Fragen muss, dann kann man das nicht als zugesicherte Eigenschaft werten und sollte vielleicht deshalb besser Formulierungen a-la "soll können" wählen. 🙂

Live-Image-Backup hat ja mehrere Probleme. Einmal musst Du darauf achten, das das Dateisystem in einem konsistenten Zustand ist.
Zweitens ja auch die Dateien. Sprich wenn Du gerade ein Dokument speicherst während das Image gezogen wird, hast Du möglicherweise nur ein halbes Dokument im Backup.

Beide Probleme müssen adressiert werden. Und das ist unter Linux, na ich sags mal wohlwollend:
Eine Herausforderung

Daher fällt es mir schwer mich da mit einem "die können das" abspeisen zu lassen.

 

[fischfilet]

Beide Probleme müssen adressiert werden. Und das ist unter Linux, na ich sags mal wohlwollend:
Eine Herausforderung

Nicht grundsätzlich. Das Dateisystem ext4 kann zwar keine snaphots, aber wenn man LVM nutzt, könnte man damit snapshots machen. Oder man hat gleich ein Dateisystem, das snapshots untersützt, also ein CoW-Dateisystem wie ZFS oder BTRFS.
Veeam verlässt sich darauf nicht und bringt die snapshot Funktionalität anscheinend über das Kernelmodul mit.

 

[andy_m4]

Und gibt diese Quelle an)

Okay. Das klingt sehr nach halbgarer Lösung.
Solche Erklärungen sind jetzt nicht gerade vertrauenssteigernd.

Ob man einer Firma, die nur sehr vage und unzureichend die Funktionalität ihrer Backup(!)-Software erklärt, da wirklich vertrauen will, muss natürlich jeder für sich selbst entscheiden.

Ergänzung (Gestern um 15:53)

Nicht grundsätzlich.

Hab ich so auch gar nicht behauptet.

Abgesehen davon wird das Problem der halb geschriebenen Dateien damit immer noch nicht anständig adressiert.
Insofern könnt ihr da jetzt noch so viel posten. Ändert erst mal nicht viel.