MS SQL Server - Tool zum restoren von "langen" Log Chains

[Unix-Tom]

Kenn sowas auch nicht aber das hast wohl eine falsch konfigurierten MSSQL vorliegen.
Backup und Rüclsicherung dauert da nur Minuten und das bei großen DB von mehreren 100GB

[hustbaer]

@Unix-Tom:
Die Geschwindigkeit vom Datentransfer passt schon.

Unsere Backups sehen so aus:

Full Backup alle 3 Tage.
Transaktions-Log Backup jede Stunde.

Gesichert wird in Files, und zwar pro Backup je ein File.
D.h. jedes Full Backup ist ein File, und das Transaktions-Log Backup macht für jede Stunde auch ein eigenes File.

Alte Backups werden dann nach einer bestimmten Zeit einfach gelöscht. Und zwar auch automatisch, im selben Maintenance-Plan der das Full-Backup erstellt, und nur, wenn das letzte Full-Backup erfolgreich war.

Wenn man jetzt die aktuellste Version wiederherstellen wollen würde, müsste man folgendes machen:

Full Backup für z.B. 2009-12-01 wiederherstellen, Datenbank im "restore" Mode lassen.

Transaktions-Log Backup 2009-12-01 01:00:00 drüberspielen.
Transaktions-Log Backup 2009-12-01 02:00:00 drüberspielen.
Transaktions-Log Backup 2009-12-01 03:00:00 drüberspielen.
Transaktions-Log Backup 2009-12-01 04:00:00 drüberspielen.
...
Transaktions-Log Backup 2009-12-02 23:00:00 drüberspielen.
Datenbank "recovern".
-> fertig.

Im schlimmsten Fall sind das 72 Transaktions-Log Backups. Und für jedes einzelne muss man - wenn man es über die GUI machen will - den Restore-Dialog aufmachen, auf "from disk" umstellen, auf "add..." drücken uswusf.
Und wehe dem der vergisst immer brav auf "no recovery" umzustellen, bei jedem einzelnen File.

DAS ist der Teil der lange dauert, nicht das eigentliche zurückspielen der Daten.

Und DAS hätte ich gerne optimiert.

Natürlich kann man sich mit "dir /B >list.txt" eine Fileliste machen, dann in ein SQL-Fenster reinkopieren, dann 72 "RESTORE LOG ..." Anweisungen draus basteln (geht mit dem Makro relativ schnell), Ctrl + E drücken, und warten.

Bloss ist das eine Prozedur, die ich im Ernstfall eigentlich nicht machen möchte. Von daher denke ich mir, wäre es praktisch, ein kleines Tool zu haben, was das automatisiert.

So ein Tool könnte auch vorher schön alle LSNs prüfen, gucken welche Transaktions-Log Backups überhaupt restored werden müssen, checken ob die eh zur richtigen Datenbank gehören usw.

Evtl. auch gleich mit einer "restore point-in-time" ("stop at") Funktion.

Ich denke mir einfach sowas wäre praktisch. Der SQL Server hat ja sonst grafische Tools für jeden Scheiss, da hat es mich einfach etwas gewundert, dass das Management Studio gerade beim Restoren von Backups so umständlich ist.

[Unix-Tom]

Auch die Tools von MSSQL sind nicht das beste.
Wir verwenden dafür Backupexec.
Da geht das alles automatisch.
Solltest Dir da mal Gedanken machen denn es kostet verhältnism. nicht viel.

[hustbaer]

Danke für den Vorschlag, aber das wird's nicht spielen.
Zu teuer, und zu kompliziert.

Im Prinzip funktioniert das auch alles ganz gut wie wir es im Moment haben, mit der einzigen Ausnahme, dass wir eben kein "angenehmes" Tool zum wiederherstellen der SQL Sicherungen haben. (Bis jetzt haben wir das Gott-sei-Dank auch noch nie machen müssen)

[Unix-Tom]

