Restic – Backup-Software auf Basis von Content Defined Chunking (CDC)

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

Das Projekt Restic

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

• Deduplizierung an der Quelle
  Die Deduplizierung der Daten erfolgt bereits auf den Quellsystemen und muss serverübergreifend optimierbar sein. Ziel ist ein gemeinsames Repository für mehrere Backup-Quellen, um Redundanzen effizient zu reduzieren.
• Unterstützung heterogener Backup-Ziele
  Die Architektur ist so ausgelegt, dass unterschiedliche Backup-Zieltechnologien unterstützt werden können, darunter:
  • Cloud-Speicher (z. B. S3, Azure Blob Storage),
  • SFTP,
  • lokale NAS-Systeme.
• Einfache Navigation innerhalb der Backups
  Es muss möglich sein, innerhalb eines Backups gezielt zu navigieren, um einzelne Dateien oder Verzeichnisse wiederherzustellen.
• Wiederherstellung als gleichwertige Disziplin
  Die Wiederherstellung ist ebenso wichtig wie die Sicherung selbst. Entsprechend müssen Mechanismen zur Überprüfung der Backup-Integrität vorhanden sein.
• Rückwärtskompatibilität innerhalb einer Hauptversion
  Backups und Repositories müssen innerhalb derselben Major-Version von Restic vollständig kompatibel bleiben.
• Sicherung auf nicht vertrauenswürdige Ziele
  Die Lösung muss auch dann einsetzbar sein, wenn das Backup-Ziel als nicht vertrauenswürdig gilt. Sämtliche Daten und Repositories können daher bereits an der Quelle vollständig verschlüsselt werden.
• Hohe Widerstandsfähigkeit gegenüber Manipulationen
  Änderungen oder Löschungen von Dateien im Speichersystem werden bei Konsistenzprüfungen erkannt, was die Erkennung von Manipulationsversuchen unterstützt.

Internes Design

Aus architektonischer Sicht basiert Restic auf mehreren zentralen technischen Mechanismen:

Snapshots

• Ein Snapshot repräsentiert ein Verzeichnis inklusive aller Dateien und Unterverzeichnisse zu einem definierten Zeitpunkt.
• Der Zustand umfasst sowohl den Inhalt als auch Metadaten wie Dateinamen und Änderungszeitpunkte.
• Für jede durchgeführte Sicherung wird ein neuer Snapshot erzeugt.
• Die Sicherung berücksichtigt auch erweiterte Dateiattribute, beispielsweise ACLs.

Content Defined Chunking (CDC) auf Basis von Rabin-Fingerprints

• Bei der initialen Sicherung werden die Daten jeder Datei in variable Datenblöcke unterteilt. Typische Blockgrößen liegen zwischen 500 KB und 8 MB, im Durchschnitt bei etwa 1 MB.
• Bei geänderten Dateien werden bei Folgesicherungen ausschließlich die veränderten Datenblöcke gespeichert. Dieses Verfahren funktioniert auch dann zuverlässig, wenn Bytes an beliebigen Positionen innerhalb einer Datei eingefügt oder entfernt werden.

Kryptografische Mechanismen

• SHA-256-Hashing
  • Zur eindeutigen Identifikation jeder Datei: Jede Datei besitzt eine initiale „Storage-ID“, die sich nicht verändert.
  • Zur Identifikation jedes einzelnen Datenblocks im Repository.
• Verschlüsselung
  • Repositories und Daten werden mittels AES-256 verschlüsselt.
  • Es können mehrere Verschlüsselungsschlüssel erzeugt und verwaltet werden.

Lokaler Cache

• Ein lokaler Cache speichert ausgewählte Metadaten und Repository-Informationen, um bereits gesicherte Dateien nachzuverfolgen.
• Dieser Cache wird bei nachfolgenden Sicherungen genutzt, wodurch:
  • Metadaten nicht erneut aus entfernten Repositories geladen werden müssen,
  • Backup-Vorgänge deutlich beschleunigt werden.

Funktionsweise von Restic

Restic arbeitet nach dem Push-Prinzip. Das bedeutet, dass der Restic-Client aktiv eine Verbindung zum Backup-Ziel herstellt und die Daten dorthin überträgt.

Es existiert kein klassisches Konzept von Voll- und inkrementellen Backups.
Jede Sicherung stellt einen vollständigen Snapshot dar. Daraus ergibt sich die Notwendigkeit, regelmäßig Integritäts- und Wiederherstellungstests durchzuführen.

