Datensicherungsstrategie

Ransomware traf an einem Freitagabend. Bis Montagmorgen war der Dateiserver verschlüsselt – und die angeschlossene externe Festplatte gleich mit. Die Dropbox-„Sicherung" hatte hilfreich die verschlüsselten Versionen synchronisiert. Das Unternehmen zahlte das Lösegeld. Das Entschlüsselungstool war fehlerhaft. Die Hälfte der Dateien kam ohnehin beschädigt zurück.

Dieses Szenario wiederholt sich immer wieder in kleinen Unternehmen. Backups existierten auf dem Papier, scheiterten aber in der Praxis.

Dieses Kapitel stellt sicher, dass Ihnen das nicht passiert. Sie richten Backups ein, die tatsächlich funktionieren, testen sie, bevor Sie sie brauchen, und erstellen eine Richtlinie, die alles geschützt hält.

Warum Backups versagen, wenn man sie braucht

Die meisten Unternehmen haben irgendeine Form von Backup. Die meisten dieser Backups würden im Ernstfall versagen. Hier ist der Grund:

Nie getestet — Das Backup läuft jede Nacht. Niemand hat je versucht, daraus wiederherzustellen. Wenn Sie es wirklich brauchen, stellen Sie fest, dass die Backups seit sechs Monaten beschädigt sind.

Gleicher Fehlerbereich — Das Backup-Laufwerk ist an den Server angeschlossen. Beide werden von Ransomware verschlüsselt. Das Backup liegt in der gleichen Cloud-Region. Die Region fällt aus, das Backup ist ebenfalls nicht erreichbar.

Unvollständiger Umfang — Server-Dateien werden gesichert. Aber niemand hat an SaaS-Daten, Datenbanken oder Konfigurationsdateien gedacht. Nach der Wiederherstellung funktioniert die Hälfte der Systeme nicht.

Keine Dokumentation — Die Person, die die Backups eingerichtet hat, hat das Unternehmen vor zwei Jahren verlassen. Niemand weiß, wie man wiederherstellt, wie die Passwörter lauten oder wo die Backups tatsächlich liegen.

Zu langsam bei der Wiederherstellung — Sie haben Backups, aber die Wiederherstellung von 5 TB dauert 3 Tage. Das Unternehmen kann 3 Tage Ausfallzeit nicht überstehen.

Ein Backup, das nicht wiederhergestellt werden kann, ist kein Backup. Es ist ein falsches Sicherheitsgefühl.

Die 3-2-1-Backup-Regel

Die 3-2-1-Regel ist seit Jahrzehnten der Standard, weil sie funktioniert:

• 3 Kopien Ihrer Daten (das Original + 2 Backups)
• 2 verschiedene Speichermedientypen
• 1 Kopie außerhalb des Standorts (geografisch getrennt)

Warum jede Zahl wichtig ist

3 Kopien — Redundanz. Wenn ein Backup ausfällt, haben Sie ein weiteres. Laufwerke versagen, Cloud-Dienste haben Ausfälle, Dateien werden beschädigt. Zwei Backups bedeuten, dass Sie jeden einzelnen Ausfall überstehen können.

2 verschiedene Medientypen — Schutz vor Ausfällen mit gemeinsamer Ursache. Wenn alle Ihre Daten auf dem gleichen Laufwerkstyp vom gleichen Hersteller liegen, könnte ein Firmware-Fehler sie alle gleichzeitig zerstören. Mischen Sie lokale Laufwerke mit Cloud-Speicher, SSDs mit Band oder NAS mit Objektspeicher.

1 außerhalb des Standorts — Schutz vor physischen Katastrophen. Brand, Überschwemmung, Diebstahl oder Ransomware, die sich durch Ihr Netzwerk verbreitet. Wenn Ihr Büro abbrennt, überleben Ihre Daten, weil eine Kopie woanders existiert.

Die moderne 3-2-1-1-0-Regel

Einige Organisationen erweitern dies auf 3-2-1-1-0:

• 1 Kopie, die luftgekoppelt oder unveränderlich ist (kann nicht geändert oder gelöscht werden, auch nicht von Administratoren)
• 0 Fehler — Backups werden verifiziert und getestet

Die zusätzliche „1" schützt vor Ransomware, die gezielt auf Backups abzielt. Wenn Angreifer Administratorzugang erhalten, löschen sie oft Backups, bevor sie Produktionsdaten verschlüsseln. Eine unveränderliche oder luftgekoppelte Kopie überlebt sogar das.

Backup-Typen: Voll-, inkrementell, differenziell

Nicht jedes Backup muss jedes Mal alles kopieren.

Vollsicherung — Vollständige Kopie aller Daten. Dauert am längsten, verbraucht den meisten Speicher, aber am einfachsten wiederherzustellen. Wöchentlich oder monatlich ausführen.

Inkrementelles Backup — Nur seit dem letzten Backup (jeglicher Art) geänderte Daten. Schnell und kompakt, aber die Wiederherstellung erfordert das letzte Vollbackup plus alle inkrementellen Backups in Reihenfolge. Wenn ein inkrementelles Backup beschädigt ist, geht alles danach verloren.

Differenzielles Backup — Nur seit dem letzten Vollbackup geänderte Daten. Größer als inkrementell, aber die Wiederherstellung erfordert nur das letzte Vollbackup plus das neueste differenzielle Backup.

Was wann zu verwenden ist

Strategie	Backup-Zeit	Speicherverbrauch	Wiederherstellungskomplexität	Geeignet für
Nur Vollsicherung	Langsam	Hoch	Einfach	Kleine Datensätze, wöchentliche Archive
Voll + Inkrementell	Täglich schnell	Gering	Komplex (Kette)	Große Datensätze, tägliche Backups
Voll + Differenziell	Mittel	Mittel	Einfach	Balance aus Geschwindigkeit und Zuverlässigkeit

Praktische Empfehlung für kleine Unternehmen:

• Vollsicherung wöchentlich (Sonntagabend)
• Inkrementell oder differenziell täglich
• Mindestens 4 Wochen Vollbackups aufbewahren

Moderne Tools (Restic, Borg, Cloud-Backup-Dienste) erledigen das automatisch mit Deduplizierung — Sie erhalten die Speichereffizienz von inkrementellen Backups mit der Einfachheit von Vollbackups.

Was zu sichern ist

Bevor Sie irgendetwas konfigurieren, inventarisieren Sie, was tatsächlich gesichert werden muss.

Kritische Datenkategorien

Unternehmensdaten

• Kundendatenbanken
• Finanzunterlagen
• Verträge und rechtliche Dokumente
• Mitarbeiterdaten
• Geistiges Eigentum (Quellcode, Designs, Dokumentation)

Systemkonfigurationen

• Server-Konfigurationen
• Netzwerkgerätekonfigurationen
• Anwendungseinstellungen
• Infrastructure-as-Code-Dateien
• SSL-Zertifikate und Schlüssel

