PrestaShop-Sicherungen und getestete Notfallwiederherstellung

So würden wir vorgehen

Wir würden von Ihrem bestehenden Shop ausgehen: Hosting-Zugriff, Datenbank-Engines, Modulspeicher, Theme und individuellem Code, Bestelldaten, Integrationen, Märkten und dem für die Wiederherstellung verfügbaren Team. Vereinbaren Sie, welchen Datenverlust Sie verkraften können und wie lange Sie den Verkauf unterbrechen dürfen. Wählen Sie dann ein Sicherungsverfahren, dessen Wiederherstellung Sie nachweisen können.

Proben Sie ein neues Sicherungsverfahren auf einer isolierten Staging-Kopie mit derselben relevanten Speicher- und Bereitstellungsstruktur. Behalten Sie das bisherige geprüfte Verfahren bei, bis der Ersatz einen zusammengehörigen Wiederherstellungssatz erstellt und eine Wiederherstellung bestanden hat. Planen Sie die Produktivumstellung, benennen Sie die Person zur Überwachung der ersten geplanten Läufe und halten Sie die bisherige Konfiguration bereit, falls die neue Aufgabe scheitert.

Verlangen Sie unabhängig vom gewählten Verfahren eine unabhängig geschützte Aufbewahrung und eine getestete Wiederherstellung. Eine Hosting-Funktion, ein Modulstatus oder ein erfolgreicher Shell-Exit belegen jeweils nur einen Teil des Prozesses; für die Abnahme zählt ein nutzbarer wiederhergestellter Shop.

Wenn Sie die Routine betreuen lassen möchten, umfasst der PrestaShop Store Care & Maintenance Plan verschlüsselte externe Sicherungen und Wiederherstellungstests.

Dateien und Datenbank gemeinsam sichern

Sie benötigen sowohl die Datenbank als auch die Shop-Dateien einschließlich geheimer Konfigurationsdaten und Kundendaten. Planen Sie Sicherungen danach, wie viele Änderungen Sie verlieren dürfen, und erstellen Sie vor Core-/Modul-/Theme-Updates, Importen, Migrationen und Serveränderungen einen separaten Wiederherstellungspunkt.

Prüfen Sie modulspezifische Ablagen und externen Objektspeicher. Modul-Uploads sind nicht grundsätzlich entbehrlich. Eine Datenbank ohne passenden Upload, Download oder kryptografischen Schlüssel kann für die betreffende Funktion unbrauchbar sein.

Schließen Sie nur Daten aus, die Sie nachweislich neu erzeugen können. Cache, Build-Abhängigkeiten und Sitzungen können in Ihrem Wiederherstellungsplan entbehrlich sein. Bewahren Sie Vendor-Pakete auf, wenn sich die genauen Versionen und eigenen Änderungen nicht aus vertrauenswürdigen Artefakten reproduzieren lassen. Protokolle können für die Untersuchung von Vorfällen wichtig sein, auch wenn Sie sie separat vom Wiederherstellungsarchiv aufbewahren. Löschen Sie keine Geschäftsdaten allein zur Verkleinerung einer Sicherung.

Stimmen Sie Datenbank- und Dateisicherung aufeinander ab. Halten Sie für einen exakt abgegrenzten Wiederherstellungspunkt alle schreibenden Prozesse an oder verwenden Sie eine getestete Snapshot-Strategie für Datenbank und Dateisystem. Eine Wartungsseite allein stoppt weder Cron noch Warteschlangen, Importe oder eingehende Integrationen. Dokumentieren Sie die genauen Namen der Datenbank- und Dateiarchive in einem Wiederherstellungsmanifest, zusammen mit den Erfassungsgrenzen, der Shopidentität, Softwareversionen und ausgeschlossenem Speicher. Damit lässt sich ein zusammengehöriger Satz von unabhängigen Archiven mit ähnlichen Datumsangaben unterscheiden.

Eine Methode für den Datenbankexport wählen

Erfassen Sie zunächst die Speicher-Engines und ersetzen Sie den Datenbanknamen:

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'prestashop'
  AND TABLE_TYPE = 'BASE TABLE';

--single-transaction liefert einen konsistenten Snapshot für transaktionale Tabellen wie InnoDB. MyISAM- und MEMORY-Tabellen können sich während dieses Dumps weiter ändern. Stoppen Sie Schreibzugriffe oder wählen Sie für diese Tabellen eine geeignete Sperr- oder physische Sicherungsmethode. Vermeiden Sie während des Dumps gleichzeitige ALTER-, CREATE-, DROP-, RENAME- oder TRUNCATE-Vorgänge. Siehe die MySQL-Snapshotbeschränkungen.

