Im Eröffnungskapitel von Craig Mullins Buch Datenbankadministration sagt er: „In vielerlei Hinsicht ist das Geschäft heute Daten“. In den meisten Organisationen ist die Person, die für den Schutz von Daten verantwortlich ist, der Datenbankadministrator … Sie.

Das stimmt; das gesamte Geschäft liegt in Ihren fähigen Händen und läuft auf diesem Server, der niemals abstürzt, mit all den Endbenutzern, die niemals Fehler bei der Verwendung von Anwendungen machen, die von den Entwicklern erstellt wurden, die fehlerfreien Code schreiben das erste Mal, jedes Mal, mit der fähigen Unterstützung dieses neuen Koop, der dank Ihres Chefs sa-Privilegien hat.

OK. Hör auf zu weinen. Es gibt Dinge, die Sie tun können, um die SQL Server-Daten unter Ihrer Obhut zu schützen, und eines der wichtigsten ist das Ausführen regelmäßiger Datenbanksicherungen.

Backups

Microsoft definiert Backups in SQL Server Books Online als:

Eine Kopie von Daten, die zum Wiederherstellen und Wiederherstellen von Daten nach einem Systemausfall verwendet wird

SQL-Sicherungen können auf verschiedene Arten erstellt werden und können alle oder einige der Daten sowie einen Teil des Transaktionsprotokolls enthalten. Während sich dieser Artikel auf die Syntax von 2005 konzentriert, sind die meisten Konzepte auf 2000 anwendbar. Dies ist ein riesiges Thema. Im besten Fall kratze ich an der Oberfläche und gebe Ihnen genügend Informationen, damit Sie nicht wieder anfangen zu weinen. Nachdem Sie dies gelesen haben, sollten Sie in der Lage sein, einen angemessenen Satz von Backups für Ihr System einzurichten.

Wiederherstellungsmodelle

Um mit der Arbeit an Sicherungen beginnen zu können, muss ein Datenbankwiederherstellungsmodell definiert werden. Im Wesentlichen definiert ein Wiederherstellungsmodell, was Sie mit den Transaktionsprotokolldaten tun werden.

Es gibt drei Wiederherstellungsmodelle: Voll-, Einfach- und Massenwiederherstellung. Diese sind ziemlich einfach zu definieren:

• Einfach – Im einfachen Wiederherstellungsmodus wird das Transaktionslog nicht gesichert, sodass Sie nur die neueste vollständige oder differentielle Sicherung wiederherstellen können.
• Voll – Im vollständigen Wiederherstellungsmodus sichern Sie die Datenbank und das Transaktionslog, sodass Sie die Datenbank zu einem beliebigen Zeitpunkt wiederherstellen können.
• Massenprotokollierung – Im Massenprotokollierungsmodus werden die meisten Transaktionen im Transaktionslog gespeichert, aber einige Massenvorgänge wie Massenladungen oder Indexerstellung werden nicht protokolliert.

Die beiden am häufigsten verwendeten Modi sind Einfach und Voll. Gehen Sie nicht unbedingt davon aus, dass Sie natürlich immer die vollständige Wiederherstellung verwenden müssen, um Ihre Daten zu schützen. Es ist eine geschäftliche Entscheidung. Das Unternehmen wird Ihnen sagen, ob Sie zu einem bestimmten Zeitpunkt wiederherstellen müssen oder ob Sie einfach die letzte vollständige Sicherung benötigen. Es wird definiert, ob Ihre Daten auf andere Weise wiederhergestellt werden können, z. B. durch manuelle Eingabe, oder ob Sie so viel wie möglich schützen müssen, wenn sie über den Draht kommen. Sie verwenden Simple Recovery, wenn Sie es sich leisten können, die seit der letzten vollständigen oder differentiellen Sicherung gespeicherten Daten zu verlieren und / oder wenn Sie zu einem bestimmten Zeitpunkt keine Wiederherstellung benötigen. Im einfachen Modus müssen Sie alle sekundären Lese- /Schreibdateigruppen wiederherstellen, wenn Sie die primäre wiederherstellen. Sie verwenden Simple hauptsächlich für sekundäre Datenbanken, die kein absolut wichtiger Bestandteil des Unternehmens oder der Berichtssysteme sind, mit schreibgeschütztem Zugriff, sodass Sie sich ohnehin keine Sorgen um ein Transaktionsprotokoll machen müssen. Sie verwenden Full, wenn jedes Bit der Daten wichtig ist, Sie zu einem bestimmten Zeitpunkt wiederherstellen müssen oder, normalerweise bei sehr großen Datenbanken (VLDB), Sie einzelne Dateien und Dateigruppen unabhängig von anderen Dateien und Dateigruppen wiederherstellen müssen.

