Verknüpfung und Wiederherstellung von Datenbank aus vollständigem und differentiellem Backup

[gerd33 18]

Hallo zusammen, bin gerade dabei meinen neuen Server aufzusetzen. Die Kiste läuft auf Windows Server 2022 Standard, der SQL Server 2022 Standard ist für die Datenbank zuständig.

Im Rahmen meines neuen Datensicherungskonzeptes möchte ich mit einer vollständigen Sicherung und einer differenzieren Sicherung zusammen arbeiten. Mein Wartungsplan schreibt wöchentlich ein vollständiges Backup ins Sicherungsverzeichnis und stündlich jeweils eine differenzielle Sicherung in ein anderes Verzeichnis.

Somit habe ich zu jedem Zeitpunkt eine vollständige Sicherung und eine max. 1h alte differenzielle Sicherung verfügbar.

 

Allerdings habe ich beim Zurückspielen der Dateien in meiner Testumgebung, massive Schwierigkeiten: Ich kann über das Management Studio nur die vollständige Sicherung wiederherstellen. Der Versuch, die vollständige Sicherung und die differenzielle Sicherung mit dem Management Studio zu verknüpfen, endet in Fehlermeldungen. Ich habe alle möglichen Einstellungen probiert, nichts hat funktioniert. Hab ich noch dazu ein YouTube Video gesehen, wo schon bei der Sicherung die vollständige und die differenzielle Sicherung jeweils zu einer einzigen Datei zusammen gefasst worden sind was ich aber auch nicht ganz nachvollziehen kann.

 

Hat jemand vielleicht eine Idee oder einen Link wo das ausführlich beschrieben wird. Ich hab mich da schon tot gegoogelt, aber nichts gefunden.

Bin für jeden Hinweis dankbar.

 

Beste Grüße, Gerd

[Dukel 454]

Wieso sicherst du nicht das Full und Diff Backup in ein einzelnes Backup File?

[q617 1]

vor 30 Minuten schrieb Dukel:

Wieso sicherst du nicht das Full und Diff Backup in ein einzelnes Backup File?

Hast Du für diese Empfehlung eine Quelle? Eine einzige Quelle?

[Dukel 454]

Empfehlung wäre übetrieben.

Ich nutze bei Kunden 3rd Party Software für Backups.

 

In der Anleitung von MS wird kein expliziter Pfad für das Diff. Backup angegeben.

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/create-a-differential-database-backup-sql-server?view=sql-server-ver16

[NilsK 2.934]

Moin,

 

hier habe ich die Grundlagen mal ausführlich zusammengefasst:

 

[SQL Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net]
https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/

 

Zugegebenermaßen ist der Teil, nach dem du fragst, etwas knapp geraten. Dazu findest du hier aber mehr - ist eigentlich auch sehr leicht zu finden.

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-differential-database-backup-sql-server?view=sql-server-ver16

 

Ich würde an deiner Stelle aber noch mal schauen, ob das Verfahren das richtige ist. Das kann sein, aber vielleicht ist auch eine Kombination mit Log-Backups günstiger.

 

Gruß, Nils

 

[gerd33 18]

Danke an alle.

Konkret versuche ich, die vollständige BAK-Datei (z.B. vom So.) mit der differenziellen BAK-Datei (z.B. vom darauf folgenden Mittwoch) zusammen wiederherzustellen, um eine gemeinsame Datenbank zu erhalten. Geht das überhaupt mit den Mitteln des Managemant-Studios? Also aus 2 BAK-Dateien eine einzige machen und damit die Datenbank wiederherzustellen.

 

[NilsK 2.934]

Moin,

 

Beschreibt der genannte Artikel das nicht? 

 

Man stellt die Backups nacheinander wieder her, dazu muss man dem ersten Restore sagen, dass noch ein zweites folgt. Das macht das Management Studio aber selbst.

 

Gruß, Nils

bearbeitet 9. August 2023 von NilsK

[q617 1]

vor 20 Stunden schrieb Dukel:

Empfehlung wäre übetrieben.

Ist das technisch überhaupt möglich? Anforderung des OP bezog sich auf Management Studio.

[Dukel 454]

Wieso sollte das nicht möglich sein? In einer Backup Datei können mehrere Backups sein.

 

BACKUP DATABASE [Test] TO  DISK = N'F:\DB-Backup\Backup-Test.bak' WITH NOFORMAT, NOINIT,  NAME = N'Test-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO


BACKUP DATABASE [Test] TO  DISK = N'F:\DB-Backup\Backup-Test.bak' WITH  DIFFERENTIAL , NOFORMAT, NOINIT,  NAME = N'Test-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

 

Aber den Restore aus zwei (Full + Diff) ist auch möglich. Wie in der Anleitung von Nils gepostet:

 

