Hallo zusammen,
ich jage gerade einem Problem hinterher und bin dem Ganzen endlich auf der Spur. Wir betreiben in einer Windows-VM einen SQL Server samt Azure DevOps Server für unsere kleine Softwareentwicklung. Die VM ist hochverfügbar und repliziert sich im 15 Minuten Raster auf den zweiten Server im Cluster.
Vom SQL Server wird an jedem Freitag ein volles Backup und an den Wochentagen jeweils differentielle Backups gezogen. Zumindest so die Theorie bzw. gehen die differentiellen Backups immer in die Hose. Grund ist eine "kaputte Historie" bzw. behauptet der SQL-Server das keine vollständige Datenbanksicherung vorhanden ist oder er schlicht keine Informationen mehr darüber hat.
Und der Grund liegt wohl an der ZFS Replikation. Im Windows Log sehe ich das im 15 Minuten Raster ein Backup aller Datenbanken erzeugt wird, also bei jeder anstehenden Replikation. Es sind Backups vom Typ "Virtual Device" und is_snapshot steht auf 1.
Nachfolgend ein Link - der Blogger befasst sich mit dem selben Thema und hat eine SQL-Query gepostet mit welcher man sich eine komplette Backup-Historie auflisten kann (also auch die "virtuellen Backups" welche eigenmächtig vom System getätigt wurden): Who is taking backup of SQL Server database?
So wie ich das bis jetzt verstanden habe (bitte ggf. korrigieren):
Die ZFS Replikation übers Netzwerk wird via Snapshots getätigt. Dabei wird der VSS Dienst in Windows ausgelöst, welcher wiederum die VSS-Schreiber informiert das ein Backup stattfindet. Im Falle des SQL Servers betrifft es den "SQL Server VSS Writer" - dieser kümmert sich darum das die ausstehenden I/O Operationen auf die Platte geschrieben werden, so dass das Backup der Festplatte mit den Anwendungsdaten konsistente transaktionale Informationen enthält.
Die Datenbank ist also im konsistenten Zustand und die Snapshot Daten können repliziert werden.
So die graue Theorie wie der Spuk funktioniert. Problem ist aber wie gesagt das dadurch meine SQL Historie kaputt geht.
Deswegen die Frage ob und wie man das anders lösen kann ?? ... so das zukünftig auch differentielle Backups etc. möglich sind.
Ich bin da neu im Thema und lerne immer gerne dazu.
ich jage gerade einem Problem hinterher und bin dem Ganzen endlich auf der Spur. Wir betreiben in einer Windows-VM einen SQL Server samt Azure DevOps Server für unsere kleine Softwareentwicklung. Die VM ist hochverfügbar und repliziert sich im 15 Minuten Raster auf den zweiten Server im Cluster.
Vom SQL Server wird an jedem Freitag ein volles Backup und an den Wochentagen jeweils differentielle Backups gezogen. Zumindest so die Theorie bzw. gehen die differentiellen Backups immer in die Hose. Grund ist eine "kaputte Historie" bzw. behauptet der SQL-Server das keine vollständige Datenbanksicherung vorhanden ist oder er schlicht keine Informationen mehr darüber hat.
Und der Grund liegt wohl an der ZFS Replikation. Im Windows Log sehe ich das im 15 Minuten Raster ein Backup aller Datenbanken erzeugt wird, also bei jeder anstehenden Replikation. Es sind Backups vom Typ "Virtual Device" und is_snapshot steht auf 1.
Nachfolgend ein Link - der Blogger befasst sich mit dem selben Thema und hat eine SQL-Query gepostet mit welcher man sich eine komplette Backup-Historie auflisten kann (also auch die "virtuellen Backups" welche eigenmächtig vom System getätigt wurden): Who is taking backup of SQL Server database?
So wie ich das bis jetzt verstanden habe (bitte ggf. korrigieren):
Die ZFS Replikation übers Netzwerk wird via Snapshots getätigt. Dabei wird der VSS Dienst in Windows ausgelöst, welcher wiederum die VSS-Schreiber informiert das ein Backup stattfindet. Im Falle des SQL Servers betrifft es den "SQL Server VSS Writer" - dieser kümmert sich darum das die ausstehenden I/O Operationen auf die Platte geschrieben werden, so dass das Backup der Festplatte mit den Anwendungsdaten konsistente transaktionale Informationen enthält.
Die Datenbank ist also im konsistenten Zustand und die Snapshot Daten können repliziert werden.
So die graue Theorie wie der Spuk funktioniert. Problem ist aber wie gesagt das dadurch meine SQL Historie kaputt geht.
Deswegen die Frage ob und wie man das anders lösen kann ?? ... so das zukünftig auch differentielle Backups etc. möglich sind.
Ich bin da neu im Thema und lerne immer gerne dazu.