Restic: Unverschlüsselte Backups

Ich habe diese Funktionsanfrage jetzt ein paar Mal gehört und dachte daran, dass es ein Problem damit gab. Da ich es nicht finden kann, wird diese Funktionsanfrage hier verfolgt. Die Kurzfassung lautet: Wir werden vielleicht irgendwann eine Option hinzufügen, um die Verschlüsselung zu deaktivieren, aber das steht derzeit nicht auf der Roadmap.

Die lange Version lautet:

• Verschlüsselung ist nicht mehr teuer, zumindest nicht mit AES-NI (Hardware Accelerated Encryption), was heutzutage (zumindest bei Laptops und Servern) durchaus üblich ist.
• restic kümmert sich nicht nur um Verschlüsselung, sondern auch um Authentizität und Signierung der Daten. Wir müssen einen Weg finden, dies ohne Verschlüsselung zu implementieren, also müssen wir sowieso einen Schlüssel / ein Passwort behalten.
• Sobald wir einen Codepfad haben, der unverschlüsselte Backups zulässt, besteht die Möglichkeit, dass Angreifer einen Weg finden, einen Client dazu zu bringen, die Daten unverschlüsselt in einem (ursprünglich) verschlüsselten Repository zu speichern. Das ist schon bei anderen Backup-Programmen passiert, also müssen wir sehr vorsichtig sein, was Zeit und Ressourcen kostet, die wir im Moment nicht haben.

Ich kann weitere Punkte hinzufügen, wenn ich sie finde.

Ein alternativer Grund für unverschlüsselte Backups (lokal) besteht darin, dass ein zentrales Repository von mehreren Benutzern gemeinsam genutzt werden könnte - dh auf meinem Heimserver möchte ich Backups über HTTPS daran senden, aber alle in ein gemeinsames Repository deduplizieren lassen. selbst wenn sie einzelnen Benutzern als logisch getrennt dargestellt werden.

Es besteht die Möglichkeit, dass Angreifer einen Weg finden, einen Client dazu zu bringen, die Daten unverschlüsselt in einem (ursprünglich) verschlüsselten Repository zu speichern.

Hm, ich dachte, die Idee war, dass ein Repository entweder verschlüsselt ist oder nicht, daher wäre es nicht möglich, Daten unverschlüsselt in ein verschlüsseltes Repository zu speichern... Und wenn ein verschlüsseltes Repository irgendwie durch ein unverschlüsseltes mit demselben ersetzt wird Name und Standort sollte der Benutzer bemerken, dass kein Passwort abgefragt wurde. Vielleicht kann eine Warnung in fettem rot blinkendem Text gedruckt werden, dass das Repository unverschlüsselt ist :).

@wrouesnel das kannst du schon machen, nach Hostnamen unterscheiden! (Das habe ich mich neulich auch gefragt) :)

@alexeymuranov wie stellen Sie fest, ob das vom Benutzer eingegebene Kennwort das Verschlüsselungskennwort für ein verschlüsseltes Verzeichnis oder das MAC-Kennwort zur Überprüfung der Authentizität eines unverschlüsselten Verzeichnisses ist? mehr --switches ? Es wird sehr schnell sehr unordentlich.

Ich möchte diese Option zum Erstellen lokaler Backups haben. Zum Beispiel führe ich jeden Tag ein Backup meines ~/Music-Verzeichnisses auf meinem Server durch, aber ich muss nicht verschlüsselt werden. Das Backup dient nicht zum Schutz vor Hardwarefehlern oder -verlust (dafür habe ich andere Backups), sondern einfach zum Schutz vor Unfällen und Bitrot. Und der Server ist ziemlich stromsparend, daher ist der Verschlüsselungsaufwand ein Problem.

@alphapapa dafür gibt es rsync .
EDIT: Und Dateiberechtigungen / Attribute. Übrigens, was ist der Unterschied zwischen "Hardwarefehler" und "Bitrot"?

@cfcs , rsync dedupliziert nicht.

dafür gibt es rsync.

@cfcs Wie wir alle wissen, ist ein Spiegel kein Backup. ;) Mit Obnam halte ich eine Reihe von Backups, ähnlich wie bei restic: keep = 7d,8w,12m,3y Seitdem ich fast meinen GPG-Schlüssel verloren habe (weil er auf mysteriöse Weise ohne mein Wissen auf 0 Byte gekürzt wurde und die gekürzte Datei gesichert wurde) wiederholt), und ich musste es aus einem jahrelangen Backup auf einer CD-R ausgraben, erkenne ich die Bedeutung der Aufbewahrung alter Backup-Daten an.

