Frontend zu rsync mit Verschlüsselung, Datei-Versionen, Vergleich

[feldmaus]

Guten Abend liebe Linuxer

ich suche eine rsync Variante um Daten von meinem Linux(Debian) Client auf meinen NAS Server zu kopieren. Basis sollte rsync sein. Am liebsten wäre mir eine Verschlüsselungs Möglichkeit für die Daten.

Als Prüf-Werkzeug wäre ein Datei-Browser um meine Quelle und die Ziel-Daten(verchlüsselt) zu vergleichen cool.

Und als I-Tüpfelchen wäre ein Versions-Handling von rsync nett, also das rsync im Rotationsverfahren verschiedene Versionen der zu sichernden Daten anlegt.

Geht das?

Grüße Mausi

[GregorS]

Geht das?

Unter der Voraussetzung, dass das NAS rsync kann: Klar geht das. Nur vielleicht nicht „aus dem Ärmel geschüttelt“.

Gruß

Gregor

[feldmaus]

Ich sehe schon, das wird ein Script Inferno

http://rsyncrypto.lingnu.com/

Habt Ihr noch andere nützliche Tools in diesem Zusammenhang?

[cosinus]

Das geht doch einfacher?
Spricht dein NAS ssh? Wenn ja, dann aktiviere es und mounte mittels sshfs das gewünschte Verzeichnis auf deinen Rechner, hier ein Beispiel:

Code: Alles auswählen

mount.sshfs user@deinnas:/irgendein/Verzeichnis /media/nas_ssh

Dann kannst du mit rsync oder irgendeinem anderen Tool Dateien auf das NAS kopieren, als wäre es ein lokales Verzeichnis.

[buhtz]

Das riecht irgendwie nach backintime (Back In Time). Hinweis: Ich bin hier Teil des Betreuer-Teams in dritter Generation.

Die Anwendung ist in die Jahre gekommen und wird gerade wieder auf Vordermann gebracht. Es erfüllt vermutlich nicht alle deine Wünsche perfekt, aber ist vielleicht nahe dran. Mach Issues auf und sag uns was dir fehlt und was nicht so schön ist.

