Geplante SQL Server Express-Sicherung. SQL. Backup einrichten. Zusätzliche Hinweise für den Administrator

Trotz der Tatsache, dass wir in unseren vorherigen Materialien das Thema bereits angesprochen haben Exemplar reservieren Microsoft-Datenbanken SQL Server Die Antwort des Lesers zeigte die Notwendigkeit, ein umfassendes Material mit einer tieferen Untersuchung des theoretischen Teils zu erstellen. Die mit Schwerpunkt auf praktischen Anleitungen verfassten Artikel ermöglichen zwar die schnelle Einrichtung von Backups, erläutern jedoch nicht die Gründe für die Wahl bestimmter Einstellungen. Versuchen wir, diese Lücke zu schließen.

Wiederherstellungsmodelle

Bevor Sie ein Backup einrichten, sollten Sie ein Wiederherstellungsmodell auswählen. Für optimale Wahl Sie sollten die Wiederherstellungsanforderungen und die Kritikalität des Datenverlusts bewerten und diese mit den Gemeinkosten für die Implementierung eines bestimmten Modells vergleichen.

Wie Sie wissen, besteht die MS SQL-Datenbank aus zwei Teilen: der Datenbank selbst und dem Transaktionsprotokoll dafür. Die Datenbank enthält Benutzer- und Dienstdaten zum aktuellen Zeitpunkt, das Transaktionsprotokoll enthält den Verlauf aller Änderungen an der Datenbank für einen bestimmten Zeitraum, mit dem Transaktionsprotokoll können wir den Zustand der Datenbank auf einen beliebigen Zeitpunkt zurücksetzen.

Für den Einsatz in Produktionsumgebungen stehen zwei Wiederherstellungsmodelle zur Verfügung: einfach und vollständig. Es gibt auch ein Modell mit unvollständige Protokollierung, wird aber nur als Ergänzung zum Vollmodell für Zeiten groß angelegter Massenoperationen empfohlen, wenn zu einem bestimmten Zeitpunkt keine Notwendigkeit besteht, die Basis wiederherzustellen.

Einfaches Modell sorgt für die Sicherung nur der Datenbank; dementsprechend können wir den Zustand der Datenbank nur zum Zeitpunkt der Erstellung wiederherstellen Sicherheitskopie, gehen alle zwischen der letzten Sicherung und dem Fehler vorgenommenen Änderungen verloren. Gleichzeitig einfache Schaltung hat einen geringen Overhead: Sie müssen nur Kopien der Datenbank speichern; das Transaktionsprotokoll wird automatisch gekürzt und vergrößert sich nicht. Außerdem ist der Wiederherstellungsprozess am einfachsten und nimmt nicht viel Zeit in Anspruch.

Vollständiges Modell ermöglicht Ihnen die Wiederherstellung der Datenbank zu jedem beliebigen Zeitpunkt, erfordert jedoch zusätzlich zu den Datenbanksicherungen die Speicherung von Kopien des Transaktionsprotokolls für den gesamten Zeitraum, für den eine Wiederherstellung erforderlich sein kann. Bei aktiver Arbeit mit der Datenbank kann die Größe des Transaktionsprotokolls und damit auch die Größe der Archive große Ausmaße erreichen. Der Wiederherstellungsprozess ist auch viel komplexer und zeitaufwändiger.

Bei der Auswahl eines Wiederherstellungsmodells sollten Sie die Wiederherstellungskosten mit den Kosten für die Speicherung von Backups vergleichen und außerdem die Verfügbarkeit und Qualifikation des Personals berücksichtigen, das die Wiederherstellung durchführt. Die Restaurierung mit einem vollständigen Modell erfordert bestimmte Qualifikationen und Kenntnisse des Personals, während es bei einem einfachen Schema ausreicht, die Anweisungen zu befolgen.

Bei Datenbanken mit wenigen hinzugefügten Informationen kann es rentabler sein, ein einfaches Modell zu verwenden Hochfrequenz Kopien, die es Ihnen ermöglichen, verlorene Daten schnell wiederherzustellen und weiterzuarbeiten, indem Sie verlorene Daten manuell eingeben. Das vollständige Modell sollte vor allem dort eingesetzt werden, wo ein Datenverlust nicht akzeptabel ist und eine eventuelle Wiederherstellung kostspielig wäre.

Arten von Backups

Vollständige Kopie der Datenbank- Wie der Name schon sagt, stellt es den Inhalt der Datenbank und einen Teil des aktiven Transaktionsprotokolls für den Zeitpunkt dar, zu dem das Backup erstellt wurde (d. h. Informationen über alle aktuellen und unvollständigen Transaktionen). Ermöglicht die vollständige Wiederherstellung der Datenbank bis zum Zeitpunkt der Erstellung der Sicherung.

Delta-Datenbankkopie- Eine vollständige Kopie hat eine erheblicher Nachteil, es enthält alle Informationen in der Datenbank. Wenn häufig Backups erstellt werden müssen, stellt sich sofort die Frage nach der Verschwendung von Speicherplatz, da der größte Teil des Speichers von denselben Daten belegt wird. Um diesen Nachteil zu beseitigen, können Sie Differenzkopien der Datenbank verwenden, die nur Informationen enthalten, die sich seit der letzten vollständigen Kopie geändert haben.

Bitte beachten Sie, dass es sich bei einer Differenzkopie um Daten vom letzten Mal handelt voll Kopieren, d.h. Jede nachfolgende Differenzkopie enthält die Daten der vorherigen (sie können jedoch geändert werden) und die Größe der Kopie wächst ständig. Zur Wiederherstellung reichen eine vollständige und eine differenzielle Kopie, in der Regel die letzte, aus. Die Anzahl der Differenzkopien sollte nach der Vergrößerung ihrer Größe gewählt werden; sobald die Größe der Differenzkopie der Größe der Hälfte der Vollkopie entspricht, ist es sinnvoll, eine neue Vollkopie anzufertigen.

Sicherung des Transaktionsprotokolls– Gilt nur für das vollständige Wiederherstellungsmodell und enthält eine Kopie des Transaktionsprotokolls ab dem Zeitpunkt, an dem die vorherige Kopie erstellt wurde.

Wichtig zu merken nächsten Moment- Transaktionsprotokollkopien stehen in keiner Verbindung zu Datenbankkopien und enthalten keine Informationen aus früheren Kopien. Um die Datenbank wiederherzustellen, benötigen Sie daher eine ununterbrochene Kopienkette für den Zeitraum, in dem Sie den Status zurücksetzen möchten der Datenbank. In diesem Fall muss der Zeitpunkt des letzten erfolgreichen Kopierens innerhalb dieses Zeitraums liegen.

Sehen wir uns die Abbildung oben an: Wenn die erste Kopie der Protokolldatei verloren geht, können Sie den Status der Datenbank nur zum Zeitpunkt der vollständigen Kopie wiederherstellen, was dem einfachen Wiederherstellungsmodell ähnelt kann den Zustand der Datenbank zu jedem Zeitpunkt erst nach der nächsten differenziellen (oder vollständigen) Kopie wiederherstellen, vorausgesetzt, dass die Kette der Protokollkopien beginnend mit der Kopie vor dem Kopieren der Datenbank und darüber hinaus kontinuierlich ist (in der Abbildung). - ab dem dritten und weiter).

Transaktionsprotokoll

