SQL Datenbank, häufige Backups, dafür auf Parity verzichten?

[GlockMane88]

Hallo Leute,

mir brennt noch eine zweite Frage auf der Zunge.. Habe einen MS SQL Server 2019 eingerichtet mit drei Datenbanken.. Da ich die Gesamtanzahl der Festplatten in meinem Homeserver beschränken möchte, überlege ich, ob ich nicht auf ein RAID komplett verzichten könnte..

Also alles was zur DB gehört inkl. Logs auf eine SSD (OS und SQL Server sind auf einer separaten SSD) und mit VEEAM Backup and Replication einmal am Tag gesichert, Transaction Logs öfter (z.B. alle 15 Minuten)..

Oder ist ein RAID für die DBs "Pflicht"?

 

[kamblars]

Pflicht nicht, nur wenn eine Platte ausfällt hast du bei der richtigen Konfiguration einiges an Zeit gespart und kannst höhere Verfügbarkeit gewährleisten.
Wenn du eine ssd auf Reserve hast: teste das Rückspielen einer Sicherung. Kannst du während der Zeit auf die DBs verzichten?

 

[PHuV]

Nein, ist es nicht! Es kommt eben darauf an, wie hochverfügbar Deine Datenbank sein muß bzw. wie lange und wie viel Dich ein Datenbankausfall kostet.

Eine laufende Datenbank mit permanent stattfindenden Transaktionen sollte man auf keinen Fall mit einem Backupprogramm sichern, da sonst inkonsistente Zustände der Datendateien ergeben! Wenn Du solch ein Fullbackup über Veeam oder sonstwas machen möchtest, mußt Du in diesem Moment die Datenbank deaktivieren bzw. offline schalten, das nennt man im DB-Bereich genau so auch offline-Backup.

• Vorteil: die Datenbank wird komplett gesichert und kann so auf diesem Stand 1:1 zurück gesichert werden
• Nachteile: die Datenbank ist in diesem Moment offline, keine Transaktionen können gemacht werden
• Die Sicherung enthält nur den Stand ab Zeitpunkt der Sicherung, alle weiteren Daten danach sind dann verloren

Jedoch macht man es an sich so, wie Du es andeutest:

• Setzten der Datenbank bzw. Datendateien im Transaktionsmodus
• Sicherung der Datenbank über eigene Mittel
• permenante Sicherung der Transaktionsdateien

kamblars es auch richtig erwähnte, man sollte IMMER eine Backupstrategie mit allen Varianten auch man mit Recovery und Co. gegentesten.

 

[Cinderella22]

Hallo,

ich klinke mich mal hier ein, da meine Frage sich ebenfalls um SQL Backup dreht.

Aktuell würde wie folgt sichern:

Vollbackup: Jeden Tag
Diff. Backup: jede Stunde
Transactions: alle 15 Minuten

Abends 20:00 Backup mit Veeam

Gerade was die Diff. Sicherung angeht bin ich noch unsicher. Ist diese überhaupt noch nötig? Im Prinzip ja nur, wenn man Stündlich zurück sichern möchte, oder wie schauts aus?

Ist der Plan generell Sinnvoll oder sollte dieser überarbeitet werden?

 

[ayngush]

Unabhängig vom eigentlichen Dienst machen wir mit Veeam nur noch Forever Forward Incremental Backups mit Syntetischen Full Backups in der offline / offsite Auslagerungssicherung auf Band.

Im Falle unserer Zeiterfassung (noch mit einer SAP-Datenbank als Backend, muss demnächst migriert werden) läuft die Sicherung mit Veeam zwei stündlich mit einer Aufbewahrung von 60 Inkrementen, sodass man 120 Stunden oder halt 5 Tage zurück kann, falls es einen systemischen Fehler gab. Ansonsten interessiert bei so etwas wie einer Zeiterfassung ja nur, der zuletzt funktionierende aktuellste Stand. Da wird auch nicht die Datenbank an sich gesichert, sondern die ganze virtuelle Maschine mit einem Hyper-V-Produktionsprüfpunkt. Inkonsistente Datendateien von Datenbanken dürften mit dieser Technologie nicht auftreten können, da alle neuen Transaktionen während des Backups nicht in das Backup oder die alten Datendateien hineinlaufen, und alle Datenträgerschreiboperationen zuvor abgeschlossen werden.
Nichts desto trotz Sollte man dabei immer über den DB-Server und dessen Wartungspläne sichern... Dafür kann man auf der VM von außen zuvor Befehle / Skripte ausführen lassen, die den Wartungsplan starten, die Datendateien für das Backup exportieren und dann im Anschluss daran die VM Sichern.
Das Recovery funktioniert bei uns und musste auch schon mal in der Realität für die Zeiterfassung genutzt werden...

Bei anderen Diensten sieht die Konfiguration dann individuell etwas anders aus. Die 10 Linux Webservices zum Beispiel werden nur einmal täglich gesichert und 30 Inkremente aufbewahrt, sodass man maximal einen Monat zurück kann, das reicht dort vollkommen aus um fehlerhafte Updates zurück zu rollen (zum Beispiel). Auf diesen Maschinen laufen keine Datenbanken.

Der Fileserver hat entsprechend ausgelagerte Sicherungen, sodass man mit viel Aufwand ein Jahr zurück kann und mit weniger Aufwand 90 Tage.

Das GFS-Prinzip hatte man damals Hauptsächtlich angewendet, weil die Magnetbandkapazitäten knapp waren und die Dauer der Backups zu lang war. Mit den ganzen B2D-Systemen ist ein forever forward inkrement Prinzip mit vollständigen syntetischen Snapshots, die zwischenzeitlich davon gezogen werden, die bessere Wahl.