--quick überträgt Zeilen fortlaufend. --skip-lock-tables macht nichttransaktionale Tabellen nicht konsistent. Trigger sind normalerweise standardmäßig enthalten; fordern Sie Routinen und Events ausdrücklich an, wenn sie in die Sicherung gehören. Das Konto benötigt die für Ihre Server-/Clientversion und Objekte erforderlichen Rechte. Prüfen Sie gegebenenfalls einen kompatiblen MariaDB-Client separat. Siehe die MySQL-Exportoptionen für gespeicherte Programme.

Verwenden Sie bei Hosting ohne SSH einen getesteten Export über das Hosting-Panel oder phpMyAdmin. Prüfen Sie gewählte Tabellen, Exportoptionen und Server-/PHP-Grenzen. Es gibt keine allgemeine Exportgrenze von 100 MB. Testen Sie das heruntergeladene Archiv durch Wiederherstellung an anderer Stelle.

PrestaShops Werkzeug Erweiterte Einstellungen > Datenbanksicherung kann Ihren Ablauf ergänzen, exportiert aber Datenbanktabellen statt des gesamten Shops. Setzen Sie die Erfassung gespeicherter Programme nicht voraus. Laden Sie das Ergebnis herunter und nehmen Sie es in die Aufbewahrung außerhalb des Servers auf; eine Ablage allein auf demselben Server überlebt dessen Verlust nicht.

Einen geprüften und verschlüsselten Dump automatisieren

Dieses Linux/Bash-Beispiel gilt für die oben genannten Bedingungen eines transaktionalen Dumps. Es benötigt MySQL-Clientwerkzeuge, gzip, GnuPG 2.1 oder neuer mit durch gpg-agent erlaubtem Loopback-Pinentry, rsync, flock und Python 3. Bereiten Sie ein eigenes Sicherungsverzeichnis außerhalb des Webroots und ein SSH-Konto auf einem anderen Server vor, dessen Zielverzeichnis bereits angelegt ist. Testen Sie vor der Zeitplanung die Kontoberechtigungen und den SSH-Hostschlüssel. Stellen Sie sicher, dass das Sicherungskonto ein beschreibbares GnuPG-Home besitzt und das Geheimnis ohne interaktive Eingabe abrufen kann.

Speichern Sie Datenbankzugangsdaten in einer geschützten Optionsdatei, die nur das Sicherungskonto lesen kann, zum Beispiel /home/backup/.my.cnf:

[client]
user=your_backup_user
password=your_database_password
host=localhost

Setzen Sie ihren Modus auf 600. Stellen Sie das Verschlüsselungsgeheimnis über Ihren geschützten Geheimnismechanismus als lesbaren Deskriptor oder Datei für den Sicherungsauftrag bereit. Bewahren Sie eine wiederherstellbare Kopie in einem separaten Passwortmanager oder Geheimnisspeicher auf. Schreiben Sie keine Passphrase in die Befehlszeile oder das Skript.

Das Skript legt die Ausgabe zunächst temporär ab, prüft die gesamte Pipeline, entschlüsselt zur Prüfung der gzip-Integrität, kontrolliert Archivkopien und die Übertragung auf den anderen Server und veröffentlicht dann lokal und rotiert. Es behält höchstens sieben Archive erfolgreicher täglicher Läufe, vier Archive von Sonntagsläufen und zwölf Archive von Läufen am Monatsersten. Dies sind Kopienzahlen, keine garantierte Abdeckung von Kalendertagen; zusätzliche manuelle Läufe und ausgefallene Aufträge beeinflussen die Abdeckung.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

DB_NAME='prestashop'
BACKUP_DIR='/srv/backups/prestashop/database'
DEFAULTS_FILE='/home/backup/.my.cnf'
SECRET_FILE='/run/secrets/prestashop-backup-passphrase'
REMOTE='backupuser@backup-host:/srv/backups/prestashop/database/'

mkdir -p "$BACKUP_DIR"/{daily,weekly,monthly}
exec 9>"$BACKUP_DIR/.lock"
flock -n 9 || { echo 'Another backup is running' >&2; exit 1; }
work=$(mktemp -d "$BACKUP_DIR/.run.XXXXXX")
trap 'rm -rf -- "$work"' EXIT
trap 'echo "Backup failed: inspect the job log" >&2' ERR
stamp=$(date -u +%Y%m%dT%H%M%SZ)
name="db_${stamp}.sql.gz.gpg"
mkdir "$work/daily"

mysqldump --defaults-extra-file="$DEFAULTS_FILE" \
  --single-transaction --quick --skip-lock-tables \
  --routines --triggers --events "$DB_NAME" \
  | gzip \
  | gpg --batch --yes --pinentry-mode loopback \
      --passphrase-fd 3 --symmetric --cipher-algo AES256 \
      3<"$SECRET_FILE" >"$work/daily/$name"

test -s "$work/daily/$name"
gpg --batch --pinentry-mode loopback --passphrase-fd 3 \
  --decrypt "$work/daily/$name" 3<"$SECRET_FILE" | gzip -t

if [ "$(date -u +%u)" = 7 ]; then
  mkdir "$work/weekly"
  cp -- "$work/daily/$name" "$work/weekly/$name"