Mit einfachen und vollständigen Wiederherstellungsmodellen können Sie jetzt eine reine Kopiersicherung ausführen, mit der Sie die Datenbank in eine Sicherungsdatei kopieren können, ohne das Protokoll, differenzielle Sicherungspläne oder die Wiederherstellung zu einem bestimmten Zeitpunkt zu beeinträchtigen. Ich werde versuchen, so viele dieser Themen wie möglich durch den Artikel aufzuschlüsseln, aber nicht die Dateien und Dateigruppen.

Arbeiten mit einfacher Wiederherstellung

Genug geredet. Kommen wir zum Ausführen von Backups. Nehmen wir an, wir befinden uns in einer einfachen Wiederherstellung einer kleinen bis mittelgroßen Datenbank. Ich werde AdventureWorks für alle Beispielskripte verwenden. Um es auf einfache Wiederherstellung zu setzen:

Ihre einfachste Sicherungsstrategie besteht darin, in regelmäßigen Abständen den folgenden SQL Server-Sicherungsbefehl auszuführen, der eine vollständige Sicherung der Datenbank durchführt:

Was ist mit all dem Tippen, das du fragst? Haben wir keine GUI-Tools, um die Arbeit für uns zu erledigen? Ja, die meisten einfachen Sicherungen können mit SQL Server Management Studio durchgeführt werden. Wenn Sie jedoch lernen und verstehen möchten, was Management Studio für Sie tut, oder wenn Sie eine feinkörnige Kontrolle darüber haben möchten, was wie und wo gesichert wird, müssen Sie die Tastatur herausbrechen und die Maus weglegen.

Der obige Befehl führt zu einer grundlegenden Sicherung auf der Festplatte. Die meisten DBAs, die ich kenne, sichern in Dateien und kratzen die Dateien dann auf ein Band oder ein anderes Medium. Dies liegt daran, dass Dateien auf der Festplatte einfach und schnell wiederhergestellt werden können, während Medien manchmal etwas schmerzhaft sein können. Zum Beispiel haben wir in der Regel zwei bis drei Tage im Wert von Backups auf unseren Dateisystemen für die sofortige Wiederherstellung. Wir gehen nur zu den Bandsystemen, wenn wir Wiederherstellungen für ältere Backups durchführen müssen.

Was hat dieser Befehl bewirkt? Es wurde eine Kopie aller festgeschriebenen Daten in der Datenbank erstellt. Es kopierte auch nicht festgeschriebene Protokolleinträge. Diese werden während der Wiederherstellung verwendet, um Änderungen, die während des Sicherungsprozesses an den Daten aufgetreten sind, entweder festzuschreiben oder rückgängig zu machen.

Backups nur zum Kopieren

Normalerweise wirkt sich das Sichern einer Datenbank auf andere Sicherungs- und Wiederherstellungsprozesse aus. Nach dem Ausführen des vorherigen Befehls würden beispielsweise alle differenziellen Sicherungen (eine Sicherung, die nur Daten kopiert, die seit der letzten Sicherung geändert wurden) dies als Ausgangspunkt für Datenänderungen verwenden, nicht die Sicherung, die Sie letzte Nacht ausgeführt haben. Wie bereits erwähnt, führt SQL 2005 ein neues Konzept für Sicherungen ein, COPY_ONLY-Sicherungen, mit denen wir den Zyklus nicht unterbrechen können:

Wir haben bereits einen dieser detaillierteren Momente gefunden, in denen das Management Studio Ihnen nicht helfen würde. Wenn Sie nur eine Kopie sichern möchten, müssen Sie die Befehlszeile verwenden.

Differentielle Backups

Nehmen wir für einen Moment an, dass wir uns noch in der einfachen Wiederherstellung befinden, aber wir haben es mit einer größeren Datenbank zu tun, sagen wir etwas über 100 GB. Vollständige Backups können den Prozess tatsächlich etwas verlangsamen. Stattdessen haben wir uns nach Rücksprache mit dem Unternehmen für ein wöchentliches Voll-Backup und tägliche differenzielle Backups entschieden. Differenzielle Sicherungen sichern nur die Datenseiten, die sich seit der letzten vollständigen Sicherung geändert haben. Im Folgenden finden Sie den SQL BACKUP-Befehl zum Ausführen einer differentiellen Sicherung:

Wenn wir nun diese Datenbank wiederherstellen müssten, würden wir zuerst zur letzten vollständigen Sicherung gehen, diese wiederherstellen und dann die differentiellen Sicherungen der Reihe nach wiederherstellen (dazu später mehr).

Es gibt eine Reihe anderer Backup-Optionen, die ich hier nicht detailliert beschreiben werde. Lesen Sie die Bücher online, um Details zu BLOCKGRÖßE, ABLAUFDATUM, AUFBEWAHRUNGSTAGEN, PASSWORT, NAME, STATISTIKEN usw. anzuzeigen.

Sie können auch eine Anweisung ausführen, die die Integrität einer Datenbanksicherung überprüft. Es überprüft nicht die Integrität der Daten in einem Backup, aber es überprüft, ob das Backup korrekt formatiert und zugänglich ist.

Vollständige Wiederherstellung und Protokollsicherungen

Wir haben hauptsächlich an einer Datenbank gearbeitet, die sich im einfachen Wiederherstellungsmodus befand (dies wurde früher als Truncate Log on Checkpoint bezeichnet). In diesem Modus sichern wir die Transaktionsprotokolle nicht für eine spätere Wiederherstellung. Jede Sicherung unter diesem Mechanismus ist eine Datenbanksicherung. Log-Backups sind einfach nicht möglich.

Sie haben die Daten jedoch nur ab dem letzten guten Backup geschützt, entweder vollständig oder differentiell. Ändern wir unsere Annahmen. Jetzt haben wir es mit einer großen, geschäftskritischen Anwendung und Datenbank zu tun. Wir möchten diese Datenbank bis zur letzten Minute wiederherstellen können. Dies ist ein sehr wichtiger Punkt. Da die Protokolleinträge gespeichert und gesichert werden, sind wir theoretisch bis zu einem Fehler geschützt. Einige Fehler können jedoch zu einer Beschädigung des Protokolls führen, sodass eine Wiederherstellung zu einem bestimmten Zeitpunkt unmöglich ist. Wir müssen also die angemessene Mindestzeit zwischen den Protokollsicherungen bestimmen. In diesem Fall können wir mit verlorenen Daten von nicht mehr als 15 Minuten leben.

Beginnen wir also damit, unsere Datenbank in den VOLLSTÄNDIGEN Wiederherstellungsmodus zu versetzen:

Anschließend führen wir planmäßig, in diesem Fall alle 15 Minuten, den Befehl SQL backup für das Transaktionslog aus:

Dieses Skript sichert festgeschriebene Transaktionen aus dem Transaktionsprotokoll. Es hat Markierungen in der Datei, die die Start- und Stoppzeit anzeigen. Das Protokoll wird abgeschnitten, wenn es erfolgreich abgeschlossen wurde, und die festgeschriebenen Transaktionen, die in die Sicherungsdatei geschrieben wurden, werden aus dem Transaktionsprotokoll entfernt. Bei Bedarf können Sie die WITH NO_TRUNCATE-Anweisung verwenden, um Daten aus dem Transaktionslog unabhängig vom Status der Datenbank zu erfassen, vorausgesetzt, sie ist online und befindet sich nicht im Notfallstatus. Dies gilt nur für Notfälle.

