SQL Server + Backups

[Thomas L. 10]

Hallo zusammen

 

So, ich muss mir mittlerweile eine neue Backup Strategie für eine unserer Datenbanken überlegen. Diese hat mittlerweile eine Größe von etwas über 50GB und ein tägliches Full Backup ist einfach nicht mehr drin (das macht die Internetverbindung zum iSCSI Target nicht mehr sinnvoll mit).

 

Daher stellt sich für mich jetzt die Frage:

* Ich würde gerne wöchentlich ein Full Backup fahren (evtl. sogar monatlich), dazwischen Differential Backups

 

Soweit so gut, im ersten Monat ist alles ok. Am 1. wird ein Full Backup erstellt, am 2. ein Differential, am 3. ein Differential bis zum 31. Nun ist wieder der 1., es soll also wieder ein Full Backup erstellt werden

 

Nun habe ich zwei Möglichkeiten. Entweder ich wähle ein "Append to Existing Backup Set", dann erhalte ich zum Schluss 100GB an Daten beim entfernten Server. Wähle ich ein "Replace existing Backup Set", so wird mir am 1. die alte Datenbank überschrieben. Genau in diesem Moment kommt es jedoch zum Server Crash und ich verliere nun sowohl das Backup wie auch die Produktivdatenbank.

 

Nun zu meiner Frage: Verstehe ich da was falsch oder wie löst man dieses Problem in der Realität?

 

Vielen Dank für Tips :)

[NilsK 2.934]

Moin,

 

Internetverbindung zum iSCSI-Target?! Auf Ideen kommen die Leute ...

 

50 GB ist ja nun nicht besonders groß. Wenn ich es vermeiden könnte, würde ich da nicht mit einem heterogenen Konzept arbeiten. Mein Rat wäre, das Gesamtkonzept zu überdenken.

 

Zu deinem Problem: Warum arbeitest du nicht einfach mit zwei Mediensätzen?

 

Gruß, Nils

[zahni 554]

ISCSI im Internet ? Darauf wäre ich im Leben nie gekommen. Wie Nils...

Hat der Anbieter sich die Daten schon gesichert ? ;)

 

Wie wäre es mit einem Bandlaufwerk oder zumindest mit einem lokalen NAS ?

[Thomas L. 10]

Ich bin gerne für alternative Vorschläge offen. Was wir haben:

 

Einen Serverraum der Zutrittsgeschützt ist (A), eine schnelle Internetverbindung, ein Viertel-Rack an geographisch anderer Stelle (B) und zwischen diesen Standpunkten eine OpenVPN Verbindung.

Die Daten sollen nun - zumindest wöchentlich - von A nach B transportiert werden. Plattenplatz ist nicht so das Problem, eher die Übertragungsrate. Zusätzlich zu den SQL Daten (~50 GB) kommen noch ein Backup des Exchange (~30 GB), SVN Repositories (diese werden sowieso täglich gesynct - sind also kein Problem) und die Daten von ein paar Fileshares hinzu.

 

Bandlaufwerk kommt nicht in Frage da es niemanden gibt der dieses täglich wechseln würde.

[Dukel 454]

Ich würde ein Lokales Backup einsetzen und dieses mit der Backup Software an den anderen Standort kopieren (je nach Backupsoftware).

D.h. man kann abends eine Sicherung machen und hat den ganzen Tag Zeit diese zu übertragen.

[Thomas L. 10]

So wird es derzeit gemacht. Der Nachteil der Sache: Es dauert bei voller Auslastung der Inetverbindung etwas über einen Tag bis alle Daten transferiert wurden. Wenn ich jetzt 2 Kopien der Datensätze habe, ist die Leitung Samstag/Sonntag ausgelastet.

Wie stelle ich zudem sicher dass ich immer nur wirklich 2 Datensätze übertrage (die letzten 2 quasi)?

[Dukel 454]

Womit machst du Backup's?

Womit kopierst du die Backup's?

 

Evtl. (keine Ahung ob das so einfach mit ner DB geht) bietet sich "Forever Incremental" oder "Syntetic Full" (oder wie das bei deiner Backupsoftware heißt) an. Damit werden nur Incrementelle Sicherungen erstellt und am Ziel zu einem neuen Full zusammengebaut.

[Thomas L. 10]

Backups mache ich mittels TSQL ;) - BACKUP DATABASE ... TO DISK, da gäbs dann eben noch das WITH DIFFERENTIAL .. aber davon wird ja in diesem Thread eher abgeraten.

[Dukel 454]

Gegen Diff hat hier doch keiner was.

 

Gibst du bei "To Disk" ein Lokales oder ein entferntes (iSCSI) Laufwerk an?

[Thomas L. 10]

Derzeit ein "lokales" iSCSI - Anbindung über Gigabit Ethernet bis zu diesem Laufwerk.

[Dukel 454]

Und womit kopierst du dann die Backups?

[Thomas L. 10]

Mittels:

robocopy /e /fft (VerzeichnisLokal) (VerzeichnisRemote)

[Dukel 454]

Und wo Crash jetzt die DB?

[Thomas L. 10]

Das Problem kommt wenn quasi das nächste Full Backup ansteht - denn dabei wird ja das alte überschrieben (oder ich habe wenn ich ein Append mache ein File mit 100 GB).

 

Die Idee hier aus dem Thread mit mehreren Backup Media Sets zu arbeiten finde ich gut, ich weiss jedoch ehrlich gesagt nicht wie das dann funktioniert bzw. wie es sich dann mit den Logdateien usw. verhält.

 

Je mehr ich darüber nachdenke desto sympathischer wird mir ein zweiter SQL Server der kontinuierlich eine Replication durchführt.

[Meiky77 10]

Hallo Thomas L.

 

hast Du im TSQL-Script schon den Parameter Format eingegeben? Dieser löscht den vorangegangen Datensatz vor dem erneuten Backup. Vorteil... Bricht das Backup ab bzw. gibt es mit dem Mediensatz bzw. Backupfile ein Problem, wir diese für den Schreibvorgang wieder aufbereitet.

 

Ansonsten kann ich dir ein Backupkonzept mit Full - Differential - Translog empfehlen. Dadurch verringert sich die Übertragung. Ein Splitt auf zwei Medien würde ich persönlich nicht empfehlen, da Du dann beide Medien fürs Recovery benötigst. ... Ist eins korrupt... dann ade Backup!

 

 

VG

Meiky77

bearbeitet 7. November 2011 von Meiky77
Wort vergessen