Sicherung & Wiederherstellung

Die Anwendung heißt „Ticket System Backup & Restore". Sie liegt neben dem Ticket-System und hat eine eigene Verknüpfung auf dem Desktop.

Es gibt sie für Windows und für Linux. Sie ist dieselbe Anwendung, nur für das jeweilige Betriebssystem gebaut.

Sie hat sechs Reiter. „Restore" listet die vorhandenen Sicherungen, „Create Backup" legt eine neue an, „Schedule" regelt den Zeitplan, „Encryption" zeigt den Wiederherstellungsschlüssel, „Settings" zeigt die Pfade und „Log" das Protokoll.

Die Einstellungen sind bereits ausgefüllt. Die Anwendung sucht sich beim ersten Start selbst, wo das Ticket-System liegt.

Der Ordner für die Sicherungen steht unter „Backup directory". Du kannst ihn ändern, zum Beispiel auf ein anderes Laufwerk.

Unter Windows fragt die Anwendung beim Start nach Administratorrechten. Ihre Einstellungen gelten für alle Administratoren des Rechners. Sie liegen unter „%ProgramData%\SMITEY\backup-app".

Die Installation richtet die tägliche Sicherung selbst ein. Sie läuft um 23:00 Uhr in der Zeitzone des Ticket-Systems.

Der Zeitplan liegt im Betriebssystem. Unter Windows ist das die Aufgabenplanung, unter Linux der Cron-Dienst. Es läuft also kein zusätzlicher Dienst nur für die Sicherung.

Die Sicherung braucht keinen angemeldeten Benutzer. Auf einem Server, an dem sich nie jemand anmeldet, läuft sie trotzdem.

Die Zeile unter den Schaltflächen sagt dir, ob die Aufgabe im Betriebssystem wirklich steht. Ein gesetztes Häkchen sagt nur, was gespeichert wurde.

Aufbewahrt wird in fünf Staffeln: 14 Tage, 4 Wochen, 12 Monate, 4 Quartale und 5 Jahre. Eine Sicherung bleibt, solange sie in einer dieser Staffeln die jüngste ihres Zeitraums ist.

Gezählt werden Kalendertage, nicht Dateien. Zwei Sicherungen an einem Tag sind ein Tag.

Sicherungen, die du von Hand anlegst, werden nie automatisch gelöscht. Dafür steht die 0 bei „Keep manual".

Änderst du den Zeitplan, bleibt deine Änderung bei einem Update erhalten. Die Installation setzt ihn nur, wenn du noch nie einen Zeitplan festgelegt hast. Hast du die Sicherung abgeschaltet, bleibt sie aus. Auch „Remove all scheduled tasks" bleibt wirksam. Ein Update richtet den Zeitplan danach nicht wieder ein.

Eine Sicherung enthält alles, was den Zustand deines Systems ausmacht. Das sind die Datenbank, die Datei-Anhänge, das Archiv und die Schlüssel. Nur eine Datenbank außerhalb von SMITEY fehlt darin.

Die Schlüssel sind der Punkt, den man leicht übersieht. Mit ihnen werden gespeicherte Zugangsdaten entschlüsselt, etwa die deines Mailkontos. Ohne sie käme eine Wiederherstellung mit toten Zugangsdaten zurück.

Jede neue Sicherung ist eine einzelne verschlüsselte Datei mit der Endung „.smbk". Darin stehen je ein Datenträger, eine Liste des Inhalts und die Datenbank als Textdatei, wenn sie mitgesichert wird.

Das System läuft dabei weiter. Deine Bearbeiter merken von einer Sicherung nichts.

„Estimate size" sagt dir vorher, wie groß die Datenbank ist. Die Datenträger mit den Anhängen kommen dazu. Gepackt wird die Sicherung nicht.

Überschrieben wird nie etwas. Jede Sicherung ist eine eigene Datei, und erst die Aufräumung entfernt alte.

Lesen dürfen die Sicherungen nur Administratoren. Dasselbe gilt für die Konfigurationsdatei und die Datei mit der ersten Anmeldung im Installationsordner. Installer und Updates setzen diese Rechte selbst.

