Wie groß sind eure größten Datenbanken? Sicherung / Rücksicherung

[openshinok]

hallo,
ich bin kurz davor einen Sharepoint Portal Server zu installieren und habe Bedenken bez. DB-Größe. Da hier sämtliche Dokumente in x Versionen abgelegt werden können wird die DB schnell wachsen. Da ich letzte Woche mit einer DB von 110 GB hantiert habe und die Rücksicherung lange gedauert hat meine Frage wie man eine wichtige DB rücksichert wenn eigentlich konstant mit der Datenbank gearbeitet wird. Ich habe schon mitbekommen dass man verschiedene Optionen bei der Rücksicherung hat dass die Datenbank schon während der Rücksicherung zugreifbar ist aber wie läuft das im Hintergrund ab und was muss ich beachten? Wird die DB auf mehrere Files aufgeteilt?

[O. Helper]

Hallo openshinok,

dass die Datenbank schon während der Rücksicherung zugreifbar ist

Das hast Du mißverstanden.
Bei Start der Rücksicherung darf niemand an der DB angemeldet sein, während der Rücksicherung kann sich niemand an die DB anmelden, sie läuft dann im "Einzelbenutzermodus" für den Restore-Prozess.

Du spielst vermutlich auf die Option "WITH Recovery / WITH NoRecovery" an, die hat aber eine andere Bewandnis.
Beim Mirroring / Logshipping nutzt man die Option NoRecovery, man sichert erst eine Vollsicherung zurück und dann laufend weitere LOG-Sicherungen, um einen HotStandBy-Server zu haben. Während dessen verbelibt die Datenbank im Rücksicherungsmodus und man kann regulär ebenfalls nicht darauf zugreifen.
Tritt der Desaster-Fall ein, sichert man noch das letzte LOG mit der Option Recovery zurück, was dann den Vorgang abschließt und die DB kann erst dann wieder genutzt werden.

Das Sichern der DBs geht mit dem MS SQL Server sehr schon, man kann es Online machen, ohne den laufenden Betrieb zu stören (abgesehen von der I/O Last).
Das Rücksichern ist hingegen "nervig". Per se dauert es aus meiner Erfahrung heraus ~ 1/3 länger als das Sichern, allein schon weil die Sicherung selbst noch geprüft wird.
Dazu dann die nervigen User "wann können wir den endlich weiter arbeiten?" (und läuft der Server, trifft man sie in Kantine beim Kaffee trinken an ... )

Es empfiehlt sich immer eine Backup/Restore Strategie auszuarbeiten (und die für Desaster Recovery auch mal durch zugehen).
Das hängt stark von den vorhandenen Resourcen und den Ausfallzeiten ab, die man sich erlauben darf.
Ich kenne Eure Hardware nicht, aber ein Restore einer 110 GB DB dürfte meiner Einschätzung nach ~ 3 Stunden dauern; mindestens.

[openshinok]

hallo,
öhm ja..... das ist dann schon mal etwas uncool das Missverständnis. Daraus folgere ich dass wenn die Kiste mal komplett abschmiert ich sehr lange beschäftigt bin die Datenbanken wieder einzuspielen und die Benutzer ggf. einen Tag (vermutlich bin ich sogar 24 Stunden mit dem Restore beschäftigt) nicht arbeiten können. Bei ca. 60 Datenbanken (zum Teil kleine und nicht lebenswichtig aber immerhin)......

Dann werde ich wohl hergehen und mir vor der Sicherung in das Sicherungsverzeichnis ein Skript laufen lassen welches mir die SQLs für die Rücksicherung generiert. Sonst stehe ich während der Rücksicherung konstant am Bildschirm um zu überwachen wann die einzelnen Datenbanken mit Rücksicherung fertig sind um mit der nächsten Rücksicherung zu beginnen.... Parallel Rücksicherung bremst wahrscheinlich eh mehr als es bringt. Per Skript laufen dann die Rücksicherungen automatisch nacheinander....

Wie ist deine Rücksicherung geplant? Machst du das auch per Skript?