SaaS-Daten

• Google Workspace (E-Mails, Dokumente, Drive)
• Microsoft 365
• Slack/Teams-Verlauf
• CRM-Daten (Salesforce, HubSpot)
• Projektmanagement (Asana, Jira, Notion)

Datenbanken

• Produktionsdatenbanken
• Anwendungsdatenbanken
• Analysedaten

Geheimnisse und Anmeldedaten

• Passwortmanager-Exporte (Passwork unterstützt verschlüsselte Exporte — planen Sie diese monatlich)
• API-Schlüssel (sicher im Passwortmanager wie Passwork gespeichert)
• Verschlüsselungsschlüssel
• SSH-Schlüssel
• Die Backup-Verschlüsselungsschlüssel selbst (separat aufbewahren — in Passwork oder offline)

Was kein Backup braucht

• Temporäre Dateien und Caches
• Leicht neu herunterladbare Software
• Daten, die bereits woanders gespeichert sind (Spiegel, Replikate)
• Protokolldateien, die älter als die Aufbewahrungsanforderungen sind

Konzentrieren Sie Backup-Ressourcen auf Daten, die unersetzlich oder teuer in der Neuerstellung sind.

Datenklassifizierung für die Backup-Priorisierung

Kategorie	Beispiele	Backup-Häufigkeit	Aufbewahrung	Wiederherstellungspriorität
Kritisch	Kundendaten, Finanzen, Produktions-DB	Kontinuierlich/stündlich	1+ Jahr	Sofortig
Wichtig	Quellcode, Konfigurationen, Dokumente	Täglich	90 Tage	Innerhalb von Stunden
Standard	Interne Dokumente, Projektdateien	Täglich/wöchentlich	30 Tage	Innerhalb von 24h
Gering	Archive, alte Projekte	Wöchentlich/monatlich	30 Tage	Nach Möglichkeit

Backup-Methoden und -Tools

Verschiedene Daten erfordern verschiedene Backup-Ansätze.

Lokale/On-Premise-Server

Für Linux-Server:

Restic — Schnelle, verschlüsselte, deduplizierte Backups. Unterstützt lokale, S3-, SFTP- und viele andere Backends.

# Install
apt install restic

# Initialize repository (to S3)
restic init -r s3:s3.amazonaws.com/your-backup-bucket

# Backup a directory
restic backup /var/www /etc /home

# List snapshots
restic snapshots

# Restore
restic restore latest --target /restore/path

BorgBackup — Ähnlich wie Restic, exzellente Deduplizierung, etwas komplexer.

# Initialize
borg init --encryption=repokey /path/to/backup/repo

# Backup
borg create /path/to/repo::backup-{now} /home /etc

# Restore
borg extract /path/to/repo::backup-name

Für Datenbanken:

PostgreSQL:

# Automated daily backup
pg_dump -h localhost -U postgres mydatabase | gzip > /backup/mydb_$(date +%Y%m%d).sql.gz

# With pg_basebackup for point-in-time recovery
pg_basebackup -h localhost -D /backup/base -Ft -z -P

MySQL/MariaDB:

# Dump all databases
mysqldump --all-databases --single-transaction | gzip > /backup/all_$(date +%Y%m%d).sql.gz

# Or use Percona XtraBackup for hot backups
xtrabackup --backup --target-dir=/backup/xtrabackup/

MongoDB:

mongodump --out /backup/mongo/$(date +%Y%m%d)

Cloud-Infrastruktur

AWS:

• S3-Versionierung — Aktivieren Sie die Versionierung für kritische Buckets. Schützt vor versehentlichem Löschen und Ransomware.
• AWS Backup — Verwaltete Backups für EC2, RDS, EFS, DynamoDB. Zentrale Richtlinien und Aufbewahrung.
• RDS-automatisierte Backups — Mit angemessener Aufbewahrung aktivieren (Standard 7 Tage, kann auf 35 erweitert werden).
• EBS-Snapshots — Regelmäßige Snapshots für EC2-Volumes planen.

# Enable S3 versioning
aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled

# Create EBS snapshot
aws ec2 create-snapshot --volume-id vol-1234567890 --description "Daily backup"

GCP:

• Cloud Storage-Versionierung — Ähnlich wie S3
• Persistent Disk-Snapshots — Über Snapshot-Zeitpläne planen
• Cloud SQL-automatisierte Backups — Standardmäßig aktiviert, Aufbewahrung konfigurieren

Azure:

• Azure Backup — Verwalteter Dienst für VMs, SQL, Dateifreigaben
• Blob Storage-Versionierung
• Azure Site Recovery — Für Notfallwiederherstellung

SaaS-Datensicherung

Ihre Cloud-Apps haben Ihre Daten, garantieren aber keine Backups so, wie Sie es benötigen.

Google Workspace:

Die integrierte Aufbewahrung von Google ist begrenzt. Verwenden Sie Drittanbieter-Backups:

• Backupify — Teil von Datto, umfassend
• Spanning — Ebenfalls Kaseya, gut für KMUs
• AFI Backup — KI-gestützt, wettbewerbsfähige Preise

Oder verwenden Sie Google Vault für die Aufbewahrung (in einigen Tarifen enthalten, aber kein echtes Backup).

Microsoft 365:

Ähnliche Situation — die Aufbewahrung von Microsoft ist kein Backup:

• Veeam Backup for Microsoft 365 — Self-hosted oder Cloud
• Druva — Cloud-nativ
• AvePoint — Umfassend

Slack:

Der Datenexport von Slack hat Einschränkungen (keine DMs in kostenlosen/Pro-Tarifen). Berücksichtigen Sie:

• Enterprise Grid enthält eDiscovery und Export
• Drittanbieter: Rewind, Backupify

Allgemeines SaaS:

Viele kleinere SaaS-Apps haben keine Backup-Integrationen. Dafür gilt:

• Daten manuell nach einem Zeitplan exportieren
• Zapier/Make verwenden, um Exporte nach Möglichkeit zu automatisieren
• Dokumentieren, wo welche Daten liegen und wie man sie exportiert

Container- und Kubernetes-Backups

Velero — Der Standard für Kubernetes-Backups:

# Install Velero
velero install --provider aws --bucket my-backup-bucket --secret-file ./credentials

# Backup namespace
velero backup create my-backup --include-namespaces my-namespace

# Schedule regular backups
velero schedule create daily-backup --schedule="0 2 * * *" --include-namespaces production

# Restore
velero restore create --from-backup my-backup

Docker-Volumes:

# Backup a volume
docker run --rm -v my_volume:/source -v /backup:/backup alpine tar czf /backup/my_volume.tar.gz -C /source .

# Restore
docker run --rm -v my_volume:/target -v /backup:/backup alpine tar xzf /backup/my_volume.tar.gz -C /target

Unveränderliche und luftgekoppelte Backups

