Restic

Entstehung und Beteiligte

Restic wurde 2014 vom deutschen Entwickler Alexander Neumann begonnen. Er wollte ein schnelles, sicheres und plattformunabhängiges Backupwerkzeug mit verschlüsselten, deduplizierten Repositorys und einfacher Prüfung.

Welches Problem sollte gelöst werden?

Backups sollten auf lokalen oder entfernten Speichern liegen können, ohne dem Zielsystem Klartextdaten anzuvertrauen. Wiederholte Sicherungen sollten nur neue Inhalte übertragen.

Technische Hürden und Lösungen

Inhaltsdefinierte Chunks und Deduplizierung müssen mit Verschlüsselung zusammenarbeiten. Repository-Indizes, Sperren und Prune benötigen konsistente Abläufe. Ein verlorenes Kennwort ist nicht wiederherstellbar; beschädigte Ziele verlangen unabhängige Kopien.

Standardisierung und Einordnung

Speichersysteme müssen Daten trotz Defekten, Bedienfehlern und Ausfällen erhalten. Historisch verlagerte sich der Fokus von einzelnen Datenträgern zu Verbünden, Snapshots, Prüfsummen, Replikation und verteilten Objekten. Redundanz ist dennoch kein Backup: Sie schützt meist vor Hardwareausfall, nicht automatisch vor Löschen, Verschlüsselungstrojanern oder fehlerhaften Anwendungen.

Technik im praktischen Betrieb

Speicher muss anhand von Fehlerdomänen geplant werden: Datenträger, Controller, Host, Rack, Standort, Zugangsdaten und Verwaltungssoftware können jeweils gemeinsam ausfallen. Prüfsummen erkennen bestimmte Beschädigungen, Replikation erhält Verfügbarkeit und Snapshots ermöglichen schnelle Rücksprünge; keine dieser Funktionen ersetzt automatisch eine unabhängige Sicherung. Regelmäßige Scrubs, SMART- beziehungsweise Gerätezustände, Kapazitätsreserven und Restoretests gehören zum Betrieb. Besonders wichtig ist ein dokumentierter Weg, Daten auch dann wiederherzustellen, wenn die ursprüngliche Verwaltungsoberfläche nicht mehr startet.

Warum das Thema heute noch relevant ist

Die Bedeutung wächst mit der Datenmenge, aber auch mit gesetzlichen und betrieblichen Anforderungen. Historische Speicherfehler zeigen, dass „das Laufwerk funktioniert“ keine ausreichende Integritätsaussage ist. Prüfsummen, Versionen und unabhängige Kopien beantworten verschiedene Risiken. Ein belastbares Konzept definiert deshalb, welche Daten wie lange aufbewahrt werden, wie schnell sie zurückkehren müssen und wer eine Wiederherstellung auch unter Zeitdruck durchführen kann.

Daten und Meilensteine

• 2014 beginnt die Entwicklung.
• Restic verschlüsselt Daten clientseitig.
• Snapshots verweisen auf deduplizierte Inhalte.
• check prüft Repositorystrukturen; Restoretests prüfen zusätzlich die Nutzbarkeit.

Snapshots statt Vollkopien

Jeder Lauf erzeugt einen neuen Snapshot. Bereits gespeicherte Datenblöcke werden wiederverwendet, sodass nur neue Inhalte übertragen werden. Dateien lassen sich aus beliebigen Ständen wiederherstellen.

Verschlüsselung und Zugang

Repository-Inhalte werden clientseitig verschlüsselt. Das Kennwort oder der Schlüssel ist für jede Wiederherstellung erforderlich und muss getrennt, sicher und dokumentiert aufbewahrt werden.

Check und Restore

Regelmäßige Prüfungen lesen Metadaten und optional Datenpakete. Erst ein Restore-Test zeigt, ob Pfade, Rechte, Schlüssel und benötigte Zeit zum Wiederherstellungsziel passen.