Eine vertrauenswürdige Sicherung wählen und die Webseite wiederherstellen

Einführung

Ein kleiner Laden verwendet einen Bestelldienst, um Kunden, Produkte und Mengen zuzuordnen. Nach einem vorbereiteten Vorfall fehlen zwei Bestellungen. Du stellst die benötigten Daten wieder her, ohne den unabhängigen öffentlichen Katalog zu ersetzen. Alle Personen und Datensätze sind synthetisch; es gibt keine Schadsoftware.

Eine Sicherung ist eine Kopie zur Wiederherstellung. Ein Archiv bündelt Dateien, eine Prüfsumme fasst deren Bytes zusammen. Du lernst, warum eine Prüfsumme nur mit vertrauenswürdiger Referenz hilft, und stellst eine echte SQLite-Datenbank über ein Vorbereitungsverzeichnis wieder her. Dies ist eine begrenzte Wiederherstellungsübung, kein vollständiges Verfahren zur Vorfallbehandlung.

Grundlegende Befehlseingabe und Tabwechsel reichen aus. Workstation und App Server sind getrennte Terminalsitzungen desselben Hosts mit unterschiedlichen Startverzeichnissen, keine getrennten Rechner. Order Service zeigt die Browseransicht.

Beschädigte Dienstdaten bewahren

In diesem Schritt verstehst du die fehlenden Geschäftsdaten und sicherst vor Änderungen eine Kopie für den Rückweg.

Öffne Order Service. Jede Zeile verbindet normalerweise Bestellnummer, Kunde, Status, Produkt und Menge. Der erforderliche Wiederherstellungspunkt enthält diese drei Bestellungen:

Aktuell erscheint nur 4101. Klicke Public catalog: Tassen, Notizbücher und Taschen sollten weiterhin aufgeführt sein. Dieser Upload gehört nicht zur Datenbank und muss erhalten bleiben. Kehre anschließend zur Bestellseite zurück.

Eine API ist die Dienstschnittstelle für Programme. In Workstation fragt curl die API ab; -f behandelt Serverfehler als Fehlschläge, -s blendet Fortschritt aus und -S zeigt Fehler trotzdem an. 127.0.0.1 bezeichnet diesen Host, 8080 den Dienstport.

curl -fsS http://127.0.0.1:8080/api/orders

Das Ergebnis ist ein JSON-Array, eine Zeilenliste in eckigen Klammern. Nur Minas Zeile ist vorhanden. Eine erfolgreiche Anfrage beweist keine vollständigen Geschäftsdaten.

Wechsle zu App Server. pwd zeigt das aktuelle Verzeichnis:

pwd

Erwartet wird /srv/order-service. SQLite speichert die Tabellen in orders.db. Der vorbereitete Dienst hat keine Schreiber und öffnet die Datenbank für jede Anfrage neu; Kopieren ist hier sicher. Eine aktive Produktionsdatenbank benötigt ein mit der Anwendung konsistentes Sicherungsverfahren.

cp erwartet erst Quelle, dann Ziel. Bewahre die aktuelle Datenbank außerhalb des Anwendungsverzeichnisses auf, damit eine falsche Wiederherstellung rückgängig werden kann:

cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db

Keine Ausgabe bedeutet normalerweise eine abgeschlossene Kopie. Wiederhole den Befehl nach der Wiederherstellung nicht: Sonst überschreibt die wiederhergestellte Datenbank deine Rückfallkopie. Der beschädigte Zustand ist bewahrt; der Dienst benötigt weiterhin Wiederherstellung.

Ein vertrauenswürdiges Wiederherstellungsarchiv wählen

In diesem Schritt verwirfst du veränderte Sicherungsbytes und legst das geeignete geprüfte Archiv im Vorbereitungsverzeichnis ab.

Wechsle zu Workstation. cd wechselt Verzeichnisse, ls listet deren Inhalt. Ein absoluter Pfad beginnt mit / und funktioniert unabhängig vom aktuellen Verzeichnis.