Die Wiederherstellungs- und Zuweisungsprozesse verstehen verschiedene Typen Um Backups zu erstellen, sollten Sie sich den Aufbau und die Funktionsweise des Transaktionsprotokolls genauer ansehen. Eine Transaktion ist die minimal mögliche logische Operation, die sinnvoll ist und nur vollständig abgeschlossen werden kann. Dieser Ansatz stellt die Datenintegrität und -konsistenz in allen Situationen sicher, da ein Zwischenzustand des Vorgangs nicht akzeptabel ist. Ein Transaktionsprotokoll wird verwendet, um alle Änderungen in der Datenbank zu kontrollieren.

Wenn eine Operation ausgeführt wird, wird dem Transaktionsprotokoll ein Datensatz über den Beginn der Transaktion hinzugefügt. Jedem Datensatz wird eine eindeutige Nummer (LSN) aus einer ununterbrochenen Reihenfolge zugewiesen. Wenn sich Daten ändern, wird ein entsprechender Eintrag im Protokoll vorgenommen. und nachdem der Vorgang abgeschlossen ist, erscheint im Protokoll eine Markierung, die angibt, dass die Transaktion geschlossen (behoben) ist.

Bei jedem Start analysiert das System das Transaktionsprotokoll und macht alle nicht festgeschriebenen Transaktionen rückgängig. Gleichzeitig werden Änderungen rückgängig gemacht, die im Protokoll aufgezeichnet, aber nicht auf die Festplatte geschrieben wurden. Dadurch ist es möglich, Caching und Lazy Writing zu verwenden, ohne sich Gedanken über die Datenintegrität machen zu müssen, selbst wenn keine Notstromsysteme vorhanden sind.

Der Teil des Protokolls, der aktive Transaktionen enthält und zur Datenwiederherstellung verwendet wird, wird als aktiver Teil des Protokolls bezeichnet. Es beginnt mit einer Zahl, die als Minimum Recovery Number (MinLSN) bezeichnet wird.

Im einfachsten Fall ist MinLSN die Datensatznummer der ersten ausstehenden Transaktion. Wenn Sie sich die Abbildung oben ansehen, erhalten wir durch Öffnen der blauen Transaktion eine MinLSN von 321. Nachdem sie im Datensatz 324 festgelegt wurde, ändert sich die MinLSN-Nummer auf 323, was der grünen Nummer entspricht, noch nicht begangen, Transaktion.

In der Praxis ist alles etwas komplizierter, zum Beispiel sind die Daten einer geschlossenen blauen Transaktion möglicherweise noch nicht auf die Festplatte geschrieben und das Verschieben von MinLSN auf 323 macht die Wiederherstellung dieses Vorgangs unmöglich. Um solche Situationen zu vermeiden, wurde das Konzept eines Kontrollpunkts eingeführt. Ein Prüfpunkt wird automatisch erstellt, wenn die folgenden Bedingungen eintreten:

  • Bei expliziter Ausführung der CHECKPOINT-Anweisung. Der Prüfpunkt wird für die aktuelle Verbindungsdatenbank ausgelöst.
  • Wenn Sie einen minimal protokollierten Vorgang für eine Datenbank ausführen, z. B. wenn Sie einen Massenkopiervorgang für eine Datenbank ausführen, die dem massenprotokollierten Wiederherstellungsmodell unterliegt.
  • Beim Hinzufügen oder Entfernen von Datenbankdateien mit der ALTER DATABASE-Anweisung.
  • Wenn Sie eine Instanz von SQL Server mithilfe der SHUTDOWN-Anweisung oder den SQL Server-Dienst (MSSQLSERVER) stoppen. In beiden Fällen wird für jede Datenbank in der SQL Server-Instanz ein Prüfpunkt erstellt.
  • Wenn Ihre SQL Server-Instanz regelmäßig automatische Prüfpunkte für jede Datenbank erstellt, um die Datenbankwiederherstellungszeit zu verkürzen.
  • Beim Erstellen einer Datenbanksicherung.
  • Beim Ausführen einer Aktion, die das Herunterfahren der Datenbank erfordert. Beispiele hierfür sind das Setzen des Parameters AUTO_CLOSE auf ON und das Schließen der letzten Verbindung des Benutzers mit der Datenbank oder das Ändern einer Datenbankeinstellung, die einen Datenbankneustart erfordert.

Abhängig davon, welches Ereignis zuerst aufgetreten ist, wird MinLSN entweder auf die Checkpoint-Datensatznummer oder den Beginn der ältesten ausstehenden Transaktion gesetzt.

Kürzung des Transaktionsprotokolls

Das Transaktionsprotokoll erfordert wie jedes Protokoll eine regelmäßige Bereinigung veralteter Einträge, da es sonst wächst und den gesamten verfügbaren Speicherplatz einnimmt. Wenn man bedenkt, dass bei aktiver Arbeit mit der Datenbank die Größe des Transaktionsprotokolls die Größe der Datenbank deutlich übersteigen kann, ist dieses Problem für viele Administratoren relevant.

Physisch gesehen ist die Transaktionsprotokolldatei ein Container für virtuelle Protokolle, die nacheinander gefüllt werden, wenn das Protokoll wächst. Das logische Protokoll, das den MinLSN-Eintrag enthält, ist der Anfang des aktiven Protokolls; die logischen Protokolle davor sind inaktiv und werden nicht benötigt automatische Wiederherstellung Basen.

Wenn ein einfaches Wiederherstellungsmodell ausgewählt wird, wird der inaktive Teil des Protokolls automatisch gelöscht, wenn die logischen Protokolle eine Größe von 70 % der physischen Datei erreichen. Kürzung. Dadurch wird jedoch nicht die physische Protokolldatei verkleinert, sondern lediglich die logischen Protokolle gekürzt, die nach diesem Vorgang wiederverwendet werden können.

Wenn die Anzahl der Transaktionen groß ist und bis zum Erreichen von 70 % der physischen Dateigröße keine inaktiven logischen Protokolle mehr vorhanden sind, wird die physische Dateigröße erhöht.

Somit wächst die Transaktionsprotokolldatei mit einem einfachen Wiederherstellungsmodell entsprechend der Aktivität der Arbeit mit der Datenbank, bis sie zuverlässig den gesamten aktiven Teil des Protokolls enthält. Danach wird sein Wachstum aufhören.

Beim vollständigen Modell kann der inaktive Teil des Protokolls erst gekürzt werden, wenn es vollständig gesichert ist. Eine Protokollkürzung erfolgt, wenn das Transaktionsprotokoll gesichert und ein Prüfpunkt erstellt wurde.

Eine falsche Konfiguration der Transaktionsprotokollsicherung in einem vollständigen Modell kann zu einem unkontrollierten Wachstum der Protokolldateien führen, was für unerfahrene Administratoren häufig ein Problem darstellt. Sie erhalten auch häufig Ratschläge zum manuellen Abschneiden des Transaktionsprotokolls. Bei einem vollständigen Wiederherstellungsmodell sollte dies nicht kategorisch erfolgen, da dadurch die Integrität der Kette der Protokollkopien verletzt wird und Sie die Datenbank nur zum Zeitpunkt der Erstellung der Kopien wiederherstellen können, was dem einfachen Modell entspricht .