fi
if [ "$(date -u +%d)" = 01 ]; then
  mkdir "$work/monthly"
  cp -- "$work/daily/$name" "$work/monthly/$name"
fi

# The remote root and account must already be prepared and tested.
rsync -a --checksum --delay-updates "$work/" "$REMOTE"

# Publish locally only after all staged copies and transfer succeeded.
for tier in daily weekly monthly; do
  if [ -d "$work/$tier" ]; then
    mv -- "$work/$tier/$name" "$BACKUP_DIR/$tier/$name"
  fi
done

# Count retention, not an age approximation. Remote retention is separate.
python3 - "$BACKUP_DIR" <<'ROTATE'
from pathlib import Path
import sys
root = Path(sys.argv[1])
for tier, keep in [('daily', 7), ('weekly', 4), ('monthly', 12)]:
    archives = sorted((root / tier).glob('db_*.sql.gz.gpg'), reverse=True)
    for archive in archives[keep:]:
        archive.unlink()
ROTATE
printf 'Backup completed: %s\n' "$name"

Passen Sie vor Verwendung sämtliche Pfade, Kontoeinstellungen und den Datenbanknamen an. Der GnuPG-Deskriptormechanismus verwendet --pinentry-mode loopback für unbeaufsichtigte Passphrasennutzung; siehe das GnuPG-Handbuch. Lokale temporäre Ausgaben werden beim Skriptende entfernt. Bash pipefail verhindert, dass ein erfolgreicher letzter Pipelinebefehl einen fehlgeschlagenen Dump verdeckt.

Ein Entschlüsselungs-/gzip-Test belegt die Integrität des Transportformats, nicht das Vorhandensein jedes benötigten SQL-Objekts oder jeder Datei. Führen Sie auch Wiederherstellungstests durch. Konfigurieren Sie den Scheduler so, dass er bei einem Exit-Code ungleich null und bei fehlenden erfolgreichen Läufen alarmiert; das Beispiel schreibt Fehler nach stderr, implementiert aber keinen E-Mail-Zustelldienst. Verhindern Sie, dass Geheimnisse in Protokollen landen und überwachen Sie freien Speicher.

Beispiel für einen täglichen Zeitplan in der Serverzeitzone. UTC in Dateinamen ändert die Planungszeitzone von Cron nicht:

0 3 * * * /home/backup/bin/backup-db.sh >> /home/backup/log/backup-db.log 2>&1

Erstellen Sie zuerst das Protokollverzeichnis und testen Sie den Auftrag unter seinem tatsächlichen Konto. Bewahren Sie Sicherungen vor Änderungen nach einer separaten Regelung auf, damit die normale Rotation benötigte Wiederherstellungspunkte nicht entfernt. Verwalten Sie die Aufbewahrung auf dem anderen Server unabhängig; dieses Skript löscht dort keine Historie.

Konsistente Dateiarchive und Spiegel erstellen

Schreiben Sie Archive außerhalb des Shop-Verzeichnisbaums, damit das Archiv nicht in sich selbst gesichert wird. Der folgende Befehl verwendet Eintragsnamen relativ zum Shop-Hauptverzeichnis und speichert symbolische Links als Links. Nehmen Sie dauerhaft gespeicherte Linkziele außerhalb dieses Verzeichnisbaums in den abgestimmten Wiederherstellungssatz auf und dokumentieren Sie sie im Bereitstellungsinventar:

tar -czf /srv/backups/prestashop/files.tar.gz   --exclude='./var/cache' --exclude='./var/sessions'   --exclude='./node_modules'   -C /var/www/html .

Für ein Archiv kritischer Dateien eines modernen Shops kann diese Ausgangsliste dienen. Prüfen Sie jedes aufgeführte Verzeichnis, ergänzen Sie weitere dauerhafte Moduldaten und passen Sie die Webserverkonfiguration an Ihre Installation an:

tar -czf /srv/backups/prestashop/critical.tar.gz   -C /var/www/html   modules themes img download upload override mails translations   config app/config .htaccess

Dies ersetzt kein vollständiges Bereitstellungsinventar. Fehlt ein erwarteter Archiveintrag oder ändert sich eine Datei während der Erfassung, muss das untersucht werden, statt den Exitstatus von tar zu ignorieren. Verschlüsseln Sie Dateiarchive mit personenbezogenen Daten oder Geheimnissen und übertragen Sie sie nach demselben geprüften Verfahren wie Datenbanksicherungen. Die Beispieldateinamen beschreiben eine einzelne Erfassung: Geben Sie aufbewahrten Dateiarchiven eindeutige Namen für den jeweiligen Wiederherstellungspunkt und ergänzen Sie das Manifest. Wenn Sie files.tar.gz wiederverwenden, ohne frühere Versionen aufzubewahren, können Sie den einzigen zu einem älteren Datenbankdump passenden Dateisatz überschreiben.

