Anbieter von cloudbasierten Sicherheitssystemen implementieren oft Verfahren auf Serverseite, um den Vendor-Lock-in zu erhöhen und Benutzer vom Kündigen der Abonnements abzuhalten. Kopia [1] umgeht dieses Problem mit der in Bild 1 gezeigten Architektur, die die Intelligenz des Backupsystems auf der Clientseite implementiert. Bevor wir uns mit diesem Aufbau im Detail beschäftigen, sei noch erwähnt, dass Kopia im Hintergrund ein als Rolling Hash bezeichnetes Verfahren verwendet. Das sind Hash-Funktionen, die Dateien sektorweise verarbeiten [2].

Unterstes Hierarchieelement der Kopia-Architektur sind die als "Blob Storage" bezeichneten Speicher, die sich um das Vorhalten der Rohdaten kümmern. Aktuell unterstützt Kopia ein gutes Dutzend verschiedener Implementierungen [3]. Eine Ebene darüber befindet sich der als "Content-Addressable Block Storage" bezeichneter Speichermanager. Er kümmert sich um das Generieren der erwähnten Hash-Funktionen und ist für Modularisierung und Verschlüsselung der von Kopia verwalteten Datensätze verantwortlich.

Da diese Ebene vor allem auf das Verwalten von rund 20 MByte großen Blöcken optimiert ist, kommt eine weitere Ebene namens "Content-Addressable Object Storage" hinzu. Im Zusammenspiel mit der Metadatenverwaltung lassen sich so mehr oder weniger beliebige Objekte im Blob Storage ablegen – im Prinzip ist die innere Architektur der als Repository bezeichneten Dateiablageorte beschrieben.

Außerhalb des blauen Kastens findet sich dann clientseitige Logik, die sich um das eigentliche Verwalten der Informationen kümmert. Dies ist insofern interessant, als die Kommunikation zwischen Repository und Client verschlüsselt abläuft. Laut dem Kopia-Entwicklerteam verlässt das zur Verschlüsselung der Datenübertragung verwendete Passwort nie den Client und ist im Repositorium für Angreifer nicht auffindbar.

Kopia liegt zum einen in einer Version vor, die mit einem grafischen Interface ausgestattetet ist, sowie in einer für den Kommandozeilenbetrieb optimierten Edition. In diesem Workshop konfigurieren wir zunächst eine Windows-10-VM, was die Verwendung des GUI illustriert. Kurz angemerkt sei, dass im Kopia-Ökosystem zwei Begriffe existieren: einerseits Kopia, das für die Kommandozeilenvariante des Sicherungswerkzeugs steht; andererseits hört die grafische Variante, die wir unter Windows verwenden, auf den Namen Kopia UI. Im Weiteren nutzen wir Kopia als Synonym für beide Ausprägungen. Und bevor wir loslegen noch der Hinweis, dass die macOS- und Linux-Varianten ebenfalls mit einer grafischen Benutzerschnittstelle verfügbar sind.

Die erforderliche Binärdatei finden Sie in GitHub [4]. Das aktuelle Release ist Version 0.17.0, die für die GUI-Variante unseres Workshops notwendige Datei heißt "KopiaUI-Setup-0.17.0.exe". Nach der Installation startet das Programm im ersten Schritt seinen in der Taskleiste eingenisteten Daemon, um danach in den Repository-Konfigurationsdialog (Bild 2) zu wechseln. Dies ist insofern logisch, als die Realisierung von Backup-Flows einen Ablageort voraussetzt.

Ein mit den Standardeinstellungen installiertes Kopia startet nicht automatisch, wenn die Workstation rebootet. Zur Behebung dieses Problems reicht es aus, das Kopia-Symbol in der Startleiste rechts anzuklicken und die Option "Launch at Startup" zu markieren. Nach einem Neustart sollte die Kopia-Anwendung dann laufen – falls nicht, greifen die Scheduling-Policies nicht, die wir uns gleich noch anschauen.

Wir arbeiten in den folgenden Schritten mit Azure Blob Storage. Das Kopia-Interface ist aktuell noch nicht in der Lage, die Ressourcen in der Cloud zu provisionieren. Aus diesem Grund ist das Öffnen des unter "https://portal.azure.com" bereitstehenden Azure-Portals erforderlich, das das Erzeugen von Azure-Cloudressourcen mit einer grafischen Benutzerschnittstelle ermöglicht.