USE [master]

RESTORE DATABASE [Restore-Test] FROM  DISK = N'F:\DB-Backup\Backup-Test-Full.bak' WITH  FILE = 1, NORECOVERY,  NOUNLOAD,  STATS = 5
GO

RESTORE DATABASE [Restore-Test] FROM  DISK = N'F:\DB-Backup\Backup-Test-Full.bak' WITH  FILE = 1, RECOVERY,  NOUNLOAD,  STATS = 5
GO

 

Wichtig ist das "Norecovery" bzw. "Recovery".

bearbeitet 10. August 2023 von Dukel

[gerd33 18]

Werde ich mal austesten.
Danke für die Unterstützung.

Ich denke dass die bisherige Probleme daher kamen, dass die BAKs von SQLServer 2014 stammten. möglichweise gibts da ein Kompatibilitätsproblem zum SQLServer 2022.

Gerd

[t-sql 18]

Am 9.8.2023 um 09:05 schrieb Dukel:

Wieso sicherst du nicht das Full und Diff Backup in ein einzelnes Backup File?

@DukelWeil das eine ziemlich schlechte Idee ist und auch von niemanden empfohlen wird.
@gerd33 1. Wieso machst Du differenzielle Backups? Irgendwann sind die gleichgroß oder größer als die eigentliche Datenbank. 2. Was für Fehlermeldungen bekommst Du denn?  3. Wie machst Du den Restore? Über das SSMS? 4. Backups können immer in die aktuellste SQL Server Version aus einer älter zurückgesichert werden. Da gibt es keinerlei Kompatibilitätsprobleme.

[gerd33 18]

Endlich hat es geklappt. Mein Fehler war wohl, dass die Vollsicherung von einem anderen Rechner
(SQLServer 2014) übernommen wurde und die differenzielle Sicherung auf dem neuen Rechner mit SQLServer 2022
erstellt wurde. Die Vollsicherung hatte alsm Eigentümer "NT-Authority, die differenzielle Sicherung hingegen
"sa". Könnte evtl. die Ursache gewesen sein.
Nachdem ich die Datenbank vom alten Server auf den neuen Server portiert hatte (unproblematisch) habe ich dort
erneut eine Vollsicherung gemacht, mehrere Datensätze geändert und dann eine sequenzielle Sicherung
durchlaufen lassen. Das Zusammenführen der beiden Sicherungen im Management Studio klappte dann problemlos. 
Verwundert hat mich nur, dass sowohl die Voll- als auch die differenzielle Sicherung im Rücksicherungs-Fenster
im Management-Studio jeweils die Reihenfolge "1" hatten. Hat aber die Rücksicherung nicht beeinträchtigt.
Ob es Sinn macht, eine zusätzliche Transaktionsprotokoll-Sicherung turnusmäßig durchlaufen zu lassen, 
weiss ich nicht, der Sinn erschließt sich mir nicht. 
Im Produktivbetrieb werde ich eine wöchentliche Vollsicherung in der Cloud, eine stündliche 
sequenzielle Sicherung, nur tagsüber, ebenfalls in der Cloud und eine nächtliche Vollsicherung
auf einem täglich gewechselten RDX-Medium in die Wartungspläne implementieren. 
Danach dürfte das System dann wohl Safe sein.

Danke für eure Unterstützung,

Gerd

 

bearbeitet 12. August 2023 von gerd33

[t-sql 18]

vor 46 Minuten schrieb gerd33:

Endlich hat es geklappt. Mein Fehler war wohl, dass die Vollsicherung von einem anderen Rechner
(SQLServer 2014) übernommen wurde und die differenzielle Sicherung auf dem neuen Rechner mit SQLServer 2022
erstellt wurde. Die Vollsicherung hatte alsm Eigentümer "NT-Authority, die differenzielle Sicherung hingegen
"sa". Könnte evtl. die Ursache gewesen sein.
Nachdem ich die Datenbank vom alten Server auf den neuen Server portiert hatte (unproblematisch) habe ich dort
erneut eine Vollsicherung gemacht, mehrere Datensätze geändert und dann eine sequenzielle Sicherung
durchlaufen lassen. Das Zusammenführen der beiden Sicherungen im Management Studio klappte dann problemlos. 
Verwundert hat mich nur, dass sowohl die Voll- als auch die differenzielle Sicherung im Rücksicherungs-Fenster
im Management-Studio jeweils die Reihenfolge "1" hatten. Hat aber die Rücksicherung nicht beeinträchtigt.
Ob es Sinn macht, eine zusätzliche Transaktionsprotokoll-Sicherung turnusmäßig durchlaufen zu lassen, 
weiss ich nicht, der Sinn erschließt sich mir nicht. 