rsync ist hilfreich, wenn viele Dateien unverändert sind; es gibt keine allgemeine Verzeichnisgrößenschwelle für einen Methodenwechsel. Beginnen Sie mit einem Probelauf und einer validierten Quelle:

rsync -an --delete /var/www/html/ backupuser@backup-host:/srv/mirror/prestashop/

Prüfen Sie Änderungen, bevor Sie die entsprechende echte Übertragung ausführen. --delete lässt einen Spiegel den Löschungen der Quelle folgen. Ein lesbarer, aber unerwartet leerer Mount oder eine gültige, aber falsche Quelle kann daher nützliche Zieldaten entfernen. Eine nicht vorhandene Quellangabe führt normalerweise zu einem Fehler, und erkannte E/A-Fehler unterdrücken normalerweise Löschungen; dies sind unterschiedliche Fälle. Validieren Sie das eingehängte Dateisystem und die erwarteten Shop-Dateien und bewahren Sie versionierte Snapshots außerhalb des Spiegels auf. Siehe das rsync-Handbuch.

Schließen Sie Modul-Uploads nicht allein aus, weil der Verzeichnisname Laufzeitdaten vermuten lässt. Schützen Sie die Historie sowohl vor versehentlichen Quelländerungen als auch vor kompromittierten Shop-Zugangsdaten.

Wiederherstellbare Historie außerhalb des Servers aufbewahren

Eine lokale Sicherung kann bei einem lokalen Fehler helfen, aber eine Kopie auf demselben Rechner teilt Risiken mit dem Shop. Halten Sie eine wiederherstellbare Kopie außerhalb dieses Ausfallbereichs vor. Ein 3-2-1-Plan bedeutet drei Kopien, zwei Speichertypen und mindestens eine Kopie an einem anderen Standort. Ergänzen Sie bei passenden Wiederherstellungsrisiken eine Offline-Kopie oder geschützte historische Kopie.

Objektspeicher, ein anderer Server und verwaltete Sicherungsdienste sind mögliche Optionen. Vergleichen Sie Zugriffskontrollen, Versionierung, Löschschutz, Wiederherstellungsgeschwindigkeit, Region sowie Betriebs-, Abruf- und Datentransferkosten. Gehen Sie nicht davon aus, dass ein Anbieter immer günstiger ist. Verwenden Sie begrenzte Zugangsdaten und stellen Sie sicher, dass der Shop nicht alle aufbewahrten Wiederherstellungspunkte löschen kann.

Legen Sie die Aufbewahrung nach Ihrem Erkennungszeitraum für Vorfälle und Speicherbudget fest. Mengenbasierte und altersbasierte Regeln sind verschieden. Zum Beispiel bedeutet find -mtime +7 weder genau sieben Kopien noch genau sieben Tage; GNU find verwendet abgeschlossene 24-Stunden-Altersabschnitte. Halten Sie bei Bedarf tägliche, wöchentliche und monatliche Ebenen vor und prüfen Sie die tatsächliche Abdeckung.

Fragen Sie Ihren Hoster nach enthaltenem Umfang, Konsistenzmethode, Häufigkeit, Aufbewahrung, Standort, Verschlüsselung, Wiederherstellungsgranularität, Gebühren und Reaktionszeit. Verlangen Sie eine Testwiederherstellung. Dokumentieren Sie die Zusagen des Anbieters und die Ergebnisse einer Testwiederherstellung.

Dokumentieren Sie den Zugriff auf externen Speicher und Entschlüsselungsschlüssel so, dass Sie ihn bei nicht verfügbarer Produktion erreichen. Eine geschützte Sicherung mit verlorenem Schlüssel erfüllt Ihr Wiederherstellungsziel nicht.

Versteckte Wiederherstellungslücken trotz Erfolgsmeldungen untersuchen

Dokumentieren Sie die letzte erfolgreiche Erfassung, geprüfte Übertragung und Anwendungswiederherstellung getrennt. Ein kürzlich hochgeladenes Archiv kann trotzdem eine ältere Erfassung enthalten. Nutzen Sie deshalb das Wiederherstellungsmanifest, um das Alter der tatsächlich wiederherstellbaren Daten zu beurteilen.

Isoliert wiederherstellen und Vollständigkeit prüfen