Nach dem Abarbeiten des Logins findet sich im Menü in der Favoriten-Rubrik die Option "Storage Accounts". Klicken Sie diese an und entscheiden Sie sich für "Create", um den Prozess zum Anlegen eines neuen Storage-Accounts anzustoßen. Im Fall von Azure gilt, dass Blob-Speicher eine spezialisierte Version eines generischen Storage-Accounts darstellt. Sprich, wer einen Blob-Speicher anlegen möchte, muss die Azure-Subskription im ersten Schritt um einen Storage-Account erweitern. Dieser nimmt danach das Blob Storage auf.

Microsoft integriert eine Abfrage, die Informationen über die Intention des zu erzeugenden Storage-Accounts abfragt. Besonders wichtig ist, im Feld "Primary Service" die Option "Azure Blob Storage" und bei "Primary Workload" "Backup and Archive" auszuwählen. Zu beachten ist dann, dass der Assistent in diesem Fall automatisch eine vergleichsweise teure Redundanzstufe auswählt. Für unseren Workshop reicht es jedoch aus, die Spiegelung über "LRS" auf die minimalste und somit kostengünstigste Betriebsweise zu limitieren. Danach folgt ein Klick auf "Option Review and Create". Wichtig ist, dass in der Zusammenfassung in der Rubrik "Network" unter "Network Connectivity" das Feld "Public Endpoint (all Networks)" ausgewählt ist. Entscheidet sich der Assistent für eine andere Option, blockiert die Azure-Firewall den Zugriff auf die Ressourcen durch Kopia.

Nach dem Anklicken von "Create" vergeht etwas Zeit, während das Azure-Backend die Ressourcen provisioniert. Ein Klick auf den Dialog, der nach Anwahl des "Go to Resource"-Knopfs erscheint, öffnet die Eigenschaften des Storage-Accounts, in dem für die Verbindung mit Kopia benötigte Credentials zur Verfügung stehen. Nun legen Sie einen Blob-Container über "Data Storage / Containers" an, was zunächst die Liste der im Storage-Account befindlichen Container zeigt. Wählen Sie danach "Plus Container", um einen neuen Container zu erzeugen. Wichtig ist die Vergabe eines Namens, der die von Microsoft für Azure-Ressourcen gegebenen Namensrichtlinien erfüllen muss. In den folgenden Schritten nutzen wir "itatestbox". Wichtig ist außerdem, dass nach getaner Konfiguration in der Kopfzeile der String "Authentication method: Access key" aufscheint – die Nutzung der neuen Entra-Funktion wird zum Zeitpunkt der Drucklegung dieses Artikels nicht unterstützt.

Im nächsten Schritt ist die Beschaffung von Access Keys notwendig. Hierzu wechseln Sie aus den Eigenschaften des soeben erzeugten Blob-Speichers in die allgemeine Eigenschaftenverwaltung des Storage-Accounts. Dort finden Sie unter "Security & Networking / Access Keys" die Credentials, deren Nutzung Kopia die Interaktion mit den Cloudressourcen ermöglicht. Nun können Sie die Credentials in das Storage-Configuration-Fenster von Kopia übertragen. Das Feld "Azure Storage Domain" kann leer bleiben, wenn das Ende des Connection Strings für den Account nach dem Schema ". . .==;EndpointSuffix=core.windows.net" aufgebaut ist.

Nach dem Anklicken des Next-Buttons überprüft Kopia die eingegebenen Anmeldedaten, beim erfolgreichen Verbindungsaufbau wechselt das System danach in das Fenster zur Passworteingabe. Dies ist insofern wichtig, als dass Sie dort jenes Kennwort festlegen, das das Backupsystem für die Verschlüsselung der in den Repositories abgelegten Sicherheitskopien heranzieht. Geht dieses verloren, sind alle Sicherungskopien unbrauchbar. Über "Show Advanced Options" lassen sich noch fortgeschrittene Einstellungen setzen, beispielsweise für die zu verwendenden kryptografischen Ressourcen. Nach dem Abnicken dieser Einstellungen ist das Repositorium aktiviert. Kopia quittiert dies insofern, als es uns eine aktuell noch leere Tabelle präsentiert, die die diversen im Repository enthaltenen Snapshots auflistet.