Das mit der 110 GB hat per USB 1.1 6,5 Stunden gedauert, wobei das ein Einzelfall war wegen Datenwiederherstellung bestimmter daten in der DB. Die Datenbank war nicht mal in der Sicherung drinnen....

[O. Helper]

Wir stellen zwar auch weitesgehend einen 24/7 Betrieb sicher, aber wenn der Desaster Fall eintritt, dann dauert es halt solange, wie es dauert. Ausserdem: Die Nacht ist bekanntlich lang und da kann man auch schon mal durch machen...

Von der Konstellation her, ist es bei uns ähnlich: 16 Serverinstanzen, ca. 60 DBs, insgesamt ungefähr 250 GB.
Ich habe zum Glück halbwegs gute Hardware, die Datenbanken liegen auf einem SAN, entsprechend gibt es Platten-Redunanzen (RAID), so das in der Hinsicht es recht sicher ist.
Gesichert wird zum einen in eine Tape-Library, zum anderen ebenfalls auf SAN. Da es über FibreChannel angebunden ist, ist der Datensatz sehr gut und somit Rücksicherung auch schnell.
Das würde ich dann von Hand machen: Entweder mit der Backup-Software über die Tape-Library oder übers Managementstudio; die paar Sekunden zum rumklicken werden schon noch vorhanden sein.

Dann haben wir ColdStandby-Server, fällt der prod. Server aus: Systemplatten aushängen, in den anderen rein, hochfahren und gut ist es gewesen (so Gott alias MS es will).
Einen Desaster-Fall habe ich schon lange nicht mehr durch gemacht, sollte ich unbedingt mal wieder zu Testen durch exzerzieren.

Zum Thema hatten wir auch schon mal eine gute Diskussion:
Strategie einer Backup / Restore Lösung eines MS SQL Server 2005

[openshinok]

der Thread ist mir bestens bekannt, den lese ich immer wenn mir langweilig ist ;o)

Warum sicherst du mit Backupagents der Backupsoftware? Das verkaufen unsere Vertriebler zwar immer aber mir ist kein wirklicher Vorteil bekannt ausser dass ich das komplette Kundenbackup im Management der Backupsoftware steuere. (Die haben sogar den Nachteil dass sie das Transaktionslog brauchen, es aber nicht kürzen und es so stetig anwächst wenn man es nicht kürzt.)

was für ein Storage hast du drunter? Welche Anbindung hast du zum Storage. Wir haben leider iSCSI sei dank "nur" GBit. Gelobt sei das zentrale Speichersystem. Ich habe tatsächlich bis vor einem halben Jahr geglaubt dass mein Storage schneller ist als die lokale Platte Ja gut liegt aber an der 1 GBit Netzwerkanbindung....

ColdStandby? Braucht der Raidcontroller nicht auch die Raidinformationen im Speicher? Ist bei FSC zumindest so, bei Maxdata ICP war es meine ich so dass die Raidinfos auf den Platten gespeichert waren....

[O. Helper]

Warum sicherst du mit Backupagents der Backupsoftware?

Der Hersteller (HAL aus "Odyssee im Weltraum") bietet leider keinen Treiber für eine virtuelles Bandlaufwerk, deshalb muss es über die Software gehen, um auf die TapeLibrary zu kommen.
Das LOG "kürzt sich" in dem Sinne nur, wenn man es auch sichert; geht mit der Software auch.

SAN haben wir von EMC; welche genau weiß ich nicht, für mich ist das nur eine Blackbox, um Hardware kümmert sich unser Helpdesk.

Raidcontroller nicht auch die Raidinformationen im Speicher

Ja, wenn ich mich recht entsinne, muss man einmal von CD booten, RAID kurze konfigurieren lassen und dann gehts weiter.
Aber auch darum darf sich zum Glück Helpdesk kümmern; für mich geht es erst los, wenn die Kiste läuft.

[openshinok]

Ich sichere erst auf Festplatte bzw. Storage-Lun manchmal auch auf günstigeres Netzlaufwerk und dort holt es die Backupsoftware fürs Band ab.

Dann habe ich schnelle Rücksicherung von Platte und ggf. früheren Stand per Tapelibrary.