1. Erstellen Sie eine isolierte Staging-Umgebung mit kompatiblen PrestaShop-, PHP- und Datenbankversionen. Bewahren Sie die ursprüngliche Sicherung auf.
2. Deaktivieren Sie vor dem SQL-Import den Datenbank-Event-Scheduler in der isolierten Testumgebung. Blockieren Sie ausgehende E-Mails, Zahlungseinzug, Webhooks, geplante Auftragsabwicklung und andere produktive Nebenwirkungen, bevor Sie die wiederhergestellte Anwendung oder ihre Aufgaben starten. Beschränken Sie Zugriff und Indexierung und verwenden Sie Sandbox-Zugangsdaten für Kassentests.
3. Entschlüsseln Sie das Datenbankarchiv und importieren Sie es mit einem Testkonto in eine neue leere Testdatenbank. Beginnen Sie einen Test niemals mit dem Löschen der Produktivdatenbank.
4. Prüfen und entpacken Sie das passende Dateiarchiv in ein leeres Staging-Root. Setzen Sie Eigentümer und Rechte korrekt und konfigurieren Sie Staging-Datenbankzugang und Shop-URLs unter Erhalt erforderlicher kryptografischer Schlüssel.
5. Leeren Sie Anwendungscaches über unterstützte Funktionen und testen Sie anschließend Frontoffice, Backoffice, Produkt-/Variantenseiten, Downloads, Kundenanpassungen, Warenkorb und einen Sandbox-Checkout.
6. Vergleichen Sie den gesicherten Bestand: Tabellen- und Objektzahlen, Zeilenzahlen wichtiger Geschäftstabellen, neueste Bestellungen, dauerhafte Dateien, Module und Konfiguration. Anzahlen allein belegen keine korrekte Anwendungsfunktion.
7. Dokumentieren Sie die verstrichene Wiederherstellungszeit, fehlende Voraussetzungen und den genau wiederhergestellten Zeitpunkt.

Führen Sie Entschlüsselung und Import mit Prüfung auf Pipelinefehler aus. Dieses Beispiel setzt voraus, dass die Optionsdatei an der bereits vorhandenen isolierten Testdatenbank authentifiziert:

set -o pipefail
gpg --batch --pinentry-mode loopback --passphrase-fd 3   --decrypt /srv/restore/db.sql.gz.gpg   3</run/secrets/prestashop-backup-passphrase   | gzip -dc   | mysql --defaults-extra-file=/home/backup/.my.cnf prestashop_test

Beispielabfragen mit dem tatsächlichen Tabellenpräfix:

SELECT COUNT(*) AS products FROM ps_product;
SELECT COUNT(*) AS orders FROM ps_orders;
SELECT COUNT(*) AS customers FROM ps_customer;
SELECT MAX(date_add) AS latest_order FROM ps_orders;

Erfassen Sie Vergleichsdaten am Wiederherstellungspunkt oder berücksichtigen Sie spätere Änderungen. Eine wachsende Produktivdatenbank stimmt nicht mit einem älteren Snapshot überein. Prüfen Sie Routinen, Events und Trigger, wenn diese benötigt werden. Kontrollieren Sie den wiederhergestellten Event-Scheduler und Anwendungsaufträge, damit ein Test nicht auf Produktivsysteme einwirkt.

Wiederholen Sie Tests nach Änderungen an Sicherungswerkzeugen, Zugangsdaten oder Infrastruktur und in einem geplanten Intervall, etwa als Quartalsübung. Wählen Sie das Intervall nach Ihrem Risiko und dokumentieren Sie das Ergebnis jeder Übung.

Update-Rücknahme vor der Produktivänderung proben

Angenommen, ein Modulupdate ändert Datenbanktabellen und schreibt neue Dateien. Wenn Sie sein Verzeichnis durch das alte Paket ersetzen, kann alter Code auf das neue Schema zugreifen. Ihre Probe muss sowohl nachweisen, wie der vorherige Anwendungszustand wiederhergestellt wird, als auch, ob sich das Update installieren lässt.

1. Wählen Sie auf der isolierten Shopkopie repräsentative Datensätze: eine Bestellung, ein Produkt mit Varianten, gegebenenfalls einen Download oder Kunden-Upload und einen modulspezifischen Datensatz. Dokumentieren Sie das erwartete Ergebnis in jedem relevanten Shop, jeder Sprache und Währung.
2. Erstellen Sie vor der Änderung einen zusammengehörigen Wiederherstellungssatz, führen Sie das Update durch und proben Sie anschließend die dokumentierte Rücknahme in einer separaten Wiederherstellungsumgebung. Prüfen Sie diese Datensätze und Geschäftsfunktionen und bewahren Sie die Nachweise zusammen mit den genauen Modul- und Shopversionen auf.
3. Vereinbaren Sie, welcher Fehler den Start stoppt, wer diese Entscheidung trifft und welcher Wiederherstellungssatz freigegeben ist. Verfehlt die Probe das Wiederherstellungsziel, ändern Sie den Prozess, bevor Sie das Live-Zeitfenster buchen.
4. Erstellen Sie für die Produktivänderung einen neuen abgestimmten Wiederherstellungspunkt, nachdem Schreibzugriffe und laufende Integrationsvorgänge unter Kontrolle sind. Dokumentieren Sie angenommene Bestellungen und externe Ereignisse, deren Verarbeitung noch aussteht, statt sich auf die ältere Staging-Sicherung zu verlassen.
5. Bestätigen Sie vor der Wiederöffnung die vereinbarten Tests und legen Sie die Verantwortung für die Wiederaufnahme jeder pausierten Aufgabe oder Integration fest. Sobald neue Transaktionen angenommen werden, bewerten Sie die Rücknahme unter Berücksichtigung dieser Transaktionen neu, bevor Sie Live-Daten ersetzen.