Übrigens, was ist der Unterschied zwischen "Hardwarefehler" und "Bitrot"?

Bitrot bleibt normalerweise unentdeckt, bis Sie die faulen Daten benötigen, und macht nicht das gesamte Gerät unlesbar. Hardwarefehler sind z. B. der vollständige Ausfall der Festplatte, das Booten des Systems usw.

Und wie Alexey betont, dedupliziert rsync weder, noch bietet es das Bereinigen alter Backup-Daten, noch Datenintegritätsprüfungen usw. rsync ist ein gutes Werkzeug, und ich benutze es regelmäßig, aber nicht, um Backups zu

Verschlüsselung ist nicht mehr teuer, zumindest nicht mit AES-NI (Hardware Accelerated Encryption), was heutzutage (zumindest bei Laptops und Servern) durchaus üblich ist.

Es sei denn, Ihre Software ist in go geschrieben. Go's crypro ist Software nur für alles außer für Intel - mit einem Arm-Gerät stecken Sie also mit "geschätzter Backup-Zeit - 14 Tage" für denselben Dateisatz fest, der in weniger als 30 Minuten mit der offiziellen Openssl-basierten Backup-Lösung auf meinem NAS abgeschlossen ist .

Diese Funktion würde ich auch gerne sehen. Ich verwende SSH für die Übertragung und speichere meine Backups auf verschlüsselten LUKS/cryptsetup-Volumes, daher erhöht die Verschlüsselung nur das Risiko, den Verschlüsselungsschlüssel zu verlieren. Außerdem erhöht die Verschlüsselung die Fehleranfälligkeit und belastet die CPU unnötig.

Trotzdem ist die Verschlüsselung sehr nützlich, wenn ich auf einem nicht vertrauenswürdigen Ziel Backups mache.

Die Leute könnten motiviert sein, eine Textdatei mit dem Passwort zusammen mit dem Backup zu sichern...

Ich verwende auch ein mit luks/dm-crypt verschlüsseltes Backup-Ziel. Es ist eine externe USB-Festplatte, die ich in /Backup/ mounte.
Sie können einfach eine Passwortdatei an diesem Ort erstellen (/Backup/restic_password) und sie mit --password-file an restic füttern. Das Repository geht unter /Backup/restic_repo/
Es ist wichtig, die Passwortdatei unveränderlich zu machen, sonst sind Sie am Arsch, wenn sie versehentlich verloren geht: chattr +i /Backup/restic_password
Außerdem verwende ich nur "restic" als Passwort, nur für den Fall.

Die Verschlüsselungsfunktion von Restic ist sehr nützlich, wenn Sie Backups auf nicht vertrauenswürdige Ziele wie Cloud-Anbieter erstellen. Aber wenn Sie nur externe Laufwerke verwenden, die Sie zu Hause aufbewahren, oder ein NAS in Ihrem Keller, dann ist erzwungene Verschlüsselung irgendwie verrückt. Der durchschnittliche Benutzer wird das Passwort sowieso vergessen.

Das Zulassen unverschlüsselter Backups würde es ZFS oder BtrFS oder NTFS oder einem anderen Dateisystem ermöglichen, Backups zu komprimieren.

(Die Verschlüsselung kann auf Wunsch über dmcrypt auf einer niedrigeren Ebene erfolgen)

Das Zulassen unverschlüsselter Backups würde es ZFS oder BtrFS oder NTFS oder einem anderen Dateisystem ermöglichen, Backups zu komprimieren.

Auch hier nehmen keine Komprimierung und obligatorische Verschlüsselung zu viel Platz auf meinem Backup-Server ein. Mein Anwendungsfall (einige Bilder, viele kleine xml/txt/csv-Dateien) würde entweder von keiner Verschlüsselung (damit ZFS seine Sache machen könnte) oder einer Komprimierung (~2.3 Komprimierungsverhältnis mit zstd,5) stark profitieren.

Wenn Sie ZFS verwenden, warum verwenden Sie dann nicht einfach zfs send Snapshots?

ZFS-Snapshots reichen in vielen Fällen nicht für die Sicherung aus. Wenn eine Datei unentdeckt beschädigt ist oder wenn Sie jahrelange Speichersätze haben möchten, helfen ZFS-Snapshots nicht viel. Angenommen, Sie verwenden FreeNAS und möchten ein Jahr lang wöchentliche Backups erstellen. Die in FreeNAS integrierte Planungs- und Snapshot-Verwaltung reicht _wirklich_ nicht aus, um das richtig zu machen. Es ist kein "Unternehmen".

