Datenbank-Sicherungs-/Wiederherstellungsprozess

Question

Der Sicherungs- und Wiederherstellungsprozess einer großen Datenbank oder einer Sammlung von Datenbanken auf dem SQL-Server ist für Notfallwiederherstellungszwecke sehr wichtig. Ich habe jedoch keine robuste Lösung gefunden, die garantiert, dass der gesamte Prozess so effizient wie möglich, 100% zuverlässig und leicht wartbar und über mehrere Server konfigurierbar ist.

Die Wartungspläne von Microsft scheinen nicht ausreichend zu sein. Die beste Lösung, die ich verwendet habe, ist eine, die ich manuell erstellt habe, indem ich viele Jobs mit vielen Schritten pro Datenbank verwende, die auf dem Quellserver (Backup) und dem Zielserver (Restore) laufen. Die Jobs verwenden gespeicherte Prozeduren, um die Sicherungskopie zu erstellen und & wiederherzustellen. Dies läuft einmal täglich (vollständige Sicherung/Wiederherstellung) und alle 5 Minuten im Intraday (Transaktionsprotokollversand).

Obwohl mein derzeitiger Prozess funktioniert und jeden Jobfehler per E-Mail meldet, weiß ich, dass der gesamte Prozess nicht sehr zuverlässig ist und nicht einfach auf allen unseren Servern von einem Nicht-DBA gewartet/konfiguriert werden kann der Prozess.

Ich würde gerne wissen, ob andere diesen gleichen Backup/Restore-Prozess haben und wie andere dieses Problem überwinden.

Answer 1

Ich mache genau die gleiche Sache und habe verschiedene Probleme halb regelmäßig sogar mit diesem Prozess.

Wie beurteilen Sie den Abstand zwischen dem Kopieren der Datei von Server A nach Server B und Wiederherstellen der Transaktionssicherung auf Server B.

Jeden einmal in einem handhaben, während die Transaktion Sicherung größer als normal ist und dauert länger Kopieren. Der Wiederherstellungsjob erhält dann einen Betriebssystemfehler, dass die Datei verwendet wird.

Dies ist nicht so ein großes Problem, da die Datei beim nächsten Mal automatisch angewendet wird, aber es wäre netter, eine elegantere Lösung im Allgemeinen zu haben und eine, die dieses Problem spezifisch behebt.

Answer 2

Ich habe einen ähnlichen Schritt verwendet, um Entwickler- und QA-Leute zu verwenden, um Entwickler-/Test-/QA-Datenbanken nachts auf Null zu halten.

Dokumentation ist der Schlüssel - wenn Sie entfernen möchten, was Scott Hanselman "Busfaktor" nennt (d. H. Die Gefahr, dass der Ersteller des Systems von einem Bus getroffen wird und alles zu saugen beginnt).

Das heißt, für normale Datenbank-Backups und Disaster Recovery-Pläne habe ich festgestellt, dass SQL Server Maintenance Plans ziemlich gut funktionieren. Solange Sie einschließen: 1) Ordentliche Dokumentation 2) Routinetests.

Ich habe einige der Möglichkeiten, skizzierte über zu gehen, das zu tun (für jedermann auf diese Frage gezogen suchen ein Beispiel dafür, wie Sie gehen über einen Disaster-Recovery-Plan erstellen):
SQL Server Backup Best Practices (Free Tutorial/Video)

Answer 3

Der wichtigste Teil Ihrer Frage ist die Möglichkeit, dass die Sicherungslösung von einem Nicht-DBA verwaltet wird. Jede native SQL Server-Antwort wie Backup-Skripte wird diese Anforderung nicht erfüllen, da Backup-Skripte T-SQL-Kenntnisse erfordern.

Aus diesem Grund möchten Sie auf Lösungen von Drittanbietern wie die Mitch Wheat erwähnt. Ich arbeite für Quest (die Macher von LiteSpeed), deshalb bin ich natürlich auch Teil davon - es ist einfach, Nicht-DBAs zu zeigen. Bevor ich meine letzte Firma verließ, hatte ich eine zehnminütige Sitzung, um den Systemadministratoren und Entwicklern zu zeigen, wie die LiteSpeed-Konsole funktionierte, und das war es. Sie haben seitdem nicht angerufen.

Ein anderer Ansatz ist die Verwendung der gleichen Backup-Software, die der Rest Ihres Shops verwendet. TSM, Veritas, Backup Exec und Microsoft DPM verfügen alle über SQL Server-Agents, mit denen Windows-Administratoren den Backup-Prozess mit unterschiedlichem Bedienkomfort verwalten können. Wenn Sie wirklich möchten, dass ein Nicht-DBA es verwaltet, ist dies wahrscheinlich der einfachste Weg, dies zu tun, obwohl Sie eine Menge Leistung opfern, die Ihnen die SQL-spezifischen Backup-Tools bieten.