In diesem Fall ist es an der Zeit, sich daran zu erinnern, worüber wir am Anfang des Artikels gesprochen haben: Wenn die Kosten für ein vollständiges Modell die Kosten für die Restaurierung übersteigen, sollte einem einfachen Modell der Vorzug gegeben werden.

Einfaches Wiederherstellungsmodell

Nachdem wir nun das erforderliche Minimum an Wissen erlangt haben, können wir mit einer detaillierteren Betrachtung der Wiederherstellungsmodelle fortfahren. Beginnen wir mit einem einfachen. Nehmen wir an, dass wir zum Zeitpunkt des Fehlers eine vollständige und zwei Differenzkopien haben:

Die Sicherungen wurden einmal täglich durchgeführt und die letzte Kopie wurde in der Nacht vom 21. auf den 22. erstellt. Der Fehler tritt am Abend des 22. auf, bevor die nächste Kopie erstellt wird. In diesem Fall müssen wir nacheinander die vollständigen und letzten Differenzkopien wiederherstellen und die Daten für den letzten Arbeitstag gehen verloren. Sollte sich aus irgendeinem Grund herausstellen, dass auch die Kopie vom 21. beschädigt ist, können wir die vorherige Kopie wiederherstellen und verlieren einen weiteren Arbeitstag, während uns gleichzeitig eine Beschädigung der Kopie vom 20. in keiner Weise daran hindert von der erfolgreichen Wiederherstellung der Daten am Abend des 21., wenn eine entsprechende Kopie verfügbar ist.

Vollständiges Wiederherstellungsmodell

Betrachten wir eine ähnliche Situation, verwenden jedoch das vollständige Wiederherstellungsmodell. Darüber hinaus erstellen wir täglich Backups nach dem Full + Differential-Prinzip und kopieren das Transaktionsprotokoll auch mehrmals täglich.

Der Wiederherstellungsprozess wird in diesem Fall komplizierter sein. Zunächst müssen Sie das Ende des Protokolls (rot dargestellt) manuell sichern, d. h. Teil des Protokolls vom Zeitpunkt der Erstellung der letzten Kopie bis zum Unfall.

Geschieht dies nicht, ist eine Wiederherstellung der Datenbank nur in dem Zustand zum Zeitpunkt der Erstellung der letzten Kopie des Transaktionsprotokolls möglich.

In diesem Fall hindert uns eine Beschädigung der Protokollkopiedatei des Vortages nicht daran, den aktuellen Zustand der Datenbank wiederherzustellen, sondern beschränkt uns auf den Zeitpunkt, an dem die letzte Kopie erstellt wurde, d. h. aktuelle Tage.

Dann stellen wir nacheinander die vollständigen und differenziellen Kopien sowie die Kopienkette des Protokolls wieder her, die nach der letzten Sicherung erstellt wurde. Die letzte, die wir wiederherstellen, ist eine Kopie des letzten Fragments des Protokolls, was uns die Möglichkeit gibt, die Datenbank richtig wiederherzustellen zum Zeitpunkt des Unfalls oder eines willkürlichen Unfalls davor.

Wenn die letzte Differenzkopie beschädigt ist, führt dies bei einem einfachen Modell zum Verlust eines weiteren Arbeitstages. Beim Vollmodell können Sie die vorletzte Kopie wiederherstellen. Anschließend müssen Sie die gesamte Transaktionskette wiederherstellen Protokollkopien vom Moment der vorletzten Kopie bis zum Fehler. Die Wiederherstellungstiefe hängt nur von der Tiefe der kontinuierlichen Protokollkette ab.

Wenn andererseits eine der Kopien des Transaktionsprotokolls beschädigt ist, beispielsweise die vorletzte, können wir die Daten nur bis zum Zeitpunkt der letzten Sicherung + dem Zeitraum in der intakten Kette der Protokollkopien wiederherstellen. Wenn die Protokolle beispielsweise um 12, 14 und 16 Uhr erstellt wurden und das um 14 Uhr erstellte Protokoll beschädigt ist, können wir mit einer täglichen Kopie die Datenbank bis zum Ende der kontinuierlichen Kette wiederherstellen, d. h. bis 12 Uhr.

  • Stichworte:

Bitte aktivieren Sie JavaScript, um die differenzielle Sicherung anzuzeigen, die auf der letzten vollständigen Sicherung der Daten basiert. Bei einem differenziellen Backup werden nur Änderungen gespeichert, die seit dem letzten vollständigen Backup vorgenommen wurden.
Empfehlungen:
  1. Verwenden Sie differenzielle Datenbankkopien, wenn das Erstellen einer vollständigen Datenbankkopie viel Zeit in Anspruch nimmt
  2. Erstellen Sie regelmäßig eine vollständige Kopie der Datenbank, um die Menge der erstellten Differenzkopien zu reduzieren.
  3. Nach der Erstellung einer vollständigen Kopie der Datenbank verlieren alle vorherigen Differenzkopien ihre Relevanz.
Weitere Informationen zu Empfehlungen zur Häufigkeit der Erstellung differenzieller Backups finden Sie hier.

Lassen Sie mich Ihnen ein kleines praktisches Beispiel geben, warum wir begonnen haben, eine Differenzkopie zu verwenden. Im Laufe der Zeit wuchs die Datenbank unseres Kunden auf eine solche Größe an, dass die Erstellung eines vollständigen Backups 8 Stunden, also mehrere Monate, dauerte und dieser Vorgang möglicherweise nicht bis zum Beginn des Arbeitstages abgeschlossen werden konnte. Nach der Umstellung auf differenzielles Backup haben wir die Zeit von 8 Stunden auf 2–4 Minuten reduziert (je nach Wochentag). Einmal pro Woche erstellten wir eine vollständige Kopie der Datenbank.

Beispiel-SQL zum Erstellen einer differenziellen Sicherungskopie einer Datenbank mit Überprüfung der Kopie nach Abschluss (im Gegensatz zu einer vollständigen Kopie mit dem Flag DIFFERENTIAL Sie sollten es stattdessen verwenden KEIN FORMAT).

Deklarieren Sie @pathBackup als varchar(55) set @pathBackup = N"C:\Backup\[DB-Dateiname]_" + REPLACE(convert(varchar,GETDATE(), 104),".","_") + " .bak“ BACKUP DATABASE [Datenbankname] TO DISK = @pathBackup WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N „Full Database Backup“, SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM GO @backupSetId als int deklarieren @pathBackup deklarieren as varchar(55) set @pathBackup = N"C:\Backup\[DB-Dateiname]_" + REPLACE(convert(varchar,GETDATE(), 104),".","_") + " .bak" Wählen Sie @backupSetId = Position aus msdb..backupset, wobei Datenbankname=N"[Datenbankname]" und backup_set_id=(wählen Sie max(backup_set_id) aus msdb..backupset aus, wobei Datenbankname=N"[Datenbankname]"), wenn @backupSetId null ist begin raiserror(N"Überprüfungsfehler. Sicherungsinformationen für Datenbank '[Datenbankname]' wurden nicht gefunden.", 16, 1) end RESTORE VERIFYONLY FROM DISK = @pathBackup WITH FILE = @backupSetId, NOUNLOAD, NOREWIND GO

3.Systemdatenbanken
Zusätzlich zur Hauptdatenbank und den zugehörigen Dateien empfehle ich dringend, Kopien der Systemdatenbanken anzufertigen. Schauen wir uns zunächst an, welche Datenbanken in MS SQL vorhanden sind. Es gibt nur 5 davon:

Ich habe mich entschieden, nur zwei Systemdatenbanken zu sichern:

  1. msdb – weil dort konfigurierte Aufgaben und andere gespeichert sind
  2. Master – alle konfigurierten SQL Server-Einstellungen werden gespeichert.
Diese Informationen sind immer noch nicht sehr kritisch und können manuell wiederhergestellt werden. Aber warum sollten Sie zusätzliche Zeit verschwenden, wenn Sie sie einfach aus einer Sicherungskopie übernehmen können?
4. Backup-Plan
Auf dieser Grundlage erstellen wir unseren Datensicherungsplan. Es kann von Ihren Anforderungen abweichen, es hängt alles von den Anforderungen für die Datenbankwiederherstellung ab. Als ich den Plan erstellte, musste ich berücksichtigen, dass die Daten so weit wie möglich wiederhergestellt werden mussten und der Datenverlust nicht mehr als eine Stunde betrug.

Wir werden folgende Backups erstellen:

  • Eine vollständige Kopie der Hauptdatenbank, mehr als einmal pro Woche, ist nicht erforderlich
  • Jeden Tag eine differenzielle Kopie der Hauptdatenbank
  • Stündliche Kopien des Hauptdatenbank-Transaktionsprotokolls
  • Kopie der Master-Systemdatenbank, einmal pro Woche
  • Kopie der msdb-Systemdatenbank, einmal pro Woche
Als Ergebnis kamen wir zu folgendem Datensicherungsplan:
Wochentag
Zeit
Aktionen
Frequenz
Beschreibung
Montag Freitag
Von 8:00 bis 21:00 Uhr
Backups

Transaktionsprotokoll

Jede Stunde
Nach der Durchführung einer Datenbanksicherung wird das Transaktionsprotokoll komprimiert und gekürzt
Samstag Sonntag
Von 8.00 bis 18.00 Uhr
Montag Sonntag
22-00
Differenzielle Kopie der Hauptdatenbank
1 pro Tag
Nachdem eine differenzielle Kopie erfolgreich ausgeführt wurde, werden alle alten Transaktionsprotokollkopien gelöscht
Samstag
12-00
Datenbankprüfung
1 pro Tag
Überprüfung der Datenbank auf Integrität.
Samstag
18-00
Erstellen einer vollständigen Kopie der Datenbank
1 pro Tag
Nach Abschluss dieses Vorgangs wird eine Benachrichtigung per E-Mail gesendet.

Wenn das Backup erfolgreich erstellt wurde, wird es gelöscht

  • altes Voll-Backup
  • alles alte Differentialkopien
  • alle alten Transaktionsprotokolle
Montag Sonntag
23-30
Erstellen einer Kopie der Mastersystemdatenbank
1 pro Tag

Sonntag
12-30
Erstellen einer Kopie der msdb-Systemdatenbank
1 Mal pro Monat
Es wird immer nur die letzte Instanz der Datenbank gespeichert
  1. Verwenden Sie die Option BACKUP WITH CHECKSUM
    um sicherzustellen, dass alles gut gelaufen ist. Der Nachteil dieser Lösung besteht darin, dass bei großen Datenbanken die Überprüfung der Prüfsumme eine erhebliche Belastung für das System darstellen kann.
  2. Sichern Sie Dateien nicht auf derselben physischen Festplatte, auf der die Datenbank oder das Transaktionsprotokoll gespeichert ist.
  3. Wenn Sie MS SQL 2008 oder höher verwenden, empfehle ich Ihnen, die SQL-Backup-Komprimierung zu verwenden. Der folgende Code aktiviert die Komprimierung standardmäßig: USE master; GO EXEC sp_configure ‚Backup-Komprimierungsstandard‘, „1“; NEUKONFIGURIEREN MIT OVERRIDE;
  4. Bewahren Sie Backups mehrere Tage lang auf, für den Fall, dass eines davon beschädigt wird – ein altes Backup ist besser als kein Backup.
  5. Verwenden DBCC CHECKDBÜberprüfen Sie jede Datenbank vor dem Kopieren. Dies macht Sie rechtzeitig auf drohende Probleme aufmerksam. DBCC CHECKDB("Datenbankname") WITH NO_INFOMSGS, ALL_ERRORMSGS; Notiz: zum Üben nutzten wir dieser Scheck, kurz bevor Sie eine vollständige Sicherung durchführen.
  6. Aktualisieren Sie regelmäßig Statistiken und organisieren Sie Datenbankindizes neu

Verwendung der Anwendung

Ein paar Nuancen zur Anwendung:
  • Alle Texte und Abfragen im Code sind in Ressourcen enthalten, das war für mich einfacher
  • Wenn Sie Verbindungsparameter und andere Einstellungen eingeben, werden diese in einer Datei gespeichert. Für Express und Standard verwendet verschiedene Dateien(dbStandart, udExpress) speichern sie die UserData-Klasse
  • Für einige Vorgänge sind möglicherweise Administratorrechte erforderlich
  • Im Moment funktioniert die Verbindung zur Datenbank unter einem Domänenkonto nicht
  • Das Programm hat keine superschöne Oberfläche
1. Administratorbenachrichtigung einrichten
Ich war zu faul, mich jedes Mal am Server anzumelden und zu überprüfen, ob die Aufgabe funktioniert hat oder ein Fehler aufgetreten ist. Und ich wollte in der Lage sein, auch andere Benachrichtigungen zu erhalten, nicht nur über den Abschluss einer Aufgabe.

Hierzu wird DatabaseMail MS SQL verwendet (ab Standardversion)
In meiner Bewerbung habe ich einen speziellen Abschnitt erstellt, um diese Aufgabe zu automatisieren

Wenn Sie darauf klicken, erscheint ein Formular zum Ausfüllen der für die Erstellung eines Mailing-Profils erforderlichen Informationen:

Die Anwendung wird automatisch für den Standard-SMTP-Port 25 für die Adresse konfiguriert, von der aus Briefe gesendet werden. Bei Bedarf kann es in der Prozedur sysmail_add_account_sp geändert werden
Benutzername und Passwort sind erforderlich, falls vorhanden Postdienst Die Authentifizierung ist konfiguriert.

Der Betreibername im System wird angezeigt, damit wir ordnungsgemäß ein Profil in DatabaseMail erstellen können. Schreiben Sie einen beliebigen Namen, der Ihnen klar ist. Nachfolgend finden Sie ein Beispiel für ein ausgefülltes Formular.

  1. MS SQL-Systemparameter ändern sich.
  2. Das DatabaseMail-Profil wird erstellt
  3. Aktiviert im SQL Agente-Profil
  4. Das DatabaseMail-Konto wird erstellt
  5. Hinzufügen eines DatabaseMail-Kontos zum Datenbank-Mail-Profil
  6. Der DatabaseMail-Operator wird erstellt
