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?
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.
Gast
#2873034
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)
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).
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.
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.