Eine technisch erfolgreiche Rücknahme klärt nicht, was außerhalb des Shops geschehen ist. Beziehen Sie Zahlungsanbieter, Lager, ERP und andere Systeme, die während des Änderungsfensters Ereignisse annehmen oder darauf reagieren können, in den Abgleichplan ein.

Für jeden Vorfall ein Wiederherstellungshandbuch nutzen

Server- oder Shop-Ausfall

Ermitteln Sie vor dem Ersetzen von Daten, ob die Ursache bei Server, Datenbank, Netzwerk, DNS oder Proxy liegt. Kontaktieren Sie den Hoster, klären Sie den Umfang und stellen Sie bei Bedarf eine kompatible Wiederherstellungsumgebung bereit. Stellen Sie zusammengehörige Dateien und Datenbank wieder her, prüfen Sie URLs, DNS, TLS und Rechte und testen Sie Bestellungen und Transaktionskommunikation vor der Wiederöffnung.

Datenbankbeschädigung

Stoppen Sie alle relevanten Schreibzugriffe und sichern Sie Protokolle, Daten und verfügbare Snapshots für die Diagnose. Ermitteln Sie die betroffenen Engines. mysqlcheck --auto-repair ist kein InnoDB-Wiederherstellungswerkzeug: REPAIR TABLE gilt nur für unterstützte Engines, wie die MySQL-Dokumentation erläutert. Wählen Sie eine Engine-spezifische Wiederherstellung oder stellen Sie eine getestete Sicherung in einer neuen Umgebung wieder her. Gleichen Sie nach diesem Wiederherstellungspunkt entstandene Bestellungen und Zahlungen vor der Umschaltung ab.

Kompromittierter Shop

Isolieren Sie den Shop und sichern Sie vor der Bereinigung Beweise. Betrachten Sie die Suche nach verdächtigen PHP-Zeichenfolgen oder aktuellen Änderungsdaten nicht als Beweis, dass alle Hintertüren gefunden wurden. Ermitteln Sie den Einstiegspunkt, stellen Sie einen bekannten vertrauenswürdigen Stand wieder her oder bauen Sie ihn neu auf, korrigieren Sie betroffene Software, wechseln Sie relevante Zugangsdaten und prüfen Sie Konfiguration und externe Integrationen.

Prüfen Sie Mitarbeiteridentitäten, Aktivkennzeichen, Profile und Shop-Rechte anhand eines vertrauenswürdigen Bestands. Das standardmäßige Mitarbeitermodell hat kein Feld date_add; eine Abfrage anhand eines Mitarbeiter-Erstellungszeitstempels schlägt daher fehl. Nutzen Sie tatsächliche Prüfprotokolle für die Chronologie. Prüfen Sie geänderte Konfiguration und Zahlungen und überwachen Sie anschließend entsprechend den Vorfallbefunden.

Gelöschte Moduldateien

Prüfen Sie beim mit -C /var/www/html . erstellten vollständigen Archiv vor der Auswahl eines Eintrags dessen Inhalt:

tar -tzf /srv/backups/prestashop/files.tar.gz
# In an empty staging root, after confirming this exact member:
tar -xzf /srv/backups/prestashop/files.tar.gz   -C /srv/restore/shop ./modules/your_module_name

Das Staging-Zielverzeichnis muss existieren. Prüfen Sie das wiederhergestellte Modul und spielen Sie die benötigten Dateien anschließend über Ihren normalen Wiederherstellungsprozess ein. Wurde es deinstalliert und wurden Tabellen oder Konfiguration entfernt, stellen Dateien allein seine Daten nicht wieder her. Neuinstallation oder Wiederherstellung von Moduldaten benötigt einen kompatiblen Plan; das Zurücksetzen der gesamten Datenbank kann auch neuere Bestellungen entfernen.

Einen fehlerhaften Bestandsimport durchgehen

Ein Import ersetzt korrekte Bestandsmengen, während Kunden weiter bestellen. Die neueste Sicherung stammt aus der Zeit vor dem Import und vor einigen berechtigten Bestellungen. Stoppen Sie zuerst den fehlerhaften Import und bestimmen Sie, welches System für Bestände maßgeblich ist; ein ERP, das sofort dieselbe Datei erneut sendet, kann eine Korrektur wieder aufheben.

Stellen Sie den Satz vor dem Import isoliert wieder her und vergleichen Sie die betroffenen Produkt- und Variantenkennungen, den Bestandskontext und die Importzuordnungen. Bewahren Sie aktuelle Bestellungen und Zahlungsreferenzen als Nachweise auf. Beschränkt sich der Schaden auf identifizierbare Bestandsdatensätze, verlangen Sie eine gezielte Korrektur über den unterstützten Bestandsablauf, erprobt auf einer Kopie des aktuellen Shops und unter Berücksichtigung berechtigter Bewegungen seit der Sicherung.

