Backups für schleichende Demenz und Datenfäulnis

[Stefan H. (Firma: dm2sh) (stefan_helmert)]

Hallo,

man kennt es doch. Da werden ständig Backups angefertigt, aber am Ende 
war es doch nutzlos. Es gibt einen Fall, wo die klassische Backups 
nichts nützen. Es geht um die langsame Schädigung von Daten.

Hat man eine Datenbank mit gegenseitigen Bezügen etc. und man trägt 
immer wieder neue Datensätze ein, während andere Datensätze verloren 
gehen, kann man bei Backup wählen zwischen ein Jahr alt und alles noch 
in Ordnung, die neuen Daten fehlen. Man kann aber auch das Backup von 
vor eine Woche nehmen, hat dann zwar halbwegs aktuelle Einträge, der 
Rest ist aber ein bisschen kaputt.

Welche Backup-Strategie wählt man um solch eine Fall zu verhindern?

[Klaus W. (mfgkw)]

Wenn du dafür eine Lösung suchst, musst du alle Vorgänge festhalten, um 
sie ggf. korrigiert nochmal auf die alten Daten loslassen zu können.
Das Backup liefert dazu nur den alten Stand wieder, mehr kann es nicht 
leisten.

[backup-gast (Gast)]

dass ist keine Aufgabe des Backups sondern viel mehr eine 
datenbank-service aufgabe! normalerweise sollten eine datenbank einmal 
am tag mti gängistens tools überprüft werden (im hintergrund)

[Dominik S. (dasd)]

backup-gast schrieb:
> dass ist keine Aufgabe des Backups sondern viel mehr eine
> datenbank-service aufgabe!

Richtig.
Was man z.B. auch machen kann/sollte:
Backup der DB mit entsprechendem Tool erstellen, dieses Backup dann in 
eine Dummy-DB zurückspielen und diese anschließend auf Konsistenz 
überprüfen.
Somit weißt du auch gleich, ob das Backup selbst in Ordnung ist (denn 
ein BU, dass du nicht wieder herstellen kannst, weil es fehlerhaft ist, 
bringt dir auch recht wenig).

[Rufus Τ. F. (rufus)]

Stefan Helmert schrieb:
> Welche Backup-Strategie wählt man um solch eine Fall zu verhindern?

Wenn an der eigentlichen Anwendung nichts verändert werden kann, dürfte 
hier ein inkrementelles Backup hilfreich sein, bei dem man eben 
rückwirkend den Zustand zum Zeitpunkt jedes einzelnen inkrementellen 
Backups rekonstruieren kann.

So macht's "Timemachine" von Apple, und das kann auch Acronis TrueImage.

Im Gegensatz zum Komplettbackup kann man hierbei halt auch Daten zu 
Zeitpunkten rekonstruieren, die mehrere Backupdurchläufe zurückliegen.

[(prx) A. K. (prx)]

Bei gegenseitigen Bezügen in einer DB kann man die auch in der DB selbst 
als Datenbeziehung definieren, so dass bei korrekt funktionierendem 
DB-System keine in Leere laufenden Bezüge möglich sind und das DB-System 
sie bereits selbst kontrollieren kann. Das hat zwar nichts mit einem 
Backup-System zu tun, verhindert aber die sonst leicht entstehenden 
Bezüge ins Nirgendwo.

Was DB-Backups angeht, so gibt es auch bei DB-Systemen wie MySQL ein 
Transaction Logging, mit dem nicht nur der Stand von Vollbackups 
wiederherstellbar ist, sondern auch beliebige Zeitpunkte dazwischen, so 
weit die Logs halt reichen. Da sich diese Logs bei MySQL in normale 
SQL-Statements übersetzen kann man ggf. auch manuell eingreifen.