Backupstrategie MSSQL

[bindehautentzündung 0]

Hallo das ist mein erster Beitrag hier, sollte er hier falsch sein, dann bitte verschieben.

 

Ich hätte eine Frage bezüglich der Backupstrategie speziell bei MSSQL Datenbanken. 

 

Über das MSSQLMS kann man über die Verwaltung ja Wartungspläne einrichten. Darüber ist es ja möglich sowohl Voll- als auch Differenzielle Sicherungen zu erstellen. Das sollte denke ich nicht das Problem darstellen.

 

Meine Frage bezieht sich nun darauf, wann welcher Job erledigt werden sollte bzw. wie ihr das macht?

 

Täglich Vollsicherung + Stündlich diff. Sicherung?

Wann macht ihr Sicherungen der Transaktionslogs - müssen diese überhaupt bei einer Vollsicherung erstellt werden?

 

Und wann lässt ihr Indizies / Index neu aufbauen?

 

Ist eine private Testumgebung - daher habe ich schon einiges ausprobiert (Täglich Voll-/ Stündlich diff.). Aber würde gerne mal andere Meinungen und Ideen hören. Vor allem was der Standard ist..

 

 

[speer 19]

Die IT ist bei uns bei Einführung einer neuen Software immer mit im Boot. Zuerst meistens der Abteilungsleiter und später kommt ein ITler mit Fachkenntnissen hinzu.

Dann wird abgeklärt in welchem SLA, beispielsweise in Deinem Beispiel, die Datenbank Verfügbar sein muss. Je nachdem kommt diese auf einen Cluster oder Single DB Server. Der Cluster ist bei uns deutlich teurer als ein normaler DB Server. Gegen Wir halten uns immer an die Schritte: 1. definiert Eure Anfroderungen, 2. kann die IT diese umsetzen und 3. Was kostet der Spaß!

 

 

[mwiederkehr 373]

Da gibt es keinen "Standard", das kommt ganz auf die Anforderungen an. Ich mache meist abends eine Vollsicherung und tagsüber viertelstündlich eine Sicherung der Logs. Sonntags baue ich zusätzlich Indizes mit mehr als 30% Fragmentierung neu auf.

 

Aber: bei meinen Kunden ist eine DB mit zehn GB schon gross. Wenn Du mit grösseren Datenbanken arbeitest, musst Du die Strategie anpassen.

[Dukel 454]

Wie schon geschrieben kommt es auf die Anforderungen an.

Ob Full oder Diff ist wie beim "normalen" Backup auch. Entweder braucht man etwas mehr Zeit beim Backup oder beim Restore,

Anderst ist es mit den Transaktionslogs. Diese musst du nur sichern, wenn du ein Point-in-Time Restore fahren willst und sehr wenig Datenverlust toleriert wird. Hier ist auch das Recovery Modell der Datenbanken relevant. Wenn Point-In-Time Restore, dann Full Recovery Modell. Wenn das nicht benötigt wird, kannst du das auf Simple oder Bulk stellen und musst dir auch keine Sorgen wegen Volllaufendem Platz machen.

[NilsK 2.940]

Moin,

 

https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/

 

Da steht erst mal alles Wichtige drin ...

 

Gruß, Nils

 

bearbeitet 12. August 2019 von NilsK

[bindehautentzündung 0]

Hallo,

 

vielen Dank für die schnellen Antworten.

 

@NilsK hab mir den Text im Link angesehen und das war schon sehr informativ vielen Dank dafür!

 

Meine TestDB steht momentan im Wiederherstellungsmodell "Einfach". Wenn ich den Text nun also richtig verstanden habe bzw. weiter unten wird es ja deutlich erwähnt;
Bringen mir in diesem Modell die Sicherung der Transaktionslogs nichts - ein Fullbackup ist hier der richtige Weg. 

 

@mwiederkehr hat erwähnt, dass er es so handhabt, dass er Indizes mit mehr als 30% Fragmentierung neu aufbauen lässt. 

Ist das generell eine Sache, die man regelmäßig machen sollte / dementsprechende Konfiguration erstellen? Ich vermute mal die Häufigkeit dieser Aktion ist stark davon abhängig, was genau überhaupt mit der Datenbank gemacht wird? (ERP, ab und an mal Lesen-/ Schreiben etc. pp.)

 

Was kann Super-Gau mäßig passieren, wenn man keine Fragmentierung durchführt?

[NilsK 2.940]

Moin,

 

verabschiede dich bei Datenbanken von der Denke "das muss man tun". Dafür sind Datenbanken in ihrer Nutzung zu unterschiedlich. Was für Datenbank A unabdingbar ist, kann für Datenbank B sinnlos oder sogar hinderlich sein.

 

Die Index-Fragmentierung kann ein Thema sein, wenn eine Datenbank in großem Umfang verändert wird. Selbst dann sind Pauschalregeln aber (leider) selten zielführend. Wenn dein ERP-Dienstleister gut ist, kann er dir Empfehlungen geben, denn ohne Kenntnis der Applikation sind Optimierungen ein weitgehend aussichtsloses Unterfangen.

 

Gruß, Nils

 

[bindehautentzündung 0]

Hallo,

 

ok verstehe, vielen Dank.

 

Ist in meinem Fall wie gesagt ausschließlich eine Testdatenbank/Testsystem wo ich hin und wieder mal Dinge ausprobiere - trotzdem aber vernünftig gesichert haben will

 

Grüße

[NilsK 2.940]

Moin,

 

naja, in dem Fall reicht es ja aus, alles nur bedarfsweise zu tun. Sichere die DB als "Full Backup", wenn es relevante Änderungen gab. Indizes optimieren und ähnliche Wartungsdinge dürften überflüssig sein, es sei denn, du willst das Prinzip daran nachvollziehen.

 

Gruß, Nils