Ein Cold Backup kopiert die Daten, während Datenbank oder Server gestoppt sind: Es schreibt niemand mehr, deshalb ist die Kopie ohne Zusatztechnik in sich stimmig — der Preis ist der Stillstand. Ein Hot Backup sichert im laufenden Betrieb ohne Ausfallzeit, braucht dafür aber Transaktionsprotokolle oder Snapshot-Technik. Faustregel: Wartungsfenster vorhanden → cold, 24/7-Betrieb → hot.
Was passiert bei einem Cold Backup?
Ein Cold Backup (auch Offline-Backup) entsteht, nachdem das System sauber angehalten wurde. Bei einer Datenbank heißt das: Dienst stoppen, Datendateien kopieren, Dienst wieder starten. Weil in diesem Fenster niemand liest oder schreibt, erwischt die Sicherung einen eingefrorenen Stand — keine halb geschriebene Transaktion, keine Datei, die sich während des Kopierens noch verändert.
Wichtig ist das saubere Herunterfahren. Wer den Dienst hart abschießt oder die VM einfach ausschaltet, bekommt kein Cold Backup, sondern die Kopie eines abgestürzten Systems — die Datenbank muss beim Start erst ihr Recovery fahren, und im schlimmsten Fall fehlt genau der Teil, der noch im Schreibpuffer lag.
- Stärken: Konsistenz ohne Zusatztechnik, wenige bewegliche Teile, sehr einfache Wiederherstellung (Dateien zurückkopieren, starten).
- Schwächen: Ausfallzeit für die gesamte Sicherungsdauer, der gesicherte Stand ist immer so alt wie das letzte Fenster, bei großen Datenmengen wird das Fenster schnell zu kurz.
- Typisch für: kleine Firmendatenbanken mit Nachtfenster, Anwendungsserver, Archivstände, Umzüge und Migrationen.
Anzeige
Was passiert bei einem Hot Backup?
Ein Hot Backup (auch Online-Backup) läuft, während Benutzer weiterarbeiten. Es gibt keine Ausfallzeit — deshalb setzen Systeme mit vielen gleichzeitigen Zugriffen praktisch immer darauf. Der Haken: Während kopiert wird, ändert sich der Datenbestand weiter. Damit die Kopie trotzdem einen gültigen Zustand ergibt, braucht es ein Änderungsprotokoll.
Datenbanken schreiben jede Änderung zuerst in ein solches Protokoll — je nach Hersteller Redo-Log, Transaktionslog oder WAL (Write-Ahead-Log). Beim Zurückspielen wird die kopierte Datei-Basis genommen und das Protokoll darüber abgespielt, bis wieder ein sauberer Stand steht. Genau dieser Mechanismus erlaubt nebenbei die Wiederherstellung auf einen bestimmten Zeitpunkt (Point-in-Time-Recovery), etwa auf „fünf Minuten vor dem versehentlichen DELETE“.
- Stärken: keine Ausfallzeit, deutlich aktuellerer Stand, Point-in-Time-Recovery möglich, skaliert auf große Datenmengen.
- Schwächen: mehr Technik und mehr Konfiguration, spürbare Last während der Sicherung, und bei falscher Einrichtung sieht das Backup gut aus, ist aber nicht wiederherstellbar.
- Typisch für: Onlineshops, Produktivdatenbanken, Mailserver, virtuelle Maschinen im Dauerbetrieb.
Cold Backup und Hot Backup im direkten Vergleich
| Merkmal | Cold Backup | Hot Backup |
|---|---|---|
| System-Zustand | sauber heruntergefahren | läuft weiter |
| Ausfallzeit | ja, für die Sicherungsdauer | keine |
| Konsistenz | automatisch gegeben | nur mit Log/Snapshot-Technik |
| Technischer Aufwand | gering | höher, mehr Fehlerquellen |
| Last im Betrieb | keine (System ist aus) | möglich, je nach Verfahren |
| Aktualität | Stand des letzten Fensters | sehr aktuell, oft mit Point-in-Time |
| Restore | Dateien zurück, fertig | Basis zurück, Logs nachfahren |
| Passt für | Wartungsfenster, Archive | 24/7-Betrieb, große Datenmengen |
Wie sieht das konkret aus? Drei Beispiele
MySQL/MariaDB: Der klassische Weg im Betrieb ist mysqldump --single-transaction. Der Dump läuft dabei in einer einzigen Transaktion und sieht einen eingefrorenen Lesestand, ohne die Tabellen zu sperren — das funktioniert allerdings nur für transaktionale Engines wie InnoDB. Liegen noch MyISAM-Tabellen im System, sind die damit nicht konsistent gesichert; für die braucht es Sperren oder ein Werkzeug wie Percona XtraBackup, das physische Dateien kopiert und die Logs nachzieht. Details zu den Sperroptionen stehen in der MySQL-Dokumentation zu mysqldump.
PostgreSQL: Hier heißt der Standardweg fürs Online-Backup pg_basebackup beziehungsweise die Low-Level-Funktionen pg_backup_start() und pg_backup_stop(). Die alten Namen pg_start_backup()/pg_stop_backup() und der exklusive Backup-Modus sind seit PostgreSQL 15 verschwunden — wer alte Skripte von einer Version 14 oder älter mitschleppt, bekommt schlicht einen Fehler. Wichtig laut PostgreSQL-Dokumentation: Die WAL-Archivierung muss vor dem ersten Basis-Backup eingerichtet und getestet sein, sonst ist der Datei-Stand allein wertlos.
Windows-Server und VMs: Unter Windows erledigt der Volume Shadow Copy Service (VSS) die Arbeit. Die Backup-Software fordert einen Schattenkopie-Punkt an, VSS meldet das an die sogenannten Writer der Anwendungen (SQL Server, Exchange, Active Directory), diese schreiben ihre Puffer weg und halten kurz still — erst dann wird der Snapshot gezogen. Das ist der Unterschied zwischen einem anwendungskonsistenten Backup und einem bloßen VM-Snapshot, der nur den Zustand „Stecker gezogen“ einfriert.
Welche Variante passt zu welchem Fall?
Die Entscheidung hängt an zwei Fragen: Darf das System stillstehen, und wie viel Datenverlust ist verkraftbar?
- Es gibt ein echtes Wartungsfenster: Cold Backup nehmen. Weniger Technik heißt weniger, was beim Restore schiefgeht — besonders bei kleinen Umgebungen ohne Backup-Spezialisten.
- Das System muss durchlaufen: Hot Backup, mit aktivierter Log-Archivierung. Ohne die Logs ist das Online-Backup nur eine hübsche Dateikopie.
- Fenster zu kurz für die Datenmenge: Ebenfalls Hot Backup, gern kombiniert mit inkrementellen Läufen — die Vollsicherung passt dann nicht mehr in die Nacht.
- Gemischt fahren: Viele Umgebungen kombinieren beides — laufende Hot Backups plus ein Cold Backup vor Updates, Migrationen oder Versionswechseln als verlässlicher Rückfallpunkt.
Typische Stolperfallen
- Snapshot ohne Anwendungswissen: Ein VM- oder Storage-Snapshot ist erst einmal nur absturzkonsistent. Ohne VSS-Writer beziehungsweise passenden Agenten steht die Datenbank im Backup wie nach einem Stromausfall.
- Dateikopie bei laufender Datenbank: Datendateien im Betrieb einfach wegkopieren ist kein Hot Backup, sondern Glücksspiel. Ohne Backup-Modus oder Log-Nachlauf fehlt der Kopie der zweite Teil.
- Logs laufen voll: Wer Redo-/Transaktionslogs archiviert, aber nie aufräumt, legt sich irgendwann die Platte voll — und damit die Datenbank still.
- Restore nie geprobt: Der häufigste Fehler überhaupt. Getestet wird oft erst im Ernstfall, und dann fehlt die Verschlüsselungs-Passphrase oder das passende Log-Set.
- Backup im gleichen Zugriffsbereich: Liegt die Sicherung auf einer dauerhaft eingebundenen Freigabe, verschlüsselt Ransomware sie mit. Laut dem Veeam Ransomware Trends Report 2025 waren rund 69 % der befragten Organisationen im Vorjahr betroffen, und nur 10 % bekamen mehr als 90 % ihrer Daten zurück. Eine Kopie offline oder unveränderbar (immutable) zu halten, ist deshalb kein Luxus.
Und was ist ein Warm Backup?
Zwischen den Extremen liegt das Warm Backup: Der Server bleibt eingeschaltet, ist im Sicherungsmoment aber weitgehend im Leerlauf — Schreibzugriffe sind pausiert oder auf ein Minimum reduziert. In der Praxis steckt das oft hinter Replikaten: Gesichert wird nicht das Produktivsystem, sondern eine mitlaufende Kopie, die kurz von der Replikation abgekoppelt wird. Man bekommt fast die Konsistenz eines Cold Backups, ohne den Betrieb anzuhalten.
Hintergrund: Warum ist Konsistenz überhaupt das Problem?
Eine Datenbank ist keine einzelne Datei, sondern ein Verbund aus Datendateien, Indizes und Protokollen, die ständig gemeinsam verändert werden. Wird mitten in einer Überweisung gesichert — Abbuchung geschrieben, Gutschrift noch nicht —, enthält die Kopie einen Zustand, den es fachlich nie geben durfte. Beim Zurückspielen ist so ein Backup im besten Fall unvollständig, im schlechtesten unbrauchbar.
Fachlich unterscheidet man deshalb drei Stufen: absturzkonsistent (wie nach einem Stromausfall, die Datenbank repariert sich beim Start selbst — meistens), dateisystemkonsistent (alle Puffer sind weggeschrieben) und anwendungskonsistent (die Anwendung selbst hat den Punkt bestätigt). Ein Cold Backup landet automatisch in der letzten Kategorie, ein Hot Backup nur mit der richtigen Technik. Wer das erklären kann, hat auch ein beliebtes Prüfungsthema der Fachinformatiker sauber im Griff — Datensicherungskonzepte werden dort gern in genau dieser Tiefe abgefragt.
Und die Regel, die über allem steht: Ein Backup zählt erst, wenn die Wiederherstellung einmal wirklich funktioniert hat. Alles davor ist eine Vermutung.
Häufige Fragen
Was ist ein Cold Backup?
Eine Sicherung, die läuft, während Datenbank oder Server sauber heruntergefahren sind. Weil währenddessen niemand schreibt, ist die Kopie ohne Zusatztechnik konsistent — dafür ist das System offline.
Was ist der Unterschied zwischen Cold Backup und Hot Backup?
Cold sichert im gestoppten Zustand und ist automatisch konsistent. Hot sichert im laufenden Betrieb ohne Ausfallzeit, braucht dafür aber Transaktionsprotokolle oder Snapshot-Technik, damit die Kopie stimmig bleibt.
Ist ein Cold Backup sicherer als ein Hot Backup?
In Sachen Konsistenz ja, weil während der Sicherung nichts geschrieben wird. Dafür ist der Stand älter und das System steht still. Ein korrekt eingerichtetes Hot Backup ist genauso verlässlich, nur aufwendiger.
Wann brauche ich ein Hot Backup?
Immer wenn Ausfallzeit keine Option ist — Onlineshops, Produktivdatenbanken, Mailserver — oder wenn die Datenmenge nicht mehr in das nächtliche Wartungsfenster passt.
Was ist ein Warm Backup?
Der Mittelweg: Der Server läuft, ist im Sicherungsmoment aber weitgehend im Leerlauf ohne aktive Schreibzugriffe. Typisch bei Replikaten, die kurz von der Replikation abgekoppelt und dann gesichert werden.