Nach dem Herstellen einer Beziehung zwischen Kopia und der als Ablageort für die zu speichernden Dateien vorgesehenen Repository-Instanz müssen Sie die zur Datensicherung durchzuführenden Operationen beschreiben. Als Begriff für diese hat sich Kopia für "Polizze" entschieden. Analog zu einer Versicherung handelt es sich bei einer Policy in Kopia um eine Sicherungsrichtlinie, die die zu speichernden Informationen ebenso festlegt wie die Frequenz, die zur Aktualisierung der im Repository vorliegenden Informationen zu verwenden ist.

Um Kopia realistisch in diesem Workshop zu nutzen, ist eine zu sichernde Datenbasis erforderlich. Am bequemsten ist das Herunterladen eines beliebigen Repositoriums aus GitHub. Wir nutzen in den folgenden Schritten den Quellcode [5] des Echtzeitbetriebssystems FreeRTOS. Die über den grünen Code-Button aktivierbare Option zum Herunterladen eines ZIP-Archivs führt im Allgemeinen nicht zu brauchbaren Repositorien, weil sie verknüpften Code nicht herunterlädt – doch für uns reicht es aus, den (nicht kompilierbaren) Inhalt der ZIP-Datei ins Dateisystems der virtuellen Maschine zu extrahieren. In unserem Beispiel landen die Daten im Verzeichnis "C:\FreeRTOS-Kernel-main".

Im nächsten Schritt ist eine Besonderheit der Benutzerschnittstelle zu beachten: Sie finden hier ein Eingabefeld für die Auswahl eines Verzeichnisses. Erstellen Sie eine Policy, müssen Sie hier den Ordner aussuchen, auf den die in der Policy festgelegten Attribute wirksam sein sollen.

Das Anklicken des blauen "Verzeichnis öffnen"-Symbols aktiviert einen Dialog, in dem wir uns nunmehr für den Ordner mit dem FreeRTOS-Quellcode entscheiden. Über "Set Policy" erreichen Sie ein aus mehreren Tabs bestehendes Fenster, in dem Sie die Policy-Eigenschaften definieren. Am wichtigsten ist dabei das Feld "Scheduling", in dem Sie die Aktualisierung der auf dem Server befindlichen Kopien festlegen. Der einfachste Weg ist die Nutzung der Funktion "Time of Day". Die dort eingegebenen Zeiten nutzt das System (bei aktiver Ausführung) dann als Anlass zur Aktualisierung der Sicherheitskopien.

Zu beachten ist, dass der eigentliche Dialog zweigeteilt ist. Beim Erzeugen einer neuen Policy zieht Kopia Standardeinstellungen aus einer globalen Policy. Dies erspart Ihnen bei umfangreichen Konfigurationen viel Klickarbeit in der Benutzer- schnittstelle. Beachten Sie zudem die Option "Manual Snapshots only", denn ist diese aktiviert, ignoriert Kopia alle termin- beziehungsweise Cron-basierten Sicherungsaufträge kommentarlos.

Alternativ dazu ist es möglich, das Feld "Defined" neben "Snapshot Frequency" anzuklicken, was Sie zu einem Dialog führt, in dem wir uns für ein 30-minütiges Backup-Intervall entscheiden. Kopia informiert in der Rubrik "Upcoming Snapshots" darüber, wann die nächsten Aktualisierungen erfolgen. Nach getaner Arbeit folgt ein Klick auf die Option "Set Policy", was dazu führt, dass Sie jetzt in der Policy-Liste zwei Regeln finden. Nach dem Ablaufen der Wartezeit erfolgt eine Sicherung, die sich wie in Bild 3 präsentiert. Ergänzend finden Sie in der Tasks-Rubrik tabellarisch die letzten von der Backupsoftware durchgeführten Aktionen.

Das Hochladen des FreeRTOS-Quellcodes auf den Server ist natürlich nur die halbe Miete. Wirklich nützlich sind Backupprogramme definitionsgemäß erst dann, wenn der Administrator übertragene Informationen wieder zurückbekommt. Im Fall von Kopia öffnen Sie dazu im ersten Schritt in der Snapshots-Ansicht den Link in der "Path-Rubrik", was Sie zu einer weiteren Tabelle führt, die die verschiedenen Snapshots listet. Das Anklicken eines dieser Snapshots bringt ein Verwaltungsfenster auf den Schirm.