Danke für eure Unterstützung,

Gerd

 

Nur ums zu verstehen: Du hast deine Vollbackup von SQL Server 2014 im SQL Server 2022 wiederhergestellt (portiert ist hier der falsche Terminus, die Datenbank wird nicht portiert, sondern höchstens importiert. Dann kein Fullbackup erstellt sondern gleich das differenzielle Backup angeschmissen (wenig sinnvoll, Stichwort Backup Chain). Immer zu erst ein Fullbackup und dann die nachfolgenden. Der Eigentümer hat damit nichts zu tun.  Zum Punkt Transaktionsprotokoll Sicherung: Brauchst du nicht, wenn deine Datenbank auf Simple Recovery steht. Sollte sie jedoch auf Bulk oder Full Recovery stehen, empfehle ich Dir dringend dich in das Thema Backup & Restore von SQL Server Datenbanken einzulesen, da hier ein Know How Defizit besteht. Is ja dann nur eine Frage der Zeit wann deine Datenbank/Verfahren stehen bleibt.  Sequenzielle Sicherung gibt es im SQL Server nicht: Es gibt Full, Diff und Transaction.  Dann noch eine Info, die du wohl überlesen hast: Es kommt der Punkt wo die differentielle gleich oder größer als deine eigentliche Datenbank ist. Warum ist das so? Beim differenziellen werden IMMER die Änderungen der Datenbank gespeichert NICHT die Änderungen zwischen zwei differentiellen Backups.

[Dukel 454]

vor einer Stunde schrieb gerd33:

Im Produktivbetrieb werde ich eine wöchentliche Vollsicherung in der Cloud, eine stündliche 
sequenzielle Sicherung, nur tagsüber, ebenfalls in der Cloud und eine nächtliche Vollsicherung
auf einem täglich gewechselten RDX-Medium in die Wartungspläne implementieren. 
Danach dürfte das System dann wohl Safe sein.

 

Hast du dir auch Gedanken über die Anforderungen (RTO, RPO) gemacht oder einfach mal irgendwas überlegt?

 

Wie wäre es mit einem einzelnen Backup (Lokal auf Disk oder RDX) und dieses dann in die Cloud Replizieren?

Wieso das Log Backup nur in die Cloud?

[gerd33 18]

Über die Größe der differentiellen Backups mache ich mit keine Sorgen, zumal nach dem wöchentlichen Full Backup die differenziellen Backups der Vorwoche gelöscht werden können. Die volle Backup-Sicherung in der Cloud kann nur am Wochenende erfolgen, da die Internetanbindung in der Praxis hier nur 50er Leitung ist. Schneller geht nicht, Glasfaser nicht in Aussicht. Die größte Einzel-DB hat ca. 30 GB, die gesamten differenziellen DBs, die stündlich in der Cloud landen haben nur ca. 20 MB., d.h. nach 1 Woche sind hier nur ca. 2 GB an differenziellen Backups in der Cloud + die 30 GB der letzten Vollsicherung.  30GB täglich in die Cloud hochzuladen, würde mein Netz massivst ausbremsen. Zumal im Tagesverlauf auch die Nebenpraxis über VPN auf die DB zugreift.

Die ganzen SIcherungsroutinen habe ich mit dem Wartungsplan-Assistent erstellt; nachdem keine Fehlermeldung mehr kommen, gehe ich davon aus, dass ich das alles richtig gemacht habe. RTO und RPO hab ich bislang nix von gehört; Bei der Installation meiner Datenbanken auf dem SQL Server habe ich mich an die Manuals meines Software-Lieferanten gehalten.

Auf meinem aktuellen System (Win Server 2012, SQL Server 2014) läuft der Kram seit 2015 stabil (allerdings nur mit nächtlicher Sicherung auf RDX-Mediium), nur dass jetzt einfach mal eine neue Hardware mit neuer Software fällig ist.

 

Der Umzug auf den neuen Server ist ohnehin schwierig genug: Es sind auf dem "alten SQL-Server noch 2 Datenbank-Instanzen anderer Hersteller vorhanden (Anbindung medizintechnischer Geräte), diese DBs werden aber von den jeweiligen Vertragshändlern umgezogen. Dadurch wird sich der Migrationsprozess ohnehin über mehrere Wohen erstrecken. Ist aber unproblematisch, da so lange beide Server online bleiben und nur die Ausgabe-Dokumente der Medizintechnischen Geräte (PDFs) statt in den Importpfad des "alten" Servers in den Importpfad des "neuen" Servers geschrieben werden, wo sich in diesem freigegebenen Verzeichnis die Software die Dateien holt und in eine SQL-Datenbank importiert.