Backup und Notfallwiederherstellung für dedizierte Server

RTO und RPO festlegen, bevor du Backup-Tools auswählst

Die Wiederherstellungszeit (Recovery Time Objective, RTO) ist die Zeit, die deine Anwendung offline sein kann, bevor die Auswirkungen auf das Geschäft nicht mehr okay sind. Eine SaaS-Anwendung mit Unternehmenskunden könnte eine RTO von 30 Minuten haben. Eine Marketing-Website könnte 4 Stunden vertragen.

Recovery Point Objective (RPO) ist, wie viel Datenverlust okay ist. Ein E-Commerce-Shop, der 500 Bestellungen pro Stunde bekommt, kann es sich nicht leisten, Daten von 24 Stunden zu verlieren – jede verlorene Bestellung bedeutet weniger Umsatz und ein Problem für den Kundenservice. Der gleiche Shop könnte alle 15 Minuten Backups machen. Ein Entwicklungsserver könnte wöchentliche Backups mit einem RPO von 7 Tagen machen.

Dokumentiere beide Zahlen, bevor du die Häufigkeit der Datensicherung, die Aufbewahrungsdauer und die Tools auswählst. Deine Backup-Architektur sollte so gestaltet sein, dass sie definierte Anforderungen erfüllt und nicht einfach die bei der Bereitstellung konfigurierten Einstellungen übernimmt.

Die 3-2-1-Regel für dedizierte Server

Die 3-2-1-Regel ist das grundlegende Konzept für die Backup-Strategie in der Produktion:

• 3 Kopien der Daten
• 2 verschiedene Arten von Speichermedien
• 1 Kopie wird außerhalb des Standorts gespeichert (also nicht auf dem Hauptserver)

Auf einem dedizierten Server sieht das normalerweise so aus:

1. Primärdaten: Der Live-Produktionsserver selbst
2. Lokale Sicherung: Eine Sicherung auf dem Server auf einer separaten Festplatte oder Partition (anders als die Festplatte mit dem Betriebssystem/den Anwendungen).
3. Offsite-Backup: Eine Kopie wird an einen Objektspeicher (S3-kompatibel), einen sekundären dedizierten Server oder den Backup-Speicher von InMotion geschickt.

Ein einziges Backup, das auf demselben Server wie die Daten gespeichert ist, ist keine Backup-Strategie. Ransomware verschlüsselt angeschlossene Speichermedien. Festplattenausfälle legen alles auf demselben Controller lahm. Ein lokales Backup ohne externe Kopie besteht beide Tests nicht.

Das Premier Care-Paket von InMotion hat 500 GB Backup-Speicher für Leute mit dedizierten Servern und bietet so eine Offsite-Kopie, ohne dass man extra Cloud-Speicher-Accounts braucht.

Backup-Tools für dedizierte Linux-Server

Restic

Restic ist ein modernes, schnelles und verschlüsseltes Backup-Tool, das S3, Backblaze B2, SFTP und lokalen Speicher als Backup-Ziele unterstützt. Deduplizierung und Verschlüsselung sind integriert, und das Repository-Format ist mit zukünftigen Restic-Versionen kompatibel.

Grundlegende Backup-Einstellungen für einen Webserver:

# Initialize a repository on S3-compatible storage

restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups init

# Set credentials via environment variables

export AWS_ACCESS_KEY_ID="your_key"

export AWS_SECRET_ACCESS_KEY="your_secret"

# Backup web root and database dumps

restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \

  backup /var/www /etc /home \

  --exclude /var/www/html/cache \

  --exclude /var/www/html/tmp

# Apply retention policy (keep 7 daily, 4 weekly, 6 monthly)

restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \

  forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Lass es je nach deinem RPO stündlich oder nachts über cron laufen.

Duplicati

Duplicati hat eine webbasierte Verwaltungsoberfläche, die es für Serverbetreiber zugänglich macht, die Backup-Jobs nicht komplett über die Befehlszeile verwalten wollen. Es unterstützt Verschlüsselung, Komprimierung und mehrere Backend-Speicherziele. Bei cPanel Servern kann Duplicati als Systemdienst laufen, der bestimmte Verzeichnisse sichert.

Rsync für inkrementelle Kopien

rsync mit –link-dest macht effiziente inkrementelle Backups, bei denen unveränderte Dateien mit dem vorherigen Backup-Snapshot hart verknüpft werden, anstatt sie zu duplizieren. So kriegst du mehrere Point-in-Time-Snapshots zu Speicherkosten, die proportional zu den geänderten Daten sind:

#!/bin/bash

BACKUP_DIR="/backup/web"

DATE=$(date +%Y-%m-%d_%H-%M)

LATEST="$BACKUP_DIR/latest"

rsync -avz --link-dest="$LATEST" /var/www/ "$BACKUP_DIR/$DATE/"

# Update the symlink to latest backup

rm -f "$LATEST"

ln -s "$BACKUP_DIR/$DATE" "$LATEST"

Datenbankspezifische Sicherung

Dateisystem-Backups von laufenden MySQL-Datenbanken erfassen inkonsistente Zustände – die Datenbankdateien auf der Festplatte können sich während der Ausführung des Backups mitten in einer Transaktion befinden. Datenbank-Backups müssen mit datenbankinternen Tools durchgeführt werden:

MySQL/MariaDB:

# Full logical backup

mysqldump --all-databases --single-transaction --routines --triggers \

  -u root -p > /backup/mysql_$(date +%Y%m%d).sql

# Compress to reduce storage

gzip /backup/mysql_$(date +%Y%m%d).sql

Für größere Datenbanken, bei denen mysqldump zu lange dauert, bietet Percona XtraBackup physische Hot-Backups, die einen konsistenten Zustand erfassen, ohne Tabellen zu sperren, und die deutlich schneller wiederhergestellt werden können als logische Dump-Dateien. Die Dokumentation zu Percona XtraBackup behandelt die Installation und Verwendung.

PostgreSQL:

pg_dumpall -U postgres | gzip > /backup/postgres_$(date +%Y%m%d).sql.gz

cPanel Backup Manager

Wenn dein dedizierter Server mit cPanel läuft, Backup Manager der eingebaute Backup Manager Backups auf Kontoebene, einschließlich Dateien, Datenbanken, E-Mails und Konfigurationen, und das alles in einem einzigen Vorgang. Du kannst ihn in WHM unter „Backup“ > „Backup-Konfiguration“ einrichten.

Wichtige Einstellungen, die du checken solltest:

• Backup-Typ: Vollständiges und inkrementelles Backup(nicht nur vollständig – inkrementelle Backups zwischen vollständigen Backups reduzieren das RPO ohne proportionale Speicherkosten)
• Remote-Ziel: Richte ein SFTP- oder S3-kompatibles Remote-Ziel für die externe Kopie ein.
• Aufbewahrung: Passend zu deinem dokumentierten RPO und Speicherbudget

Backup Manager von InMotion bietet dir zusätzliche 500 GB Backup-Speicherplatz, auf den du direkt über cPanel zugreifen kannst, ohne dass du irgendwelche zusätzlichen Serverkonfigurationen machen musst.

Testen von Wiederherstellungen

Ein Backup, das nie getestet wurde, ist nur eine Vermutung, kein Schutz. Beim Testen sollten drei Szenarien abgedeckt werden:

Wiederherstellung auf Dateiebene: Stell ein bestimmtes Verzeichnis aus der Sicherung wieder her und check, ob der Inhalt mit dem gesicherten Inhalt übereinstimmt. Mach das mal im Monat.

Datenbankwiederherstellung: Mach den letzten Datenbank-Dump auf einem Staging-Server wiederher und check, ob die Anwendung richtig läuft. So kannst du Fehler im Dump-File erkennen, bevor du ihn in der Produktion brauchst. Mach das am besten jeden Monat.

Vollständige Serverwiederherstellungsübung: Richte einen neuen Server ein, stell alles aus dem Backup wieder her und check, ob die Anwendung richtig läuft. Dieser Test zeigt, ob deine Dokumentation, Backup-Konfiguration und Wiederherstellungsverfahren wirklich durchgängig funktionieren. Mach das mal im Quartal.

Schreib die Wiederherstellungsprozedur genau auf, einschließlich Befehlen, Zeitangaben und Überprüfungsschritten. Die Person, die während eines Vorfalls die Wiederherstellung durchführt, ist möglicherweise nicht die Person, die die Backup-Konfiguration erstellt hat.

Automatisierung der Backup-Überprüfung

Restic hat eine eingebaute Integritätsprüfung, die die Konsistenz des Backup-Repositorys ohne vollständige Wiederherstellung checkt:

restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups check

Run this weekly via cron and alert on non-zero exit codes. A corrupted backup that's never checked is indistinguishable from a good backup until you need it.

For file-level verification, add a checksum comparison step to your backup process:

# Store a checksum of the source directory

find /var/www -type f -exec md5sum {} \; | sort > /backup/checksums_$(date +%Y%m%d).txt

# Compare after restore

md5sum -c /backup/checksums_20260227.txt

Notfallwiederherstellungsplanung über Backups hinaus

Backups stellen Daten wieder her. Ein Notfallwiederherstellungsplan kümmert sich um alles andere:

• DNS-Failover: Kannst du den Datenverkehr auf einen vorübergehenden Ersatz umleiten, wenn dein Server ausfällt? Mit dem Proxy-DNS Cloudflareist das Failover auf IP-Ebene nur eine Frage der Änderung eines A-Eintrags.
• Dokumentierte Serverkonfiguration: Dein Backup enthält deine Daten, aber nicht deine Nginx , Firewall-Regeln, PHP-FPM-Pool-Einstellungen und Anwendungsabhängigkeiten. Dokumentiere oder automatisiere die Serverkonfiguration, damit ein neuer Server so eingerichtet werden kann, dass er dem vorherigen entspricht.
• Kommunikationsplan: Wer wird benachrichtigt, wenn der Server ausfällt? In welcher Reihenfolge? Wer darf den Server während einer Wiederherstellung für Wartungsarbeiten offline nehmen?

Mit dem Premier Care-Paket InMotion Hostingkriegst du Zugang zu InMotion Solutions – dem Beratungsteam, das dir bei komplizierten Serverwiederherstellungsszenarien hilft. Die 1 Stunde pro Monat, die dir für Solutions zur Verfügung steht, kannst du am besten nutzen, um Disaster-Recovery-Verfahren zu testen und Runbooks für die Wiederherstellung zu dokumentieren, bevor du sie brauchst.