MDH GROUP · BLOG

Disaster‑Recovery für self‑hosted Affilentra: Backup, Point‑in‑Time‑Recovery und getestete Restore‑Prozesse

Warum ein Disaster‑Recovery‑Plan für Affilentra unverzichtbar ist Affilentra verbindet Tracking, Provisionsberechnung und Abrechnung auf einer self‑hosted PHP/MySQL‑Plattform. Als Betreiber tragen Sie Verantwortung für Datenintegrität, Auszahlungshistorie und Partner‑Vertrauen. Ein gezielter Disaste

← Alle Beiträge

Disaster‑Recovery für self‑hosted Affilentra: Backup, Point‑in‑Time‑Recovery und getestete Restore‑Prozesse

Warum ein Disaster‑Recovery‑Plan für Affilentra unverzichtbar ist

Affilentra verbindet Tracking, Provisionsberechnung und Abrechnung auf einer self‑hosted PHP/MySQL‑Plattform. Als Betreiber tragen Sie Verantwortung für Datenintegrität, Auszahlungshistorie und Partner‑Vertrauen. Ein gezielter Disaster‑Recovery‑Plan stellt sicher, dass verlorene Daten (Transaktionen, Konfigurationen, Werbemittel) schnell und reproduzierbar wiederhergestellt werden — ohne Überraschungen bei Rollen, Rechten oder Abrechnungen.

Kurzüberblick: Ziele dieses Leitfadens

  • Konsequente Sicherung von Datenbank, Dateisystem und Konfiguration.
  • Einrichtung von Point‑in‑Time‑Recovery (PITR) mit MySQL‑Binlogs.
  • Automatisierung, Verschlüsselung und Aufbewahrungsregeln.
  • Festgelegte, getestete Restore‑Prozesse und regelmäßige Prüfungen.

1. Architektur und Voraussetzungen

Analysieren Sie zuerst Ihre Installation: Wo liegen PHP‑Dateien, Uploads, Cron‑Jobs, Konfigurationsdateien (z. B. config.php) und die MySQL‑Datenbank? Trennen Sie die Rollen: Softwarebetreiber (Infrastruktur/Backups), Händler (Produktverwaltung) und Partner (Trackinglinks) benötigen unterschiedliche Wiederherstellungsziele und Zugriffsrechte.

Empfohlene Voraussetzungen:

  • Root/Administratorzugang zum Server und zur MySQL‑Instanz.
  • Zuverlässiger Exportspeicher (lokal + offsite z. B. Objekt‑Storage oder externes Backup‑System).
  • Verschlüsselungstools (gpg, age) und ein Key‑Management‑Konzept.

2. Backup‑Strategie: Was gehört wohin?

Die drei Säulen sind:

  • Datenbank (MySQL): komplette Dumps plus Binlogs für PITR.
  • Dateisystem: PHP‑Code, Uploads, Medien, Werbemittel.
  • Konfiguration & Cron: config‑Dateien, systemd‑Units, SSL‑Zertifikate.

Datenbank‑Backups

Erstellen Sie regelmäßige konsistente Full‑Backups (z. B. mittels mysqldump --single-transaction für InnoDB‑Tabellen) oder nutzen Sie physische Backups (Percona XtraBackup) für große Installationen. Zusätzlich müssen MySQL‑Binlogs aktiviert sein, damit Sie auf Transaktionsebene rekonstruieren können.

Wichtige MySQL‑Konfiguration (my.cnf):

  • log_bin = mysql-bin
  • server-id = 1 (oder eindeutige ID)
  • binlog_format = ROW (empfohlen für zuverlässige Replikation/PITR)
  • Optional: expire_logs_days oder eigene Rotation via Script

Point‑in‑Time‑Recovery (PITR)

PITR ergänztdie Full‑Backups: sichern Sie kontinuierlich Binlogs und notieren Sie Zeitstempel oder GTIDs bei jedem Full‑Backup. Im Wiederherstellungsfall stellen Sie den letzten Full‑Backup wieder her und spielen dann die Binlogs mit mysqlbinlog --start-datetime / --stop-datetime | mysql ein, bis zum gewünschten Moment vor dem Vorfall.

Dateisystem‑ und Konfigurations‑Backups

Sichern Sie:

  • Quellcodeverzeichnis (PHP‑Files, Libraries).
  • Uploads/Media/Assets (Trackingbilder, Werbemittel).
  • config‑Dateien, SSL‑Zertifikate, Cron‑Skripte und systemd/Unit‑Files.

Erstellen Sie atomare Archive (z. B. tar + gzip) oder nutzen Sie dateibasierte Werkzeuge (rsync) für inkrementelle Backups. Achten Sie auf Dateiberechtigungen und SELinux/ACLs beim Restore.

3. Automatisierung, Speicherung und Verschlüsselung

Automatisierung

Verwenden Sie Cron oder systemd‑Timers für wiederkehrende Jobs:

  • Daily Full DB Dump (nachts, außerhalb von Spitzenzeiten).
  • Kontinuierliches Sammeln und Archiveren der Binlogs (z. B. alle 5–15 Minuten).
  • Tägliche/mehrfache Dateisystem‑Snapshots oder inkrementelle Rsync‑Jobs.