Die Versionierung wird vollständig unterstützt. Dadurch lassen sich beispielsweise Strategien nach dem GFS-Prinzip (Grandfather-Father-Son) umsetzen, etwa:

• die letzten 7 täglichen Backups,
• 4 monatliche Backups,
• 5 jährliche Backups.

Dabei ist zu beachten, dass Daten durch das Entfernen von Snapshots zunächst nicht physisch gelöscht, sondern lediglich nicht mehr referenziert werden. Erst durch anschließende Bereinigungsprozesse werden nicht mehr benötigte Daten tatsächlich entfernt.

Darüber hinaus können bei der Sicherung Dateien ausgeschlossen werden, beispielsweise:

• bestimmte Verzeichnisse,
• Dateien ab einer definierten Größe,
• bestimmte Dateitypen.

Backups sind nicht direkt über das Dateisystem zugreifbar. Die Navigation und Wiederherstellung erfolgen ausschließlich über Restic selbst.
Eine grafische Benutzeroberfläche existiert nicht; die Bedienung erfolgt über eine schlanke Kommandozeilenschnittstelle.

Löschen von Sicherungs-Snapshots

Das Entfernen alter Snapshots erfolgt in zwei Schritten:

• Forget (Vergessen eines Snapshots)
  Der Snapshot wird aus dem Repository entfernt, die zugehörigen Daten bleiben jedoch weiterhin physisch vorhanden.
• Prune (Bereinigung)
  Erst dieser Schritt entfernt tatsächlich die Datenblöcke, die nicht mehr von Snapshots referenziert werden.
  • Der Vorgang kann zeitaufwendig sein, da sämtliche Blobs analysiert und das Repository entsprechend aktualisiert werden.
  • Bei entfernten Repositories kann diese Operation direkt vom Storage-Ziel aus durchgeführt werden und belastet die Quellsysteme nicht.
  • Während des Prune-Vorgangs wird das Repository jedoch gesperrt, sodass keine Backups durchgeführt werden können.

Nach Bereinigungsoperationen wird empfohlen, eine Integritätsprüfung des Repositories (Check) durchzuführen.

Aktuelle Grenzen von Restic

• Die Lösung ist vorwiegend auf die Sicherung von Linux-Dateien ausgerichtet. Belastbare Erfahrungswerte in großen, heterogenen Multi-OS-Infrastrukturen sind bislang begrenzt. Eine der wenigen Ausnahmen stellen veröffentlichte Erfahrungen des CERN dar.
• Es existiert keine native Unterstützung für Cold-Storage-Mechanismen oder Prozesse zum Rehydrieren archivierter Daten. Diese Funktionalität ist Bestandteil des Projekts Rustic, das dieselben Repositories wie Restic nutzt, jedoch in Rust implementiert ist, um Performance und Sicherheit weiter zu verbessern.

Wenn Sie sich für den Einsatz von Restic als Backup-Lösung interessieren, kontaktieren Sie uns gerne.

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

Borg Backup

Borg Backup basiert auf ähnlichen technischen Prinzipien wie Restic. Zentrale Unterschiede sind:

• Die Implementierung in Python erfordert zusätzliche Abhängigkeiten, was insbesondere auf älteren Betriebssystemversionen problematisch sein kann.
• Die Nutzung ist ausschließlich über SSH möglich; eine native Unterstützung von Object Storage existiert nicht. Cloud-Speicher lassen sich nur über Zwischenspeicher oder zusätzliche Server integrieren.
• In der Praxis wird in der Regel ein separates Repository pro Server eingesetzt.
  • Dies reduziert die Deduplizierungseffekte in Umgebungen mit vielen gleichartigen Systemen.
  • Gleichzeitig kann dies als Vorteil betrachtet werden, da Integritätsprobleme auf einzelne Backups begrenzt bleiben.
• Unterstützung mehrerer Kompressionsverfahren, darunter lz4, zstd, zlib und lzma.

Kopia

Kopia basiert ebenfalls auf vergleichbaren Mechanismen und ist – wie Restic – in Go implementiert. Obwohl das Projekt noch relativ jung ist, hat es insbesondere in den Jahren 2020 und 2021 eine starke Entwicklung erfahren.

Zentrale Unterschiede:

• Verfügbarkeit einer grafischen Benutzeroberfläche (GUI)
• Unterstützung mehrerer Kompressionsverfahren, darunter pgzip, zstd und S2