Datenverlust Datenbank – Was tun? 15 TOP Tipps

Wieso verlieren gute Datenbanken keine Daten?

Dieser Beitrag erklärt, welche Maßnahmen gegen den Datenverlust schützen…

Starten wir!

Software Maßnahmen

Das Datenbank-Managementsystem einer ausgereiften Structured-Query-Datenbank wie MariaDB oder Postgres nutzt eine Vielzahl an Maßnahmen, um Datenverlust oder ungewünschte Datenänderung zu vermeiden:

• bei Stromausfall
• Überflutung
• unberechtigten Zugriff auf Daten
• Software-Fehler
• hohe Last auf der Datenbank

Die Rettung in der Not – Write-A-Head-Logging

Die Datenbank schreibt erstmal alle „ändernden“ Datenbankeinträge in eine Write-A-Head Log. Statt die notwendigen Aktionen auszuführen, soll dieser Schritt mit wenig Rechenleistung dazu dienen, im Falle eines plötzlichen Ausfalls, die Änderungen nachzuvollziehen.

Wenn z. B. der Strom ausfällt und die Datenbank erst 500 Tausend von 1 Million Zeilen ändern konnte, dann ist die Datenbank inkonsistent. Das Rollback findet automatisch statt, weil die „Schreib-Ende“-Nachricht nicht eingetroffen ist (Operation in der Mitte abgebrochen).

Ein Team ist stärker als einer – Replikation

Eine Datenbank ist gut, drei Datenbanken sind besser. Datenbanken duplizieren all ihre Daten über Datenbanken, die weltweit verteilt sind. Im Falle eines Desasters oder lokalen Stromausfalls sind weder Daten noch die Verfügbarkeit weg.

Ich komme zuerst! – Mutex

Wenn zwei Personen die gleiche Datenzelle ändern wollen, kommt es häufig zu Race Conditions.

Wenn Du 100 € von Deinem Konto auf ein anderes Konto einer anderen Bank übertragen willst, dann müssen zwei Operationen auf zwei Datenbanken, die 1000 Kilometer auseinander stehen, stattfinden.

Bricht die Operation in der Mitte ab, würde die Technik Geld erschaffen oder vernichten. Um Überschreibungen zu verhindern, werden Datenreihen reserviert und gesperrt. Die Operation wird zu 100 % ausgeführt, falls nicht, wird alles wieder rückgängig gemacht.

Schön hinten anstellen! – Pipeline

Software-Pipelines sind Warteschlangen. Die Datenbank kann viele Operationen nur nacheinander ausführen, damit keine Kauderwelsch herauskommt. Die Warteschlange sammelt alle hereinkommenden Anfragen von verschiedenen Nutzern ein und trägt dafür Sorge, dass keine übersehen wird oder untergeht.

Ausweis bitte vorzeigen! – Zugriffskontrolle

Ein langes Passwort und 2FA sind unser Industriestandard, um den Unberechtigten den Zugriff zu verweigern. Richtige Credentials stellen sicher, dass Daten nicht unberechtigt geändert oder abgerufen werden.

Datenbanken können Berechtigungen sehr granular vergeben. Einige User können nur Lesen (SELECT), andere nur Berechtigungen vergeben (GRANT) und andere dürfen nur schreiben (INSERT) z. B. technische User.

Kontrolle des Inhaltes und der Länge

Datenbanken sind streng. Sie validieren Spaltennamen, Länge von Inhalten, Inhaltstypen und die Syntax. Stimmt irgendetwas nicht, bricht die Datenbank die Verarbeitung ab und verhindert so falsche Modifikationen.

Kein Vertrauen – Sichere Verschlüsselung

Eine Verschlüsselung auf der Softwareebene verhindert, dass unverschlüsselte Hardware ein Problem wird.

Viele Geräte arbeiten ungeschützt und befinden sich nicht in einem stark bewachten Rechenzentrum. Es könnten einzelne Dateien, Spalten oder Tabellen verschlüsselt werden oder die gesamte Partition, auf der die Software installiert ist.

Flüchtiger Speicher ist flüchtig – Write-To-Disk

In-Memory-Datenbanken behalten alle Daten im Hauptspeicher. Das sind super schnelle Datenbanken, die bei einem Stromausfall alt aussehen. Deshalb sollten solche Datenbanken in regelmäßigen Abständen die Datensätze auf der Festplatte sichern. Viele Nicht-In-Memory Datenbanksysteme nutzen trotzdem den Hauptspeicher und müssen das gleiche auch machen.

Der eigene Weg – Backup-System