Loggen Sie jede Sicherung mit Zeitstempel, SHA256‑Checksumme und Dateigröße zur Integritätsprüfung.

Aufbewahrungspolitik

Definieren Sie eine Aufbewahrungsrichtlinie passend zu Ihrer Compliance und Recovery‑Zeitziele. Eine Beispielstruktur zur Orientierung:

  • Tägliche Backups: 14 Tage
  • Wöchentliche Backups: 12 Wochen
  • Monatliche Backups: 12 Monate

Lagern Sie Backups mindestens an einem externen Standort (offsite). Objekt‑Storage (S3‑kompatibel) oder ein separater Backup‑Provider reduzieren Risiken von Hardwareausfällen.

Verschlüsselung und Schlüsselmanagement

Verschlüsseln Sie Backups im Ruhezustand mit GPG/age‑Schlüsseln. Trennen Sie Aufbewahrungsorte von Schlüsselmaterial (z. B. Keys in dediziertem HSM oder Passwortmanager mit Zugangskontrolle). Planen Sie Key‑Rotation und dokumentieren Sie Wiederherstellungs‑Zugriffe.

4. Restore‑Prozesse und regelmäßige Tests

Wiederherstellungs‑Checkliste (Basisablauf)

  1. Isolieren Sie die Umgebung, um Datenüberschreibung zu vermeiden.
  2. Stellen Sie das passende Full‑Backup der MySQL‑DB wieder her.
  3. Importieren Sie Binlogs bis zum gewünschten Stop‑Zeitpunkt (PITR).
  4. Stellen Sie das Dateisystem‑Backup zurück (Code & Media).
  5. Prüfen Sie Konfigurationen, Berechtigungen und Secrets.
  6. Führen Sie Integritäts‑ und Funktionstests durch (Tracking, Login, Provisionsberechnung).
  7. Dokumentieren Sie Dauer und Abweichungen; passen Sie die Strategie an.

Regelmäßige Restore‑Tests

Testen Sie mindestens monatlich einen vollständigen Restore in einer isolierten Testumgebung. Üben Sie PITR‑Szenarien mit unterschiedlichen Zeitpunkten (z. B. Fehler kurz vor Abrechnungstag). Validieren Sie insbesondere:

  • Vollständigkeit der Transaktionshistorie und Auszahlungschroniken.
  • Funktionalität von Trackinglinks und Conversion‑Validierung.
  • Rollen‑ und Rechtekonstellation (Softwarebetreiber vs. Händler vs. Partner).

5. Beispiel: Schritt‑für‑Schritt Restore mit PITR

1) Wählen Sie das letzte konsistente Full‑Backup (z. B. full_2026-10-01.sql.gz). 2) Entpacken und importieren Sie es in eine leere MySQL‑Instanz. 3) Bestimmen Sie Start‑/Stop‑Zeitpunkte der Binlogs (z. B. anhand des Vorfallszeitpunkts). 4) Verwenden Sie mysqlbinlog, um die Binlogs in Reihenfolge anzuwenden. 5) Stellen Sie anschliessend Dateisystem‑Archive zurück, korrigieren Sie Pfade und Berechtigungen, und starten Sie Web‑/Cron‑Dienste.

Bei Unklarheiten halten Sie eine Playbook‑Datei mit exakten Befehlen, Usernames und Pfaden bereit — getrennt vom Server und nur für autorisierte Betreiber zugänglich.

6. Governance, Rollen und Verantwortlichkeiten

Definieren Sie klare Aufgaben:

  • Softwarebetreiber: Infrastruktur, Backups, Restore‑Tests.
  • Händler: Plausibilitätsprüfung von Produktdaten und Konditionen nach Restore.
  • Partner: Prüfung von Trackinglinks und Auszahlungshistorie.

Kommunikationsplan: Benennen Sie Ansprechpartner, Eskalationsstufen und Kommunikationskanäle für einen Ausfall.

Fazit und nächster Schritt

Ein zuverlässiger Disaster‑Recovery‑Plan für Ihre self‑hosted Affilentra‑Instanz kombiniert konsistente DB‑Backups, Binlog‑basierte PITR, verschlüsselte Offsite‑Speicherung und regelmäßige Restore‑Tests. Beginnen Sie mit einem einfachen Pilot: setzen Sie Full‑Backups, aktivieren Sie Binlogs, automatisieren Sie die Archivierung und führen Sie den ersten Wiederherstellungs‑Test in einer isolierten Umgebung durch.

Sie möchten direkt loslegen oder benötigen Unterstützung bei der Implementierung? Einstieg wählen: Einstieg wählen

Nächster Schritt

Affilentra selbst ausprobieren

Einheitliche Plattform, die Produktbereitstellung, Tracking, Conversion-Validierung, Provisionsberechnung und Auszahlung entlang klar getrennter Rollen transparent zusammenführt; Option zur self-hosted Installation mit Dauerlizenz ohne Umsatzbeteiligung; Händler behalten Kontrolle über Produkte, Konditionen und Werbemittel; Partner erhalten persönliche Trackinglinks und nachvollziehbare Auszahlungshistorie.

Einstieg wählen