Es wird im nächsten Artikel ausführlicher beschrieben und ich habe es teilweise von hier übernommen. Selbstverständlich können diese Aktionen auch mit SSMS durchgeführt werden.
2.Zusätzliche Hinweise für Administrator
Das Programm stellt zwei Aufgaben bereit, die auf die Datenbank angewendet werden:
  1. Überprüfung der Integrität der Datenbank. Zur Überprüfung der Datenbank wurde das Standardverfahren DBCC CHECKDB verwendet.
  2. Informieren über freien Speicherplatz in Dateigruppen.
  3. Die zweite Aufgabe wurde mithilfe einer Abfrage an die Systemtabelle dbo.sysfiles implementiert
  4. Hier ist ein Beispiel dieser Anfrage, das gegen die Datenbank ausgeführt wurde:
Wählen Sie NAME = left(a.NAME,15), a.FILEID, = Convert(decimal(12,2),round(a.size/128.000,2)), = Convert(decimal(12,2),round( fileproperty(a.name,"SpaceUsed")/128.000,2)), = Convert(decimal(12,2),round((a.size-fileproperty(a.name,"SpaceUsed"))/128.000,2) ), FILENAME = a.FILENAME Aus dbo.sysfiles a
Die Antwort vom Server erfolgt im Formular an die E-Mail-Adresse des Administrators HTML-Markup. Diese Syntax ist dank der folgenden Standard-MS SQL FOR XML-Funktion möglich.

Außerdem suchte ich nach einer Möglichkeit, das zurückgegebene Ergebnis der Ausführung von Abfragen in umzuwandeln HTML-Text, stieß auf die folgende Seite, auf der eine Person ein ganzes Verfahren für diese Zwecke erstellt hat
Sie können diese Vorgänge über den entsprechenden Eintrag im Programmmenü konfigurieren:

Es erscheint ein Fenster, das das Postfach angibt, an das der HTML-Text des Berichts gesendet werden soll:

3. Beheben von Problemen beim Einrichten von DatabaseMail
In MS SQL 2008 ist beim Einrichten des SQL Server-Agenten ein Problem aufgetreten. Die Symptome sind wie folgt: Nach der Konfiguration ist es nicht möglich, den SQL Agent zu starten. Dies wird größtenteils mit gelöst Installationsupdate an den SQL-Server.

Wenn diese Updates nicht helfen, müssen Sie den Fix herunterladen. Es ist auf dieser Website zu finden. Den endgültigen Link kann ich derzeit nicht bereitstellen. Um zum Fixpaket zu gelangen, müssen Sie eine Reihe von Fragen beantworten.
Wenn es Probleme mit dem DatabaseMail-Modul gibt. Nachdem Sie dieses Modul mithilfe der Anwendung konfiguriert haben, müssen Sie zum SQL-Agenten gehen und das Ereignisprotokoll anzeigen. Wenn die Fehlermeldung „Verbindung zu nicht möglich“ auftritt Briefkasten" Dies bedeutet, dass ein Problem vorliegt, auch wenn der Brief per Verifizierung versendet wird.

Dies kann durch folgende Manipulationen korrigiert werden:

  1. Management Studio – SQL Server-Agent – ​​Eigenschaften.
  2. Warnsystem
  3. Deaktivieren Sie E-Mail-Profil aktivieren
  4. OK klicken
  5. Melden Sie sich erneut an und aktivieren Sie das Kontrollkästchen
  6. Starten Sie den SQL Server-Agenten neu.
Überprüfen Konto für den SQL-Agent-Dienst. Wenn es sich um ein Domänenkonto handelt, ändern Sie es in ein Systemkonto oder umgekehrt. Alles sollte funktionieren.
4. Richten Sie die Sicherung mit der SQL-Standardanwendung ein:
Wählen Sie die Standardversion. Benachrichtigungen einrichten. (siehe Abschnitt Benachrichtigungseinstellungen):

Wir stellen eine Verbindung zur Datenbank her, geben die Verbindungsdaten ein und geben die Datenbank an, für die der Job verwendet werden soll:

Wählen Sie die Sicherungseinstellung:

Geben Sie die Pfade zum Speichern von Datenbankkopien an. Wenn die angegebenen Ordner nicht vorhanden sind, versucht das Programm, sie zu erstellen (die entsprechenden Rechte sind erforderlich).

Klicken Sie auf Speichern und die entsprechenden Aufgaben werden in der Datenbank konfiguriert. Es empfiehlt sich, für jedes Backup unterschiedliche Ordner zu konfigurieren, denn... Beim Löschen werden alle Dateien mit der Erweiterung bak gelöscht. (cm. Abschnitt zum Löschen von Datenbankkopien)

5. Richten Sie die Sicherung mit der SQL Express-Anwendung ein:
Da SQL Express über keinen SQL-Agenten verfügt, musste die Aufgabe der Automatisierung von Backups anders gelöst werden. IN vom Benutzer angegeben Im Ordner wird eine Bat-Datei erstellt, die die SQL-Abfrage beschreibt, die für die Erstellung einer Sicherungskopie verantwortlich ist. Bei Bedarf können Sie es direkt bearbeiten. Darüber hinaus sollte der Standard-Windows-Scheduler funktionieren; er erstellt eine Aufgabe, die einmal täglich zur angegebenen Zeit ausgeführt wird.

Starten Sie dazu die Anwendung. Wählen Sie MS SQL Express:

Es erscheint ein Formular zum Ausfüllen der Parameter:

Wir geben an, wo unsere Kopie gespeichert wird und wo sich die Bat-Datei befindet, um eine Kopie der Datenbank zu erstellen (der Dateiname muss nicht angegeben werden, er wird automatisch angegeben). Als nächstes legen wir die Verbindungseinstellungen und den Zeitpunkt fest, zu dem die Aufgabe gestartet werden muss.

Der einzige Nachteil dieses Ansatzes besteht darin, dass das Passwort für die Verbindung zur Datenbank im Klartext gespeichert werden muss.

6. Aufgaben aus der Datenbank löschen.
Wenn Sie alle Aufgaben aus der Datenbank löschen müssen (z. B. wenn Sie die Pfade zum Speichern der Datenbank ändern möchten). Nutzen Sie dazu den entsprechenden Eintrag im Programmmenü. Alle Aufgaben mit einem bestimmten Startpräfix (in meinem Fall King) werden aus dem SQL Agent gelöscht:

7. Datenbankkopien löschen
In einigen Aufgaben ist das Löschen alter Datenbankkopien so konfiguriert, dass sie gelöscht werden. Dazu verwende ich die Prozedur master.dbo.xp_delete_file. Anwendungsbeispiel: Löscht alle Dateien mit der Erweiterung „bak“ aus dem angegebenen Ordner, deren Erstellungsdatum mehr als 14 Tage zurückliegt.
EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N"bak",dateadd(d,-14,getdate()),0;
Und hier ist ein weiteres detaillierteres Beispiel und Informationen darüber, welche Parameter diese Funktion benötigt.

So stellen Sie Backups wieder her

Aus Zeitgründen wurde das Wiederherstellungsmodul noch nicht implementiert, vielleicht werde ich es in Zukunft hinzufügen, aber vorerst werde ich nur kurz beschreiben, wie die Datenbank wiederhergestellt werden kann.

Verwendung eines SQL-Skripts. Um eine Datenbank wiederherzustellen, verwenden Sie den Befehl RESTORE.

Wenn Sie nur die Datenbank von einer vollständigen Kopie wiederherstellen müssen, führen Sie einfach das folgende Skript aus:
RESTORE DATABASE [Datenbankname] FROM DISK = „Z:\SQLServerBackups\back.bak“ WITH REPLACE
Wenn Sie nacheinander eine vollständige Kopie, differenzielle Kopien und Transaktionsprotokolle wiederherstellen müssen, müssen Sie das folgende SQL-Skript schreiben.