Wie jedes System, dass Daten hält, sollte ein Backup möglich sein. Backups von Datenbanken sind kompliziert, weil Datenbanken im Betrieb unter ständigen Änderungen stehen, sodass das System keinen „fixen“ Stand für eine paar Stunden hat. Viele strukturierte Datenbank-Managementsysteme haben für dieses Problem eine eigene Lösung, um die Datenschrittweise in ein portables Format zu überführen.

Rückmeldung erst, wenn geschrieben

Wenn ein Endnutzer Daten in einer Datenmaske eingibt und diese absendet, können einige Sekunden vergehen. Das liegt daran, dass die Datenbank beschäftigt ist. Der Nutzer kann / sollte nichts Weiteres machen, bis der Schreibvorgang ordentlich in der Datenbank durchgeführt wurde.

Falls es zu einem Problem kommt (kurzer Stromausfall), kann der Nutzer das gleiche Formular mit den gleichen Daten nochmals einige Sekunden später absenden. Die Bestätigung an den Nutzer markiert das Ende der Schreiboperation auf der Hardware.

Rückmeldung erst, wenn verteilt

Einen Schritt extremer ist die Nutzung von mehreren Knoten (Nodes). Eine verteilte Datenbank schreibt Änderungen auf verschiedenen Nodes gleichzeitig, um zu verhindern, dass Daten verloren gehen.

Da die Nodes unterschiedlich weit entfernt sind und unterschiedlich schnell schreiben können, dauert dieser Prozess noch länger. Dafür sind die Daten besser verfügbar und können schneller von verschieden Usern weltweit gelesen werden.

Hardware Maßnahmen

Wer Software sagt, muss auch die Hardware beachten! Die Software ist nur so gut, wie die Hardware auf der das System läuft.

Festplatten sterben auch – RAID‑Systeme

RAID (Redundant Array of Independent Disks) kombiniert mehrere Festplatten zu einem logischen Verbund. Warum hilft RAID gegen Datenverlust?

• Redundanz: Je nach RAID‑Level (z. B. RAID 1, 5, 6, 10) bleiben Daten trotz Ausfall einzelner Festplatten erhalten.
• Höhere Verfügbarkeit: SQL‑Datenbanken können weiterlaufen, selbst wenn eine Platte defekt ist.
• Schnellere Wiederherstellung: Defekte Platten lassen sich im laufenden Betrieb ersetzen (Hot‑Swap).

RAID schützt vor Hardware‑Ausfällen, aber nicht vor logischen Fehlern (z. B. DROP TABLE).

USV / UPS (Unterbrechungsfreie Stromversorgung)

Eine UPS liefert Notstrom, wenn die reguläre Stromversorgung ausfällt. Warum hilft eine UPS gegen Datenverlust?

• Verhindert plötzliche Abstürze: SQL‑Server können Transaktionen sauber abschließen.
• Schützt vor Datenkorruption: Ein Stromausfall während eines Schreibvorgangs kann Datenblöcke beschädigen.
• Ermöglicht kontrolliertes Herunterfahren: Das System fährt geordnet herunter, statt abrupt zu stoppen.

ECC‑Speicher (Error Correcting Code RAM)

ECC‑RAM erkennt und korrigiert Speicherfehler automatisch. Warum hilft ECC‑RAM gegen Datenverlust?

• Verhindert stille Datenkorruption: Bit‑Fehler im RAM können SQL‑Abfragen verfälschen oder Daten falsch schreiben.
• Stabilität für produktive Datenbanken: SQL‑Server laufen oft 24/7 — Speicherfehler wären fatal.
• Korrigiert Einzelbitfehler automatisch: Ohne ECC könnten diese Fehler unbemerkt in die Datenbank gelangen.

Industrie – Spezielle SSDs (Enterprise‑SSDs)

Enterprise‑SSDs sind für den Serverbetrieb optimiert und unterscheiden sich stark von Consumer‑SSDs. Warum helfen Enterprise‑SSDs gegen Datenverlust?

• Power‑Loss‑Protection: Kondensatoren stellen sicher, dass Daten im Cache bei Stromausfall trotzdem auf die SSD geschrieben werden.
• Höhere Haltbarkeit (DWPD‑Werte): SQL‑Datenbanken erzeugen viele Schreibvorgänge — Enterprise‑SSDs sind dafür ausgelegt.
• Bessere Fehlerkorrektur: Fortschrittliche Controller und Firmware reduzieren das Risiko von Datenfehlern.
• Konstante Performance: Keine plötzlichen Einbrüche, die zu Timeouts oder Transaktionsfehlern führen könnten.