SQL Server + Backups

[Thomas L.]

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]

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]

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.]

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]

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.]

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]

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.]

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]

Gegen Diff hat hier doch keiner was.

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

[Thomas L.]

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