Dies hat aber damit zu tun, das diese Kunden partu den
SQL-Server in eine VM installiert haben und meinen pünktlich um 23:00 Uhr einen SnapShot von der VM ziehen zu müssen.
Diese VM Fetischisten kenne ich auch. Ist immer lustig denen mal zu erklären, das deren sogenannte Sicherungsstrategie eher gefährlich ist als hilfreich. Der VM Snapshot hat eine ähnliche Funktion bei Firebird wie Forced writes zu deaktivieren. Das was gerade im Speicher ist und auf der Platte geändert wurde wird gesichert. Ob das zur careful write schreibreihenfolge von Firebird passt ist egal. Wenn nun beim Snapshot irgendwas schief läuft (und ja, auch das ist nur software, die ggf mal auf volle oder defekte Platten trifft und dann nicht weitermachen kann), ist es gar nicht mal so unwahrscheinlich, das die gesicherte VM nicht 100% sauber ist.
Wenn das die einzige Strategie ist, dann herzlichen Glückwunsch wenn es knallt. Wir bekommen ja aus verschiedenen Umgebungen Firebird Datenbanken zur Reparatur, vor kurzem war ein dabei, bei der die ersten ca 60% der Datei auch sauber gefüllt war, der Rest waren leider binäre Nullen. Leider zeigten diverse Pointer in diesen Bereich, unter anderem Teile der Transaktionsinventory Page. Nach kurzer Analyse war klar: Keine Reparatur möglich (Wenn bei einem Auto der Motor ausgebaut ist, kann die Werkstatt mit der Meldung, das Auto springt nicht an, auch nicht umgehend das Problem beheben, aber immerhin schnell ein Ergebnis melden).
Irgendwie haben die meisten Admins im Umfeld von Virtualisierung schon religiösen Charakter, wer dann Jehova sagt (oder VM sind nicht immer die optimale Lösung), wird gesteinigt. Gerade Firebird Server selbst zu sichern ist ziemlicher mumpitz, neben den Datenbanken ändert sich da hoffentlich fast nie was, wenn die dedicated sind. Warum also jeden Tag sichern? Die Datenbanken sollten eher noch öfter gesichert werden, ob stündlich durch Shadows oder in Realtime per Replikation, da steckt die Arbeit am Ende drin.
Kleiner Tip: Einfach mal in einem unscheinbaren Bereich der Datenbankdatei mit einem Hex Editor die
DB bewusst beschädigen und dann abwarten, ob der Kunde mit seiner Strategie das merkt oder tagelang eine kaputte
DB absichert, die unbrauchbar ist. Solche Diskussionen wecken viele Schlaumeier oder zumindest deren Vorgesetzte oft auf.