4
MS SQL Server - Sicherung von MDF-Dateien
MDF-Sicherung ohne Log-Datei sinnvoll?
Hallo zusammen,
mal so ne Frage in die Runde:
mir ist aufgefallen, dass wir bei unseren nächtlichen Sicherungsläufen (Band) nicht nur die bak-Dateien sichern, die über die Wartung des SQL Servers erstellt werden, sondern auch die DB-Dateien (MDF), aber ohne Tx-Logs (LDF). Macht das überhaupt Sinn oder reicht es aus Eurer Sicht aus, nur die BAK-Dateien zu sichern? Es sieht für mich ein wenig "doppelt gemoppelt" aus, mal abgesehen davon, dass ich eine MDF ohne LDF gar nicht zur Wiederherstellung verwenden kann oder doch?? Wenn ja, kann ich das auch über die GUI/Enterprise Manager oder nur per TSQL? Durch das Weglassen der MDFs in unserer Bandsicherung könnten wir dadurch eine Menge Speicherplatz sparen.
Was meint Ihr dazu bzw. wie sieht Eurer Backup/Restore-Szenario aus? Danke für Eure Meinung!
Viele Grüße, Maze
Hallo zusammen,
mal so ne Frage in die Runde:
mir ist aufgefallen, dass wir bei unseren nächtlichen Sicherungsläufen (Band) nicht nur die bak-Dateien sichern, die über die Wartung des SQL Servers erstellt werden, sondern auch die DB-Dateien (MDF), aber ohne Tx-Logs (LDF). Macht das überhaupt Sinn oder reicht es aus Eurer Sicht aus, nur die BAK-Dateien zu sichern? Es sieht für mich ein wenig "doppelt gemoppelt" aus, mal abgesehen davon, dass ich eine MDF ohne LDF gar nicht zur Wiederherstellung verwenden kann oder doch?? Wenn ja, kann ich das auch über die GUI/Enterprise Manager oder nur per TSQL? Durch das Weglassen der MDFs in unserer Bandsicherung könnten wir dadurch eine Menge Speicherplatz sparen.
Was meint Ihr dazu bzw. wie sieht Eurer Backup/Restore-Szenario aus? Danke für Eure Meinung!
Viele Grüße, Maze
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 68060
Url: https://administrator.de/contentid/68060
Ausgedruckt am: 13.11.2024 um 00:11 Uhr
4 Kommentare
Neuester Kommentar
Normalerweise hat der SQL Server die MDF Dateien im exklusiven Zugriff, bei uns können deswegen die MDF gar nicht gesichert werden.
Außerdem: Wir haben z.T. mehr als eine MDF/NDF Datei pro Datenbank da kann bei einer Sicherung der Dateien ja gar keine Konsistenz der Datenbank sichergestellt werden.
Wir sichern die Datenbank Online (also über TSQL Backup Database) und dann noch das Transaktionsprotokoll mit TSQL Backup Log.
Die dabei erzeugten Dateien werden dann über die Filesicherung des Servers auf Band gesichert.
Wenn Du eine Point in Time Recovery machen willst, musst Du eh auf den Sicherungen des SQL Servers aufsetzen, direkt mit den MDF Dateien kommst Du da nicht weit.
-> Also die MDF nicht sichern. Und falls Du die sichern willst (als letzten Rettungsacker) vorher den SQL Server beenden.
Außerdem: Wir haben z.T. mehr als eine MDF/NDF Datei pro Datenbank da kann bei einer Sicherung der Dateien ja gar keine Konsistenz der Datenbank sichergestellt werden.
Wir sichern die Datenbank Online (also über TSQL Backup Database) und dann noch das Transaktionsprotokoll mit TSQL Backup Log.
Die dabei erzeugten Dateien werden dann über die Filesicherung des Servers auf Band gesichert.
Wenn Du eine Point in Time Recovery machen willst, musst Du eh auf den Sicherungen des SQL Servers aufsetzen, direkt mit den MDF Dateien kommst Du da nicht weit.
-> Also die MDF nicht sichern. Und falls Du die sichern willst (als letzten Rettungsacker) vorher den SQL Server beenden.
Hallo,
ich kenne den "Leasy SQL" Server zwar nicht kann aber beschrieben wie wir unsere MSSQL Server sichern, oder welche Möglichkeiten es gibt.
1. SQL Server herunterfahren, per File Backup die Datenbanken abziehen, SQL Server wiedere starten. Nachchteil ist hier natürlich das der Server währen des Backups nicht läuft.
2. internes Backup Tool des SQL Servers nutzen und die Dumps/Backups ins Filesystem schreiben, dort per File Backup abholen und sichern. Hat den Nachteil das der Doppelte Platz auf den Storage Systemen vorhanden sein muss. Wenn der Server abschmiert ist auch die letzte Sicherunge wech.
3. Backup Software mit entsprechenden Agents benutzen. Hier online Sicherungen der Datenbanken und periodische Sicherungen der Logs machen.
Wir nutzen die letzte Möglichkeit, hat den Vorteil das kein Plattenplatz verschwendet wird, was bei grossen Datenbanken und schnellem Storage schon ins Geld gehen kann. Ausserdem liegen die Daten relativ sicher auf den Bändern. Wir können Point in Time recoverys usw. machen.
Nochmal zu deinder Frage mit mdf und ldf. Mir ist kein Datenbanksystem bekannt bei dem Du einfach nur mit der Datenbankdatei ein Recovery der Datenbank machen kannst. Du brauchst immer die passenden Logfiles dazu. Die mdf und ldf kannst Du also getrost aus dem Backup nehmen, die Chancen sind gross das die Datenbankdatei zum backup zeitpunkt geöffnet war uns somit nicht konsistent auf dem Tape gelandet ist.
Du solltest sowieso mal ins Auge fassen einen recovery Test des Servers zu machen, dann weisst Du mit Sicherheit ob deine Strategie funktioniert. Ausserdem kannst Du dann schon mal einen Plan entwickeln, im Erstfall willst Du ja nicht "Jugend forscht" spielen.
Beim MSSQL Server ist z.B. ohne Master Datenbank nichts zu machen. Wenn Du nun den Windows Server per Desaster Recovery wiederholst, hast Du ja noch keinen Master Datenbank. Diese kann den mit dem recreate Master Tool, erzeugt werden. Erst dann lassen sich die SQL Services starten um eine restore aller Datenabnks (inkl. master) zu fahren. Das sind aber alles Dinge die nur bei einem Test hochkommen.
Bis dann
VoSp
ich kenne den "Leasy SQL" Server zwar nicht kann aber beschrieben wie wir unsere MSSQL Server sichern, oder welche Möglichkeiten es gibt.
1. SQL Server herunterfahren, per File Backup die Datenbanken abziehen, SQL Server wiedere starten. Nachchteil ist hier natürlich das der Server währen des Backups nicht läuft.
2. internes Backup Tool des SQL Servers nutzen und die Dumps/Backups ins Filesystem schreiben, dort per File Backup abholen und sichern. Hat den Nachteil das der Doppelte Platz auf den Storage Systemen vorhanden sein muss. Wenn der Server abschmiert ist auch die letzte Sicherunge wech.
3. Backup Software mit entsprechenden Agents benutzen. Hier online Sicherungen der Datenbanken und periodische Sicherungen der Logs machen.
Wir nutzen die letzte Möglichkeit, hat den Vorteil das kein Plattenplatz verschwendet wird, was bei grossen Datenbanken und schnellem Storage schon ins Geld gehen kann. Ausserdem liegen die Daten relativ sicher auf den Bändern. Wir können Point in Time recoverys usw. machen.
Nochmal zu deinder Frage mit mdf und ldf. Mir ist kein Datenbanksystem bekannt bei dem Du einfach nur mit der Datenbankdatei ein Recovery der Datenbank machen kannst. Du brauchst immer die passenden Logfiles dazu. Die mdf und ldf kannst Du also getrost aus dem Backup nehmen, die Chancen sind gross das die Datenbankdatei zum backup zeitpunkt geöffnet war uns somit nicht konsistent auf dem Tape gelandet ist.
Du solltest sowieso mal ins Auge fassen einen recovery Test des Servers zu machen, dann weisst Du mit Sicherheit ob deine Strategie funktioniert. Ausserdem kannst Du dann schon mal einen Plan entwickeln, im Erstfall willst Du ja nicht "Jugend forscht" spielen.
Beim MSSQL Server ist z.B. ohne Master Datenbank nichts zu machen. Wenn Du nun den Windows Server per Desaster Recovery wiederholst, hast Du ja noch keinen Master Datenbank. Diese kann den mit dem recreate Master Tool, erzeugt werden. Erst dann lassen sich die SQL Services starten um eine restore aller Datenabnks (inkl. master) zu fahren. Das sind aber alles Dinge die nur bei einem Test hochkommen.
Bis dann
VoSp
Hi Andreas,
vielen Dank für Deinen Beitrag!
Stimmt eigentlich ... Aufgrund Deines Beitrags habe ich gerade erstmal nachgeschaut, ob die MDFs wirklich mitgesichert werden. Und sie werden es tatsächlich nicht bzw. sind auf dem Band nicht vorhanden. Komisch, aber unsere Bandsicherung meckert nicht. Muss ich mal klären.
Bei uns genauso, halt eben nur per Software und nicht als Skript. Die Software arbeitet aber
mit denselben SQL-Befehlen.
Da gibt es doch irgendsoeinen Befehl "Restore db ... with move ..." und dann kann man die alten MDF-Dateien und die LDF-Datei in eine neu angelegt DB zurücksichern glaube ich. Das müsste dann ja auch eigentlich über die GUI möglich sein, gell! Bin bei TSQL nicht so sicher im Thema. Die Frage wäre jetzt, ob die LDF ggf. automatisch neu erstellt wird, wenn ich bspw. nur die MDFs zur Verfügung habe. Wenn ich den Server vorher runtergefahren habe, müssten doch eigentlich keine Tx mehr im Log sein, die noch nicht in der DB sind, oder?
Viele Grüße, Maze
vielen Dank für Deinen Beitrag!
Normalerweise hat der SQL Server die MDF
Dateien im exklusiven Zugriff, bei uns
können deswegen die MDF gar nicht
gesichert werden.
Dateien im exklusiven Zugriff, bei uns
können deswegen die MDF gar nicht
gesichert werden.
Stimmt eigentlich ... Aufgrund Deines Beitrags habe ich gerade erstmal nachgeschaut, ob die MDFs wirklich mitgesichert werden. Und sie werden es tatsächlich nicht bzw. sind auf dem Band nicht vorhanden. Komisch, aber unsere Bandsicherung meckert nicht. Muss ich mal klären.
Außerdem: Wir haben z.T. mehr als eine
MDF/NDF Datei pro Datenbank da kann bei einer
Sicherung der Dateien ja gar keine Konsistenz
der Datenbank sichergestellt werden.
Wir sichern die Datenbank Online (also
über TSQL Backup Database) und dann noch
das Transaktionsprotokoll mit TSQL Backup
Log.
Die dabei erzeugten Dateien werden dann
über die Filesicherung des Servers auf
Band gesichert.
MDF/NDF Datei pro Datenbank da kann bei einer
Sicherung der Dateien ja gar keine Konsistenz
der Datenbank sichergestellt werden.
Wir sichern die Datenbank Online (also
über TSQL Backup Database) und dann noch
das Transaktionsprotokoll mit TSQL Backup
Log.
Die dabei erzeugten Dateien werden dann
über die Filesicherung des Servers auf
Band gesichert.
Bei uns genauso, halt eben nur per Software und nicht als Skript. Die Software arbeitet aber
mit denselben SQL-Befehlen.
Wenn Du eine Point in Time Recovery machen
willst, musst Du eh auf den Sicherungen des
SQL Servers aufsetzen, direkt mit den MDF
Dateien kommst Du da nicht weit.
-> Also die MDF nicht sichern. Und falls
Du die sichern willst (als letzten
Rettungsacker) vorher den SQL Server beenden.
willst, musst Du eh auf den Sicherungen des
SQL Servers aufsetzen, direkt mit den MDF
Dateien kommst Du da nicht weit.
-> Also die MDF nicht sichern. Und falls
Du die sichern willst (als letzten
Rettungsacker) vorher den SQL Server beenden.
Da gibt es doch irgendsoeinen Befehl "Restore db ... with move ..." und dann kann man die alten MDF-Dateien und die LDF-Datei in eine neu angelegt DB zurücksichern glaube ich. Das müsste dann ja auch eigentlich über die GUI möglich sein, gell! Bin bei TSQL nicht so sicher im Thema. Die Frage wäre jetzt, ob die LDF ggf. automatisch neu erstellt wird, wenn ich bspw. nur die MDFs zur Verfügung habe. Wenn ich den Server vorher runtergefahren habe, müssten doch eigentlich keine Tx mehr im Log sein, die noch nicht in der DB sind, oder?
Viele Grüße, Maze
Hi VoSp,
vielen Dank für Deine ausführlichen und treffenden Hinweise.
Jupp, 3. machen wir auch (& zum Teil auch 2. wie in der anderen Antwort zu Andreas' Beitrag beschrieben) noch. Dass heisst wir sichern online und die vom SQL-Server erstellten BAK-Dateien - eben auf Band.
Das mit dem Recovery-Test ist ein guter Hinweis. Dazu müsste man mal ne anständige Testumgebung aufsetzen, aber das ist eben so ein Problem in unserer kleinen Infrastruktur ...
PS: der "Leasy-Server" ist ein MS SQL 2000er. Läuft halt die "Leasy-DB" drauf. Sorry.
Viele Grüße, Maze
vielen Dank für Deine ausführlichen und treffenden Hinweise.
Jupp, 3. machen wir auch (& zum Teil auch 2. wie in der anderen Antwort zu Andreas' Beitrag beschrieben) noch. Dass heisst wir sichern online und die vom SQL-Server erstellten BAK-Dateien - eben auf Band.
Das mit dem Recovery-Test ist ein guter Hinweis. Dazu müsste man mal ne anständige Testumgebung aufsetzen, aber das ist eben so ein Problem in unserer kleinen Infrastruktur ...
PS: der "Leasy-Server" ist ein MS SQL 2000er. Läuft halt die "Leasy-DB" drauf. Sorry.
Viele Grüße, Maze
