
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.
VPS-Server (Virtual Private Server) bilden das Rückgrat vieler moderner Webprojekte, SaaS-Anwendungen und E-Commerce-Plattformen. Im Jahr 2026 steigt die Datenmenge, die auf solchen Servern gespeichert wird, kontinuierlich an, während gleichzeitig die Bedrohungslage durch Ransomware, Phishing und Zero-Day-Exploits komplexer wird. Eine durchdachte Backup-Strategie ist daher nicht länger optional, sondern ein geschäftskritischer Faktor.
Ein einzelner Hardwaredefekt, ein fehlerhaftes Software-Update oder ein erfolgreicher Cyberangriff kann innerhalb von Minuten den gesamten Geschäftsbetrieb lahmlegen. Studien zeigen, dass über 60 Prozent der kleinen und mittelständischen Unternehmen, die einen signifikanten Datenverlust erleiden, innerhalb von sechs Monaten insolvent werden. Diese Zahl verdeutlicht, wie essenziell präventive Maßnahmen sind.
Moderne Backup-Strategien unterscheiden sich grundlegend von den einfachen Datei-Kopien früherer Jahre. Heute erwarten Administratoren automatisierte, verschlüsselte, versionssichere und geografisch verteilte Sicherungen, die innerhalb weniger Minuten wiederhergestellt werden können. Cloud-native Lösungen, inkrementelle Snapshots und Immutable Storage haben die Spielregeln neu definiert.
Zudem steigen die Anforderungen durch gesetzliche Vorgaben wie die DSGVO, branchenspezifische Compliance-Richtlinien und internationale Standards. Unternehmen müssen nachweisen können, dass ihre Daten regelmäßig gesichert, getestet und wiederherstellbar sind. Eine lückenhafte Backup-Dokumentation kann im Ernstfall zu rechtlichen Konsequenzen führen.
Die klassische 3-2-1-Regel besagt, dass man drei Kopien seiner Daten auf zwei verschiedenen Medientypen speichern sollte, wobei eine Kopie offsite (extern) aufbewahrt wird. Für 2026 empfehlen Experten jedoch die erweiterte 3-2-1-1-Regel, die zusätzlich eine unveränderbare (immutable) Kopie vorsieht.
Diese zusätzliche Kopie schützt gezielt vor Ransomware-Angriffen, bei denen Angreifer versuchen, sowohl die Produktionsdaten als auch die Backups zu verschlüsseln oder zu löschen. Immutable Backups können über einen definierten Zeitraum nicht modifiziert oder gelöscht werden – selbst nicht durch Administratoren mit Root-Zugriff.
Ein typisches Setup könnte folgendermaßen aussehen: Die Primärdaten liegen auf dem VPS, eine erste Backup-Kopie wird lokal auf einem zweiten Speichermedium (z. B. einer separaten SSD) gesichert, eine zweite Kopie wird verschlüsselt in die Cloud (z. B. zu Hetzner Storage Box, AWS S3 oder Backblaze B2) übertragen, und die dritte Kopie wird als Immutable Snapshot in einem WORM-Speicher (Write Once Read Many) abgelegt.
Cloud-Anbieter wie Wasabi, Backblaze oder Hetzner bieten mittlerweile Object-Lock-Funktionen an, mit denen sich solche unveränderbaren Backups kostengünstig realisieren lassen. Die Investition in diese zusätzliche Sicherheitsebene amortisiert sich bereits beim ersten erfolgreich abgewehrten Angriff.
Inkrementelle Backups speichern nur die Daten, die sich seit dem letzten Backup geändert haben. Dies spart enorm viel Speicherplatz und reduziert die Backup-Zeit erheblich. Allerdings benötigt man für eine vollständige Wiederherstellung das letzte Vollbackup sowie alle nachfolgenden inkrementellen Sicherungen – ein längerer Restore-Prozess ist die Folge.
Differenzielle Backups hingegen sichern alle Änderungen seit dem letzten Vollbackup. Der Restore-Vorgang ist schneller, da nur das Vollbackup und das letzte differenzielle Backup benötigt werden. Der Nachteil: Die Backup-Dateien werden mit der Zeit immer größer, was mehr Speicherplatz erfordert.
Für die meisten VPS-Setups empfiehlt sich eine Kombination: Wöchentliche Vollbackups, tägliche inkrementelle Sicherungen und stündliche differentielle Snapshots für kritische Datenbanken. Diese Hybridstrategie bietet einen optimalen Kompromiss zwischen Speichereffizienz und Wiederherstellungsgeschwindigkeit.
Tools wie BorgBackup, Restic oder Duplicati unterstützen Deduplizierung und inkrementelle Sicherungen nativ. Sie komprimieren und verschlüsseln die Daten bereits auf Client-Seite, bevor sie in die Cloud übertragen werden. Das spart Bandbreite und schützt die Vertraulichkeit der Daten während der Übertragung.
Die manuelle Durchführung von Backups ist fehleranfällig und wird in professionellen Umgebungen nicht mehr praktiziert. Linux-basierte VPS-Systeme bieten zwei bewährte Mechanismen zur Automatisierung: Cronjobs und Systemd-Timer.
Cronjobs sind seit Jahrzehnten der Standard für zeitgesteuerte Aufgaben. Eine typische Crontab-Datei könnte so aussehen, um täglich um 3 Uhr morgens ein Backup zu erstellen:
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Das dazugehörige Backup-Skript könnte mit BorgBackup realisiert werden. Es erstellt ein neues Archiv, behält eine definierte Anzahl alter Backups und überträgt die Daten verschlüsselt in einen externen Speicher.
#!/bin/bash
export BORG_PASSPHRASE="sicheres-passwort"
borg create --stats --compression lz4 \
backup@server:/path/to/repo::'backup-{now}' \
/var/www /etc /home
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
backup@server:/path/to/repo
Systemd-Timer bieten eine modernere Alternative mit besserer Logging-Integration und Abhängigkeitsverwaltung. Sie eignen sich besonders für komplexe Backup-Pipelines, die mehrere Services koordinieren müssen. Die Timer-Unit wird über einen Service mit ExecStart und einen Timer mit OnCalendar aktiviert.
Die Wahl des richtigen Cloud-Speicheranbieters hat erheblichen Einfluss auf Kosten, Performance und Datensicherheit. Die folgende Tabelle vergleicht die wichtigsten Anbieter für VPS-Backups:
| Anbieter | Speicherpreis pro TB/Monat | Egress-Gebühren | Immutable Storage | Standorte |
|---|---|---|---|---|
| Backblaze B2 | 6,00 $ | 0,01 $ pro GB | Ja (Object Lock) | EU, US |
| Hetzner Storage Box | 3,81 € | Keine | Nein | Deutschland, Finnland |
| Wasabi Hot Cloud Storage | 6,99 $ | Keine | Ja (Object Lock) | EU, US, APAC |
| AWS S3 Standard | 23,00 $ | 0,09 $ pro GB | Ja (Object Lock) | Global |
| Scaleway Glacier | 2,50 € | 0,01 € pro GB | Ja | Frankreich, Niederlande |
Für datenschutzsensible Anwendungen in der EU empfehlen sich Anbieter mit Rechenzentren in Deutschland oder Frankreich. Hetzner und Scaleway bieten dabei ein hervorragendes Preis-Leistungs-Verhältnis und unterliegen vollständig der DSGVO. Backblaze und Wasabi punkten mit attraktiven Preisen und ohne Egress-Gebühren, was besonders bei häufigen Restore-Vorgängen wichtig ist.
Bei der Auswahl sollte man auch die Verfügbarkeit von Versionierung, Lifecycle-Policies und API-Zugriffen berücksichtigen. Versionierung ermöglicht es, versehentlich gelöschte oder überschriebene Dateien wiederherzustellen, während Lifecycle-Policies automatisch alte Backups in günstigere Speicherklassen verschieben.
Datenbanken wie MySQL, PostgreSQL oder MongoDB benötigen besondere Backup-Strategien, da ein einfaches Kopieren der Datendateien während des laufenden Betriebs zu inkonsistenten Backups führen kann. Die wichtigste Regel lautet: Verwenden Sie die nativen Backup-Tools der jeweiligen Datenbank.
Für MySQL/MariaDB empfiehlt sich mysqldump für kleinere Datenbanken oder Percona XtraBackup für produktive Umgebungen mit großen Datenmengen. mysqldump erstellt eine SQL-Datei mit allen CREATE- und INSERT-Anweisungen:
mysqldump -u root -p --single-transaction --quick \
--lock-tables=false \
--all-databases > backup_$(date +%F).sql
Der Parameter --single-transaction sorgt dafür, dass ein konsistenter Snapshot zum Zeitpunkt des Backup-Starts erstellt wird, ohne dass die Datenbank für Schreibvorgänge gesperrt wird. Bei sehr großen Datenbanken kann dies zu langen Backup-Zeiten und hohem RAM-Verbrauch führen.
PostgreSQL bietet mit pg_dump und pg_basebackup zwei mächtige Werkzeuge. pg_basebackup erstellt eine physische Kopie des gesamten Datenverzeichnisses und eignet sich hervorragend für Point-in-Time-Recovery. In Kombination mit Write-Ahead-Logs (WAL) lässt sich die Datenbank auf jeden beliebigen Zeitpunkt zurücksetzen.
MongoDB verwendet mongodump für logische Backups oder Filesystem-Snapshots für physische Sicherungen. In Replica-Set-Umgebungen empfiehlt es sich, Backups immer von einem Secondary Node zu erstellen, um die Performance des Primärknotens nicht zu beeinträchtigen.
Logical Volume Manager (LVM) und ZFS bieten die Möglichkeit, nahezu augenblicklich Snapshots des gesamten Dateisystems zu erstellen. Diese Technologie ist besonders wertvoll für VPS-Umgebungen, da sie konsistente Backups innerhalb von Sekunden ermöglicht.
Ein LVM-Snapshot speichert nur die geänderten Blöcke seit der Snapshot-Erstellung. Der ursprüngliche Datenträger bleibt lesbar, während der Snapshot als separates Volume gemountet werden kann. Dies ermöglicht es, ein konsistentes Backup zu erstellen, ohne die laufenden Schreiboperationen zu unterbrechen.
# Snapshot erstellen
lvcreate -L 10G -s -n vps_snapshot /dev/vg0/vps_root
# Snapshot mounten
mount -o ro /dev/vg0/vps_snapshot /mnt/snapshot
# Backup durchführen
tar -czf /backup/vps_$(date +%F).tar.gz /mnt/snapshot
# Snapshot entfernen
umount /mnt/snapshot
lvremove -f /dev/vg0/vps_snapshot
ZFS bietet noch leistungsfähigere Funktionen wie inkrementelle Snapshots (zfs send/receive), integrierte Komprimierung, Deduplizierung und Prüfsummen. Ein ZFS-Snapshot belegt zunächst keinen zusätzlichen Speicherplatz und wächst nur, wenn sich Daten ändern. Mit zfs send können Snapshots effizient auf andere Pools oder Cloud-Speicher übertragen werden.
Viele Cloud-Hoster wie Hetzner, Netcup oder IONOS bieten mittlerweile VPS-Tarife mit ZFS-Storage an. Die native Snapshot-Funktion lässt sich über die API automatisieren und mit externen Backup-Systemen kombinieren. So entsteht eine mehrstufige Backup-Architektur mit minimaler Komplexität.
Zwei zentrale Metriken bestimmen die Qualität jeder Backup-Strategie: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). RTO beschreibt die maximale Ausfallzeit, die ein System nach einem Desaster haben darf, bevor signifikante Schäden entstehen. RPO hingegen definiert den maximalen akzeptablen Datenverlust, gemessen in Zeit.
Ein E-Commerce-Unternehmen benötigt möglicherweise eine RTO von 15 Minuten und eine RPO von 5 Minuten – bei einem Ausfall wären längere Unterbrechungen geschäftskritisch. Ein internes Wiki hingegen toleriert eventuell eine RTO von 24 Stunden und eine RPO von einem Tag. Diese Anforderungen beeinflussen direkt die Wahl der Backup-Strategie und der Speicherinfrastruktur.
Um eine RPO von 5 Minuten zu erreichen, sind kontinuierliche Replikation oder binäre Logs notwendig. Datenbanken wie PostgreSQL erlauben es mit der Konfiguration von archiving_mode und archive_command, jedes WAL-Segment automatisch in einen entfernten Speicher zu übertragen. Im Ernstfall können alle Transaktionen bis zum Zeitpunkt kurz vor dem Ausfall wiederhergestellt werden.
Regelmäßige Disaster-Recovery-Tests sind unerlässlich, um die tatsächliche Wiederherstellungszeit zu validieren. Ein Backup, das nie getestet wurde, ist kein Backup. Mindestens quartalsweise sollten komplette Restore-Szenarien durchgespielt und die Ergebnisse dokumentiert werden. Nur so lassen sich Schwachstellen in der Backup-Pipeline rechtzeitig identifizieren.
Backup-Daten enthalten oft die sensibelsten Informationen eines Unternehmens: Kundendaten, Geschäftsgeheimnisse, Finanzunterlagen. Daher ist eine durchgängige Verschlüsselung unerlässlich – sowohl bei der Übertragung (in transit) als auch bei der Speicherung (at rest).
Tools wie BorgBackup und Restic verschlüsseln die Daten bereits vor der Übertragung mit AES-256. Der kryptografische Schlüssel wird aus einer Passphrase abgeleitet, die getrennt vom Backup aufbewahrt werden muss. Verliert man diese Passphrase, sind die Daten unwiederbringlich verloren.
Für maximale Sicherheit empfiehlt sich die Kombination aus Verschlüsselung und Compliance-Zertifizierungen. ISO 27001, SOC 2 und BSI C5 sind relevante Zertifikate, die von Cloud-Providern erwartet werden. Bei der Wahl des Anbieters sollte man darauf achten, dass die Rechenzentren in zertifizierten Standorten betrieben werden.
Die DSGVO verlangt zudem, dass personenbezogene Daten nur so lange gespeichert werden, wie es für den Zweck erforderlich ist. Backups sollten daher ebenfalls einer automatisierten Aufbewahrungsfrist unterliegen, nach der sie sicher gelöscht werden. Die meisten Backup-Tools unterstützen entsprechende Retention-Policies, die alte Archive nach definierten Regeln entfernen.
Ein Backup, das stillschweigend fehlschlägt, ist gefährlicher als gar kein Backup, da es eine trügerische Sicherheit vermittelt. Daher ist ein zuverlässiges Monitoring der Backup-Pipelines unerlässlich. Moderne Monitoring-Stacks wie Prometheus, Grafana und Alertmanager bieten alle notwendigen Werkzeuge.
Zentrale Metriken, die überwacht werden sollten, sind: Erfolgsstatus des letzten Backups, Backup-Dauer, Größe der inkrementellen Deltas, verfügbare Speicherkapazität und Alter des letzten erfolgreichen Backups. Schwellenwerte definieren, wann ein Alarm ausgelöst wird.
# Beispiel einer Prometheus-Alert-Regel
- alert: BackupFailed
expr: backup_last_success_timestamp < time() - 86400
for: 1h
labels:
severity: critical
annotations:
summary: "Backup fehlgeschlagen auf {{ $labels.instance }}"
Neben Prometheus-basierten Lösungen gibt es spezialisierte Backup-Monitoring-Tools wie BackupNinja, Bacula oder Amanda, die bereits umfassende Reporting-Funktionen integriert haben. Sie versenden automatisch E-Mail- oder Slack-Benachrichtigungen bei Fehlern und bieten webbasierte Dashboards zur Übersicht aller Backup-Jobs.
Ein häufig übersehener Aspekt ist das Monitoring der Restore-Zeiten. Nur wer regelmäßig testet, wie lange eine Wiederherstellung tatsächlich dauert, kann im Ernstfall fundierte Entscheidungen treffen. Ein jährlicher, dokumentierter Restore-Test gehört daher in jeden professionellen Backup-Workflow.
Einer der häufigsten Fehler ist die fehlende Trennung von Backup- und Produktionsumgebung. Befinden sich beide auf demselben Server oder im selben Rechenzentrum, können ein Hardwaredefekt oder ein Ransomware-Angriff beide gleichzeitig treffen. Eine geografisch verteilte Backup-Strategie ist daher Pflicht.
Ein weiterer typischer Fehler ist die fehlende Versionsverwaltung. Wird ein Backup versehentlich überschrieben oder mit fehlerhaften Daten überschrieben, gibt es ohne Versionierung kein Zurück. Moderne Backup-Tools bieten daher standardmäßig mehrere Versionen derselben Datei, oft mit konfigurierbarer Aufbewahrungsdauer.
Unzureichende Dokumentation ist ein dritter kritischer Fehler. In einer Krisensituation müssen die zuständigen Mitarbeiter in der Lage sein, die Backup-Pipeline schnell zu verstehen und die Wiederherstellung durchzuführen. Runbooks mit Schritt-für-Schritt-Anleitungen gehören in jeden professionellen Backup-Workflow.
Bewährte Praktiken umfassen die regelmäßige Überprüfung der Wiederherstellbarkeit, die Nutzung unterschiedlicher Verschlüsselungscodes für verschiedene Backup-Sets, die Implementierung von Least-Privilege-Zugriffsrechten und die Verwendung separater Backup-Konten, die nicht für alltägliche administrative Aufgaben genutzt werden. Diese Maßnahmen verringern das Risiko kompromittierter Credentials erheblich.
Eine durchdachte Backup-Strategie ist weit mehr als nur eine technische Notwendigkeit. Sie ist ein strategischer Wettbewerbsvorteil, der die Geschäftskontinuität sichert, das Vertrauen von Kunden stärkt und die Einhaltung gesetzlicher Vorschriften gewährleistet. Im Jahr 2026 reicht es nicht mehr aus, lediglich Dateien zu kopieren – gefragt sind automatisierte, verschlüsselte, geografisch verteilte und getestete Backup-Pipelines.
Die 3-2-1-1-Regel, kombiniert mit modernen Tools wie BorgBackup, Restic, ZFS-Snapshots und Cloud-Storage mit Object-Lock, bildet das Fundament einer robusten Strategie. Automatisierung durch Cronjobs oder Systemd-Timer minimiert menschliche Fehler, während Monitoring und Alarmierung sicherstellen, dass Probleme frühzeitig erkannt werden.
Investitionen in Disaster-Recovery-Tests, Mitarbeiterschulungen und klare Runbooks zahlen sich im Ernstfall vielfach aus. Wer seine Backup-Strategie regelmäßig überprüft, an neue Bedrohungen anpasst und kontinuierlich verbessert, ist für die Herausforderungen der kommenden Jahre bestens gerüstet.
Starten Sie noch heute mit der Evaluierung Ihrer aktuellen Backup-Lösung. Identifizieren Sie Schwachstellen, definieren Sie RTO- und RPO-Ziele und implementieren Sie schrittweise die in diesem Artikel beschriebenen Best Practices. Die Sicherheit Ihres Unternehmens hängt davon ab.

Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.