Ich muss 10-20 SQL Server 2008 R2-Datenbanken mit einer Größe zwischen 10 und 50 GB sichern, während sie online sind und gleichzeitig von einer einzigen Unternehmensanwendung verwendet werden. Ich muss sie auch in einen Zustand zurückversetzen, der über alle Datenbanken hinweg weitgehend synchronisiert ist (ich kann es mir leisten, dass zwischen den Datenbanken einige Sekunden desynchronisiert werden). Der Zweck besteht darin, Produktionsdaten für QA / DEV-Umgebungen zu erfassen.

Ich möchte unbedingt nicht verlangen, dass Datenbanken vollständig wiederhergestellt werden und dass eine Sicherungsmethode entwickelt wird, mit der Daten für QS-Umgebungen erfasst werden und die von einem Hauptsicherungsvorgang unabhängig bleibt, den ich nicht steuern kann.

Für meine Kunden werden 1-2 Stunden benötigt, um 20 vollständige Backups mit jeweils ~ 30 GB zu erstellen. Dies macht vollständige Sicherungen nacheinander nicht akzeptabel, da die Datenbanken bei einer einfachen Wiederherstellung zu desynchronisiert wären.

Ich suche eine bessere Idee als diese:

IDEE 1: SAN-Level-Snapshot von VM-Festplatten. xcopy MDFs / LDFs vom Schnappschuss.

Sobald die kopierten Dateien an eine andere Serverinstanz angehängt sind, sollte der Wiederherstellungsprozess konsistente Datenbanken erzeugen, die praktisch gleichzeitig als Momentaufnahme vorliegen.
Herum googeln hat mich überzeugt, dass dies eine schlechte Idee ist, zumindest weil ich unter Umständen Desync vs. master / msdb / etc bekomme.

IDEE 2: Koordinieren Sie eine komplexe Sicherung und Synchronisierung aller Datenbanken

Dies erfordert von mir, dass anspruchsvolle Datenbanken vollständig wiederhergestellt werden, was ich nicht möchte. Starten Sie parallele Sicherungen für alle Datenbanken rechtzeitig (T0). Sobald T0 erreicht ist, sichern Sie alle Protokolle (sollte höchstens einige Minuten dauern). Nehmen Sie die resultierenden unzähligen Backups und versuchen Sie, diese wiederherzustellen und Protokolle vorwärts / rückwärts zu rollen, um einen relativ zu T0 konsistenten Status für alle Datenbanken zu erhalten.
Dies erfordert viel Planung und Skripterstellung, damit es zuverlässig verwendet werden kann. Ich würde daher große Anstrengungen unternehmen, um dies zu vermeiden.

Vermisse ich eine andere Lösung?

PS1: Ich hätte gerne db-Schnappschüsse verwendet . Die Idee war, einen Snapshot für jede Datenbank zu erstellen (der in Sekunden abgeschlossen sein sollte) und anschließend nacheinander in den folgenden Minuten / Stunden eine vollständige Sicherung durchzuführen. Stellen Sie dann alle auf einem anderen Server wieder her und stellen Sie alle auf den Snapshot zurück. AFAIK Dieses Szenario ist nicht möglich, da Snapshots nicht zusammen mit der Datenbank gesichert werden können. Sie können nur auf dem Server zurückgesetzt werden, auf dem sie erstellt wurden. Außerdem benötigen sie die Enterprise Edition, die ich nicht für alle Kunden habe.

PS2: Wenn Sie eine Lösung von Drittanbietern kennen, die db-übergreifende synchronisierte Sicherungen erstellen kann, erwähnen Sie diese bitte.

Ich muss 10-20 SQL Server-Datenbanken sichern, die gleichzeitig von einer einzelnen Unternehmensanwendung verwendet werden, während sie online sind, damit sie in einem Zustand wiederhergestellt werden können, der über alle Datenbanken hinweg weitgehend synchronisiert ist

Was Sie suchen, ist ein konsistentes Backup für alle Ihre Kundendatenbanken. Sie sollten FULL-Backups zusammen mit verwenden Marked Transactions(Hervorhebung in Fettdruck hinzugefügt):

Wenn Sie verwandte Aktualisierungen für zwei oder mehr verwandte Datenbanken vornehmen , können Sie Transaktionsmarken verwenden, um sie an einem logisch konsistenten Punkt wiederherzustellen . Bei dieser Wiederherstellung gehen jedoch alle Transaktionen verloren, die nach der als Wiederherstellungspunkt verwendeten Markierung festgeschrieben wurden. Das Markieren von Transaktionen ist nur dann geeignet, wenn Sie verwandte Datenbanken testen oder wenn Sie bereit sind, kürzlich festgeschriebene Transaktionen zu verlieren.

Stellen Sie sicher, dass Sie eine Ad-hoc-Transaktionsprotokollsicherung durchführen. Andernfalls ist COPY_ONLYIhre Wiederherstellung schmerzhaft, da jede Ad-hoc-Transaktionsprotokollsicherung, ohne COPY_ONLYdie die Protokollkette unterbrochen wird. Vorsichtshalber können Sie festlegen, dass Benutzer nur COPY_ONLY Sicherungen verwenden .

Ich benötige eine Lösung für SQL Server-Versionen 2008 R2 und höher. Die Größe der Datenbank beträgt bis zu 50 GB pro Datenbank und die Zeit, um alle zu sichern, beträgt wahrscheinlich mehr als 1-2 Stunden.

Markierte Transaktionen werden für Ihre Situation funktionieren. Das Einzige, was Sie parallel sichern STRIPEkönnen, ist, dass Sie Ihre Sicherungskopien nicht verlieren. Um sie schneller zu machen, können Sie mit BUFFERCOUNTund spielen MAXTRANSFERSIZE.