RESTORE DATABASE TEST_DB – Wiederherstellen einer vollständigen Kopie FROM test_db_full WITH NORECOVERY; GO RESTORE DATABASE TEST_DB – Wiederherstellung der Differenzkopie FROM test_db_diff WITH FILE = 1, NORECOVERY; GO RESTORE LOG TEST_DB – Transaktionsprotokoll Nr. 1 wiederherstellen FROM test_db_tran_1 WITH FILE = 1, WITH NORECOVERY; GO RESTORE LOG TEST_DB – Wiederherstellen des Transaktionsprotokolls Nr. 2 FROM test_db_tran_2 WITH FILE = 1, WITH NORECOVERY; GO RESTORE DATABASE TEST_DB WITH RECOVERY; GEHEN
Sie können SSMS auch zum Wiederherstellen der Datenbank verwenden.

Tags: Tags hinzufügen

Nachdem ich viele Informationen aus verschiedenen Quellen studiert hatte, beschloss ich, den Prozess der Einrichtung einer MS SQL Server-Datenbanksicherung für zu beschreiben voll Welches Modell Sie verwenden möchten, liegt bei Ihnen. Ich füge jedoch hinzu, dass bei einem großen Informationsfluss in Ihrer Datenbank (z. B. Dutzende, Hunderte oder Tausende von Dokumenten werden in einer Stunde erstellt) der Verlust von Informationen während eines Arbeitstages sind einfach inakzeptabel. In diesem Fall gewährleistet nur das vollständige Modell die Sicherheit Ihrer Daten. Dieser Artikel richtet sich an Anfänger Systemadministratoren und enthält meiner Meinung nach der Mindestsatz an Aktionen zum Sichern einer 1C-Datenbank. Die Installation/Konfiguration des SQL-Servers selbst und die Bereitstellung einer Datenbank darauf ist nicht Gegenstand dieses Artikels.

Alle Einstellungen werden wir mit SQL Management Studio vornehmen. Zuerst müssen Sie ein Backup-Gerät erstellen. Sie müssen es nicht erstellen, aber meiner Meinung nach ist es viel bequemer und korrekter. im Handumdrehen SQL Management Studio -> Serverobjekte -> Sicherungsgeräte. Sie müssen den Namen des Geräts und die Datei angeben, in der die Backups gespeichert werden (vorzugsweise mit der Erweiterung BAK), dann können Sie den Inhalt des Mediums anzeigen, alle Backups werden dort aufgelistet.

Jetzt können Sie mit der Einrichtung des Wartungsplans beginnen. Ein Wartungsplan kann für alle Datenbanken gleichzeitig erstellt werden. Bequemer ist es jedoch, für jede Datenbank einen eigenen Wartungsplan zu erstellen.

Unser Serviceplan besteht aus drei Unterplänen: 1 – Datenbanksicherung (vollständig); 2 – Datenbanksicherung (Differenz); 3 – Sichern Sie das Transaktionsprotokoll. Jeder Unterplan hat seinen eigenen Ausführungsplan. Jeder richtet den Zeitplan nach eigenem Ermessen ein, aber in meinem Fall wird einmal pro Woche am Sonntag eine vollständige Kopie erstellt, jeden Tag außer sonntags eine Differenzkopie und jede Stunde ein Transaktionsprotokoll. Mit diesem Backup-Modell können Sie die gewünschte Datenbank zu jedem Datum und zu jeder Uhrzeit wiederherstellen und sparen dadurch Platz auf Ihrer Festplatte Tatsächlich wird einmal pro Woche ein vollständiges Backup durchgeführt, und unter der Woche werden nur Änderungen vorgenommen.

Einen Tagesplan erstellen. Wöchentlich unterscheidet sich nur durch die Checkbox „Sonntag“ und deaktiviert von „Montag“ bis „Samstag“.

Fahrplan für den Schienenverkehr. Die Einsparzeit während des Tages wird rot hervorgehoben. Dies ist beispielsweise sinnvoll, wenn Benutzer während eines bestimmten Zeitraums mit der Datenbank arbeiten. Wenn der Betriebsmodus 24x7 ist, belassen wir ihn auf der Standardeinstellung.

Die folgende Abbildung zeigt den wöchentlichen Unterplan-Editor; er besteht aus Aufgaben, die in einer bestimmten Reihenfolge ausgeführt werden. Die Reihenfolge wird manuell festgelegt und grüne Pfeile bedeuten, dass die nächste Aufgabe erst dann abgeschlossen wird Erfolgreiche Fertigstellung die vorherige, und die blaue bedeutet, dass die Aufgabe immer dann ausgeführt wird, wenn die vorherige Aufgabe abgeschlossen ist. Im Wartungsteilplan-Editor können Aufgaben über das „Elements Panel“ hinzugefügt werden, das sich bei geöffnetem Editor in der oberen linken Ecke befindet.

Aufgaben. Sie müssen zu jeder Aufgabe gehen und die Datenbank auswählen, für die sie ausgeführt werden soll, sowie eine Reihe weiterer Einstellungen (falls vorhanden). Schauen wir uns an, welche Aufgaben der wöchentliche Teilplan unseres Wartungsplans enthält.

1. „Aufgabe zur Überprüfung der Datenbankintegrität“. Die folgende Aufgabe wird nur ausgeführt, wenn die Datenbank keine Fehler enthält. (Sollten wir die Datenbank mit Fehlern sichern?)

2. „Index neu erstellen“-Aufgabe. Es ist notwendig, den Index jeden Tag wiederherzustellen (neu aufzubauen), weil... Bei der Arbeit mit Indizes kommt es zu einer starken Fragmentierung, und wenn die Fragmentierung 25 % überschreitet, beginnt SQL merklich langsamer zu werden. Dieser Vorgang ist recht ressourcenintensiv und kann daher mindestens einmal pro Woche durchgeführt werden Tageszeit Teilplan, um es durch die weniger ressourcenintensive Aufgabe „Index-Reorganisation“ zu ersetzen.

3. „Aufgabe „Statistik aktualisieren““ Zur Optimierung... Diese Aufgabe kann übrigens mehrmals am Tag durchgeführt werden, wenn Ihre Datenbank stark ausgelastet ist.

4. Nach dem Aktualisieren der Statistiken MÜSSEN Sie den prozeduralen Cache leeren. Ziehen Sie dazu die Aufgabe „T-SQL-Anweisung ausführen“ in den Editor und schreiben Sie eine Prozedur in das Feld „T-SQL-Anweisung:“. DBCC FREEPROCCACHE. Sie müssen jedoch berücksichtigen, dass dieser Vorgang den Cache ALLER Datenbanken löscht und wir die Statistiken einzeln aktualisiert haben! Lesen Sie, wie Sie den prozeduralen Cache für eine bestimmte Datenbank löschen. Kurz gesagt: DBCC FLUSHPROCINDB(DB_ID)

