none
Abschneiden SQL-LogFiles bei der Sicherung RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hi,

    wir sichern unsere SQL-Datenbanken (Vollständig) über BackupExec und dabei werden die Logs bekanntlich nicht abgeschnitten.
    http://www.backupexecfaq.com/articles/concepts/backing-up-microsoft-sql-server.html

    Aus diesem Grund schneide ich die Logs per Batch vor der Sicherung ab, denn ich möchte eigentlich bei einem nötigen Restore nur den aktuellen Tag absichern können:
    22:00Uhr Logs abschneiden - 22:05Uhr Backup DB - 14:23Uhr CrashDB
    Damit müsste ich dann doch einen Restore bis 14:22Uhr machen können.

    In dem oben genannten Link werden die Logs aber im Anschluss abgeschnitten. Welchen Sinn hat das: Dass ich durch einen Fullrestore auch an den vorangegangen Tag zu jedem Punkt springen kann, was ich in meinem Scenario nicht kann? ...will ich nach vorne müsste ich doch erst einen Full-Restore machen, die Logsicherung zurückspielen und dabei kann ich erst auf 14:22Uhr zurückspringen, denn ohne Logrestore wären die Logs nicht vollständig, richtig? :-? Es ist also nur davon abhängig in welche Richtung ich den Restore plane, oder?

    Wer bringt Licht ins dunkle und kann mir sagen, ob die Gedankengänge richtig sind?

    Viele Grüße
    Christian

    Montag, 17. Januar 2011 16:41
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Christian,

    so irgendwie liegst Du in Gänze falsch und gerade bei Backup sollte man sich besser keine Fehler erlauben. Lies Dir bitte unbedingt mal "Sichern und Wiederherstellen von Datenbanken in SQL Server" durch, dort ist alles umfangreich beschrieben.

    22:00Uhr Logs abschneiden - 22:05Uhr Backup DB - 14:23Uhr CrashDB
    Damit müsste ich dann doch einen Restore bis 14:22Uhr machen können.

    Ich nehme an, 14:23Uhr soll am Folgetag sein? Nein, dann kannst du nur das Backup von 22:05 Uhr zurücksichern, nicht mehr.

    Eine einfache Backup & Restore-Planung kann so aussehen:
    Um 0:00 Uhr wird ein Fullback erstellt, ab dann stündlich eine Log-Sicherung. Hast Du um 14:23 Uhr eine DB Crash, dann müsstest Du
    - Restore Fullback
    - + Kompletter Restore der Log-Backups von 01:00 - 14:00 Uhr
    - + Restore Log-Back von 15:00 Uhr (ohne der manuellen nach Crash) mit Stopppunkt auf 14:22 Uhr.

    Du solltest aber nie das Log "abschneiden" (Truncate_Only), weil das die Log-Sicherungskette unterbricht. In einer Log-Sicherung werden nur alle Änderungen seit der letzten Full/Log-Sicherung, deswegen werden immer alle Log-Sicherungen benötigt. Schneidest Du zwischendurch mal das Log ab, werden alle folgende Log bis zur nächsten Vollsicherung unbrauchbar.

     

     

     

    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Dienstag, 18. Januar 2011 07:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi Olaf,

    erstmal Danke für die Rückmeldung!

    Ich nehme an, 14:23Uhr soll am Folgetag sein? Nein, dann kannst du nur das Backup von 22:05 Uhr zurücksichern, nicht mehr.

    Ich habe ja keine einfache Backupstrategie, sondern vollständig und da die Logs vor dem Fullbackup abgeschnitten wurden, müsste ich mit den Logs bis zum Folgetag 14:22 kommen - eine Minute bevor alles gelöscht wurde, oder?

    Eine einfache Backup & Restore-Planung kann so aussehen:
    Um 0:00 Uhr wird ein Fullback erstellt, ab dann stündlich eine Log-Sicherung. Hast Du um 14:23 Uhr eine DB Crash, dann müsstest Du
    - Restore Fullback
    - + Kompletter Restore der Log-Backups von 01:00 - 14:00 Uhr
    - + Restore Log-Back von 15:00 Uhr (ohne der manuellen nach Crash) mit Stopppunkt auf 14:22 Uhr.

    Ja, eigentlich alles klar nur verzichte ich auf die LogBackups und kann somit sofort den Stoppzeitpunkt setzen - er spielt die logs doch dann sauber ein?

    Du solltest aber nie das Log "abschneiden" (Truncate_Only), weil das die Log-Sicherungskette unterbricht. In einer Log-Sicherung werden nur alle Änderungen seit der letzten Full/Log-Sicherung, deswegen werden immer alle Log-Sicherungen benötigt. Schneidest Du zwischendurch mal das Log ab, werden alle folgende Log bis zur nächsten Vollsicherung unbrauchbar.

    Da mit BackupExec die Logs eben nicht abgeschnitten werden und somit die Logs alle Infos auch vor der Sicherung enthalten bleiben, mache ich mir gerade darüber Gedanken, wann ich denn am Log schnippel. Hinterher ist schlecht, denn schneide ich nach dem Fullbackup einfach ab, ist die Kette nicht vollständig.

    Bei uns reicht es eigentlich immer tageweise zu springen, nur möchte ich am aktuellen Tag auch bis zu einer bestimmten Uhrzeit... Ansonsten würde ich die Strategie auf einfach setzen.

    ...ok, werde jetzt mit BE vor der Vollsicherung eine sauber Log-Sicheurng zu einem überschreibbaren BTD-Ordner machen und diesen mit auf Band ziehen. Dann sollte ich auch jeden Tag durch die abendlich Log-Sicherung zu jedem Zeitpunkt springen können... ich muss halt nur ein paar Schritte mehr machen:
    1. Restore Fullbackup
    2. Restore BTD-Ordner mit Log-Daten vom Folgetag
    3. Restore Log-Back mit Stopppunkt.

    Sieht jetzt noch jemand durch und gibt es Einwände? ;-)

    Viele Grüße
    Christian

    Dienstag, 18. Januar 2011 09:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christian,

    Ich habe ja keine einfache Backupstrategie, sondern vollständig

    Da sprichst Du das Recovery Model an, das meinte ich nicht. Wäre RecoveryModel = Simple, wären Log-Sicherungen eh nicht möglich.

    müsste ich mit den Logs bis zum Folgetag 14:22 kommen - eine Minute bevor alles gelöscht wurde, oder?

    Wenn Du nach dem Crash eine Log Sicherung durchführen kannst, dann kannst Du mit dem Fullbackup + der Log-Sicherung von 14:23 bis auf 14:22 zurücksichern; sonst natürlich nicht.

    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Dienstag, 18. Januar 2011 11:05
    |
  • Question
    Anmelden
    1
    Anmelden

    Mir scheint das ganze Vorgehen noch etwas undurchsichtig. Ergänzend zu dem von Olaf geposteten Artikel habe ich dies mal mit eigenen Worten hier beschrieben:
    http://www.insidesql.org/blogs/cmu/sql_server/sichern-und-wiederherstellen-von-datenbanken

    Mir fällt eigentlich kein vernünftiger Grund ein, warum ich ein Log auf Produktion abschneiden sollte, zumal diese auch keinen Einfluss auf die Grösse oder Dauer des Full-Backups haben. Das Full-Backup sichert die Daten und holt sich die Daten aus dem Log, die während der Dauer des Backups zusätzlich geändert wurden. Damit hat man eine Sicherung, die alles konsistent bis zum Ende der Sicherung beinhaltet.

    Logsicherungen gehören auf Produktion eigentlich mehrfach am Tage selbstverständlich dazu wenn ich das Recovery Modell FULL verwende.

    Ganz wichtig: Testen ob das gewählte Vorgehen auch zum gewünschten Ergebnis führt.

    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    http://www.insidesql.org/blogs/cmu

    Dienstag, 18. Januar 2011 12:38
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hi Christoph,

    Mir fällt eigentlich kein vernünftiger Grund ein, warum ich ein Log auf Produktion abschneiden sollte, zumal diese auch keinen Einfluss auf die Grösse oder Dauer des Full-Backups haben. Das Full-Backup sichert die Daten holt sich die Daten aus dem Log, die während der Dauer des Backups zusätzlich geändert wurden. Damit hat man eine Sicherung, die alles konsistent bis zum Ende der Sicherung beinhaltet.

    Weil BackupExec das Log bei einer Vollsicherung nicht kürzt und die Platte damit vollläuft - ist der Grund OK?

    Logsicherungen gehören auf Produktion eigentlich mehrfach am Tage selbstverständlich dazu wenn ich das Recovery Modell FULL verwende.

    Bei meinem Exchange sicher ich die Logs einmal am Tag, warum reicht das beim SQL nicht? Dem RAID vertraue ich jetzt mal! ;-)

    Ganz wichtig: Testen ob das gewählte Vorgehen auch zum gewünschten Ergebnis führt.

    Auf jeden Fall - bisher war das einfach Modell ausreichend (getestet und dokumentiert ;-) ), aber ich wollte ein wenig flexibler sein und bis zu einem bestimmten Zeitpunkt spulen kann!

    Habe jetzt einen zweiten BackupExec-Job, der die Logsicherung durchführt und es automatisch kürzt. Dieses läuft in einen BTD-Ordner, der nach zwei Wochen überschrieben wird.

    Viele Grüße
    Christian

    Viele Grüße
    Christian

    Mittwoch, 19. Januar 2011 13:47
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christian
    Du schreibst:

    Habe jetzt einen zweiten BackupExec-Job, der die Logsicherung
    durchführt und es automatisch kürzt. Dieses läuft in einen
    BTD-Ordner, der nach zwei Wochen überschrieben wird.

    Damit hast Du aber keine konsistente Abfolge von Logsicherungen. Wenn Du Sicherungen durchführst, wird der nicht mehr benötigte (weil gesicherte) Inhalt zum Überschreiben freigegeben.
    Aber vielleicht interpretiere ich auch Deine Aussage mit dem "kürzen" einfach falsch und Du meinst genau dieses "sichern & freigeben" damit ! ? !

    Warum sollte ich mehr als eine Log-Sicherung machen? Damit ich im Falle eines Fehlers (ich habe auch schon kaputte Raids gesehen, bzw. defekte Raid-Verkabelungen) nicht der ganze Tag futsch ist, sondern nur der Teil seit der letzten Log-Sicherung. Der Overhead für viele (alle 15 Minuten) Sicherungen ist minimal, der Gewinn ungleich grösser, zumal das Log auf der Platte nicht so groß sein muss wenn es regelmässig gesichert wird.

    Zwei Wochen hört sich gut an, damit Du damit ein evtl. defektes Full-Backup überbrücken kannst!

    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    http://www.insidesql.org/blogs/cmu

    Mittwoch, 19. Januar 2011 14:12
    |
    Beantworter