Sie sollten die Sicherungskomprimierung verwenden und die sofortige Dateiinitialisierung aktivieren .

Beziehen auf

• Verwenden markierter Transaktionen (vollständiges Wiederherstellungsmodell)
• Wie kann die Geschwindigkeit der vollständigen SQL-Datenbanksicherung mithilfe von Komprimierung und Solid State Disks erhöht werden?

Wenn Sie sowohl vollständige als auch Transaktionsprotokollsicherungen ausführen (und wenn Sie diese Daten für wichtig halten sollten), können Sie die Sicherungen und Transaktionsprotokollsicherungen einfach auf das Testsystem kopieren und eine Wiederherstellung zu einem bestimmten Zeitpunkt ausführen , um die Datenbanken wiederherzustellen + - zur gleichen Zeit.

Abhängig davon, ob sich alle Datenbanken auf demselben SQL Server-Computer befinden oder wie gut die Serveruhren synchronisiert sind, sollten Sie in der Lage sein, das Ziel für die Desynchronisierung um einige Sekunden zu erreichen.

Es mag eine Art Pflasterlösung sein, würde aber die Anforderungen erfüllen und ziemlich einfach und kostengünstig sein.

Wenn Sie nicht über vollständige Sicherungen und Transaktionsprotokollsicherungen Ihrer wichtigen Datenbanken (die sich in vollständiger Wiederherstellung befinden) verfügen, müssen Sie Ihre Sicherungsstrategie wirklich überarbeiten. Bei Snapshots auf SAN-Ebene geht es tatsächlich darum, dass sich eine Datenbank im vollständigen Wiederherstellungsmodus befindet, da Sie ohnehin keine Wiederherstellung zu einem bestimmten Zeitpunkt durchführen können.

Bitte lesen Sie, was MrDenny dazu zu sagen hat

Haben Sie sich unter den von Ihnen angegebenen Umständen mit VSS-Sicherungen über einen VSS-Anbieter befasst, der entweder von einem Drittanbieter oder von Microsoft stammt? Sie können eine COPY_ONLY-Sicherung durchführen, die Ihre Produktionswiederherstellungskette nicht unterbricht, und Sie sollten am Ende eine Sicherung aller Datenbanken erstellen, die Sie innerhalb Ihrer vertretbaren Grenzen an anderer Stelle wiederherstellen können. Beachten Sie, dass eine VSS-Sicherung dieselben Mechanismen und Nachteile wie Datenbank-Snapshots aufweist, da eine sehr aktive Datenbank aufgrund der verwendeten spärlichen Dateien ein Speicherplatzproblem verursachen kann. Werfen Sie einen Blick auf den TechNet - Ressourcen auf den SQL Writer - Dienst hier und VSS - Sicherungen von SQL Server hier .

Führen Sie dazu über die Windows Server-Sicherung die Schritte des Assistenten für eine manuelle Sicherung aus, und stellen Sie sicher, dass Sie in den benutzerdefinierten Konfigurationseinstellungen unter VSS-Einstellungen die Option VSS-Kopie-Sicherung auswählen. Auf diese Weise kann Ihre Windows Server-Sicherung andere auf dem Server vorgenommene Sicherungen nicht beeinträchtigen. Weitere Informationen finden Sie in der Referenz zur Windows Server-Sicherung .

Ich werde @ Kin's als Antwort wählen, da es das erste war, das mit der Frage übereinstimmt. Am Ende habe ich eine zusätzliche Antwort gefunden, die ich im Folgenden beschreiben werde.

Für Kunden, die ein einfaches Wiederherstellungsmodell verwenden, wird eine Kopie von MDFs und LDFs benötigt, die aus einem temporären Festplatten-Snapshot extrahiert wurden, der auf Hypervisor- oder SAN-Ebene bei T0 erstellt wurde. Ich kann diese verwenden, um die DBS im Zustand von T0 wiederherzustellen.

Für Kunden, die das vollständige Wiederherstellungsmodell verwenden, wird Folgendes benötigt:

• Kopien des MAIN-Sicherungsprozesses der letzten vollständigen Sicherung, die vor T0 abgeschlossen wurde, + minimale Kette nachfolgender Transaktionsprotokollsicherungen, die T0 abdecken. Ich kann dann zu einem bestimmten Zeitpunkt eine Wiederherstellung auf T0 durchführen.

• Zugriff auf meine eigenen COPY_ONLYHilfssicherungen. Ich beginne sie alle parallel bei T0, was nicht länger als ein paar Sekunden dauern sollte und mein wichtigstes Anliegen war. Bei der Wiederherstellung führe ich dann von jeder Sicherung eine Wiederherstellung zu einem bestimmten Zeitpunkt auf FirstLSN durch. Das Schöne daran ist, dass ich überhaupt nicht mit dem MAIN-Sicherungsprozess interagieren muss, was mein anderes Problem war. Sie können sogar die Protokolle abschneiden, während meine COPY_ONLYSicherungen ausgeführt werden, ohne ihre Kohärenz zu beeinträchtigen.

Ich mache dies mehrmals im Jahr für die Qualitätssicherung und andere Umgebungen, die Kopien der Produktion sind. Für Wiederherstellungen ist ein vollständiger Wiederherstellungsmodus unbedingt erforderlich, und die Wiederherstellung bis zu einem bestimmten Zeitpunkt funktioniert einwandfrei. Es gibt auch viele Replikationen, und es kommt selten vor, dass nach der Wiederherstellung zu einem bestimmten Zeitpunkt Fehler "Zeile nicht gefunden" wurden. Wir verwenden auch die SAN-Clone / Snapshot-Methode für eine geografisch entfernte Kopie der Produktion. Dies ist auch für die Synchronisierung der Datenbanken von Vorteil.