5. „DB Backup“ (Aufgabe zum Sichern der Datenbank). In dieser Aufgabe geben wir an, welche Datenbank wir sichern und welche Art von Sicherung (für einen wöchentlichen Unterplan – vollständig, für einen täglichen Unterplan – differenziell, für einen stündlichen – Transaktionsprotokoll). Wir stellen den Schalter auf die Position „Erstellen eines.“ „Sicherungskopie der Datenbanken in einer oder mehreren Dateien“ und fügen Sie das zuvor erstellte Sicherungsgerät hinzu. In diesem Fall werden ALLE Kopien in einer Datei gespeichert, die beim Erstellen angegeben wurde Backup-Gerät: Wenn der Schalter auf „Eine Backup-Datei für jede Datenbank erstellen“ belassen wird, wird für jedes Backup eine separate Datei für Vollständig, Differenziell und VT erstellt, was beim Wiederherstellen sehr unpraktisch, beim Speichern jedoch praktisch ist. Vergessen Sie nicht anzugeben, dass Sie Backups komprimieren müssen!

6. „Protokoll löschen“ Löscht Datensätze, die beim Ausführen von Aufgaben erstellt wurden. Sie können auch die Aufgabe „Post-Maintenance Cleanup“ aktivieren und so konfigurieren, dass Textprotokolle oder veraltete Backups gelöscht werden.

Der Unterplan für die VT-Sicherung besteht aus einer Aufgabe „Datenbanksicherung“. Für mich ist es bequemer, die VT nicht auf dem Backup-Gerät, sondern in einer separaten Datei zu speichern, die in den Aufgabeneinstellungen angegeben werden muss.

MS SQL Express verfügt nicht über einen Agenten, mit dem Sie geplante Aufgaben ausführen können, Sie können ihn aber auch verwenden Standardmittel Windows.

Sehr oft reicht für kleine Projekte die Express-Version des SQL-Servers aus. Eines der Probleme besteht darin, dass die Express-Version keinen SQL-Agent-Dienst hat, mit dem Sie einige Aufgaben nach einem Zeitplan ausführen können. Stattdessen können Sie SQLCMD und standardmäßige geplante Aufgaben von Windows verwenden. Als Erstes müssen wir ein Skript schreiben, das die notwendigen Backups für uns erstellt. Um es zu generieren, können Sie MS Management Studio verwenden (es kann auch für die Express-Version heruntergeladen werden) und im Backup-Erstellungsfenster nicht auf „OK“ klicken, sondern auf „ Skriptaktionen für...”.

Normalerweise verwende ich für solche Aufgaben das folgende Skript:

DECLARE @pathName NVARCHAR(512) SET @pathName = "D:\Backup\db_backup_" + Convert(varchar(8), GETDATE(), 112) + ".bak" BACKUP DATABASE TO DISK = @pathName WITH NOFORMAT, NOINIT, NAME = N"db_backup", SKIP, NOREWIND, NOUNLOAD, STATS = 10

Dieses Skript erstellt ein Backup mit einem Dateinamen db_backup_YYYYDDMM.bak Wo JJJJTTMM ist das aktuelle Datum. Das Datum im Dateinamen ermöglicht es uns, jeden Tag ein Backup in einer neuen Datei zu erstellen. Führen Sie es aus und prüfen Sie, ob das Backup tatsächlich so erstellt wird, wie Sie es benötigen. Wir speichern dieses Skript in einem Ordner unter dem Namen Schedule.sql, vermuten c:\geplante Aufgaben\. Lassen Sie uns eine ausführbare Datei im selben Ordner erstellen backup.bat, folgender Inhalt:

Sqlcmd -S SEVERNAME -U Benutzername -P Passwort -i Schedule.sql 7z a -tzip D:\Backup \db_backup_%date%.zip -i! D:\Backup\db_backup_*.bak aus d:\Backup\db_backup_*.bak

Wo wir ändern: SERVERNAME – Servername, UserName – Benutzername, Passwort – Benutzerpasswort, Schedule.sql – Name des gespeicherten Skripts. Die zweite und dritte Zeile der Batchdatei archivieren die Sicherung zip-Datei und löscht die Sicherungsdatei selbst. Damit die Archivierung funktioniert, müssen Sie den 7z-Archiver installieren und die vollständigen Pfade zur ausführbaren Datei 7z.exe schreiben oder 7z.exe und 7z.dll im selben Ordner ablegen, in dem sich die Skripte befinden. Jetzt können wir die ausführbare Datei „backup.bat“ ausführen und prüfen, ob sie wie erwartet funktioniert. Der letzte Schritt besteht darin, den Zeitplan in Windows-Aufgaben zu schreiben. Starten Sie den Taskplaner über das Startmenü oder geben Sie in die Befehlszeile ein taskschd.msc. In verschiedenen Windows-Versionen Es sieht anders aus und Sie können Informationen zur Ausführung der Aufgabe in nachlesen Windows-Hilfe. Die Hauptsache ist, die Aufgabe als Benutzer mit ausreichenden Rechten auf die verwendeten Ordner auszuführen. Mit solchen Aktionen können Sie auch beliebige andere Aufgaben programmieren. Im Drehbuch Schedule.sql Sie können jeden vor dem Backup anrufen notwendigen Verfahren, kann die Datenbank neu indizieren oder komprimieren.

Es wird empfohlen, es zu konfigurieren regelmäßige Datenbanksicherungen(im Falle von Hardware- oder Softwarefehlern), und es ist am besten, Sicherungskopien für die letzten paar Tage zu speichern, zum Beispiel sieben (für die letzte Woche).

Dazu können Sie entweder den in SQL Server integrierten Taskplaner verwenden – „SQL Server Agent“ (in Freie Version(nicht im Lieferumfang enthalten) oder den standardmäßigen „Windows Scheduler“ in Kombination mit dem Dienstprogramm SQLCMD.EXE, mit dem Sie Abfragen an SQL Server ausführen können Befehlszeile. Im Scheduler müssen Sie mindestens sieben Jobs erstellen (einen für jeden Wochentag), von denen jeder (einmal pro Woche) eine der sieben Dateien mit der entsprechenden Datenbanksicherung ersetzt.

Darüber hinaus empfiehlt es sich, Sicherungsdateien nicht nur auf der Festplatte des Computers zu speichern, auf dem SQL Server installiert ist, sondern diese auch auf Band oder zu duplizieren Festplatte einem anderen Computer im Netzwerk. Dazu können Sie entweder eine spezielle Software verwenden, mit der Sie Sicherungskopien der gesamten Festplatte erstellen können, oder denselben Scheduler verwenden, um Dateien auf Band oder einen anderen Computer zu kopieren (zweiter Schritt).

Verwenden von Windows Scheduler (kostenlose Version)

Um eine Aufgabe im Windows-Planer zu erstellen, müssen Sie Folgendes tun:

Starten Sie das Notepad-Programm (Start->Alle Programme->Zubehör->Notepad), geben Sie die folgenden zwei Zeilen ein und speichern Sie sie dann als Batch-Datei (*.BAT):

SQLCMD -S (local) -E -Q „BACKUP DATABASE AltaSVHDb TO DISK = „D:\BACKUP\ AltaSVHDb_monday.bak“ WITH INIT, NOFORMAT, SKIP, NOUNLOAD“
XCOPY D:\BACKUP\ AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

Wo "(lokal)"- Servername (bei der Installation einer benannten Instanz von SQL Server müssen Sie den vollständigen Namen angeben: „COMPAN_NAME\SQLEXPRESS“), „AltaSVHDb“- Name der Datenbank, „D:\BACKUP\ AltaSVHDb_monday.bak“- der Name der Datei, von der eine Sicherungskopie erstellt werden soll (variiert je nach Wochentag), „BACKUP_SERVER“- der Name des Computers, auf den zusätzlich kopiert werden soll, "Ordner"- ein Ordner auf diesem Computer (er muss freigegeben sein).

Starten Sie den Aufgabenplanungsassistenten (Systemsteuerung -> Geplante Aufgaben -> Aufgabe hinzufügen) und klicken Sie auf die Schaltfläche „Weiter“:

Klicken Sie auf die Schaltfläche „Durchsuchen“ und geben Sie den Pfad zur in Schritt a) erstellten Befehlsdatei (*.BAT) an:

Geben Sie einen Namen für die Aufgabe an, wählen Sie die Ausführungsoption „wöchentlich“ und klicken Sie auf die Schaltfläche „Weiter“:

Aktivieren Sie das Kontrollkästchen neben dem gewünschten Wochentag und geben Sie im Feld „Startzeit“ die Uhrzeit an, zu der der Sicherungsvorgang beginnen soll (normalerweise erfolgt dies nachts), und klicken Sie dann auf die Schaltfläche „Weiter“:

Geben Sie den Benutzernamen und das Passwort (zweimal) des Betriebssystemkontos ein, unter dem die Aufgabe ausgeführt werden soll, und klicken Sie auf die Schaltfläche „Weiter“:

Aufmerksamkeit! Damit die Aufgabe erfolgreich abgeschlossen werden kann, müssen Sie das hier angegebene Konto (Domäne bzw lokalen Computer) Schreibberechtigungen für den oben genannten Ordner „\\BACKUP_SERVER\Ordner“, sowie den Zugriff auf SQL Server selbst konfigurieren.

Klicken Sie auf die Schaltfläche „Fertig stellen“.

Notiz. Um die Funktionalität des Systems zu überprüfen dieser Aufgabe, Sie müssen in der Liste der Aufgaben klicken (Systemsteuerung->Zugewiesene Aufgaben) Rechtsklick Maus auf die Aufgabe von Interesse und in Kontextmenü Wählen Sie „Ausführen“ und stellen Sie dann sicher, dass die Datenbanksicherungsdatei erfolgreich in den in Schritt a) angegebenen Pfaden erstellt wurde.

Verwendung von „SQL Server Agent“ (nicht in der kostenlosen Version enthalten)

Um einen Job im SQL Server Agent zu erstellen, müssen Sie Folgendes tun:

Starten Sie das Dienstprogramm SQL Server Management Studio und stellen Sie unter einem Administratorkonto eine Verbindung zum Server her.

Klicken Sie im linken Teil des Fensters mit der rechten Maustaste auf den Abschnitt „Serverobjekte/Backup-Geräte“ und wählen Sie im Kontextmenü „Backup-Gerät erstellen“:

Geben Sie im Feld „Gerätename“ den Namen ein, der mit der Datenbanksicherungsdatei verknüpft werden soll, ändern Sie ggf. den Pfad im Feld „Datei“ und klicken Sie auf „OK“:

Klicken Sie im linken Teil des Fensters mit der rechten Maustaste auf den Abschnitt „SQL Server-Agent/Aufgaben“ und wählen Sie im Kontextmenü „Aufgabe erstellen“:

Geben Sie im Feld „Name“ den Namen der Aufgabe ein:

Klicken Sie auf der Seite „Schritte“ auf die Schaltfläche „Erstellen“:

Geben Sie im angezeigten Fenster einen Namen in das Feld „Schrittname“ ein, stellen Sie sicher, dass „Transact-SQL (T-SQL) Script“ im Feld „Typ“ ausgewählt ist, und geben Sie die Zeile in das Feld „Befehl“ ein :

BACKUP-DATENBANK AltaSVHDb NACH AltaSVHDb_monday MIT INIT, NOFORMAT, SKIP, NOUNLOAD

Wo „AltaSVHDb“- Name der Datenbank, „AltaSVHDb_monday“- Name des in Schritt c) erstellten Backup-Geräts (variiert je nach Wochentag):

Klicken Sie im vorherigen Fenster auf die Schaltfläche „OK“. Daraufhin sollte auf der Seite „Schritte“ die folgende Zeile erscheinen:

Damit die Datenbanksicherungsdatei sofort auf einen anderen Computer im Netzwerk kopiert werden kann, müssen Sie die Schritte f) - h) im Fenster „Auftragsschritt erstellen“ wiederholen und im Feld „Typ“ die Option „Typ“ auswählen Operationssystem(CmdExec)“ und im Feld „Befehl“ die Zeile angeben:

XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

Wo „D:\MSSQL\BACKUP\AltaSVHDb_monday.bak“- der in Schritt c) angegebene Pfad (variiert je nach Wochentag), „BACKUP_SERVER“- den Namen des Computers, auf den die Kopie erstellt werden soll, "Ordner"- Ordner auf diesem Computer (muss freigegeben werden):

Notiz. Damit die Datei erfolgreich kopiert werden kann, müssen Sie den „SQL Server Agent“ unter einem Windows-Domänenkonto ausführen, dem Schreibrechte auf den oben genannten Ordner gewährt wurden (siehe auch „SQL2005_installation.doc“ oder „SQL2008_installation.doc“). ) und auch den Zugriff auf den SQL-Server selbst konfiguriert (siehe Abschnitt „Konfigurieren der Zugriffsrechte auf die Datenbank“, Sie müssen dieses Konto in die Rolle „sysadmin“ auf der Seite „Serverrollen“ aufnehmen und dürfen auf der Seite „Benutzer“ nichts tun „Zuordnung“ und „Geschützte Objekte“-Seiten).

Klicken Sie auf der Seite „Zeitpläne“ auf die Schaltfläche „Erstellen“:

Geben Sie einen Namen in das Feld „Name“ ein, stellen Sie sicher, dass „Wiederkehrende Aufgabe“ im Feld „Zeitplantyp“ und „Wöchentlich“ im Feld „Ausführen“ ausgewählt ist. Aktivieren Sie das Kontrollkästchen neben dem gewünschten Wochentag (deaktivieren Sie den Rest) und geben Sie im Feld „Einmalige Aufgabe“ die Uhrzeit an, zu der der Sicherungsvorgang beginnen soll (normalerweise erfolgt dies nachts):

Klicken Sie im vorherigen Fenster auf die Schaltfläche „OK“. Daraufhin sollte auf der Seite „Zeitpläne“ die folgende Zeile erscheinen:

Klicken Sie auf die Schaltfläche „OK“.

Notiz. Um die Funktionalität der erstellten Aufgabe zu überprüfen, müssen Sie mit der rechten Maustaste auf die gewünschte Aufgabe im Abschnitt „SQL Server-Agent/Aufgaben“ klicken und im Kontextmenü „Aufgabe in einem Schritt ausführen“ auswählen und den ersten Schritt davon auswählen Aufgabe im erscheinenden Fenster aus und klicken Sie auf „OK“. Als nächstes erscheint ein Fenster, das den Fortschritt der Aufgabe anzeigt. Wenn die Aufgabe mit einem Fehler endet, dann detaillierte Beschreibung Fehler können durch Aufrufen des Eintrags „Protokoll anzeigen“ im selben Kontextmenü angezeigt werden.