cd /home/labex/project/recovery/backups

ls

Es gibt drei .tar.gz-Archive: tar bündelt Dateien, gzip komprimiert sie. Die Namen beschreiben Sicherungszeiten; die neueste Datei ist nicht automatisch sicher oder geeignet.

cat zeigt eine Textdatei an. Lies die getrennt vom Sicherungsverwalter gelieferten Wiederherstellungspunkte:

cat /opt/backup-custodian/recovery-points.txt

Das Archiv 0800 liegt vor den Bestellungen 4102 und 4103. 0900 enthält den erforderlichen Stand. 1000 ist später, benötigt aber weiterhin eine Integritätsprüfung.

Integrität bedeutet unveränderte Bytes gegenüber einer Referenz. SHA-256 erzeugt dafür einen Digest. Das Manifest des Verwalters gehört root und liegt außerhalb deines gewöhnlich bearbeitbaren Wiederherstellungsordners. Das Szenario setzt einen unabhängig geschützten Lieferkanal voraus; Signaturen und Schlüsselverteilung werden nicht gelehrt. Administratorrechte können lokale Eigentumsgrenzen überwinden: Der Lehrhost ist kein manipulationssicherer Vertrauensanker.

sha256sum -c liest Dateinamen/Digest-Paare und vergleicht die Dateien im aktuellen Verzeichnis. Nutze das unabhängige Manifest:

sha256sum -c /opt/backup-custodian/SHA256SUMS

0800 und 0900 sollten OK melden, 1000 FAILED. Der Fehlerstatus und die Warnung sind beabsichtigt: Mindestens ein Archiv wurde verändert. Entpacke diesen Kandidaten nicht.

Das benachbarte Manifest lässt sich zusammen mit den Sicherungen verändern. Vergleiche dessen Ergebnis:

sha256sum -c SHA256SUMS

Alle drei melden OK. Wer ein Archiv ändert, kann auch die danebenliegende Prüfsumme ersetzen. Eine Übereinstimmung mit einem unzuverlässigen Digest beweist keine Echtheit. 0800 ist unverändert, aber unvollständig. Wähle 0900, weil es unverändert und geeignet ist.

Das Vorbereitungsverzeichnis ermöglicht Prüfung vor Eingriffen am laufenden Dienst. mkdir -p erstellt es und akzeptiert ein bereits vorhandenes Verzeichnis:

mkdir -p /home/labex/project/recovery/stage

Kopiere den geprüften Kandidaten dorthin:

cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz

Bei einem Tippfehler in der Quelle meldet cp eine fehlende Datei; prüfe mit ls und versuche es erneut. Die Prüfung bewertet die tatsächlichen Archivbytes, keine schriftliche Behauptung der Verifikation.

Die vorbereitete Datenbank prüfen

In diesem Schritt prüfst du Archivmitglieder, entpackst die einzige erwartete Datei und liest die vorbereitete Datenbank ohne Änderungen.

Wechsle in Workstation ins Vorbereitungsverzeichnis:

cd /home/labex/project/recovery/stage

tar -tvzf listet ein gzip-Archiv: t bedeutet Auflisten, v zeigt Typ und Rechte, z steht für gzip und f benennt das Archiv. Auflisten entpackt nichts.

tar -tvzf orders-0900.tar.gz

Das einzige Mitglied sollte orders.db sein; das Rechtefeld beginnt mit - für eine reguläre Datei. Halte bei absoluten Pfaden, ..-Bestandteilen, Links oder unerwarteten Dateien an. Die Namensprüfung hilft hier, weil dieses vertrauenswürdige Lehrarchiv eine reguläre Datei enthält; sie ist keine vollständige sichere Entpackrichtlinie für beliebige Archive. Führe niemals Programme aus verdächtigen Sicherungen aus.

Verwende zum Entpacken x statt t und lasse v weg. Das abschließende orders.db begrenzt das Entpacken auf dieses Mitglied; --no-same-owner behält deinen eigenen Eigentümer bei:

tar -xzf orders-0900.tar.gz --no-same-owner orders.db

SQLite speichert zusammengehörige Tabellen in einer Datei. Das vorbereitete Werkzeug db-view öffnet schreibgeschützt, prüft Konsistenz und Beziehungen und zeigt verbundene Geschäftszeilen. Du musst weder SQL schreiben noch die Datenbank bearbeiten. Übergib den vorbereiteten Dateipfad:

/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db

Erwartet werden Integrity: ok, Relationships: ok und alle drei Bestellungen. Eine gültige Datenbank kann trotzdem zum falschen Stand gehören; vergleiche auch Kunden, Status und Mengen mit Schritt 1.

Ein falscher Pfad erzeugt einen Fehler statt einer leeren Datenbank. Prüfe pwd und ls und versuche es erneut. Bei abweichenden Daten kehre zum unabhängigen Manifest zurück und wähle vor erneutem Entpacken das richtige Archiv. Die Webseite bleibt beschädigt: Vorbereitung allein stellt die Anwendung nicht wieder her.

Den laufenden Dienst wiederherstellen und testen

In diesem Schritt ersetzt du nur die vorgesehene Datenbank und bestätigst die Wiederherstellung durch echte Anfragen bei erhaltenem öffentlichem Upload.

Wechsle zu App Server. Die Rückfallkopie liegt außerhalb dieses Verzeichnisses, die vorbereitete Datenbank wurde geprüft. Kopiere nur diese Datenbank an den vorgesehenen Anwendungspfad:

cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db

Quelle und Ziel sind unterschiedliche Dateien. Kopiere nicht das gesamte Vorbereitungsverzeichnis über /srv/order-service: Dort liegen unabhängige Uploads, die erhalten bleiben müssen. Ein Neustart des Dienstprozesses ist unnötig, weil diese vorbereitete schreibgeschützte Anwendung die Datenbank nach jeder Anfrage schließt. Andere Anwendungen können dokumentierte Wartung oder Neustarts verlangen.

Frage die Anwendung ab, statt dich auf eine Sicherung oder eine Textdatei restored zu verlassen:

curl -fsS http://127.0.0.1:8080/api/orders

Erwarte 4101, 4102 und 4103 mit richtigen Kunden, Status packed und Mengen 1, 2 und 3. Öffne Order Service und aktualisiere. Die Tabelle sollte dieselben Datensätze zeigen.

Prüfe auch den unabhängigen öffentlichen Upload:

curl -fsS http://127.0.0.1:8080/uploads/catalog.txt

Public catalog: mugs, notebooks, tote bags

Klicke im Browser Public catalog und bestätige denselben Inhalt. Wiederherstellung bedeutet vollständige benötigte Geschäftsdaten und weiterhin funktionierende unabhängige Funktionen.

Bei Database unavailable prüfe die vorbereitete Datenbank erneut und wiederhole die Einzeldateikopie mit korrekten absoluten Pfaden. Für die Rückkehr zum beschädigten Ausgangszustand während der Fehlersuche nutze die bewahrte Kopie:

cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db

Der letzte Befehl macht die Wiederherstellung absichtlich rückgängig. Falls du ihn nutzt, kopiere vor Abschluss erneut die geprüfte vorbereitete Datenbank an den aktiven Pfad. Bewahre die Rückfalldatei für weitere Prüfung auf.

Zusammenfassung

Du hast eine Rückfallkopie bewahrt, Sicherungsbytes mit einem unabhängigen vertrauenswürdigen Manifest verglichen, einen geeigneten Stand gewählt und eine vorbereitete SQLite-Datenbank geprüft. Anschließend hast du den echten Dienst wiederhergestellt und Beziehungen sowie einen unabhängigen Upload geprüft. Neu, unverändert und geeignet sind verschiedene Eigenschaften; sichere Wiederherstellung kombiniert sie richtig.