Ransomware-Betreiber zielen gezielt auf Backups ab. Wenn sie Ihre Backups löschen können, müssen Sie zahlen. Unveränderliche und luftgekoppelte Backups schützen davor.

Unveränderlicher Speicher

Unveränderlicher Speicher verhindert Änderungen oder Löschungen für einen festgelegten Zeitraum, auch durch Administratoren.

AWS S3 Object Lock:

# Enable Object Lock when creating bucket
aws s3api create-bucket --bucket my-backup-bucket --object-lock-enabled-for-bucket

# Set default retention
aws s3api put-object-lock-configuration --bucket my-backup-bucket --object-lock-configuration '{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": {
      "Mode": "GOVERNANCE",
      "Days": 30
    }
  }
}'

Der Governance-Modus erlaubt die Außerkraftsetzung mit speziellen Berechtigungen. Der Compliance-Modus kann von niemandem überschrieben werden, einschließlich Root.

Azure Immutable Blob Storage: Zeitbasierte Aufbewahrungsrichtlinien oder Legal-Hold-Richtlinien.

Backblaze B2: Object Lock-Unterstützung, sehr kosteneffektiv.

Luftgekoppelte Backups

Luftgekoppelt bedeutet physisch oder logisch von Ihrem Netzwerk getrennt.

Physische Luftkoppelung:

• Externe Laufwerke, die nur während des Backups angeschlossen sind
• Band-Backups, die außerhalb des Standorts aufbewahrt werden
• Wöchentlich/monatlich rotierende Offline-Speicher

Logische Luftkoppelung:

• Separates Cloud-Konto ohne Netzwerkpfad von der Produktion
• Backups werden von einem System mit anderen Anmeldedaten gezogen (nicht geschoben)
• Nur-Schreib-Zugriff — der Backup-Dienst kann schreiben, aber nicht löschen

Empfohlene Architektur für Ransomware-Schutz

Production Environment
        │
        ▼
[Primary Backup] ──────► AWS S3 (same account)
        │                Daily, 30-day retention
        │
        ▼
[Secondary Backup] ────► AWS S3 (different account)
        │                Object Lock enabled
        │                Cross-account, no delete permissions
        │
        ▼
[Tertiary Backup] ─────► Offline/Air-gapped
                         Weekly to external drive
                         Stored offsite

Backup-Automatisierung

Manuelle Backups werden nicht durchgeführt. Automatisieren Sie alles.

Planung mit cron

# /etc/cron.d/backup

# Daily database backup at 2 AM
0 2 * * * root /usr/local/bin/backup-database.sh >> /var/log/backup.log 2>&1

# Weekly full system backup at 3 AM Sunday
0 3 * * 0 root /usr/local/bin/backup-full.sh >> /var/log/backup.log 2>&1

# Monthly offsite sync at 4 AM on the 1st
0 4 1 * * root /usr/local/bin/backup-offsite.sh >> /var/log/backup.log 2>&1

Beispiel-Backup-Skript

#!/bin/bash
# /usr/local/bin/backup-database.sh

set -e

BACKUP_DIR="/backup/database"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30

# Create backup
pg_dump -h localhost -U postgres mydb | gzip > "$BACKUP_DIR/mydb_$DATE.sql.gz"

# Verify backup is not empty
if [ ! -s "$BACKUP_DIR/mydb_$DATE.sql.gz" ]; then
    echo "ERROR: Backup file is empty" | mail -s "Backup Failed" [email protected]
    exit 1
fi

# Upload to S3
aws s3 cp "$BACKUP_DIR/mydb_$DATE.sql.gz" s3://my-backup-bucket/database/

# Clean old local backups
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Log success
echo "$(date): Backup completed successfully"

Backups überwachen

Backups schlagen lautlos fehl. Überwachen Sie sie:

Auf Abschluss prüfen:

# Alert if no backup file created in last 25 hours
find /backup -name "*.gz" -mtime -1 | grep -q . || alert "Backup missing"

Cloud-Überwachung:

• AWS CloudWatch für AWS Backup
• Drittanbieter: Healthchecks.io — Kostenlos für einfache Überwachung
• Prometheus/Grafana für Metriken

Einfache Überwachung mit healthchecks.io:

# Add to end of backup script
curl -fsS -m 10 --retry 5 https://hc-ping.com/your-uuid-here

Wenn der Ping nicht planmäßig eintrifft, werden Sie benachrichtigt.

Wiederherstellung testen

Das Backup ist erst vollständig, wenn Sie daraus wiederhergestellt haben.

Warum Tests wichtig sind

• Backup-Dateien können beschädigt sein
• Der Wiederherstellungsprozess könnte sich geändert haben
• Möglicherweise fehlen kritische Dateien
• Die Person, die weiß, wie man wiederherstellt, ist möglicherweise nicht verfügbar

Zeitplan für Wiederherstellungstests

Testtyp	Häufigkeit	Was zu testen
Dateiwiederherstellung	Monatlich	Zufällige Dateien aus dem Backup wiederherstellen
Datenbankwiederherstellung	Vierteljährlich	In Testumgebung wiederherstellen, Daten verifizieren
Vollständige Systemwiederherstellung	Jährlich	Gesamten Server/Dienst von Grund auf wiederherstellen
Notfallwiederherstellungsübung	Jährlich	Vollständigen Ausfall simulieren, vollständige Wiederherstellung zeitlich messen

So testen Sie eine Datenbankwiederherstellung

1. Testumgebung erstellen — Nicht in die Produktion wiederherstellen!

2. Backup wiederherstellen:

# PostgreSQL
gunzip -c backup.sql.gz | psql -h test-server -U postgres -d testdb

# MySQL
gunzip -c backup.sql.gz | mysql -h test-server -u root -p testdb

3. Datenintegrität verifizieren:

-- Check row counts
SELECT COUNT(*) FROM important_table;

-- Check for recent data
SELECT MAX(created_at) FROM transactions;

-- Run application smoke tests

4. Ergebnisse dokumentieren:

• Benötigte Zeit zur Wiederherstellung
• Aufgetretene Fehler
• Ergebnisse der Datenverifizierung
• Erforderliche Verbesserungen

Vollständiger Notfallwiederherstellungstest

Einmal im Jahr einen vollständigen Katastrophenfall simulieren:

1. Ein unkritisches System wählen oder eine Testumgebung verwenden
2. So tun, als ob die Primärquelle zerstört wäre — Überhaupt nicht darauf zugreifen
3. Nur aus Backups wiederherstellen
4. Messen:
   • Recovery Time Objective (RTO): Wie lange, bis der Dienst wiederhergestellt ist?
   • Recovery Point Objective (RPO): Wie viele Daten gingen verloren?
5. Alles dokumentieren: Was funktioniert hat, was schwierig war, was fehlte

Das zeigt Lücken, die Sie auf keine andere Weise finden werden.

Compliance- und regulatorische Anforderungen

Wenn Sie mit personenbezogenen Daten umgehen oder mit Unternehmenskunden arbeiten, sind Backups nicht nur bewährte Praxis — sie sind oft gesetzlich vorgeschrieben.

