Backuplösung für Linux gesucht

[foofoobar]

@zelect0r Und/Oder mit casync für deduplizierung ergänzen.

https://en.wikipedia.org/wiki/Casync

 

[zelect0r]

Ja @foofoobar viele Wege führen nach Rom!
Für Server Backups nutze ich bspw. "rsync".

Timeshift

Bei Timeshift handelt es nicht um eine vollwertige Backup Lösung.
Das sind sogenannte Snapshots, insbesondere für EXT4, also sogenannte Momentaufnahmen.
Welche dir deinen Systemausgangspunkt nach Fehlern (Natürlich auch ohne Fehler) wiederherstellen können.
Ich nutze BTRFS mit Snapper, das ist ebenso eine solche Lösung,
nur das dieses Dateisystem diese Funktion schon inbegriffen hat.
Bei diesen Lösungen wird mit Absicht darauf verzichtet Benutzer-Spezifische Daten zu sichern.
Also /home bleibt da standard mäßig außen vor und dementsprechend natürlich auch ein Daten-Grab,
wie z.b. eine Extra Platte.

Ansonsten könnte man auch Clonezilla nutzen,
habe ich früher zu Windows Zeiten auch benutzt.
Der Nachteil hier ist das die Partitionen mindestens exakt gleich Groß sein müssen.
Ansonsten lassen sich diese nicht wieder herstellen und man braucht einen bootfähigen Clonezilla Stick,
oder Ventoy-Stick.

Wenn es nur um Daten einer anderen Platte geht, welche Vollständig gesichert werden sollen, würde auch klassisches kopieren der Daten vollkommen ausreichen, mit rsync hätte man allerdings den Vorteil auch einen Schalter mit einzubauen der bei regelmäßiger Verwendung erkennt ob Daten gelöscht worden sind und das dann im Ziel berücksichtigt, wenn man das möchte.

Mit anderen externen Backup-App-Lösungen habe ich unter Linux keine Erfahrung,
würde aber so oder so unter Linux auf das Terminal zurückgreifen.

 

[andy_m4]

Echte Männer brauchen kein Backup.
Echte Männer halten zudem ihre Daten einzig und allein auf einer RAM-Disk.

 

[zelect0r]

@andy_m4

Im Bezug darauf, wirklich mal Gedanken machen was wirklich gesichert werden muß und worauf man gegebenenfalls auch verzichten kann, um einfach Platz und Aufwand zu sparen, Daten die z.b. lange unangetastet liegen, die man generell als Archiv betrachten würde, sind vielleicht auch weniger wichtig.

 

[Donnerkind]

Damit könnte man angehangen an den dd prozess direkt compressed zippen.

Ich empfehle zstd statt gzip. deutlich bessere Kompression bei einem Bruchteil des Rechenaufwands.

 

[zelect0r]

@Donnerkind Zsatndard kenne ich noch nicht.
Ließt sich aber gut. Ist ja sogar noch ein sehr junges Projekt (2016).

 

[TomTDooley]

Hier wird die Kombination "Timeshift" (/) + "rsync" (/home) bevorzugt, wenn beides auf einem zweiten Datenträger als Backup landet.

Das "Timeshift" /home nicht automatisch sichert, ist doch eher ein Vorteil, statt Nachteil. Wer möchte bei einer Systemwiederherstellung schon seine "Eigenen Dateien" verlieren?

 

[RMS_der_Zweite]

Ich mache das so:

Zu Anfang mit dd ein Image erstellt, dd if=/dev/nvme0n1 of=nvme bs=8M
Genauer habe ich nur die ersten beiden Partitionen (EFI und root) mit dd kopiert, auf den kleineren Zieldatenträger kopiert und mit gparted die Partitionstabelle auf die kleinere Größe korrigiert. Das ist für den Anfang aber vielleicht ein bisschen viel Gehakel. Wenn der Zieldatenträger mindestens gleich groß ist, kann man sich das sparen.

Jedenfalls hat man dann ein Image, das man mit rsync aktualisieren kann:

partx -v -a nvme
mount -o /dev/loopXX nvme /mnt
cd /mnt
rsync -avxHAX --progress --delete / ./
cd ..
losetup -d /dev/loopXX

Will man das nicht von Hand machen, hier per Skript:

disk=$(partx -a -v nvme |grep dev.loop |tail -1 |sed s/:.*//)
mount ${disk}p2 /mnt
cd /mnt
if [ ! -d bin ]; then echo no bin dir; exit 1; fi
rsync -avxHAX --progress --delete / ./
cd /
umount /mnt
losetup -d $disk

Die kleine Sicherheitsabfrage im Skript ist dafür da, dass nicht alles auseinenanderfliegt wenn der Mount aus irgendeinem Grund fehlschlägt, denn dann würde er das Root FS auf sich selbst replizieren.

Gibt inzwischen sicher auch einsteigerfreundlichere Lösungen, aber so macht es genau das was ich haben will, ein Image das ich einfach auch auf kleinere Platten kopieren kann und das immer aktuell ist.

 

[mchawk777]

So, jetzt hab ich noch das Thema Backup vor mir. Unter Windows habe ich bisher immer AOMEI Backupper Pro und Hasleo Backup Suite genutzt.

Du suchst was in dieser Art dieser Apps?
Veeam Backup for Linux.
Es gibt nur diese eine App unter Linux, die ansatzweise vergleichbar mit den von Dir genannten ist.
Egal, wie man es dreht und wendet.

 

[Donnerkind]

Die kleine Sicherheitsabfrage im Skript ist dafür da, dass nicht alles auseinenanderfliegt wenn der Mount aus irgendeinem Grund fehlschlägt, denn dann würde er das Root FS auf sich selbst replizieren.

Bei Skripten, die potentiell viel Schaden anrichten können, bietet sich ganz oben ein set -e an. Das sorgt dafür, dass das Skript abbricht, sobald irgendein Kommando mit einem Exitcode != 0 endet. Aber ich fürchte, wir schweifen ab. 🤓

 

[foofoobar]

Du suchst was in dieser Art dieser Apps?
Veeam Backup for Linux.
Es gibt nur diese eine App unter Linux, die ansatzweise vergleichbar mit den von Dir genannten ist.
Egal, wie man es dreht und wendet.

Braucht allerdings für online Images out-of-tree-kernel-module.
Diese Einschränkung passt nicht zu jedem Usecase.

 

[zelect0r]

@Bruehwuerfel schau dir doch mal Vorta an!
Schaue mir das gerade mal an.
Sieht sehr gut aus und macht was es soll.
Geplante Aufgaben habe ich natürlich für den test auf Standard gelassen, aber man kann es automatisieren,
die Kompression habe ich auf Zstandard Level 8 gestellt, dann habe ich noch ein Passwort verwendet,
im Reiter Source/Quellen, kann man angeben was gebackupped werden soll und was nicht.
Bei Repository kannst du das Ziel angeben, entweder eine andere Platte, Ordner oder sogar einen entfernten Rechner/Server, in Archive siehst du dann das fertige Backup.

Da waren nur .jpg und .png's drin, also nicht viel mit kompression^^

Extrahieren ist dann wiederherstellen.

 

[RMS_der_Zweite]

Bei Skripten, die potentiell viel Schaden anrichten können, bietet sich ganz oben ein set -e an.

Guter Tipp, allerdings kann zum einen rsync leicht auf einen non-zero exit code laufen wenn man erweiterte Attribute bei Dateien nutzt, zum anderen sorgt ein Fehler nicht unbedingt für einen falschen Code.

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. ^^

 

[zelect0r]

Hab jetzt mal das home folder backupped.
Scheint alles tadellos zu funktionieren.

❯ pwd
/home/zelect0r

~
❯ du -hs
17G     .

Ergebnis:

/mnt/M2SSD256GB/Test_Backup
❯ du -hs
6,6G    .

 

[klausk1978]

https://www.borgbackup.org/

 

[zelect0r]

@klausk1978 deswegen doch "vorta" das ist doch borgbackup unter dem GUI.
Ich dachte er wolle eher was fürs UI.

 

[Donnerkind]

zum anderen sorgt ein Fehler nicht unbedingt für einen falschen Code

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

 

[Bruehwuerfel]

@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.

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.

 

[zelect0r]

Von Veeam würde ich die Finger lassen, dem proprietären Krams da.
Das Ziel Datei-System ist dem Tool bestimmt egal, so lange der Mount-Point existiert.
Aber auf NTFS würde ich nicht speichern, und ebenso auch keine SteamLibary darauf hosten.

 

[Habicht]

Auf dem Smartphone schreit ja auch niemand "Klickibunti!"

Ein Smartphone ist doch aber nichts anderes als Klickibunti.

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

Wie kommst du darauf, dass es um Akzeptanz der breiten Masse geht?

Für die breite Masse gibt es Windows - das reicht doch völlig.