Müssen Sie die gesamte Datenbank wiederherstellen, vereinbaren Sie vor der Umstellung, wie spätere Bestellungen, Zahlungen, Sendungen und Bestandsbewegungen abgeglichen werden. Öffnen Sie den Shop nicht allein deshalb wieder, weil die früheren Bestandszahlen richtig aussehen. Bewahren Sie Importquelle, betroffene Kennungen und Korrekturergebnisse auf, damit derselbe Feed vor dem nächsten Lauf geprüft werden kann.

RPO, RTO und zeitpunktgenaue Wiederherstellung festlegen

RPO ist das akzeptable Datenverlustfenster. RTO ist die Zielzeit bis zur Wiederherstellung des Dienstes. Bei einem täglichen Zeitplan kann fast ein Tag an Änderungen außerhalb der letzten erfolgreichen Sicherung liegen; fehlgeschlagene Aufträge vergrößern die Lücke. Setzen Sie Ziele nach Geschäftsauswirkungen und gemessener Wiederherstellungsleistung, nicht nach einer allgemeinen Bestellzahlregel.

Ein kurzes RTO lässt sich je nach Shop durch schnelle Wiederherstellung, ein Bereitschaftssystem oder eine andere Architektur erreichen. Messen Sie Bereitstellung, Übertragung, Entschlüsselung, Import, Prüfung, DNS und Wiederöffnung. Ein Bereitschaftssystem garantiert allein weder Umschaltzeit noch Schutz vor replizierter Beschädigung.

Für eine zeitpunktgenaue MySQL-Wiederherstellung:

1. Aktivieren und speichern Sie die passenden Binärlogs und prüfen Sie, dass Ihre Serverkonfiguration die erforderlichen Änderungen tatsächlich aufzeichnet.
2. Erfassen Sie die genauen Binlog-Koordinaten der Sicherung oder unterstützte GTID-Metadaten mit den dokumentierten Sicherungsoptionen der betreffenden Server-/Clientversion.
3. Bewahren Sie jedes erforderliche Log ab dieser Snapshot-Grenze außerhalb des Servers auf. Überwachen Sie Wachstum, Lücken und Aufbewahrung.
4. Stellen Sie den Snapshot isoliert wieder her.
5. Prüfen Sie die Logs auf die Transaktionsgrenze vor der unerwünschten Änderung und spielen Sie sie anschließend ab der genau gespeicherten Snapshot-Grenze bis zur gewählten Transaktionsgrenze ein.
6. Validieren Sie den entstandenen Anwendungszustand und gleichen Sie externe Bestellungen und Zahlungen vor der Produktivschaltung ab.

Die geplante Startzeit, etwa 03:00, ist nicht die genaue Log-Grenze des Snapshots. Eine Wiedergabe ab dieser Uhrzeit kann bereits im Dump enthaltene Transaktionen wiederholen. Siehe MySQLs Wiederherstellungsverfahren anhand von Ereignispositionen. Dimensionieren Sie den Logspeicher anhand gemessener Last und Aufbewahrungsbedarf und überwachen Sie ihn auf Lücken.

Die Wiederherstellungsroutine pflegen

• Bei jedem geplanten Lauf: Erfolg, aktuelle Artefakte, Integritätsprüfungen, externe Übertragung und brauchbares Alter des Wiederherstellungspunkts prüfen.
• Regelmäßig: Kapazität, Aufbewahrungsabdeckung, geschützte Historie, Rechte und Wiederherstellbarkeit der Schlüssel prüfen. Bestätigen Sie, dass Dateisicherungen so aktuell sind, wie es Ihr RPO verlangt.
• Nach wichtigen Änderungen: Eine separate abgestimmte Sicherung erstellen und aufbewahren und prüfen, ob der Sicherungsauftrag mit neuen Zugangsdaten oder neuer Bereitstellung weiter funktioniert.
• Im gewählten Übungsintervall: Den gesamten Shop isoliert wiederherstellen, Geschäftsfunktionen testen und gemessene RTO/RPO dokumentieren.
• Nach einem Vorfall oder einer fehlgeschlagenen Übung: Handbuch aktualisieren, Ablauf korrigieren und den relevanten Test wiederholen.

Bewahren Sie Handbuch sowie Kontakt- und Zugriffsanweisungen außerhalb des Produktivservers auf. Halten Sie fest, wer die Wiederöffnung genehmigen darf, wo Wiederherstellungsartefakte und Geheimnisse liegen und wie Änderungen nach dem wiederhergestellten Snapshot abgeglichen werden.

Zu den unterstützenden Umgebungen siehe den Staging-Leitfaden und den Sicherheitsleitfaden.