Läuft deine Datenbank auf einem eigenen Server und nicht im Container von SMITEY, kann die Anwendung sie nicht sichern. Sichere sie dann mit eigenen Mitteln. Die Sicherung enthält in diesem Fall nur die Anhänge, die Archive und die Schlüssel, wie gewohnt verschlüsselt. Ein Update erkennt eine solche Datenbank selbst und stellt die Anwendung darauf um. Bis dahin scheitert die tägliche Sicherung auf einer solchen Installation, außer du stellst sie vorher von Hand um. Auf der Befehlszeile geht das auch von Hand mit „config --database external". Mit „config --database bundled" schaltest du zurück.

Jede neue Sicherung ist verschlüsselt. Das gilt für Sicherungen nach Zeitplan, von Hand und vor einem Update. Du musst dafür nichts einschalten.

Verschlüsselt wird mit AES-256. Den Schlüssel legt die Installation selbst an. Bei einer bestehenden Installation entsteht er beim ersten Update auf eine Fassung mit Verschlüsselung. Er liegt geschützt auf dem Server. Nur Administratoren können ihn lesen.

Das schützt Kopien außerhalb des Servers. Wer eine Sicherung auf einem Netzlaufwerk, einem USB-Stick oder in einem Speicher im Netz findet, kann sie ohne den Schlüssel nicht lesen. Wer den Server selbst in der Hand hat, hat auch den Schlüssel.

Der Wiederherstellungsschlüssel ist derselbe Schlüssel in einer Form, die du aufschreiben kannst. Er beginnt mit „SMBK-". Du findest ihn im Reiter „Encryption" und in der Datei „SMITEY-credentials.txt" im Installationsordner. Hast du die Datei gelöscht, findest du den Schlüssel weiter im Reiter „Encryption".

„Copy" legt den Schlüssel in die Zwischenablage. „Save to file..." speichert ihn mit Schlüssel-ID und Datum in einer Textdatei. Bewahre ihn zum Beispiel in einem Passwort-Manager oder auf Papier in einem Tresor auf.

Bis du die Verwahrung bestätigst, zeigt die Anwendung oben eine gelbe Leiste. Klicke dazu auf „I stored the key outside this server" und beantworte die Rückfrage mit „Yes". Danach verschwindet die Leiste. Der Reiter nennt dann den Zeitpunkt der Bestätigung.

Die Schlüssel-ID zeigt, zu welchem Server eine Sicherung gehört. Passt eine Sicherung nicht zu diesem Server, nennt die Anwendung ihre Schlüssel-ID. Dann fragt sie nach dem passenden Wiederherstellungsschlüssel.

Kann die Anwendung den Schlüssel nicht lesen, legt sie keine Sicherung an. Eine unverschlüsselte Sicherung entsteht dann auch nicht. Der Reiter „Encryption" sagt in diesem Fall, dass der Schlüssel nicht gelesen werden kann. Fehlt die Schlüsseldatei ganz, legt die nächste Sicherung einen neuen Schlüssel an. Die gelbe Leiste erscheint dann wieder, denn auch der neue Schlüssel muss verwahrt werden. Ältere Sicherungen öffnet weiter nur der alte Wiederherstellungsschlüssel.

Ältere Sicherungen im ZIP-Format sind nicht verschlüsselt. Du kannst sie weiter einspielen. Der Reiter nennt ihre Zahl. Die Aufräumung entfernt sie nach denselben Regeln wie jede andere Sicherung.

Auf einem Server ohne Oberfläche zeigt „key --show" dasselbe auf der Befehlszeile.

Im Reiter „Restore" wählst du die Sicherung aus, die zurück soll. Dann klickst du auf „Restore".

Vorher fragt die Anwendung nach. Sie sagt dabei, was passiert: Der heutige Stand wird überschrieben, und die Anwendung startet die Container neu. Sind im heutigen Stand Personen anonymisiert, folgt eine zweite Frage. Sie nennt die Zahl und fragt, ob diese Personen nach der Wiederherstellung erneut anonymisiert werden sollen. „Yes" ist vorausgewählt. Mit „No" wird die Sicherung ohne diesen Schritt zurückgespielt. Schließt du das Fenster stattdessen, wird nichts zurückgespielt.

Das Häkchen „Wipe target volumes before restore" räumt die Datenträger vorher leer. So bleibt keine Datei liegen, die es zum Zeitpunkt der Sicherung noch nicht gab.

Der Ablauf steht im Reiter „Log". Dort siehst du Schritt für Schritt, was die Anwendung getan hat. Hast du die zweite Frage mit „Yes" beantwortet, nennt eine Zeile am Ende, wie viele Anonymisierungen das Ticket-System im nächtlichen Lauf erneut anwendet. Lassen sie sich nicht übertragen, zeigt das Protokoll stattdessen eine Warnung. Gab es Warnungen, nennt die Statuszeile unten im Fenster ihre Zahl.