Zur Verschlüsselung sei noch gesagt: Back In Time bietet dies an und nutzt dafür encfs. Letzteres hat aber diverse sicherheitsrelevante Issues und wird eigentlich nicht mehr empfohlen. Sogar Debian weißt dich beim Installieren via apt deutlich darauf hin. Langfristig werden wir EncFS entfernen, voraussichtlich nach dem Debian 13 Release in ca 2 Jahren (siehe #1549 und #1249). Für einen Ersatz fehlt es an Ressourcen und willigen (d.h. nutzenden) Entwicklern. GoCrypt ist der aktuelle Ersatzkandidat. Es fehlt aber jemand, der es nutzt und auch implementieren möchte.

[feldmaus]

Ich schaue mir beide Lösungen an. Im Prinzip weiß ich noch nicht genau, was ich bevorzuge. Auf dem NAS Server läuft ein Backup nach Zeitplan ab mit 30+12+10 Versionen(30Tage+12Monate+10Jahre). Von NAS Server auf externes USB Laufwerk.

Dabei werden die privaten Benutzer-Verzeichnisse mitgesichert. Diese Daten würde ich gerne aus Datenschutz- und Effizienz-Gründen verschlüsselt auf meiner Festplatte liegen haben, sowie die Übertragung auch verschlüsselt ablaufen sollte.

Aus dem Bauch heraus würde ich sagen, dass es leistungsschonender ist, wenn ich diese Dateien einzeln verpackt auf dem Server ablege und nicht als ein Riesenpaket. Denn es werden bis zu 52 Versionen von Daten in einer Rotationssicherung erstellt.

[MSfree]

Dabei werden die privaten Benutzer-Verzeichnisse mitgesichert. Diese Daten würde ich gerne aus Datenschutz- und Effizienz-Gründen verschlüsselt auf meiner Festplatte liegen haben, sowie die Übertragung auch verschlüsselt ablaufen sollte.

rsync ansich fährt ein unverschlüsseltes Protokoll. Die Transportverschlüsselung ist jedoch kein Problem, das geht mit rsync via SSH oder rsync auf ein sshfs oder mit rsync über VPN (oder mit rsync via SSH durch einen VPN-Tunnel sogar doppelt transportverschlüsselt)

Mit rsync kann man aber Dateien nicht verschlüsselt ablegen. Als Workaround könnte man das Sicherungsmedium mit LUKS verschlüsseln. Das Sicherungsmedium ist damit gegen unbefugten Zugriff gesischert, solange es nicht gemountet ist. Die Benutzerverzeichnisse sind aber bei einem LUKS-mount nicht individuell verschlüsselt, so daß man im gemounteten Zustand Zugriff auf alle Benutzerdaten hat, der Datenschutz wäre also nur begrenzt gewährleistet.

[feldmaus]

Danke für die Anregungen. Mein aktueller Plan sieht wie folgt aus. Wobei ich glaube, dass Ecryptfs auf dem Server einfacher(ohne Passwort der Benutzer) und performanter gesichert werden könnte.



Ich nutze 3 externe USB Platten zur einfachen Synchronisierung der Daten auf dem NAS. Diese werden dann zufällig gewechselt und an verschiedene Orte gesichert.

[mludwig]

Ich werfe mal rsnapshot in den Raum. Nutzt rsync (auch über ssh verschlüsselte Übertragung), und legt Versionen per hardlink an, wenn sich an der Datei nichts geändert hat - sehr platzsparende Versionierung halt. Dateien werden aber nicht verschlüsselt abgelegt.

[JTH]

Borg Backup würde sich hier gut anbieten:
Es kann (Main Features) das Backup (nicht nur die Übertragung) verschlüsseln, die Übertragung geht z.B. über SSH (wie bei rsync) und die Integrität des Backups wird natürlich geprüft (das sollte bei jeder vernünftigen Backuplösung so sein). Eine neue Version/ein neuer Stand derselben Backupquelle nennt sich da meine ich „Archiv“.

Benutzt hab ich es allerdings noch nie

[buhtz]

Borg Backup würde sich hier gut anbieten:

Lässt sich das einzelne Backup, dann im Dateisystem durchsuchen oder ist es ein Borg-eigenes Format, wozu ich dann Borg brauche?

[feldmaus]

Laut meinen Recherchen muss man die Borg Backups auch mit <borg list ...> durchsuchen. Ansonsten macht Borg einen guten Eindruck.

Mir ist aufgefallen, dass mein NAS den ssh Fernzugang nur für Benutzer der Gruppe Administratoren zulässt !!!

Das schränkt mich dann natürlich stark ein.

[florit]

Gibt es auch eine Lösung für *.tar.gz archive mit Passwort?

Ich meine ein Archiv von einen Ordner anlegen mit Passwort auf einen nfs-mount …
Das müsste auch mit einem NAS klappen … oder liege ich da falsch … müsste auch mit einem verschlüsselten Dateisystem funktionieren

So dass das backup im ausgeschalteten Zustand verschlüsselt ist … wenn das NAS läuft dann nicht …
Vielleicht könnte auch so etwas wie time machine ein Lösungsweg sein … nehme mal an wird kein mac sein sondern linux

[ArcticBears]

Ähnliches Problem beschäftigt mich i.M. auch und ist imho daher ähnlich übertragbar:

Ich suche eine Home-Backup-Lösung mit Frontend, um Verzeichnisse samt Inhalt sowohl inkrementell als auch differentiell auf div. ext. USB-SSDs zu sichern. Die Verschlüsselung ist dabei einfach durch LUKS/zulumount gesichert.
Als "gebranntes Kind" möchte ich auf jeden Fall vermeiden, dass unbemerkt alte Verzeichnisse u. Dateien plötzlich leer (=0) sind.


Als Dein gesuchtes

Prüf-Werkzeug wäre ein Datei-Browser um meine Quelle und die Ziel-Daten zu vergleichen

nutz(t)e ich bisher Unison-gtk , dass bei mir mittels angepasster Profile Teile meiner Platte im Betrieb adHoc spiegelt, nutzt aber imho nicht rsync(?). Hier kann man i.d. Frontend einzeln sehen/entscheiden, was warum wo synchronisiert werden soll, sowohl Quelle nach Ziel als auch umgekehrt.
Warum tue ich das?
- Der alte PC verkraftet kein echtes Raid. So habe ich zumindest schnell wieder eine manuelle Spiegelung nach getaner Arbeit, falls HD1 plötzlich abraucht.
- Für recht statische Verzeichnisse/Dateien, wie z.B. der Abgleich von Download-, oder MedienVerzeichnissen ist das Teil eigentlich ideal imho.

Als rsync-Frontends habe ich mal LuckyBackup als auch BackInTime getestet.

LuckyBackup wird im Inet als zu bunt oder 80er-Jahre geflamed. Ich persönlich empfand das nicht so störend.
LB ist genau wie BIT extensiv konfigurierbar. LB zeigt dabei leicht kopierbar die rsyc-Befehle an und hat auch gut sichtbar einen hilfreichen Simulationsknopf. LB`s Oberflächliche ist recht simpel/intuitiv bedienbar, die spezial-Konfigurationsmöglichkeiten verbergen sich hinter dem Schalter "Erweitert". Eine Verschlüsselung oder Fernzugriff ist nicht vorgesehen. Da haben cosinus und MSfree sich aber schon zu oben im Thread geäußert. Diese Vorgehensweise würde ich auch persönlich vorziehen.

BIT ist vom Design etwas mehr im neuen Jahrhundert angekommen. Praktisch ist hier die vorkonfigurierte Ausschlußliste, die unnötige Dateien zur Sicherung ausklammern läßt. LB gestaltet diesen Punkt etwas einfacher/ungenauer. Eine Simulation gibt es nicht. Die verwendeten rsyc-Befehle sind erst hinterher aus den log-Dateien zu kopieren. BIT bietet Verschlüsselung lokal als auch fern per SSH an.

LB bietet eine Anzahl der zu behaltenden Snapschüsse an; hier ist BIT eindeutig viel umfangreicher zu konfigurieren (Reiter "Auto-Remove"). LB bietet im Gegensatz zu BIT die Ausführung von Pre-/Postskripten an.
Erwähnenswert ist noch, dass LB eine recht flache einfache Verzeichnisstruktur zur Sicherung aufbaut, während BIT doch sehr verzweigt und kompliziert hier agiert.

Die Rücksicherung funktioniert bei beiden, allerdings bietet LB mir da eine Vorschau sowie Simulation, während BIT mir die Möglichkeit bietet, vorhandene Dateien mit der Endung ".backup.datum" vor dämlichen Datenverlust zu sichern.

In "Vorta" als Backend für BorgBackup hab ich auch kurz reingeschaut. Vorta lässt imho nur verschlüsselte Sicherung lokal als auch fern zu, bietet verschiedene Kompressionsmöglichkeiten und verwendet zur Rücksicherung ein Mountsystem.
Mir erscheint im ersten Eindruck die Oberfläche etwas gewöhnungsbedürftig, aber das Restoreverfahren ist zumindest interessant, da hier einmal der Snapshot irgendwo gemounted sein kann. Das Restore mittels klickbaren VerzeichnisTree ("Entpacken") kann nett sein, aber mir fehlt hier ggf.die Änderung der Zielauswahl.


Fazit:
Funktioniert bestimmt alles, wenn man sich damit auseinandersetzt. Ich habe nur kurz rumgetestet mit kleinen Verzeichnismengen und Vorta nur einen kurzen Blick gegönnt. Daher bitte jetzt keinen "FlamingMoe", sondern konstruktive Ergänzungen bzw. Vorschläge.

Ehrlich gesagt hat mir LB am meisten zugesagt, auch wenn mir das Rotating ("Auto-Remove") von BIT echt dabei fehlt....

[buhtz]

Danke für deine ausführliche Analyse und Gegenüberstellung.
Also BIT maintainer (in dritter Generation) interessiert es mich natürlich besonders.

nutz(t)e ich bisher Unison-gtk , dass bei mir mittels angepasster Profile Teile meiner Platte im Betrieb adHoc spiegelt, nutzt aber imho nicht rsync(?)

Du weißt es vermutlich, aber für andere Mitlesende die über eine Backup-Strategie nachdenken, sei es noch mal gesagt. Unison ist kein Backup Werkzeug, sondern ein Synchronisationswerkzeug. Zwei Speicherorte werden einander angeglichen. Für rsync gilt das, ohne weitere Konfiguration, auch.
Erst durch zusätzliche Parameter, kann man rsync (und vermutlich auch unison), dann auch als Backup nutzen.

BIT ist...

Die von dir genannten Punkte haben wir auf "der Liste". Allerdings relativ weit unten, nicht weil wir es nicht wichtig finden, sondern weil einfach elementarere Probleme weiter oben stehen.

LB bietet im Gegensatz zu BIT die Ausführung von Pre-/Postskripten an.

BIT hat das auch, wenn nur etwas versteckt. Stichwort user-callback Skripte. Die Doku dazu ist etwas in die Jahre gekommen und selber nutze ich es nicht. Daher kann ich dir dazu nicht mehr Details nennen. Am besten auf unserer Mailingliste frage, oder gleich Issues aufmachen, wenn du konkrete Vorschläge zur Verbesserung der Doku hast.

[ArcticBears]

Also BIT maintainer (in dritter Generation) interessiert es mich natürlich besonders.

Dabei sei erwähnt, dass an BIT wohl aktuell gearbeitet wird. LB liegt imho seit 2018 mit v0.5.0 brach?

[...] Unison ist kein Backup Werkzeug, sondern ein Synchronisationswerkzeug. Zwei Speicherorte werden einander angeglichen. [...]

Dass Unison nur für mich aufgrund meiner besonderen Anforderungen Verwendung findet und nur "spiegelt", habe ich imo klar gemacht. Ich hatte es auch nur wegen der Ursprungsfrage von feldmaus nach einem vergleichenden Frontend erwähnt. Als Backup-Lösung denkbar ungeeignet! (ausser eben für o.g. Spezialfälle)

Die von dir genannten Punkte haben wir auf "der Liste". Allerdings relativ weit unten, nicht weil wir es nicht wichtig finden, sondern weil einfach elementarere Probleme weiter oben stehen.

Wie ich festgestellt habe, gilt es wohl erst mal noch einige Bugs auszuräumen? Zumindest habe ich gleich ein paar gefunden, als ich es doch statt LB nutzen wollte.
Ich warte dann mal ab und nutze dann erst einmal LB im EchtzeitBetrieb. Das scheint zu funktionieren bei meinen "geringen" Anforderungen.

[GregorS]

... Zwei Speicherorte werden einander angeglichen. Für rsync gilt das, ohne weitere Konfiguration, auch. ...

Nein, rsync löscht am „Ziel“ keine Dateien, es sei denn, man will dies explizit.

Gruß

Gregor

[buhtz]

Dabei sei erwähnt, dass an BIT wohl aktuell gearbeitet wird. LB liegt imho seit 2018 mit v0.5.0 brach?

Zu BIT: Ja, wir (3 Leute) sind seit letzten Sommer 2022 aktiv im Projekt, nachdem der vorherige Maintainer (2. Generation) das Zepter an uns übergeben hat. Er selbst berät uns aber weiterhin im Hintergrund.

Wie ich festgestellt habe, gilt es wohl erst mal noch einige Bugs auszuräumen? Zumindest habe ich gleich ein paar gefunden, als ich es doch statt LB nutzen wollte.

Ich kann verstehen, wenn du keine vollständigen BugReports abgeben möchtest. Kosten Aufwand und Zeit. Aber wenn du magst, kannst du mir gerne per PM mal Quick n Dirty über die gefundenen Bugs berichten. Evtl. ist ja was Neues dabei.

... Zwei Speicherorte werden einander angeglichen. Für rsync gilt das, ohne weitere Konfiguration, auch. ...

Nein, rsync löscht am „Ziel“ keine Dateien, es sei denn, man will dies explizit.

Ah ja, stimmt. Damit fällt bei rsync (ohne weitere Konfigurationsparameter) der "Nachteil" weg, dass in der Quelle verlorene Dateien, sofort in auch im Ziel (dem "Backup") verschwinden.

[jph]

Borg Backup würde sich hier gut anbieten:

Lässt sich das einzelne Backup, dann im Dateisystem durchsuchen oder ist es ein Borg-eigenes Format, wozu ich dann Borg brauche?

Borg erlaubt es, eine Sicherung via FUSE zu mounten: https://borgbackup.readthedocs.io/en/st ... mount.html

Ich nutze Borg schon länger und bin da zufrieden mit. Allerdings empfiehlt es sich meiner Einschätzung nach, nicht reines Borg, sondern Borgmatic als Wrapper drumherum zu verwenden. Das erspart größtenteils das Schreiben eigener Skripte. Borgmatic erlaubt genau wie reines Borg das Mounten einer Sicherung: https://torsion.org/borgmatic/docs/how- ... -a-backup/

Borg kann optional verschlüsseln, aber vor allem kann es deduplizieren, d.h. eine verschobene oder umbenannte Datei wird nicht wie bei rsync/rsnapshot erneut kopiert. Das bewirkt nicht nur kleinere Sicherungen, sondern auch schnellere Sicherungen, weil eine solche Datei nicht erst übers Netzwerk kopiert werden muss.

[GregorS]

... d.h. eine verschobene oder umbenannte Datei wird nicht wie bei rsync/rsnapshot erneut kopiert. Das bewirkt nicht nur kleinere Sicherungen, sondern auch schnellere Sicherungen, weil eine solche Datei nicht erst übers Netzwerk kopiert werden muss.

Dass umbenannte/verschobene Dateien erneut kopiert werden und dann zusammen mit den Originalen doppelt im Backup landen, ist wohl der größte „Nachteil“ von rsync. Man muss also von Zeit zu Zeit auch mal Dubletten löschen, wenn man nicht schon beim Umbenennen/Verschieben der Originale daran denkt, diese Änderung auch im Backup nachzuvollziehen.

Da ich meine Datensammlung gut pflege und mir vor ein paar Jahren eine Backup-Platte mit 4 TB zugelegt habe, braucht es bei mir ziemlich lange, bis das Backupmedium „vollgelaufen“ ist.
Da ich mich lediglich um meine eigenen Daten kümmern muss und vor dem wöchentlichen Backup lokal aufräume, dauerte das erste Vollaufen rund drei Jahre. Ich habe dann halt das Backup-Medium gelöscht und eine neue „Start-Vollsicherung“ laufen lassen – das dauert dann halt mal eine „bange Nacht“ („bang“, weil dann mal für ein paar Stunden lang gar kein Backup existiert). Vielleicht bunkere ich beim nächsten Mal einfach die vollgelaufene Platte und kaufe eine Neue. Alle drei Jahre kann man das ja mal machen.

Mein Vorgehen ist aus professioneller Sicht sicherlich stümperhaft, aber wie gesagt, ich muss mich einzig um meine eigenen, privaten Daten kümmern. Wäre ich auch für fremde Daten verantwortlich, würde ich das bestimmt sicherer organisieren. Mir kam es aber in erster Linie darauf an, bei Bedarf ohne jedes Hilfsmittel bzw. -programm auf unverschlüsselte Daten zurückgreifen zu können. Jeder Rechner, der meine Backup-Platte mounten kann, kann auch die Daten lesen.

Soviel aus meinem Nähkästchen.

HTH

Gregor

[ArcticBears]

Oh, Nähkästchengeplauder? Gerne.

Dass umbenannte/verschobene Dateien erneut kopiert werden und dann zusammen mit den Originalen doppelt im Backup landen, ist wohl der größte „Nachteil“ von rsync.

Weiß nicht?! Bei sehr großen Dateien sicher doof, aber mir ist wichtiger, dass die Datei nach einem Crash noch irgendwo existiert. Ob die nun doppelt oder 10fach in einem Verzeichnis auftaucht, ist mir dann egal. Hauptsache sie ist da und <>null.
Selbst das Umbenennen hat ja meistens irgendwo einen Sinn gehabt und warum soll ich das als Backup-Historie da nicht mitsichern? Daher: Als Schalter gerne, als Default bitte nicht.

[...] Backup-Platte mit 4 TB zugelegt [...] gelöscht und eine neue „Start-Vollsicherung“ laufen lassen – das dauert dann halt mal eine „bange Nacht“ („bang“, weil dann mal für ein paar Stunden lang gar kein Backup existiert). Vielleicht bunkere ich beim nächsten Mal einfach die vollgelaufene Platte und kaufe eine Neue.

Jei-jei-jei...
[Nähkästchen ON]
Deswegen hatte ich ja oben mich als "gebranntes Kind" bezeichnet:
Ich hatte mich auch auf eine unverschlüsselte ext. HD, auch 4GB, verlassen für private Daten. Leider ohne großes Backup-Konzept, nur mittels cp-Skript und 2. SummenDirectory.
Dann hatte ich Linux neu aufgesetzt und von der HD das vermeintlich komplette aktuelle home-Dir zurückgespielt. 2 Tage später sagte die 4GB-HD nix mehr. Richtig Tot.
Dann habe ich festgestellt, dass bei der Rücksicherung (per cp!) rel. viele Dir/Files=null waren.
Ach ja: Ein paar Tage späte brannte es bei meinem Nachbarn unter mir und ich hatte keine Zeit, etwas mitzunehmen. Aber Glück gehabt: nicht abgebrannt. Ansonsten...

Daher bin ich jetzt bei einem 3-2-1-System auch für meine privaten Daten.
1 Backup auf HD im Arbeits-PC (s.o.) oder Raid
2 ext. Backups, davon mind. 1 ausser Haus (SSDs (MLC) finde ich jetzt auch stabiler als mechanische HDs)
Dabei sind natürlich unterschiedliche Backup-Zustände normal. Gerade die ausser Haus kriegt seltener ein Update.

Ich überlege immer noch, ob ich die alte Backup-HD zur prof. Rettung einschicke, da mir einige wichtige Dokumente fehlen. Der Spass geht so ab 300€ imo los... ;-((
[Nähkästchen OFF]

[...] ich muss mich einzig um meine eigenen, privaten Daten kümmern. [...] Jeder Rechner, der meine Backup-Platte mounten kann, kann auch die Daten lesen.

Jei... Da auch mein Senf dazu:
1. Wenn Du Deinen PC verschlüsselst, warum nicht dann auch die Sicherung?
2. Gerade bei dem "1" (ausser Haus) von 3-2-1 würde ich verschlüsseln.
3. Bei einer Sicherung in eine Cloud würde ich auch immer verschlüsseln.

[GregorS]

1. Wenn Du Deinen PC verschlüsselst, warum nicht dann auch die Sicherung?
2. Gerade bei dem "1" (ausser Haus) von 3-2-1 würde ich verschlüsseln.
3. Bei einer Sicherung in eine Cloud würde ich auch immer verschlüsseln.

1. Mach' ich doch gar nicht.
2. So 'privat' sind meine privaten nun echt nicht.
3. Mit irgendwelchen Clouds habe ich auch nicht zu tun.

Vermutlich bringst Du etwas durcheinander.

Gruß

Gregor

[ArcticBears]

Ja....nö....äh?
Das war jetzt mit 3-2-1 und den Punkten 1-3 zur Verschlüsselung nicht nur auf Dich bezogen.
Ich meinte das eher so allgemein als Tipp (oder zur Diskussion stehend?) von mir für alle, die es wissen wollen. Oder auch nicht.

Nachtrag zu 2.:
Es haben bestimmt schon einige doof aus der Wäsche geguckt, als plötzlich alle ihre Passworte im Darknet aufgetaucht sind? ...weil eine Festplatte nicht verschlüsselt war und in falsche Hände geriet.

[AxelMD]

Hallo,

evtl. ist rclone etwas für dich.

rclone Thread: viewtopic.php?t=182737



Das NAS muss mit rclone kein rsync können.
Bei mir funktioniert es sehr zuverlässig.

MfG
AxelMD

[jph]

Ich nutze Borg schon länger und bin da zufrieden mit. Allerdings empfiehlt es sich meiner Einschätzung nach, nicht reines Borg, sondern Borgmatic als Wrapper drumherum zu verwenden. Das erspart größtenteils das Schreiben eigener Skripte. Borgmatic erlaubt genau wie reines Borg das Mounten einer Sicherung: https://torsion.org/borgmatic/docs/how- ... -a-backup/

Ich mache mal die Ingrid: BorgMatic empfiehlt sich für einen headless vor sich hinwerkelnden Server oder für die Sicherung der Systemkonfiguration.

Auf dem Desktop ist Pika Backup ein besserer Wrapper für Borg: https://gitlab.gnome.org/World/pika-backup

Pika Backup ist leider nicht in den Paketquellen enthalten, kann aber bspw. über Flathub installiert werden: https://flathub.org/apps/org.gnome.World.PikaBackup