Beachten Sie, dass wir in diesem Fall nicht die INIT-Anweisung verwenden, aber Sie können dies tun, wenn Sie möchten. Wenn Sie Protokollsicherungen durchführen, haben Sie Optionen:

1. Führen Sie alle Sicherungen in einer einzigen Datei aus, in der sie gestapelt werden, und alles, was Sie bei der Wiederherstellung (später behandelt) tun müssen, ist, sie durchzugehen.
2. Benennen Sie die Sicherungen eindeutig, wahrscheinlich mit Datum und Uhrzeit in der Zeichenfolge.

In diesem letzteren Fall, sagt safety, verwenden Sie INIT, weil Sie maximale Kontrolle darüber ausüben, was wo gesichert wird, und Sie werden genau wissen können, was ein Backup ist, wann es genommen wurde und von wo basierend auf dem Namen. Dies ist ein weiterer Ort, an dem das Bedienen von Backups über die Befehlszeile mehr Kontrolle bietet als über die GUI. Wir haben beide Ansätze in unseren Systemen aus verschiedenen Gründen verwendet. Sie können entscheiden, was für Ihre Technologie- und Geschäftsanforderungen am besten geeignet ist.

Die meisten Optionen, die für die Datenbanksicherung verfügbar sind, sind in der Protokollsicherung enthalten, einschließlich COPY_ONLY. Auf diese Weise können Sie einen Satz Transaktionsdaten erfassen, ohne das Protokoll oder die nächste geplante Protokollsicherung zu beeinträchtigen. Dies wäre praktisch, um Produktionsdaten zur Fehlerbehebung usw. auf ein anderes System zu übertragen.

Wenn Ihre Datenbank auf VOLLSTÄNDIGE Wiederherstellung eingestellt ist, müssen Sie Protokollsicherungen ausführen. Manchmal vergessen die Leute und das Transaktionsprotokoll wächst so weit, dass es das Laufwerk füllt. In diesem Fall können Sie ausführen:

Wenn Sie NO_LOG an die Protokollsicherung anhängen und keinen Speicherort für das Protokoll angeben, wird der inaktive Teil des Protokolls entfernt, und zwar ohne einen Protokolleintrag selbst. Dies wird absolut nicht empfohlen, da dadurch die Protokollkette unterbrochen wird, die Reihe von Protokollsicherungen, aus denen Sie Ihre Datenbank zu einem bestimmten Zeitpunkt wiederherstellen würden. Microsoft empfiehlt, unmittelbar nach der Verwendung dieser Anweisung eine vollständige Sicherung durchzuführen. Außerdem warnen sie davor, dass diese Anweisung in einer zukünftigen Version veraltet sein könnte.

Wiederherstellen von Datenbanken

So wichtig SQL Server-Sicherungen sind, und sie sind von entscheidender Bedeutung, sie sind nutzlos, ohne die Möglichkeit, die Datenbank wiederherzustellen.

Wiederherstellen einer vollständigen Datenbanksicherung

Das Wiederherstellen einer vollständigen Datenbanksicherung ist so einfach wie das Erstellen:

Es ist wirklich so einfach – es sei denn, wir sichern alles in einer Datei, als wäre es ein Sicherungsgerät. In diesem Fall müssen Sie angeben, auf welche Datei innerhalb des „Geräts“ Sie zugreifen. Wenn Sie nicht wissen, welche Datei, müssen Sie eine Liste generieren:

Dies wird Ihnen die gleiche Liste geben, wie ich oben von Management Studio gezeigt habe. Wenn wir nun die zweite Datei in der Gruppe, die COPY_ONLY-Sicherung, wiederherstellen möchten, geben Sie den folgenden Befehl aus:

Wenn Sie mitverfolgen, können Sie leider feststellen, dass Sie gerade diesen Fehler generiert haben:

Dies bedeutet, dass sich Ihre Datenbank im vollständigen Wiederherstellungsmodus befindet, Sie jedoch den „Tail of the log“ nicht gesichert haben, dh die seit dem letzten Ausführen einer Sicherung eingegebenen Transaktionen. Sie können diese Anforderung überschreiben, wenn Sie die vorherige Syntax in ändern:

Das ist das erste Mal, dass wir die WITH Klauseln gestapelt haben (WITH FILE=2 und WITH REPLACE wird als WITH FILE=2, REPLACE ), aber es wird nicht das letzte sein. Lesen Sie die Bücher online durch. Die meisten WITH-Klauselanweisungen können in Kombination mit den anderen verwendet werden.

Was passiert, wenn wir eine andere Datenbank als die ursprüngliche wiederherstellen möchten? Beispielsweise möchten wir eine Kopie unserer Datenbank aus einem separaten Backup erstellen. Vielleicht möchten wir es auf einen Produktions-Support-Server verschieben, wo wir einige Arbeiten daran ausführen werden, getrennt von der Produktionskopie der Datenbank. Wenn wir den einfachen Ansatz wählen, versuchen Sie dies:

In diesem Fall sollten Sie eine ganze Reihe von Fehlern sehen, die sich auf Dateien beziehen, die nicht überschrieben werden. Wenn Sie dies jedoch auf einem Server mit der vorhandenen Datenbank tun, müssen Sie den Speicherort der physischen Dateien mithilfe der logischen Namen ändern. Um die logischen Namen der Dateien für eine bestimmte Datenbank zu kennen, führen Sie dies aus, bevor Sie versuchen, die Dateien zu verschieben:

Dies kann dann verwendet werden, um die entsprechenden logischen Namen zu identifizieren, um dieses Skript zu generieren:

Wiederherstellen einer differentiellen Sicherung

Die letzte Methode besteht darin, die differentielle Sicherung anzuwenden. Dies erfordert zwei Schritte. Zuerst stellen wir die Datenbank wieder her, aber mit einer Wendung, und dann wenden wir die differentielle Sicherung an:

Das meiste davon ist wahrscheinlich selbsterklärend, basierend auf dem, was wir bereits behandelt haben. Die eine Falte ist die Einbeziehung der NORECOVERY Schlüsselwort. Ganz einfach, während einer Wiederherstellung können Transaktionen während des Sicherungsvorgangs gestartet worden sein. Am Ende einer Wiederherstellung werden abgeschlossene Transaktionen in die Datenbank übertragen und unvollständige Transaktionen zurückgesetzt. Einstellung NORECOVERY hält Transaktionen offen. Auf diese Weise kann der nächste Satz von Transaktionen der Reihe nach aus dem nächsten Backup abgerufen werden.

In diesem Artikel geht es hauptsächlich um einfache Sicherungen und Wiederherstellungen, aber eine erweiterte Wiederherstellung in 2005 ermöglicht die Wiederherstellung sekundärer Dateigruppen, während die Datenbank online ist. Die primäre Dateigruppe muss während des Vorgangs online sein. Dies wird für sehr große Datenbanksysteme hilfreicher sein.

Wiederherstellen von SQL Server-Datenbanken zu einem Zeitpunkt

Das Wiederherstellen von Protokollen ist nicht viel schwieriger als die differentielle Datenbankwiederherstellung, die wir gerade abgeschlossen haben. Es ist nur ein bisschen mehr damit verbunden, einen Moment in der Zeit wiederherzustellen. Angenommen, Sie sichern Ihre Protokolle in einer einzelnen Datei oder einem einzelnen Gerät:

Andernfalls erhalten Sie einfach die Dateinamen, die Sie benötigen. Führen Sie zuerst die Datenbankwiederherstellung aus und achten Sie darauf, sie in einem nicht wiederhergestellten Zustand zu belassen. Folgen Sie dem mit einer Reihe von Protokollwiederherstellungen zu einem bestimmten Zeitpunkt.