DSGVO

Die DSGVO sagt nicht explizit „Sie müssen Backups haben", aber Artikel 32 verlangt:

„die Fähigkeit, die Verfügbarkeit und den Zugang zu personenbezogenen Daten bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen"

Das bedeutet:

• Sie benötigen Backups jedes Systems, das personenbezogene Daten enthält
• Backups müssen verschlüsselt sein (Artikel 32 verlangt „Verschlüsselung personenbezogener Daten")
• Backup-Standorte sind wichtig — Die Speicherung von Backups außerhalb der EU/des EWR erfordert geeignete Übertragungsmechanismen (Standardvertragsklauseln, Angemessenheitsbeschlüsse)
• Aufbewahrungsfristen gelten auch für Backups — Sie können Backup-Daten nicht unbegrenzt aufbewahren
• Zugangskontrollen — Der Backup-Zugang sollte eingeschränkt und protokolliert werden

Das Problem mit dem Recht auf Löschung: Artikel 17 gibt Personen das Recht, ihre Daten löschen zu lassen. Aber das Löschen spezifischer Datensätze aus Backups ist technisch schwierig. Der akzeptierte Ansatz:

1. Sofort aus Produktionssystemen löschen
2. Dokumentieren, dass die Daten in Backups mit einem bestimmten Ablaufdatum existieren
3. Wenn das Backup abläuft oder wiederhergestellt wird, Löschung erneut anwenden
4. Gelöschte Daten nicht in die Produktion zurückspielen

Erforderliche Dokumentation:

• Backup-Aufbewahrungsfristen
• Verwendete Verschlüsselungsmethoden
• Backup-Standort (Land/Region)
• Aufbewahrung von Zugriffsprotokollen

ISO 27001

ISO 27001 Anhang A enthält spezifische Kontrollen für Backups:

A.12.3 Informationssicherung:

• A.12.3.1 verlangt, dass Sicherungskopien von Informationen, Software und Systemabbildern regelmäßig erstellt und getestet werden

Was „regelmäßig getestet" bedeutet:

• Testhäufigkeit in Ihrer Richtlinie definieren (mindestens monatlich empfohlen)
• Testergebnisse dokumentieren
• Backup-Verifizierung in Ihren ISMS-Geltungsbereich einbeziehen

Weitere Kontrollen, die Backups betreffen:

• A.8.2 (Informationsklassifizierung) — Backup-Aufbewahrung sollte der Datenklassifizierung entsprechen
• A.11.1 (Sichere Bereiche) — Physischer Schutz von Backup-Medien und -Speicher
• A.12.4 (Protokollierung und Überwachung) — Backup-Zugriff sollte protokolliert werden
• A.18.1.3 (Schutz von Aufzeichnungen) — Einige Aufzeichnungen haben gesetzlich vorgeschriebene Aufbewahrungsfristen

SOC 2

SOC 2 Trust Services Criteria umfassen:

Verfügbarkeit (A1.2):

• Recovery-Ziele (RTO/RPO) müssen dokumentiert und getestet sein
• Backup-Verfahren müssen dokumentiert sein
• Wiederherstellungstests müssen regelmäßig stattfinden

Allgemeine Kontrollen:

• CC6.1 — Der logische Zugang zu Backup-Systemen muss kontrolliert werden
• CC7.2 — Systemänderungen (einschließlich Backup-Konfiguration) müssen verwaltet werden
• CC7.3 — Die Backup-Integrität muss verifiziert werden

Für SOC 2-Audits müssen Sie nachweisen:

• Dokumentierte Backup-Richtlinie
• Nachweise der Backup-Ausführung (Protokolle)
• Nachweise von Wiederherstellungstests (Testergebnisse mit Datum)
• Zugangskontrollen für Backup-Systeme

PCI-DSS (wenn Sie Zahlungsdaten verarbeiten)

PCI-DSS 4.0-Anforderungen:

• Anforderung 9.4.1: Backups mit Karteninhaberdaten müssen sicher aufbewahrt werden
• Anforderung 3.1: Die Speicherung von Karteninhaberdaten sollte minimiert werden — beinhaltet Backup-Aufbewahrung
• Anforderung 12.10.1: Der Vorfallreaktionsplan muss Backup-Verfahren umfassen

Praktische Compliance-Checkliste

Anforderung	DSGVO	ISO 27001	SOC 2	Ihr Status
Dokumentierte Backup-Richtlinie	✓	✓	✓	☐
Verschlüsselung im Ruhezustand	✓	✓	✓	☐
Verschlüsselung bei der Übertragung	✓	✓	✓	☐
Definierte Aufbewahrungsfristen	✓	✓	✓	☐
Regelmäßige Tests dokumentiert	Impliziert	✓	✓	☐
Zugriffskontrollen und Protokollierung	✓	✓	✓	☐
Backup-Standort dokumentiert	✓	✓	✓	☐
RTO/RPO definiert	Impliziert	✓	✓	☐

Das Backup-Richtliniendokument

Erstellen Sie eine schriftliche Richtlinie, damit alle den Plan kennen.

Vorlage für die Backup-Richtlinie

---

[Unternehmensname] Datensicherungsrichtlinie

Zweck: Sicherstellung, dass kritische Daten bei Hardwareausfällen, Ransomware, versehentlichem Löschen oder Katastrophen wiederhergestellt werden können.

Geltungsbereich: Alle Unternehmensdaten einschließlich Server, Datenbanken, SaaS-Anwendungen und Mitarbeiter-Workstations.

Backup-Zeitplan:

Datentyp	Häufigkeit	Aufbewahrung	Standort
Produktionsdatenbanken	Stündlich	30 Tage	AWS S3 + kontoübergreifend
Dateiserver	Täglich	90 Tage	Backblaze B2
SaaS (Google Workspace)	Täglich	1 Jahr	Backupify
Systemkonfigurationen	Bei Änderung + wöchentlich	90 Tage	Git + S3
Mitarbeiter-Laptops	Kontinuierlich	30 Tage	[Backup-Dienst]

3-2-1-Implementierung:

• Kopie 1: Produktionsumgebung
• Kopie 2: Primäres Cloud-Backup (AWS S3)
• Kopie 3: Sekundäres Cloud-Backup (Backblaze B2, anderer Anbieter)
• Außerhalb des Standorts: Alle Cloud-Backups sind geografisch verteilt
• Unveränderlich: S3 Object Lock für sekundäres Backup aktiviert

Tests:

• Monatlich: Zufällige Dateiwiederherstellungsverifizierung
• Vierteljährlich: Vollständige Datenbankwiederherstellung in Testumgebung
• Jährlich: Vollständige Notfallwiederherstellungsübung

Wiederherstellungsziele:

• RTO (Wiederherstellungszeit): 4 Stunden für kritische Systeme, 24 Stunden für Standard
• RPO (Wiederherstellungspunkt): 1 Stunde für Datenbanken, 24 Stunden für Dateien

Verantwortlichkeiten:

• Backup-Konfiguration und Überwachung: [Name/Rolle]
• Wiederherstellungstests: [Name/Rolle]
• Richtlinienüberprüfung: [Name/Rolle], jährlich
• Inhaber des privaten Schlüssels (Wiederherstellungsbefugnis): [Name/Rolle]
• Notfallzugangshaber: [Name/Rolle]

Zugangskontrolle:

• Backup-Zugriffsregister-Standort: [Link/Standort]
• Häufigkeit der Zugriffsüberprüfung: Vierteljährlich
• Autorisiertes Wiederherstellungspersonal: [Namen auflisten]

Wiederherstellungsverfahren:

1. Bewerten, was wiederhergestellt werden muss
2. Backup-Speicheranmeldedaten aus Passwork abrufen
3. Runbook in [Standort] befolgen
4. Vollständigkeit der Wiederherstellung verifizieren
5. Vorfall dokumentieren

Compliance:

• Personenbezogene Daten enthalten: Ja/Nein
• Backup-Verschlüsselung: AES-256 (Restic)
• Verschlüsselungsschlüssel-Standort: Passwork-Tresor „Backup Keys"
• Speicherregionen: [EU/US/andere — für DSGVO dokumentieren]
• Umgang mit dem Recht auf Löschung: Löschung bei Wiederherstellung anwenden, Backups nach [X] Tagen ablaufen lassen

Zuletzt aktualisiert: [Datum] Nächste Überprüfung: [Datum + 1 Jahr]

---

Häufige Backup-Fehler

Fehler 1: Backup auf demselben System

Wenn Ransomware Ihren Server und das angeschlossene USB-Laufwerk verschlüsselt, sind beide verloren. Cloud-Synchronisierungsordner (Dropbox, OneDrive, Google Drive) sind kein Backup — sie synchronisieren ebenfalls die verschlüsselten Dateien.

Lösung: Backups müssen auf separaten Systemen mit separaten Anmeldedaten liegen.

Fehler 2: Keine externe Kopie

Brand, Überschwemmung, Diebstahl oder ein verärgerter Mitarbeiter mit Administratorzugang kann On-Premise-Backups zerstören.

Lösung: Mindestens eine Kopie an einem anderen physischen Standort oder in einer anderen Cloud-Region.

Fehler 3: Nie Wiederherstellungen testen

Sie stellen fest, dass das Backup nicht funktioniert, wenn Sie es dringend brauchen.

Lösung: Geplante Wiederherstellungstests, dokumentierte Ergebnisse.

Fehler 4: Die falschen Dinge sichern

Sie sichern den Dateiserver, vergessen aber die Datenbank, die SaaS-Apps oder die Konfigurationsdateien, die alles zum Laufen bringen.

Lösung: Vollständiges Inventar der zu sichernden Daten, bevor Sie irgendetwas konfigurieren.

Fehler 5: Keine Überwachung

Backup-Jobs schlagen lautlos fehl. Niemand bemerkt es monatelang.

Lösung: Automatisierte Überwachung und Benachrichtigung für Backup-Jobs.

Fehler 6: Anmeldedaten an einem Ort

Das Backup-Verschlüsselungspasswort liegt auf dem Server, der verschlüsselt wurde.

Lösung: Backup-Anmeldedaten im Passwortmanager (Passwork) speichern, zugänglich für mehrere autorisierte Personen.

Fehler 7: Den Verschlüsselungsschlüssel verlieren

Verschlüsselte Backups mit verlorenem Schlüssel sind wertlos. Die Person, die Backups eingerichtet hat, ist gegangen, und niemand kennt die Passphrase.

Lösung: Verschlüsselungsschlüssel in Passwork speichern, eine Papierkopie an einem sicheren Ort erstellen und die Wiederherstellung mit diesen Schlüsseln jährlich testen.

Fehler 8: DSGVO-Löschanfragen nicht berücksichtigen

Jemand beantragt die Löschung seiner Daten gemäß DSGVO. Sie löschen aus der Produktion, aber seine Daten leben in 30+ Backup-Kopien weiter.

Lösung: Ihren Ansatz dokumentieren: Daten werden sofort aus der Produktion gelöscht, Löschung wird auf wiederhergestellte Backups angewendet, Backups laufen nach [X] Tagen ab.

Backup-Zugriffskontrolle

Wer kann auf Ihre Backups zugreifen?

Backups enthalten oft sensiblere Daten als Produktionssysteme — sie sind eine vollständige Momentaufnahme von allem. Dennoch ist der Backup-Zugriff oft ein nachträglicher Gedanke.

Ein Backup-Zugriffsregister führen:

Person	Rolle	Zugriffsebene	Erteilt am	Zuletzt überprüft
[Name]	Security Champion	Vollständig (verschlüsseln/entschlüsseln/wiederherstellen)	2024-01-15	2024-06-01
[Name]	DevOps-Leiter	Nur lesen/wiederherstellen	2024-02-01	2024-06-01
[Name]	CTO	Notfallzugang (versiegelte Anmeldedaten)	2024-01-15	2024-06-01

Regeln für den Backup-Zugriff:

1. Minimum notwendig — Die meisten Personen benötigen keinen Backup-Zugriff. Entwickler brauchen ihn selten.
2. Getrennt von der Produktion — Backup-Anmeldedaten sollten sich von Produktions-Anmeldedaten unterscheiden
3. Vierteljährlich überprüfen — Zugriff für Personen entfernen, die das Unternehmen verlassen haben oder die Rolle gewechselt haben
4. Zugriff protokollieren — Wissen, wer wann auf Backups zugegriffen hat
5. Vier-Augen-Prinzip für kritische Daten — Erwägen Sie, dass zwei Personen für die Wiederherstellung sensibelster Backups erforderlich sind

Was gilt als kritische Daten in Backups?

Einige Daten erfordern zusätzlichen Schutz:

• Persönliche Kundendaten (DSGVO-Bereich)
• Finanzdaten und Zahlungsdaten
• Authentifizierungsdaten und Geheimnisse
• Verschlüsselungsschlüssel
• Quellcode (geistiges Eigentum)
• Gesundheitsdaten (HIPAA-Bereich)
• Persönliche Mitarbeiterdaten

Wenn Ihre Backups diese enthalten, erwägen Sie den unten beschriebenen asymmetrischen Verschlüsselungsansatz.

Hybridverschlüsselung: Security Champion kontrolliert die Wiederherstellung

Ein praktisches Setup, bei dem nur der Security Champion (oder ein designierter Backup-Administrator) Backups entschlüsseln kann. Verwendet hybride Verschlüsselung: schnelles AES-256 für die Daten, RSA für den Schlüsselschutz.

Backup-Erstellung (jeder mit Zugriff auf das Backup-Skript kann dies ausführen):

1. Einen zufälligen AES-256-Schlüssel generieren
2. Backup-Daten mit diesem AES-Schlüssel verschlüsseln
3. Den AES-Schlüssel mit dem öffentlichen RSA-Schlüssel verschlüsseln
4. Beides speichern: encrypted_backup + encrypted_key

Wiederherstellung (nur der Security Champion):

1. Den AES-Schlüssel mit dem privaten RSA-Schlüssel entschlüsseln
2. Backup-Daten mit dem AES-Schlüssel entschlüsseln
3. Wiederherstellen

Warum dieses Muster:

• Backup-Skripte können automatisch ausgeführt werden (nur öffentlicher Schlüssel nötig)
• Nur der Inhaber des privaten Schlüssels kann wiederherstellen
• Wenn der Backup-Speicher kompromittiert wird, sind die Daten weiterhin verschlüsselt
• AES-256 ist schnell für große Dateien; RSA übernimmt den Schlüsselaustausch

Schritt-für-Schritt mit OpenSSL

1. RSA-Schlüsselpaar generieren (Security Champion macht das einmalig):

# Generate 4096-bit RSA private key
openssl genrsa -aes256 -out backup_private.pem 4096

# Extract public key
openssl rsa -in backup_private.pem -pubout -out backup_public.pem

# Private key: store securely (Passwork, offline, safety deposit box)
# Public key: distribute to backup servers

2. Backup-Skript (läuft automatisch, verwendet nur öffentlichen Schlüssel):

#!/bin/bash
# backup-encrypt.sh

BACKUP_FILE=$1
PUBLIC_KEY="/etc/backup/backup_public.pem"
OUTPUT_DIR="/backup/encrypted"
DATE=$(date +%Y%m%d_%H%M%S)

# Generate random 256-bit AES key
AES_KEY=$(openssl rand -hex 32)

# Encrypt backup with AES-256-CBC
openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in "$BACKUP_FILE" \
    -out "${OUTPUT_DIR}/backup_${DATE}.enc" \
    -pass pass:"$AES_KEY"

# Encrypt AES key with RSA public key
echo "$AES_KEY" | openssl rsautl -encrypt -pubin \
    -inkey "$PUBLIC_KEY" \
    -out "${OUTPUT_DIR}/backup_${DATE}.key.enc"

# Clean up
unset AES_KEY
rm "$BACKUP_FILE"  # Remove unencrypted backup

echo "Backup encrypted: backup_${DATE}.enc + backup_${DATE}.key.enc"

3. Wiederherstellungsskript (nur Security Champion, erfordert privaten Schlüssel):

#!/bin/bash
# backup-decrypt.sh

ENCRYPTED_BACKUP=$1
ENCRYPTED_KEY="${ENCRYPTED_BACKUP%.enc}.key.enc"
PRIVATE_KEY="/secure/backup_private.pem"
OUTPUT_FILE="${ENCRYPTED_BACKUP%.enc}.restored"

# Decrypt AES key using RSA private key
AES_KEY=$(openssl rsautl -decrypt \
    -inkey "$PRIVATE_KEY" \
    -in "$ENCRYPTED_KEY")

# Decrypt backup with AES key
openssl enc -aes-256-cbc -d -salt -pbkdf2 \
    -in "$ENCRYPTED_BACKUP" \
    -out "$OUTPUT_FILE" \
    -pass pass:"$AES_KEY"

# Clean up
unset AES_KEY

echo "Backup decrypted: $OUTPUT_FILE"

4. Vollständiges Beispiel — Datenbank-Backup mit Verschlüsselung:

#!/bin/bash
# full-db-backup.sh

DB_NAME="production"
BACKUP_DIR="/backup"
PUBLIC_KEY="/etc/backup/backup_public.pem"
DATE=$(date +%Y%m%d_%H%M%S)

# Dump database
pg_dump -h localhost -U postgres "$DB_NAME" | gzip > "${BACKUP_DIR}/db_${DATE}.sql.gz"

# Generate AES key and encrypt
AES_KEY=$(openssl rand -hex 32)

openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in "${BACKUP_DIR}/db_${DATE}.sql.gz" \
    -out "${BACKUP_DIR}/db_${DATE}.sql.gz.enc" \
    -pass pass:"$AES_KEY"

echo "$AES_KEY" | openssl rsautl -encrypt -pubin \
    -inkey "$PUBLIC_KEY" \
    -out "${BACKUP_DIR}/db_${DATE}.key.enc"

# Remove unencrypted file
rm "${BACKUP_DIR}/db_${DATE}.sql.gz"

# Upload to S3 (encrypted files only)
aws s3 cp "${BACKUP_DIR}/db_${DATE}.sql.gz.enc" s3://backup-bucket/db/
aws s3 cp "${BACKUP_DIR}/db_${DATE}.key.enc" s3://backup-bucket/db/

# Cleanup and notify
unset AES_KEY
echo "$(date): Database backup encrypted and uploaded" >> /var/log/backup.log

Schlüsselverwaltung für dieses Setup

Aufbewahrung des privaten Schlüssels:

• Primär: Passwork (verschlüsselt, in einem Tresor, auf den nur der Security Champion zugreifen kann)
• Backup: Ausgedruckt, im Unternehmens- oder Banksafe aufbewahrt
• Niemals auf Backup-Servern oder im Backup-Speicher

Verteilung des öffentlichen Schlüssels:

• Kann auf Backup-Servern gespeichert werden (er ist öffentlich)
• In Backup-Skripte einbinden
• Versionskontrolle ist in Ordnung (er ist kein Geheimnis)

Schlüsselrotation:

• Jährlich ein neues Schlüsselpaar generieren
• Alte private Schlüssel aufbewahren, um alte Backups zu entschlüsseln
• Dokumentieren, welcher Schlüssel welchen Backup-Bereich verschlüsselt

Notfallzugang:

• CTO oder eine zweite Person sollte eine versiegelte Kopie des privaten Schlüssels haben
• „Break-Glass"-Verfahren dokumentiert
• Notfallzugang jährlich testen

Praktische Tipps, die Geld und Schmerzen sparen

Backup-Integrität ohne vollständige Wiederherstellung verifizieren

Vollständige Wiederherstellungen brauchen Zeit. Aber Sie können prüfen, ob Backups lesbar sind:

# Restic: check backup integrity
restic check

# Restic: check and read all data (slower, but catches more problems)
restic check --read-data

# Borg: verify repository
borg check /path/to/repo

# Check backup file isn't empty or corrupted
gzip -t backup.sql.gz && echo "OK" || echo "CORRUPTED"

Planen Sie Integritätsprüfungen wöchentlich. Sie sind schneller als vollständige Wiederherstellungen, aber erkennen die meisten Beschädigungen.

Verwaltung von Verschlüsselungsschlüsseln

Wenn Sie Ihren Backup-Verschlüsselungsschlüssel verlieren, sind Ihre Backups nutzlos. Das passiert häufiger, als man denkt.

Tun Sie das:

1. Verschlüsselungsschlüssel in Passwork speichern (getrennt vom Backup selbst)
2. Eine Papierkopie in einem Safe oder Banksafe erstellen
3. Sicherstellen, dass mindestens zwei Personen wissen, wo Schlüssel gespeichert sind
4. Testen, dass Schlüssel funktionieren, indem Sie auf einem neuen System wiederherstellen

Nicht tun:

• Den Verschlüsselungsschlüssel auf demselben Server speichern, der gesichert wird
• Nur eine Person, die den Schlüssel kennt
• Ein Passwort verwenden, das Sie möglicherweise vergessen

Optimierung des Backup-Fensters

Backups belasten Produktionssysteme. Den Schmerz minimieren:

Intelligent planen:

# Run backup during low-traffic hours
0 3 * * * /usr/local/bin/backup.sh  # 3 AM

# For global teams, find the quietest hour (check your analytics)

Bandbreite drosseln:

# Restic: limit bandwidth to 50 MB/s
restic backup --limit-upload 50000 /data

# rsync: limit bandwidth
rsync --bwlimit=50000 /source /destination

# AWS S3: configure transfer acceleration or use multipart uploads

Datenbankspezifische Tools verwenden:

• PostgreSQL: pg_dump mit --no-synchronized-snapshots für weniger Sperrung
• MySQL: --single-transaction für InnoDB-Tabellen
• MongoDB: Replikat-Set-Backups vom Sekundärserver

Deduplizierung zur Speicherkosteneinsparung

Deduplizierung speichert jeden einzigartigen Datenblock nur einmal, auch wenn er in mehreren Backups vorkommt.

Tools mit integrierter Deduplizierung:

• Restic, BorgBackup — exzellente Deduplizierung
• AWS S3 — keine native Deduplizierung, aber Glacier spart Geld für Archive
• Backblaze B2 — keine Deduplizierung, aber günstig genug, dass es keine Rolle spielt

Reale Einsparungen: Ein 100-GB-Datensatz mit täglichen Backups für 30 Tage:

• Ohne Deduplizierung: 3 TB Speicher
• Mit Deduplizierung (typisch 90% Reduktion): 300 GB Speicher

Ihren Passwortmanager sichern

Ihr Passwortmanager (Passwork) enthält die Schlüssel zu allem. Wenn Sie ihn verlieren, wird die Wiederherstellung viel schwieriger.

Für Passwork:

• Integrierte verschlüsselte Exportfunktion verwenden
• Monatliche Exporte planen
• Exporte in Ihrem Backup-System speichern (separat verschlüsselt)
• Self-hosted Passwork: Datenbank und Dateispeicher als Teil Ihres Infrastruktur-Backups sichern

Wiederherstellungsszenario: Wenn Ihre Infrastruktur verschlüsselt ist und Sie nicht auf Passwork zugreifen können, benötigen Sie das Passwork-Backup, um Anmeldedaten für Ihre anderen Backups zu erhalten. Mindestens einen Passwork-Export an einem völlig separaten Standort aufbewahren.

Großvater-Vater-Sohn-Rotation

Für Langzeitaufbewahrung ohne endlosen Speicher:

• Täglich (Sohn): 7 tägliche Backups aufbewahren
• Wöchentlich (Vater): 4 wöchentliche Backups aufbewahren (jeden Sonntag)
• Monatlich (Großvater): 12 monatliche Backups aufbewahren (Monatserster)

Das ergibt ein Jahr monatlicher Wiederherstellungspunkte, einen Monat wöchentlicher Punkte und eine Woche täglicher Punkte — mit nur 23 Backup-Kopien statt 365.

Die meisten Backup-Tools unterstützen dies mit Aufbewahrungsrichtlinien:

# Restic: keep 7 daily, 4 weekly, 12 monthly
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# BorgBackup
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12

Ausfallsicherheit über Regionen und Anbieter hinweg

Ein Cloud-Anbieter kann Ausfälle haben. Für kritische Daten:

Regionsübergreifend (gleicher Anbieter):

# AWS: replicate S3 bucket to another region
aws s3api put-bucket-replication --bucket source-bucket --replication-configuration file://replication.json

Anbieterübergreifend:

• Primäres Backup: AWS S3
• Sekundäres Backup: Backblaze B2 oder Google Cloud Storage
• rclone verwenden, um zwischen Anbietern zu synchronisieren

# rclone: sync S3 to Backblaze B2
rclone sync s3:my-backup-bucket b2:my-backup-bucket --transfers 8

Warum beides: Wenn AWS einen größeren Ausfall hat, können Sie weiterhin auf Backups zugreifen. Bei einem Sicherheitsvorfall beim Anbieter sind Ihre Daten woanders.

Schnelle Größenüberprüfung

Dies zu Backup-Skripten hinzufügen, um leere oder verdächtig kleine Backups zu erkennen:

#!/bin/bash
BACKUP_FILE=$1
MIN_SIZE_KB=1000  # Minimum expected size in KB

SIZE=$(du -k "$BACKUP_FILE" | cut -f1)

if [ "$SIZE" -lt "$MIN_SIZE_KB" ]; then
    echo "WARNING: Backup file suspiciously small ($SIZE KB)" | mail -s "Backup Size Alert" [email protected]
    exit 1
fi

Wiederherstellungsverfahren

Diese vor dem Bedarfsfall dokumentieren.

Dateiwiederherstellungsverfahren

1. Identifizieren, was wiederhergestellt werden muss (Dateiname, Pfad, ungefähres Datum)
2. Auf Backup-Speicher zugreifen (Anmeldedaten in Passwork: Eintrag „Backup - S3")
3. Verfügbare Snapshots auflisten: restic snapshots
4. Die Datei finden: restic find filename
5. Wiederherstellen: restic restore snapshot_id --target /restore --include path/to/file
6. Die wiederhergestellte Datei verifizieren
7. An den Produktionsstandort verschieben, wenn korrekt

Datenbankwiederherstellungsverfahren

1. Den Schaden einschätzen (beschädigte Daten, versehentliches Löschen, vollständiger Verlust)
2. Wiederherstellungspunkt bestimmen (auf welchen Zeitpunkt soll wiederhergestellt werden?)
3. Anwendungszugriff stoppen, um weitere Schreibvorgänge zu verhindern
4. Backup-Anmeldedaten aus Passwork abrufen
5. Backup-Datei herunterladen
6. Wenn Zeit erlaubt, zuerst in Testumgebung wiederherstellen
7. In Produktion wiederherstellen
8. Datenintegrität verifizieren
9. Anwendungszugriff fortsetzen
10. Dokumentieren, was passiert ist und was verloren ging

Vollständiges Server-Wiederherstellungsverfahren

1. Neuen Server bereitstellen (gleiche Spezifikationen wie ausgefallener Server)
2. Basis-Betriebssystem installieren
3. Serverkonfiguration aus Backup abrufen
4. Konfigurationsdateien wiederherstellen
5. Anwendungsdaten wiederherstellen
6. Datenbank wiederherstellen
7. Verifizieren, dass alle Dienste laufen
8. DNS bei Bedarf aktualisieren
9. Gründlich testen, bevor die Wiederherstellung für abgeschlossen erklärt wird

Tools und Dienste

Backup-Software

Open Source:

• Restic — Schnell, verschlüsselt, dedupliziert
• BorgBackup — Exzellente Deduplizierung
• Duplicati — GUI-basiert, gut für Workstations
• Velero — Kubernetes-Backups

Kommerziell:

• Veeam — Branchenführer, teuer
• Acronis — Gute All-in-One-Lösung
• Druva — Cloud-nativ

Backup-Speicher

Cloud-Objektspeicher:

• AWS S3 — Standardwahl, Glacier für Archive
• Backblaze B2 — Viel günstiger als S3, S3-kompatible API
• Wasabi — Günstig, keine Egress-Gebühren
• Google Cloud Storage — Gut, wenn Sie auf GCP sind

Backup-spezifische Dienste:

• Backblaze Personal/Business — Einfaches Workstation-Backup
• Tarsnap — Sicher, nutzungsbasiert, Unix-fokussiert

Überwachung

• Healthchecks.io — Dead-Man's-Switch für Cron-Jobs
• Cronitor — Ähnlich, mehr Funktionen
• Cloud-nativ: AWS CloudWatch, GCP Monitoring, Azure Monitor

Workshop: Ihre Backup-Strategie implementieren

3–4 Stunden für die Ersteinrichtung, danach laufende Wartung einplanen.

Teil 1: Inventar und Klassifizierung (45 Minuten)

1. Alle zu sichernden Daten auflisten
2. Nach Priorität klassifizieren (kritisch, wichtig, standard, gering)
3. Aktuelle Backup-Lücken identifizieren
4. Dokumentieren, wo jede Art von Daten liegt

Teil 2: Primäres Backup einrichten (60 Minuten)

1. Backup-Tool wählen (Restic, Borg oder Cloud-nativ)
2. Für Ihre kritischen Daten konfigurieren
3. Automatisierten Zeitplan einrichten
4. Verifizieren, dass das erste Backup erfolgreich abgeschlossen wird
5. Die Konfiguration dokumentieren

Teil 3: Externes/unveränderliches Backup einrichten (45 Minuten)

1. Sekundäres Backup-Ziel erstellen (anderer Anbieter/Konto)
2. Unveränderlichkeit aktivieren, wenn verfügbar
3. Replikation vom Primär konfigurieren
4. Verifizieren, dass das Backup den sekundären Standort erreicht

Teil 4: Wiederherstellung testen (30 Minuten)

1. Eine zufällige Datei aus dem Backup auswählen
2. An einem Teststandort wiederherstellen
3. Verifizieren, dass der Inhalt mit dem Original übereinstimmt
4. Den Wiederherstellungsprozess dokumentieren

Teil 5: Dokumentation (30 Minuten)

1. Ihre Backup-Richtlinie schreiben (obige Vorlage verwenden)
2. Wiederherstellungsverfahren dokumentieren
3. Anmeldedaten im Passwortmanager speichern
4. Wiederkehrende Wiederherstellungstests planen

Ergebnisse:

• Vollständiges Dateninventar
• Automatisierte Backups für kritische Daten laufen
• Externes/unveränderliches Backup konfiguriert
• Erster Wiederherstellungstest abgeschlossen
• Backup-Richtlinie dokumentiert
• Wiederherstellungsverfahren dokumentiert
• Überwachung konfiguriert

Gespräch mit der Unternehmensführung

Wenn jemand fragt, warum Sie dafür Zeit aufgewendet haben:

„Ich habe eine umfassende Backup-Strategie nach der 3-2-1-Regel implementiert — drei Kopien unserer Daten, zwei verschiedene Speichertypen, eine außerhalb des Standorts. Außerdem habe ich unveränderlichen Speicher aktiviert, damit Ransomware unsere Backups nicht löschen kann, selbst wenn Angreifer Administratorzugang erhalten. Und ich habe die Wiederherstellung getestet, um sicherzustellen, dass sie tatsächlich funktioniert. Wenn unsere Server morgen verschlüsselt würden, könnten wir kritische Systeme innerhalb von 4 Stunden wiederherstellen."

Kurze Version: „Ich habe ordentliche Backups eingerichtet und getestet, dass wir tatsächlich daraus wiederherstellen können. Ransomware kann uns nicht stoppen."

Selbstcheck: Haben Sie es wirklich getan?

Backup-Abdeckung

• Alle zu sichernden Daten inventarisiert
• Daten nach Priorität klassifiziert
• Produktionsdatenbanken werden gesichert
• Dateiserver/Speicher werden gesichert
• Kritische SaaS-Daten haben eine Backup-Lösung
• Systemkonfigurationen werden gesichert

3-2-1-Implementierung

• Mindestens 3 Kopien kritischer Daten vorhanden
• Backups auf verschiedenen Speichertypen/Anbietern
• Mindestens eine Kopie extern/in der Cloud
• Mindestens eine Kopie ist unveränderlich oder luftgekoppelt

Automatisierung und Überwachung

• Backups laufen automatisch nach Zeitplan
• Überwachung benachrichtigt bei Backup-Fehlern
• Backup-Protokolle werden aufbewahrt

Tests und Dokumentation

• Mindestens einen Wiederherstellungstest abgeschlossen
• Backup-Richtlinie dokumentiert
• Wiederherstellungsverfahren dokumentiert
• Anmeldedaten im Passwortmanager gespeichert
• Zeitplan für Wiederherstellungstests erstellt

Sicherheit und Compliance

• Backups sind verschlüsselt (im Ruhezustand und bei der Übertragung)
• Verschlüsselungsschlüssel getrennt von Backups gespeichert
• Backup-Standort dokumentiert (für DSGVO)
• Aufbewahrungsfristen definiert
• Mindestens zwei Personen können auf Backup-Anmeldedaten zugreifen

Zugangskontrolle

• Backup-Zugriffsregister gepflegt (wer kann auf was zugreifen)
• Backup-Anmeldedaten von Produktions-Anmeldedaten getrennt
• Kritische Daten-Backups verwenden asymmetrische Verschlüsselung (RSA + AES)
• Privater Schlüssel sicher gespeichert (Passwork + Offline-Backup)
• Notfallzugangsverfahren dokumentiert

Wenn Sie mindestens 18 dieser 26 Punkte abhaken können, sind Sie bereit weiterzumachen.

Was kommt als nächstes

Backups sind solide. Noch ein Quick Win, bevor es zur Entwicklungssicherheit geht.

Nächstes Kapitel: Website-Schutz mit Cloudflare — DDoS-Schutz, WAF und Bot-Mitigation für Ihre öffentlich zugänglichen Websites.