Restic, eine Sicherungssoftware auf der Grundlage von Content Defined Chunking (CDC)

Restic ist ein Open-Source-Projekt, das 2014 unter der BSD-Lizenz gestartet wurde.

Das Restic-Projekt

Restic ist eine Backup-Lösung, die auf folgenden Prinzipien basiert:

• Die Deduplizierung an der Quelle muss zwischen mehreren Quellservern optimierbar sein und es muss ein gemeinsamer Speicherort für alle Backups vorhanden sein.
• Die Architektur muss verschiedene Backup-Ziele unterschiedlicher Technologien unterstützen: Cloud-Speicher (S3, Azure Blob, …), SFTP, lokales NAS, …
• Es muss möglich sein, über Restic einfach in einem Backup zu navigieren, um eine Datei wiederherzustellen.
• Die Wiederherstellung ist genauso wichtig wie das Backup: Es muss Mechanismen zur Überprüfung der Integrität des Backups geben.
• Die Abwärtskompatibilität der Backups und aller Repositorys innerhalb derselben Hauptversion von Restic.
• Die Lösung muss auch dann einsetzbar sein, wenn das Backup-Ziel nicht vertrauenswürdig ist: Alle Daten und Repositorys müssen an der Quelle verschlüsselt werden können.
• Die Lösung bietet ein hohes Maß an Widerstandsfähigkeit gegen Bedrohungen, z. B. wenn eine Datei im Speicher gelöscht oder geändert wird, wird dies bei Konsistenzprüfungen erkannt, …

Restic funktioniert unter Linux, Mac, BSD und Windows (mit VSS-Unterstützung).

Internes Design

Aus Sicht des internen Produktdesigns basiert Restic auf folgenden Mechanismen:

• Snapshot, der ein Verzeichnis mit allen Dateien und Unterverzeichnissen zu einem bestimmten Zeitpunkt in einem definierten Zustand darstellt.
  • Die Sicherung integriert erweiterte Dateiattribute (wie ACLs).
• • Für jede durchgeführte Sicherung wird ein neuer Snapshot erstellt.
• • Der Zustand bezeichnet hier den Inhalt und die Metadaten wie den Namen und den Zeitpunkt der Änderung des Verzeichnisses und seines Inhalts.
• Von Content Defined Chunking (CDC) unter Verwendung der Rabin-Implementierung:
  • Bei geänderten Dateien müssen nur die geänderten Teile in einer späteren Sicherung gespeichert werden. Dies funktioniert auch dann, wenn Bytes an beliebigen Stellen in der Datei eingefügt oder gelöscht werden.
  • Bei der ersten Sicherung werden die Daten jeder Datei in Stücke variabler Länge (zwischen 500 KB und 8 MB, in der Regel etwa 1 MB) aufgeteilt.
• SHA-256-Hash für:
  • Identifizieren jedes Stücks des Repositorys
• • Identifizieren jeder Datei: Eine Datei hat einen anfänglichen Hashwert („Speicher-ID“), der sich nie ändert.
• Verschlüsselung der Repositorys und Daten auf Basis von AES-256
• Es können mehrere Verschlüsselungsschlüssel generiert werden.
• Lokaler Cache, der bestimmte Dateien aus dem Repository zwischenspeichert, um bereits kopierte Dateien zu verfolgen, und diesen für spätere Backups verwendet:
  • Dadurch werden Sicherungsvorgänge beschleunigt, da die Metadaten nicht aus einem Remote-Repository geladen werden müssen.

Funktionsweise von Restic

Es handelt sich um eine Push-Backup-Lösung, d. h., der Restic-Client verbindet sich mit dem Speicherserver, um seine Daten zu senden.

Es gibt keine Konzepte für vollständige und differenzielle Backups, sondern jeder Backup ist eine vollständige Momentaufnahme. Das bedeutet, dass natürlich in regelmäßigen Abständen Integritäts- und Wiederherstellungstests der Backups durchgeführt werden müssen.