Über die Option "Mount as Local File System" weisen Sie Kopia an, die Inhalte der Sicherung als lokales Laufwerk zu mounten. Alternativ nutzen Sie "Restore", um eine gewöhnliche Wiederherstellung der Sicherungsdateien auszulösen.

Zum Abschluss wollen wir uns noch die nicht grafische Version ansehen, die Sie per CLI konfigurieren. Als Host dient uns eine virtuelle Maschine, die mit Ubuntu in Version 24.04 LTS arbeitet. Die im Folgenden vorgestellten Befehle decken nur einen kleinen Teil des Funktionsumfangs der Kopia-CLI ab. Unter [6] findet sich eine vollständige Beschreibung.

Auf frisch konfigurierten Systemen ist es im ersten Schritt erforderlich, durch Eingabe von sudo apt install curl Curl herunterzuladen. Danach setzen Sie die beiden folgenden Befehle in einer Root-Shell ab:

Der erste Befehl lädt einen PGP-Schlüssel, der der Paketverwaltung die Überprüfung der Korrektheit der Daten im Repository erlaubt. Der zweite Befehl integriert diesen Schlüssel und das Repository in die Paketquellen.

Der eigentliche Download von Kopia erfolgt durch sudo apt update und sudo apt install kopia. Dies führt dazu, dass die virtuelle Maschine die Version 0.17.0 der Backupsoftware lädt. Analog zur Arbeit mit dem grafischen Benutzerinterface ist im nächsten Schritt das Anmelden eines Repositories erforderlich. Im Allgemeinen kommt dabei das Snap-in "kopia repository" zum Einsatz. Aufgrund der unterschiedlichen Bedürfnisse der Storage-Provider gilt, dass die Parametrierung des Befehls vom jeweiligen Backend abhängig ist, mehr dazu findet sich ebenfalls unter [3]. Als Nächstes bietet es sich an, nach folgendem Schema ein weiteres Repository ins Leben zu rufen:

Ist dieses bereits parametriert, reagiert der Kommandozeilenclient mit der Ausgabe des Fehlers "ERROR unable to get repository storage: found existing data in storage location". Zur Behebung dient der Connect-Befehl, der sich mit einem bereits eingerichteten Repository verbindet:

Zu beachten ist, dass er die drei von Create bekannten Parameter erwartet. Die Abfrage des Verschlüsselungspassworts erfolgt über eine gewöhnliche Eingabezeile; nach getaner Arbeit quittiert das Kommando den erfolgreichen Verbindungsaufbau durch die Statusmeldung "Connected to repository".

Im nächsten Schritt geben Sie kopia snap-shot list --all an, um eine Liste der Repository-Inhalte auf den Bildschirm zu holen. Von besonderer Wichtigkeit sind die IDs, die einzelne Sicherheitskopien identifizieren. Zur Anzeige der im Snapshot befindlichen Informationen legen Sie einen Mountpoint an. Danach verbinden Sie diesen mit den jeweiligen Daten:

Das Ergänzen des "&"-Zeichens weist die Shell dazu an, den Befehl auszuführen und zu wiederholen, Kopia hält also permanent die Verbindung aufrecht. Danach zeigt Ihnen ein ls-Befehl, dass der FreeRTOS-Sourcecode nun auch in der Ubuntu-VM zur Verfügung steht.

Kopia arbeitet mit zahlreichen Backends zusammen und bietet dem Administrator fortgeschrittene Möglichkeiten der Konfiguration. Dabei verschlüsselt es die Sicherungen und erlaubt auch deren Lagerung in der Cloud oder an Remote-Stand- orten. Zudem lassen sich die Backup-Snapshots flexibel handhaben und daraus beispielsweise nur bestimmte Dateien wiederherstellen. Ergänzend zu den im Workshop angesprochenen Features bietet die Software auch Kompression und Deduplizierung der Daten. Alles in allem zeigt sich Kopia als flexibles Backupwerkzeug, das auch in seiner noch sehr jungen Version eine Alternative zu kommerziellen Systemen ist.