SQL-Server per Skript sichern mit Ausnahmen

01/09/2008 - 19:05 von Yvonne.Lebhardt | Report spam
Hallo Profis,

bisher sichere ich unsere SQL-Server 2005 Datenbanken
(Wiederherstellungsmethode: einfach) mittles Wartungsplan.

Da der Zeitpunkt der SQL-Backups von einigen externen Faktoren abhàngt
möchte ich in Zukunft per Skript (Vollbackup) sichern. Dazu habe ich
ein paar Fragen:

1. Ist folgendes geeignet: BACKUP DATABASE AdventureWorks TO DISK N'c:\AdventureWorksDiff.bak' WITH COPY_ONLY.

2. Ich eine mich zu erinern, dass es mal was gab mit: Wenn man das
Ereignisprotokoll nicht sichert wird dieses beliebig groß. Kann das
bei Wiederherstellungsmodell einfach auch passieren?

3. Ich möchte gerne alle Datenbanken außer xyz sichern. Sprich: Ich
möchte nicht für jede neue DB die Sicherung einrichten, aber auch
nicht alles sichern, da einige Testdatenbanken die sehr groß sind
ausgeklammert werden sollen.

4. Gibt es irgendwas was mich davon abhalten sollte per Skript zu
sichern, statt per Wartungsplan?

Danke für Eure Hilfe!!

Yvonne
 

Lesen sie die antworten

#1 Elmar Boye
01/09/2008 - 23:51 | Warnen spam
Hallo Yvonne,

schrieb:
bisher sichere ich unsere SQL-Server 2005 Datenbanken
(Wiederherstellungsmethode: einfach) mittles Wartungsplan.

Da der Zeitpunkt der SQL-Backups von einigen externen Faktoren abhàngt
möchte ich in Zukunft per Skript (Vollbackup) sichern.



Welche externen Faktoren?

Erfahrungsgemàß sollte eine Sicherung immer planmàßig und routinemàßig
ohne Benutzereingriff erfolgen - so kann sie z. B. nicht vergessen werden
oder dem Zeitdruck zum Opfer fallen.

In Sonderfàllen - wie größeren Wartungsarbeiten an einer
Datenbank - schiebt man besser eine zusàtzliche Sicherung ein.

Argumente wie zu großer Platzbedarf etc. können dort niemals
gelten, denn die Kosten für eine manuelle Wiederherstellung
(wenn überhaupt möglich) sind immer eine (großes) Vielfaches davon.

1. Ist folgendes geeignet: BACKUP DATABASE AdventureWorks TO DISK > N'c:\AdventureWorksDiff.bak' WITH COPY_ONLY.



COPY_ONLY ist nur für Sonderfàlle gedacht, eine Standardsicherung
sollte ohne die Option erfolgen. Siehe dazu BACKUP DATABASE:
<URL:http://msdn.microsoft.com/de-de/library/ms189128(SQL.90).aspx>

(Beispiel A. wàre dort eine Standardsicherung)

Zudem sollten Sicherungen niemals im Stammverzeichnis erfolgen,
sondern entweder im Standard-Backupverzeichnis (das auch verwendet
wird wenn kein vollstàndiger Pfad vorgegeben ist) oder ein eigenes
Verzeichnis erfolgen. Dies schon aus Sicherheitsgründen:
<URL:http://msdn.microsoft.com/de-de/library/ms189128(SQL.90).aspx>

Zudem ist es empfehlenswert nicht immer in die gleiche Datei
zu sichern, sondern sie zum Beispiel mit Datum und Uhrzeit
zu benennen (das tut der Wartungsplan). So wird nicht aus Versehen
die letzte gültige Sicherung überschrieben (und gerade wàhrend der
Sicherung passiert ein Malheur ;-()

2. Ich eine mich zu erinern, dass es mal was gab mit: Wenn man das
Ereignisprotokoll nicht sichert wird dieses beliebig groß. Kann das
bei Wiederherstellungsmodell einfach auch passieren?



Beim Wiederherstellungsmodell "einfach" wird das Protokoll immer
beim Prüfpunkt abgeschnitten. Es wàchst also nicht beliebig,
sondern wird nur so groß wie die größte Transaktionsgruppe.

Nur beim Wiederherstellungsmodell "vollstàndig" oder "massenprotokolliert"
muß generell auch eine Protokollsicherung erfolgen, damit das
Protokoll abgeschnitten werden kann.

3. Ich möchte gerne alle Datenbanken außer xyz sichern. Sprich: Ich
möchte nicht für jede neue DB die Sicherung einrichten, aber auch
nicht alles sichern, da einige Testdatenbanken die sehr groß sind
ausgeklammert werden sollen.



Für jede Datenbank ist ein eigener Backup-Befehl notwendig.
Wenn Du einen Wartungsplan erstellt wird genau das erzeugt.


4. Gibt es irgendwas was mich davon abhalten sollte per Skript zu
sichern, statt per Wartungsplan?



Siehe zum einen die Einleitung.

Zudem ist im Wartungsplan alles eingebaut, was ich bei 1.) angeführt habe
und einiges mehr, wie z. B. das Untergliedern in Verzeichnisse, das
Überprüfeh sowie das Bereinigen in einem weiteren Schritt uam.

Das kann man zwar mit einem Skript selbst abdecken. Das erfordert
aber einiges an SQL- und Betriebssystem-Kenntnissen und intensiven Test.
Denn Fehler dort können im Ernstfall, wenn das Backup benötigt wird -
zum Totalverlust führen. Es will also gut überlegt sein.

Gruß Elmar

Ähnliche fragen