5
MS SQL Server B2D bereinigen
Hi,
wir sichern diverse MS-SQL-Instanzen mit MS-SQL-Bordmitteln auf Disk. Dabei werden per Wartungsplan z.B. wöchentlich je Datenbank eine Vollsicherung und täglich eine Differenzsicherung erstellt. Soweit kein Problem.
In diesen Wartungsplänen sind auch Schritte "Wartung bereinigen" enthalten, welche z.B. die Voll- und Differenzsicherungen nach 2 Wochen wieder löschen. So weit so gut.
Meine Frage:
Macht es einen Unterschied, ob man die Bereinigung der Backupdateien mit einem SQL-Wartungsauftrag ausführt (sprich: mit SQL-Kommandos) oder ob man die Dateien am SQL-Server vorbei auf der Freigabe löscht? Merkt der Server sich jede einzelne Backup-Datei, welche er für eine DB erstellt und noch nicht wieder gelöscht hat oder sucht er beim Wiederherstellen einfach in der Freigabe nach verfügbaren Backups für die jeweilige DB?
E.
wir sichern diverse MS-SQL-Instanzen mit MS-SQL-Bordmitteln auf Disk. Dabei werden per Wartungsplan z.B. wöchentlich je Datenbank eine Vollsicherung und täglich eine Differenzsicherung erstellt. Soweit kein Problem.
In diesen Wartungsplänen sind auch Schritte "Wartung bereinigen" enthalten, welche z.B. die Voll- und Differenzsicherungen nach 2 Wochen wieder löschen. So weit so gut.
Meine Frage:
Macht es einen Unterschied, ob man die Bereinigung der Backupdateien mit einem SQL-Wartungsauftrag ausführt (sprich: mit SQL-Kommandos) oder ob man die Dateien am SQL-Server vorbei auf der Freigabe löscht? Merkt der Server sich jede einzelne Backup-Datei, welche er für eine DB erstellt und noch nicht wieder gelöscht hat oder sucht er beim Wiederherstellen einfach in der Freigabe nach verfügbaren Backups für die jeweilige DB?
E.
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: 11553418774
Url: https://administrator.de/contentid/11553418774
Ausgedruckt am: 18.12.2024 um 18:12 Uhr
5 Kommentare
Neuester Kommentar
Nicht das ich wüsste.
Bei mir ist aber der Wartungsschritt "Bereinigen" als Bedingung einer erfolgreichen Sicherung drinnen.
Sprich wenn mit der Sicherung mal was nicht stimmt, werden auch abgelaufene nicht gelöscht..
Wenn du das unabhängig davon machst kannst du das schwerer überprüfen.
Bei mir ist aber der Wartungsschritt "Bereinigen" als Bedingung einer erfolgreichen Sicherung drinnen.
Sprich wenn mit der Sicherung mal was nicht stimmt, werden auch abgelaufene nicht gelöscht..
Wenn du das unabhängig davon machst kannst du das schwerer überprüfen.
Moin,
Willst du aber den Donnerstag zurücksichern, braucht er ja das jüngste Fullbackup.
Haust du, wie von @wiesi200 schon geschrieben, die Dateien stumpf weg, wird das mit dem Restore nichts.
Und wenn am 24.12. dann keine Backups mehr generiert werden (platte voll) und ihr am 03.01. zurück kommt, wäre es doof, wenn dann dort etwas fehlt.
Was passiert bei euch eigentlich mit den TransactionLogs - oder meint ihr das mit den Diffs/ Increments?
Wir versuchen (mit zwei Ausnahmen) die DBs immer via VEEAM wegzusichern. Dort wird im 15Minuten-Takt das Transaction-Log gesichert und Abends/ Nachts die DB Komplett. Aufräumen macht Veeam selbst - wenn alles erfolgreich gewesen ist. Bei den beiden Ausnahmen läuft es wie oben beschrieben: nur wenn die Backup-Kette sauber ist, werden (ggf.) zurückliegende Files bereinigt.
Ob MS SQL aber intern irgendwo merkt, ob die ganze Kette vollständig ist, weiss ich gerade nicht. Gemeckert hatte der MSSQL aber mal, als ich eine trn zurücksichern wollte. Irgendwas fehlte im in der Kette. Kann also gut sein, dass der interne Agent weiss, ob alles da ist (oder eben nicht).
wöchentlich je Datenbank eine Vollsicherung und täglich eine Differenzsicherung erstellt. Soweit kein Problem.
Für den Restore eines FullBackups werden die Diffs ja nicht benötigt.Willst du aber den Donnerstag zurücksichern, braucht er ja das jüngste Fullbackup.
Haust du, wie von @wiesi200 schon geschrieben, die Dateien stumpf weg, wird das mit dem Restore nichts.
Und wenn am 24.12. dann keine Backups mehr generiert werden (platte voll) und ihr am 03.01. zurück kommt, wäre es doof, wenn dann dort etwas fehlt.
Was passiert bei euch eigentlich mit den TransactionLogs - oder meint ihr das mit den Diffs/ Increments?
Wir versuchen (mit zwei Ausnahmen) die DBs immer via VEEAM wegzusichern. Dort wird im 15Minuten-Takt das Transaction-Log gesichert und Abends/ Nachts die DB Komplett. Aufräumen macht Veeam selbst - wenn alles erfolgreich gewesen ist. Bei den beiden Ausnahmen läuft es wie oben beschrieben: nur wenn die Backup-Kette sauber ist, werden (ggf.) zurückliegende Files bereinigt.
Ob MS SQL aber intern irgendwo merkt, ob die ganze Kette vollständig ist, weiss ich gerade nicht. Gemeckert hatte der MSSQL aber mal, als ich eine trn zurücksichern wollte. Irgendwas fehlte im in der Kette. Kann also gut sein, dass der interne Agent weiss, ob alles da ist (oder eben nicht).
Prinzip und Zusammenhang von Voll- und Differenzbackup bzgl. Wiederherstellung ist mir klar.
Transactionlog-Sicherungen machen wir nur bei DB's, für welche das explizit angefordert wurde.
Aber das war ja nicht meine Frage.
Transactionlog-Sicherungen machen wir nur bei DB's, für welche das explizit angefordert wurde.
Aber das war ja nicht meine Frage.
Zitat von @wiesi200:
Bei mir ist aber der Wartungsschritt "Bereinigen" als Bedingung einer erfolgreichen Sicherung drinnen.
Sprich wenn mit der Sicherung mal was nicht stimmt, werden auch abgelaufene nicht gelöscht..
Wenn du das unabhängig davon machst kannst du das schwerer überprüfen.
Ja, so ist das bei uns auch. Aber das ist auch der Punkt.Bei mir ist aber der Wartungsschritt "Bereinigen" als Bedingung einer erfolgreichen Sicherung drinnen.
Sprich wenn mit der Sicherung mal was nicht stimmt, werden auch abgelaufene nicht gelöscht..
Wenn du das unabhängig davon machst kannst du das schwerer überprüfen.
Wir haben viele DB's in den Instanzen. Deshalb auch nur einen Wartungsplan mit Vollsicherung "alle Datenbanken". Wenn die Sicherung z.B. bei 99/100 Datenbanken mit Fehler abbricht, dann wird anschließend die Bereinigung nicht ausgeführt, auch nicht für die 98 erfolgreich gesicherten. Wenn dann ein Admin mal nicht sofort eingreift, dann bleiben u.U. die Sicherungsdaten länger auf der Freigabe, als gewollt, und das Laufwerk läuft voll.
Man müsste also je DB einen eigenen Plan erstellen, oder ein TSQL-Script schreiben, was die DB's der Reihe nach sichert und anschließend gleich für diese DB bereinigt, wenn Sicherung erfolgreich.
@em-pie
Ja, VEEAM haben wir auch im Einsatz und das wäre sicherlich das "Schönste". Aber warum auch immer, wird SQL bei uns über den Umweg mit dem B2D gesichert. Also SQL-Server --> B2D --> VEEAM. Das kann ich gerade nicht beantworten, warum das so ist. Ich betreue seit Jahresanfang unseren SQL-Cluster nur interimsweise.
Ja, VEEAM haben wir auch im Einsatz und das wäre sicherlich das "Schönste". Aber warum auch immer, wird SQL bei uns über den Umweg mit dem B2D gesichert. Also SQL-Server --> B2D --> VEEAM. Das kann ich gerade nicht beantworten, warum das so ist. Ich betreue seit Jahresanfang unseren SQL-Cluster nur interimsweise.