Jetzt haben wir eine Datenbank, die genau die letzte festgeschriebene Transaktion um 14:30:29 Uhr am 23. Denken Sie daran, dass Sie bei mehrstufigen Wiederherstellungen wie dieser die Datenbank in einem Wiederherstellungsstatus belassen müssen. Das bedeutet, dass Sie NORECOVERY an jede Anweisung anhängen müssen, bis Sie den Wiederherstellungsprozess abgeschlossen haben. Wenn Sie aus irgendeinem Grund NORECOVERY zu allen Ihren Anweisungen hinzugefügt haben oder einfach in der Mitte anhalten und die Datenbank wieder online stellen möchten, können Sie diese Anweisung verwenden, um den Vorgang abzuschließen:

Datenbank-Snapshots

SQL Server 2005 führte das Konzept eines Snapshots oder einer schreibgeschützten statischen Ansicht einer Datenbank ein. Snapshots werden hauptsächlich erstellt, um eine schreibgeschützte Version einer Datenbank für Berichtszwecke bereitzustellen. Sie funktionieren jedoch ähnlich wie Backups. Der einzige Hauptunterschied besteht darin, dass alle nicht festgeschriebenen Transaktionen zurückgesetzt werden. Es gibt keine Option zum Vorwärtsrollen, Erfassen von Protokollen usw., dass Backups bieten, noch sind sehr viele SQL Server-Ressourcen überhaupt verwendet. Vielmehr wird die Datenträgertechnologie verwendet, um eine Kopie der Daten zu erstellen. Aus diesem Grund sind sie viel schneller als Backups zu erstellen und wiederherzustellen.

HINWEIS:
Weitere Informationen zum SQL 2005-Snapshot finden Sie unter http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

Eine gute Verwendung von Snapshots kann neben der Berichterstellung darin bestehen, vor der Wartung einen Snapshot zu erstellen, nachdem Sie bereits alle aktiven Benutzer (und deren Transaktionen) aus dem System entfernt haben. Während Snapshots die Volatilität von Live-Backups nicht unterstützen, sind ihre Geschwindigkeit und einfache Wiederherstellung ein großartiges Werkzeug für die schnelle Wiederherstellung nach einem verpfuschten Rollout. Snapshots werden auf dem Server gespeichert, daher müssen Sie sicherstellen, dass Sie über ausreichenden Speicherplatz verfügen.

Die Syntax ist anders, da Sie keine Datenbank sichern, sondern eine neue erstellen:

Jetzt wird es für den schreibgeschützten Zugriff zugänglich sein. Da es uns in erster Linie darum geht, dies als Sicherungsmechanismus zu verwenden, sollten wir die Methode zum Zurücksetzen einer Datenbank auf einen Datenbank-Snapshot einbeziehen.

Identifizieren Sie zunächst den Snapshot, den Sie verwenden möchten. Wenn in einer Datenbank mehr als eine vorhanden ist, die Sie wiederherstellen möchten, müssen Sie alle außer der verwendeten löschen:

Anschließend können Sie die Datenbank zurücksetzen, indem Sie eine RESTORE-Anweisung ausführen (gemischte Metaphern, nicht gut):

Das war’s. Auf meinem System dauerte die Ausführung der Datenbank-Snapshots von Adventureworks 136 ms. Die vollständige Sicherung dauerte 5.670 ms. Die Wiederherstellung des Snapshots dauerte 905 ms und die Wiederherstellung der Datenbank dauerte 13.382 ms. Die Integration in einen Produktions-Rollout-Prozess könnte zu erheblichen Vorteilen führen

Auch hier ist anzumerken, dass es einige Einschränkungen bei der Verwendung des Snapshots gibt. Sie müssen über genügend Speicherplatz für eine zweite Kopie der Datenbank verfügen. Sie müssen vorsichtig mit Snapshots umgehen, da der größte Teil der Syntax der von Datenbanken selbst verwendeten ähnelt. Letzte, während es Snapshots an eine Datenbank angehängt sind, können Sie nicht eine Wiederherstellung aus einer Datenbanksicherung dieser Datenbank ausführen.

Best Practices