Die Versionsverwaltung wird unterstützt, d. h. es kann eine Strategie vom Typ GFS implementiert werden: 7 letzte tägliche Backups, 4 monatliche, 5 jährliche.

Das bedeutet jedoch nicht, dass die Daten gelöscht werden, sondern nur, dass sie unzugänglich gemacht werden. Anschließend müssen Bereinigungsvorgänge durchgeführt werden, um unnötige Daten zu löschen.

Bei der Sicherung können Dateien durch Angabe von Ausschlussmustern (ein Verzeichnis, eine Dateigröße, ein Dateityp usw.) ausgeschlossen werden.

Die Dateien können nicht direkt über das Dateisystem wiederhergestellt werden. Sie müssen daher Restic verwenden, um in den Sicherungen zu navigieren. Es gibt keine grafische Benutzeroberfläche, sondern nur eine einfache Befehlszeilenschnittstelle.

Löschen von Sicherungs-Snapshots

Um alte Snapshots zu löschen, müssen zwei Aktionen durchgeführt werden:

• Das „Vergessen“ eines Snapshots (forget) entfernt den Snapshot aus dem Repository, löscht jedoch nicht die unnötigen Daten.
• Das „Bereinigen“ (prune) löscht tatsächlich die Daten, auf die der Snapshot im Repository verweist.
  • Wenn sich das Repository an einem entfernten Speicherort befindet, kann diese Aktion direkt vom Remote-Speicher aus durchgeführt werden und hat somit keine Auswirkungen auf die Ursprungsserver. Allerdings wird durch diese Aktion das Repository gesperrt und somit alle Backups blockiert.
• • Diese Aktion kann sehr lange dauern, da jeder Blob analysiert wird, um festzustellen, ob er gelöscht werden kann, und das Repository aktualisiert wird.
• Es wird empfohlen, zwischen zwei Bereinigungsvorgängen eine Integritätsprüfung des Repositorys durchzuführen (Check).

Aktuelle Einschränkungen von Restic

• Die Lösung ist vor allem auf die Sicherung von Linux-Dateien ausgerichtet, und die Erfahrungen mit großen Multi-OS-Infrastrukturen sind noch begrenzt
  • abgesehen von den Erfahrungen des CERN
• Keine native Unterstützung von Cold-Storage-Mechanismen (und Archiv-Wiederherstellungsprozessen)
  • Ist Teil des Rustic-Projekts, das dieselben Repositorys wie Restic verwendet, jedoch für mehr Leistung und Sicherheit in Rust entwickelt wurde.

Wenn Sie an der Backup-Lösung Restic interessiert sind, kontaktieren Sie uns.

Weitere Backup-Lösungen, die Content Defined Chunking (CDC) verwenden

Borg Backup

Diese Software basiert auf ähnlichen Mechanismen wie Restic. Die wichtigsten Unterschiede sind:

• Da sie in Python geschrieben ist, müssen Abhängigkeiten installiert werden, was bei älteren Betriebssystemversionen zu Problemen führen kann.
• Nur über SSH verwendbar und keine native Unterstützung für Objektspeicherung (erfordert einen Pufferspeicher oder einen Server in der Cloud).
• In der Praxis benötigt sie ein Repository für jeden Server, was die Deduplizierungskapazität verringert, wenn viele Server auf demselben Betriebssystem basieren.
  • Dies kann als Vorteil angesehen werden, da die Auswirkungen eines Integritätsproblems auf eine Sicherung und nicht auf eine Reihe von Sicherungen beschränkt sind.
• Verwendung mehrerer Datenkomprimierungslösungen (lz4, zstd, zlib, lzma)

Kopia

Diese Software basiert auf ähnlichen Mechanismen wie Restic und ist ebenfalls in GO geschrieben. Obwohl das Projekt noch recht jung ist, hat es 2020 und 2021 einen starken Aufschwung erlebt.

Die wichtigsten Unterschiede sind:

• Verfügbarkeit einer grafischen Benutzeroberfläche (GUI)
• Datenkomprimierung (pgzip, zstd, S2)