Wenn Sie ein ausgeklügelteres Planungssystem haben, würde es wahrscheinlich viel besser funktionieren. Es gibt auch das Problem, dass zfs send einen Snapshot benötigt, bevor Sie ihn versenden können. Sie müssen auch einen Snapshot-Zeitplan verwalten und sicherstellen, dass Ihr Snapshot und der Sendeplan (manuell) synchronisiert sind, damit Sie Ihren RTO/RPO erreichen.

Und ja... Ich spreche von Enterprise-Features auf FreeNAS. Aber das ist die Sorge...

Verschlüsselung ist nicht mehr teuer, zumindest nicht mit AES-NI

Die AES-NI-Anforderung schließt viele ältere Server aus (die in einigen Fällen _besonders wichtig_ zu sichern sind!).

Ich helfe jemandem, bessere Backups auf einer Sammlung von Servern im ländlichen Afrika auf 10+ Jahre alter gespendeter Hardware (einige davon sogar noch 32-Bit!) laufen zu lassen. Ich befürchte, dass die Verschlüsselung einfach zu viel Overhead verursacht, daher muss ich mich vorerst woanders umsehen.

+1 für keine Verschlüsselung

das wäre nützlich

+1 für keine Verschlüsselung

das wäre nützlich

Bitte verwenden Sie die Funktion "Daumen hoch" für die ursprüngliche Ausgabe anstelle von '+1', um zu vermeiden, dass die Posteingänge von Beobachtern überflutet werden. Danke schön!

Wie ist der Status dieser Funktion?

Ich muss Dateien (gemeinsam genutzte Dokumente wie Übersetzungen von Bedienungsanleitungen) vom internen Samba-Server sichern, auf die sowieso alle Benutzer der Firma Zugriff haben, sie sind innerhalb der Grenzen der Firma nicht wirklich vertraulich. Backup-Verschlüsselung ist in diesem Fall sinnlos, ich verwende sowieso Jailkit für zusätzliche Sicherheit für Backups und verwende das btrfs-Dateisystem mit aktivierter Komprimierung. Ich sichere Sachen wie VM-Disk-Dumps sowieso auf andere Weise. Die Verschlüsselung ist in meinem Anwendungsfall kein Problem, die Verhinderung von Datenverlust ist die einzige Priorität. Die Verwendung eines Passworts wie 'restic' ist eine alberne Problemumgehung.

Bitte implementieren Sie dies.

@mrkafk Was ist für Sie das eigentliche Problem mit Restic mit Verschlüsselung? Selbst wenn Sie es nicht benötigen, benötigen Sie sehr spezifische Gründe, damit es ein Problem darstellt, da Ihre CPUs höchstwahrscheinlich Hardwareverschlüsselung unterstützen.

Ich habe mein eigentliches Problem beschrieben: Angesichts des spezifischen Kontexts brauche ich es nicht, während es meines Wissens zumindest Komprimierungsgewinne im btrfs-Dateisystem eliminiert. Ich habe jede Menge Dateien zu sichern, deshalb verwende ich in erster Linie btrfs mit aktivierter Komprimierung, weil ich mit RAID-1 für die Hardware-Redundanz viel Speicherplatz benötige (wenn das nicht wäre, würde ich es viel lieber verwenden ext4). Außerdem fühlt es sich albern an, mit einem gefälschten Passwort zu verschlüsseln und unnötig zu verschlüsseln.

Ok, aus den Dingen, die Sie geschrieben haben, entnehme ich ein tatsächliches Problem, nämlich dass die BTRFS-Komprimierung nicht so effektiv ist, wie sie ohne Verschlüsselung sein könnte. Das ist ein guter Punkt. Abgesehen davon sehe ich nichts, was Sie durch die Verschlüsselung von Restic einschränkt.

Es ist unmöglich, den Verschlüsselungsschlüssel zu verlieren, wenn er nicht verschlüsselt ist. Das ist besonders relevant für Backups.

Mebus

Es ist unmöglich, den Verschlüsselungsschlüssel zu verlieren, wenn er nicht verschlüsselt ist. Das ist besonders relevant für Backups.

Das wurde diskutiert, als würde die Welt schon morgen enden :) https://github.com/restic/restic/issues/1786