Die Art und Weise, wie Sie Datenbanksicherungen durchführen, sollte keine technische Entscheidung sein. Es sollte vom Geschäft diktiert werden. Kleine Systeme mit niedrigen Transaktionsraten und / oder Reporting-Systeme, die regelmäßig geladen werden, benötigen immer nur eine vollständige Datenbanksicherung. Mittlere und große Systeme werden abhängig von der Art der verwalteten Daten, um zu bestimmen, welche Arten von Backups erforderlich sind.

Für ein mittelgroßes System würde ein tägliches Backup mit Log-Backups während des Tages wahrscheinlich die meisten Datenanforderungen zeitnah erfüllen.

Bei einer großen Datenbank besteht der beste Ansatz darin, die Backups zu kombinieren, um maximale Wiederherstellbarkeit in kürzester Zeit zu gewährleisten. Führen Sie beispielsweise eine wöchentliche Vollsicherung durch. Führen Sie während der Woche zweimal täglich ein differentielles Backup durch. Führen Sie tagsüber alle 10 Minuten eine Protokollsicherung durch. Dies gibt Ihnen eine große Anzahl von Wiederherstellungsmechanismen.

Bei sehr großen Datenbanken müssen Sie Dateigruppen- und Dateisicherungen ausführen, da eine vollständige Sicherung oder sogar eine differentielle Sicherung der gesamten Datenbank möglicherweise nicht möglich ist. In diesem Bereich stehen eine Reihe zusätzlicher Funktionen zur Verfügung, auf die ich hier jedoch nicht eingehen werde.

Sie sollten sich die Zeit nehmen, einige Skripte für die Ausführung Ihrer Sicherungen und Wiederherstellungen zu entwickeln. Eine Namenskonvention, so dass Sie wissen, welche Datenbank, von welchem Server, ab welchem Datum, in welchem bestimmten Backup und Format wird sehr förderlich für Ihre geistige Gesundheit. Ein gemeinsamer Speicherort für Backups, ob vollständig oder inkrementell, sollte definiert werden. Alle Verantwortlichen sollten sowohl in Backup und Recovery als auch in der Fehlerbehebung geschult sein. Es gibt viele Möglichkeiten, dies zu tun, aber Sie können ein paar Vorschläge in Pop-Backups und Pop-Wiederherstellungen finden.

Der eigentliche Test besteht darin, Ihre Sicherungsmechanismen auszuführen und dann eine Wiederherstellung durchzuführen. Versuchen Sie dann eine andere Art der Wiederherstellung und eine andere und eine andere. Stellen Sie sicher, dass Sie nicht nur die Sorgfaltspflicht bei der Definition der Sicherung des Systems erfüllt haben, sondern auch den zusätzlichen Schritt unternommen haben, um sicherzustellen, dass Sie diese Sicherungen wiederherstellen können. Wenn Sie dies nicht praktiziert und die Praxis dokumentiert und dann das Dokument getestet haben, sind Sie in der Tat nicht bereit für eine Katastrophe.

Zusammenfassung

Backups in Ihrem Unternehmen sollten wie Abstimmungen in Chicago sein, früh und oft. Das Einrichten grundlegender Backups ist recht einfach. Das Hinzufügen von Protokollsicherungen und Differentialen ist ebenfalls einfach. Erkunden Sie die Optionen, um zu sehen, wie Sie Datei- und Dateigruppensicherungen und -wiederherstellungen hinzufügen, um die Geschwindigkeit Ihrer Sicherungen und Wiederherstellungen zu erhöhen. Behalten Sie einen gemeinsamen Namensstandard bei. Seien Sie vorsichtig, wenn Sie Snapshots verwenden, aber verwenden Sie sie auf jeden Fall. Speichern Sie Ihre Dateien an einem Standardspeicherort zwischen Servern. Üben Sie Ihre Wiederherstellungen. Schließlich, um wirklich Ihre Backups singen, laden Sie eine kostenlose Testversion von Red Gate SQL Backupâ ¢. Es bietet Hochleistungskomprimierung und Netzwerkresistenz, um den Prozess des Schreibens oder Kopierens von Backups über schuppige Netzwerke hinweg fehlertolerant zu gestalten.