Enthält die Sicherung die Datenbank, kommt der komplette Stand zurück. Tickets, Kommentare, Verlauf, Datei-Anhänge, erfasste Zeiten und die Wissensdatenbank stehen wieder so da wie zum Zeitpunkt der Sicherung.

Danach ist das System wieder benutzbar. Bei einer kleinen Installation dauert das keine Minute.

Enthält die Sicherung die Datenbank, kommt sie ganz oder gar nicht zurück. Die Datenträger folgen danach. Scheitert ein Datenträger, ist die Datenbank schon zurück, aber Dateien können fehlen. Der Reiter „Log" zeigt, welcher Schritt gescheitert ist. In jedem Fall startet die Anwendung die Container danach wieder, auch wenn die Wiederherstellung gescheitert ist.

Eine Sicherung aus einer älteren Fassung lässt sich in eine neuere einspielen. Beim nächsten Start hebt das System die Datenbank auf seinen eigenen Stand.

Einwilligungen und Abmeldungen zur Zufriedenheitsumfrage überträgt die Anwendung ohne Rückfrage. Das gilt auch, wenn du die zweite Frage mit „No" beantwortest. Die Anwendung liest sie vor der Wiederherstellung aus der laufenden Installation. Danach nennt eine Zeile im Reiter „Log" die Zahl, zum Beispiel „12 consent and unsubscribe record(s) were carried over." Das Ticket-System übernimmt sie beim ersten Start. Eine Einwilligung oder Abmeldung, die nach der Sicherung kam, gilt also weiter. Scheitert die Übertragung, zeigt das Protokoll eine Warnung. Die Wiederherstellung gilt trotzdem als gelungen.

Eine verschlüsselte Sicherung prüft die Anwendung zuerst vollständig. In der Statuszeile steht dabei „Checking the encrypted backup before anything is changed...". Erst danach stoppt sie die Container. Ist die Datei beschädigt oder verändert, bricht sie ab und meldet „The backup file is damaged. Nothing was changed."

Stammt die Sicherung von einem anderen Server, fragt die Anwendung nach dessen Wiederherstellungsschlüssel. Das geschieht nach den Rückfragen. Das Fenster „Recovery key needed" nennt die Schlüssel-ID der Sicherung. Dasselbe Fenster erscheint, wenn der Schlüssel dieses Servers fehlt.

Ein Tippfehler fällt auf, bevor etwas geändert wird. Die Statuszeile meldet dann „The recovery key has a typing error. Check each character." Danach fragt das Fenster erneut. Gehört der Schlüssel zu einer anderen Sicherung, meldet die Statuszeile „This recovery key does not belong to this backup." Mit „Cancel" bricht die Anwendung ab und meldet „Restore cancelled. Nothing was changed."

Den eingegebenen Schlüssel übernimmt die Anwendung nicht. Sie behält ihren eigenen. Neue Sicherungen entstehen danach weiter mit dem Schlüssel dieses Servers. Spielst du auf einem neuen Server zurück, verwahre auch dessen Wiederherstellungsschlüssel.

Eine Sicherung ohne Datenbank spielt nur die Anhänge, die Archive und die Schlüssel zurück. Vorhandene Schlüssel bleiben erhalten. Die Datenbank bleibt, wie sie ist. Die Anwendung sagt das vor dem Einspielen und fragt nach. Mit „No" wird nichts geändert.

Ist die Installation auf eine eigene Datenbank eingestellt, überspringt die Anwendung den Datenbankteil auch dann, wenn die Sicherung eine Datenbank enthält. Das betrifft zum Beispiel eine ältere Sicherung. Die Anwendung fragt vorher nach. Mit „No" wird nichts geändert.

Auf einem Server gibt es oft keine Oberfläche. Dieselbe Anwendung kann deshalb auch als Befehl.

Fünf Befehle brauchst du im Alltag: „backup" sichert, „list" zeigt die vorhandenen Sicherungen, „restore" holt eine zurück, „schedule" setzt den Zeitplan und „config" zeigt die Einstellungen. Für den Schlüssel kommen „key" und „decrypt" dazu.

Dahinter steckt dieselbe Anwendung wie im Fenster. Es gibt keinen zweiten Weg, der etwas anderes tut.