Eine brauchbare Wiederherstellungsübergabe verlangen

Verlangen Sie Unterlagen zur Wiederherstellung, die eine andere autorisierte Person nutzen kann, wenn der übliche Entwickler oder die Agentur nicht verfügbar ist. Lassen Sie diese Person die Anleitung bei einer Übung befolgen und korrigieren Sie jeden Schritt, der undokumentiertes Wissen voraussetzt.

• Welchen Shop und welche Daten deckt der Plan ab? Verlangen Sie das Bereitstellungsinventar, Tabellenpräfix, den Multishop-Umfang, dauerhaften Modulspeicher und Ausschlüsse sowie ein Wiederherstellungsmanifest aus einem abgeschlossenen Lauf.
• In welcher Umgebung kann der wiederhergestellte Shop laufen? Bewahren Sie die erforderlichen PrestaShop-, PHP-, Datenbank- und Modulversionen, Bereitstellungsartefakte und Anweisungen zum Einrichten der Ersatzumgebung auf.
• Wie rufen wir Daten ohne Produktivzugriff ab und entschlüsseln sie? Dokumentieren Sie Speicherorte, Kontozuständigkeiten, Verweise auf Geheimnisspeicher und Anweisungen zur Kontowiederherstellung. Halten Sie den Zugriff kontrolliert und benennen Sie eine autorisierte Vertretung; die Betriebsanleitung sollte auf Geheimnisse verweisen, statt Klartextpasswörter zu enthalten.
• Wer bemerkt eine ausgebliebene Sicherung und wer handelt? Benennen Sie Haupt- und Ersatzkontakte, Eskalationsweg und die benötigten Zugriffe und belegen Sie, dass Fehlermeldungen sie erreichen.
• Welche Wiederherstellung wurde tatsächlich erfolgreich getestet? Verlangen Sie den getesteten Wiederherstellungspunkt, wiederhergestellte Geschäftsfunktionen, gemessene Zeiten und offene Lücken, einschließlich möglicher Abhängigkeiten vom Anbietersupport.
• Wer steuert externe Auswirkungen und die Wiederöffnung? Listen Sie die Schalter für E-Mails, Zahlungsbenachrichtigungen, geplante Aufgaben und Exporte zur Auftragsabwicklung auf, das für jeden Geschäftsdatensatz maßgebliche System sowie die Personen, die Abgleich und Produktivumstellung freigeben.
• Was passiert bei einem Anbieterwechsel? Bestätigen Sie, wie Sie aufbewahrte Sätze exportieren, die Entschlüsselungsmittel behalten und die Verantwortung für die Wiederherstellung übertragen, bevor Konten oder Zugriffe geschlossen werden.

Häufige Fragen von Shopbetreibern

Kann ich nur einen Shop einer Multishop-Installation wiederherstellen?

Vereinbaren Sie den Umfang vor der Wiederherstellung. Shops können Tabellen, Kunden, Katalogdatensätze und Dateien gemeinsam nutzen. Daher kann die Wiederherstellung ausgewählter Tabellen anhand ihres Namens andere Shops beeinflussen oder Beziehungen beschädigen. Proben Sie den vorgeschlagenen Umfang anhand der vollständigen Installation.

Kann eine anonymisierte Staging-Kopie unsere Notfallsicherung sein?

Eine anonymisierte Kopie kann entfernte oder geänderte Kundendetails und Bestelldaten nicht wiederherstellen. Bewahren Sie den geschützten ursprünglichen Wiederherstellungssatz auf und erstellen Sie daraus bei Bedarf bereinigte Entwicklungskopien.

Erstattet die Wiederherstellung einer Bestelldatenbank eine eingezogene Zahlung?

Nein. Eine vom Anbieter bereits angenommene Zahlung muss weiterhin abgeglichen werden, selbst wenn ihre lokale Bestellung verschwindet. Prüfen Sie die Anbieterreferenz, bevor Sie einen Einzug wiederholen, eine Erstattung auslösen oder eine Bestellung neu erstellen.

Können wir PrestaShop während der Behebung eines Ausfalls aktualisieren?

Stellen Sie nach Möglichkeit zuerst die gesicherte Version in ihrer kompatiblen Umgebung wieder her. Die Kombination aus Wiederherstellung und ungetestetem Core-, Theme- oder Modulupgrade fügt eine weitere mögliche Fehlerursache hinzu; prüfen Sie ein erforderliches Upgrade vor der Produktivumstellung separat.

Können wir alte Verschlüsselungsschlüssel nach der Rotation löschen?

Erhalten Sie die Möglichkeit, jeden aufbewahrten Wiederherstellungspunkt zu entschlüsseln. Bestätigen Sie vor der Außerbetriebnahme eines Schlüssels, welche Archive ihn verwenden, und proben Sie deren Wiederherstellung mit der Ersatzlösung; ein Schlüsselwechsel für künftige Aufgaben verändert bestehende verschlüsselte Archive nicht.