Ich verstehe eigetlich nicht ganz wo das Problem liegt. Wenn MSSQL einen Sicherung macht dann kann man die Rücksicherung ab diesem Zeitpunkt machen. Egal ob Full oder nicht.
MSSQL sucht sich die richtigen Dateien bzw. Transactionslog selbst und gibt ein Datum und Zeit vor.
Wofür sichert ihr das LOG?
Es reicht ein Fullbackup zu machen. Es gibt Kunden welche die DB alle 5 Minuten sichern.
Und das ist nicht auf meinem Mist gewachsen sondern schlägt selbst Microsoft vor.
Diese Sicherung kann man dann auch immer wegsichern.
Die beste Lösung ist sowieso auch zusätzlich eine Replikation.
Tool kenne ich wie gesagt nicht und wenn es das gebe hätte ich es schon mal gefunden.

[hustbaer]

Unix-Tom schrieb:

Ich verstehe eigetlich nicht ganz wo das Problem liegt. Wenn MSSQL einen Sicherung macht dann kann man die Rücksicherung ab diesem Zeitpunkt machen. Egal ob Full oder nicht.
MSSQL sucht sich die richtigen Dateien bzw. Transactionslog selbst und gibt ein Datum und Zeit vor.

ja solange man den original-server noch hat.
auf einem neu aufgesetzten server kannst du dich brausen gehen. zumindest hätte ich keinen weg gefunden wie es geht. wenn es geht, sag mir bitte wie, denn genau das will ich machen.

Wofür sichert ihr das LOG?
Es reicht ein Fullbackup zu machen. Es gibt Kunden welche die DB alle 5 Minuten sichern.

äh. weil eine vollständige sicherung länger als 5 minuten braucht, UND weil eine vollständige sicherung nicht ausreichend ist, wenn man einen "point in time" restore machen will?

Und das ist nicht auf meinem Mist gewachsen sondern schlägt selbst Microsoft vor.

wo? wem? als lösung für was? hab ich noch nie irgendwo gelesen.

Diese Sicherung kann man dann auch immer wegsichern.

wenn die DB klein genug ist, und man die entsprechenden netzwerk und storage bandbreiten hat, sicherlich.

Die beste Lösung ist sowieso auch zusätzlich eine Replikation.

replikation is kacke. bei jeder schema-änderung muss man die neu einrichten. bäh.
mirroring wäre schon eher interessant. ist aber wieder eine kostenfrage. bei unbegrenzten resourcen, klar.

Tool kenne ich wie gesagt nicht und wenn es das gebe hätte ich es schon mal gefunden.

[Unix-Tom]

GAb mal eine TECHDAY wo es so erzählt wurde.

Schema ändert man ja täglich und die Replication ist in 1 Minute wieder neue eingerichtet.
Aber ich habe es auch noch nie machen müssen das ich einen Rechner neu aus den Trasnactionlog aufsetzen musste. Das hat immer Backupexec erledigt.
Wenn man aber MSSQL mit so großen DB`s einsetzt sollten doch die 2000€ kein Thema sein oder?

[hustbaer]

Mit den 2000€ ist es ja nicht getan.
Das Ding muss ja auch noch wer installieren, konfigurieren, Ernstfall-Szenario durchspielen, warten.
Davon abgesehen wird bei uns im Moment gerade ziemlich geknausert, gerade was Ausgaben für Software angeht.

[Unix-Tom]

Und genau das ist das Problem.
Du weißt ja selbst wieviele verlorene Daten es gibt weil die Sicherungsstrategie nicht gestimmt hat.

BE ist sehr einfach und braucht fast keine Wartung.

[hustbaer]

Naja.
Zurückspielen können wir die Daten. Das haben wir durchaus schon probiert, und funktioniert "super".

Wobei "super" eben heisst: es hat noch nie Probleme gegeben, nur durch die vielen *.trn Files die man einzeln restoren muss, dauert es halt ewig, und nervt wie Sau.

Aber naja. Kann man auch nixe machen.