Die Anwendung liegt in „/opt/smitey/Backup". Du rufst sie mit „sudo" auf und hängst den Befehl an. Die Container laufen als „root", deshalb braucht auch die Sicherung diese Rechte.

Die sechs Kästen unten kannst du kopieren. Sie decken ab, was im Betrieb wirklich gebraucht wird.

Eine Wiederherstellung fragt auch hier nach. Sie läuft erst mit dem Zusatz „--yes". Sie überträgt dann auch die Anonymisierungen des heutigen Stands, wie „Yes" im Fenster. Mit „--no-reapply" läuft sie ohne diesen Schritt.

Zum Nachlesen liegt eine Datei auf dem Server. Sie heißt „BACKUP-RESTORE.txt" und liegt in „/opt/smitey". Darin stehen der Zeitplan, alle Befehle und der Weg zurück noch einmal in Ruhe. Es gibt sie auf Deutsch und auf Englisch. Hast du bei der Installation Deutsch gewählt, ist es die deutsche Fassung, sonst die englische. Beide Fassungen liegen zusätzlich unter „/opt/smitey/docs".

„key --show" zeigt den Wiederherstellungsschlüssel, die Schlüssel-ID und die Zahl der unverschlüsselten Sicherungen. Liegt der Schlüssel außerhalb des Servers, bestätigst du das mit „key --confirm-stored".

Eine Sicherung von einem anderen Server spielst du mit „--key-file" zurück. Die angegebene Datei enthält den Wiederherstellungsschlüssel. Die Datei aus „Save to file..." eignet sich dafür ebenfalls. Statt der Datei geht auch die Umgebungsvariable „SMITEY_BACKUP_KEY". Mit „sudo" schreibst du sie direkt vor das Programm, also „sudo SMITEY_BACKUP_KEY=<Schlüssel> /opt/smitey/Backup/TicketSystemBackup restore …". Der Schlüssel steht dann im Verlauf der Shell. Passt der Schlüssel nicht, wird nichts geändert.

„decrypt" legt den Inhalt einer Sicherung als unverschlüsselte Dateien in einen leeren Ordner. Diese Dateien sind nicht verschlüsselt. Sie enthalten Passwörter und personenbezogene Daten. Lösche sie, sobald du fertig bist.

Die Sicherungen liegen als Dateien im eingestellten Ordner. Der liegt auf derselben Maschine wie das Ticket-System.

Gegen die häufigen Fälle hilft das gut. Ein versehentlich gelöschter Bestand, ein misslungenes Update oder ein Fehler in den Daten sind damit abgedeckt.

Gegen einen Ausfall der Platte hilft es nicht. Ist die Platte weg, sind die Sicherungen mit weg.

Kopiere die Dateien deshalb woanders hin. Ein Netzlaufwerk, ein zweiter Server oder ein Speicher im Netz reichen dafür.

Eine kopierte Datei lässt sich auf jedem Server wieder einspielen. Auf einem anderen Server brauchst du dafür den Wiederherstellungsschlüssel. Über „Import backup file…" holst du die Datei zurück in die Liste.

Die Kopien sind verschlüsselt. Ohne den Wiederherstellungsschlüssel kann sie niemand lesen. Lege den Schlüssel deshalb nicht neben die Kopien. Ältere Sicherungen mit der Endung „.zip" sind nicht verschlüsselt.

Ein Update legt vorher eine eigene Sicherung an. Das passiert unabhängig von deinem Zeitplan und ohne dass du etwas anhakst.

Gesichert wird dasselbe wie sonst: die Datenbank, die Anhänge, die Archive und die Schlüssel. Läuft die Datenbank außerhalb von SMITEY, sichert das Update nur Anhänge, Archive und Schlüssel.

Diese Sicherung legt die Anwendung „Ticket System Backup & Restore" an. Sie ist verschlüsselt wie jede andere und liegt im selben Ordner. In der Liste steht sie mit der Art „Update". Von diesen Sicherungen bleiben die drei neuesten. Ältere löscht die Anwendung selbst.

Der Hinweis vor dem Update sagt es dir. Du musst also nicht daran denken, vorher selbst zu sichern.

Scheitert diese Sicherung, bricht das Update ab, bevor etwas ausgetauscht wird. Eine Datenbank außerhalb von SMITEY hält das Update nicht auf. Das Update stellt die Anwendung dann so um, dass auch die tägliche Sicherung die Datenbank auslässt. Sichere diese Datenbank mit eigenen Mitteln.