iSCSI Target für Windows Backup zeitgesteuert mounten?

[r4pt0x 10]

Unsere Windows 2008 Server schreiben an 2 Standorten abends um 21:00 ihre Full-backups auf ein iSCSI-Target (jeweils ein NAS lokal am Standort).

Diese Backups sollen dann später zusammen mit den Datenbankbackups rotiert und zum jeweils anderen Standort übertragen werden, sodass an jedem Standort alle Backups verfügbar sind.

Die Rotation, Auslagerung und zusätzliche Rotation der Datenbank-Backups auf ein DVD-RAM Laufwerk übernimmt jeweils ein debian-Server.

 

Bei Backups die von den debian-servern geschrieben werden, werden die iSCSI-targets (oder NFS-shares) ausschließlich zur Backupzeit eingehängt und sind ansonsten unangetastet (so wie es sein soll...). Für Windows habe ich hier noch keine zufriedenstellende Lösung gefunden...

 

Bei den Datenbank-backups des MSSQL Servers ist das kein Problem, da diese auf einen SMB-Share auf dem debian-Server geschrieben werden, der auch die Rotation und Auslagerung übernimmt. Der Share und die Backup-Dateien wird zu beginn des Rotationsskripts (startet mit ausreichend Verzögerung zu den Backups der DB-Server) auf Zugriffe geprüft, wenn negativ wird der Share nach aussen read-only und die Rotation kann sicher mit konsistenten Daten durchlaufen. Danach wird das Laufwerk ausgehängt, der Share bleibt readonly, damit keiner "ins leere schreibt" und erst kurz vor den geplanten Backups des nächsten Tages wird das Dateisystem neu eingehängt und der share auf RW gesetzt.

Den share nur zu Backup-Zeit überhaupt zu aktivieren funktioniert leider nicht, da die W2k8-Server dann nach gewisser Zeit das Laufwerk trennen und einfach überhaupt keine Backups mehr schreiben anstatt zu versuchen das Ziel neu zu verbinden.

 

Ich kann nun zwar das iSCSI Target vom debian-Server auch mounten ohne dass die W2k8-VM vorher die Verbindung trennt, aber das ist alles andere als sauber und führt zu ständigen Fehlereinträgen in den Logs beider Server: Debian moniert natürlich unsauberes Trennen von Windows (da nicht getrennt...), W2k8 wirft gleich ~10-15 Fehler in die Logs, dass das die Deteisystemstruktur angeblich defekt wäre (schreibt darauf dann aber trotzdem das neue Backup :schreck:)

 

Ich suche deshalb nach einer sauberen Lösung, damit auch die Windows-Server ihre Backup-Ziele NUR zum Backup einbinden und nicht dauerhaft offen stehen lassen (und dann doch drauf herumschreiben währrend eine Rotation läuft...)

Gibt es da eine brauchbare Lösung am besten ohne Drittanbietersoftware? Die Server sind sowieso schon aufgedunsen genug da für jede Kleinigkeit Fremdsoftware benötigt wird :rolleyes:

 

Schonmal danke für alle Anregungen!

[Dukel 437]

Was ist das für eine Backupsoftware?

[r4pt0x 10]

Auf den Windows-Servern wir die Windows Server Sicherung verwendet (ausschließlich Fullbackups), da diese einfach wiederherstellbar und bare-metal fähig sind.

Nur leider kann WSS eben nur eins: Sichern. Ansonsten ist das ganze ja leider dumm wie Brot (keine vernünftige Rotation, Auslagerung oder sonstiges...)

 

Die Datenbankbackups werden direkt aus MSSQL-Server 2008 heraus geschrieben.

[Dukel 437]

Wieso schreibst du das Windows Backup dann nicht auch auf das SMB Share?

[r4pt0x 10]

Aus mehreren Gründen:

 

1. die Geschwindigkeit auf ein iSCSI target ist um einiges besser und da kein seperates Dateisystem dazwischen liegt werden potentielle Fehlerquellen deutlich reduziert.

 

2. Die Fullbackups sollen direkt aufs Ziel geschrieben werden, nicht erst auf den share und dann nochmal übers Netz auf das NAS.

 

3. Ist das mit dem share ja auch keine wirklich saubere Lösung sondern war eigentlich als provisorisches Workaround gedacht.

 

4. wird die Zeit irgendwann knapp - der Backupaustausch zwischen den Standorten dauert so schon bis kurz vor Arbeitsbeginn (und da wird dann die Bandbreite des VPN für den normalen Betrieb benötigt!), ich kann also nicht noch länger warten bis ich damit anfangen kann, sondern sollte eher sogar noch früher anfangen, da bleibt keine Zeit auch noch Backups mit 200GB mehrfach durchs Netz zu schieben...

 

 

Ich könnte zwar auch den umständlichen weg gehen und das target vom NAS am debian-server zur Backupzeit einhängen und diesen Mountpunkt wieder als iSCSI-target für Windows bereitstellen, aber die Performance dürfte grausig sein, das Verhalten von Windows wenn das target tagsüber "ins leere Zeigt" ist auch ungewiss und gerade bei Backups sollte ja die Kette so kurz wie möglich sein...

 

 

Es muss doch eine Möglichkeit geben, per script auch unter Windows ein iSCSI-target zu verbinden und zu trennen!?

[Dukel 437]

Das klingt für mich nach viel gebastel.

Such dir eine gescheite Backupsoftware die deine Anforderungen unterstützt.

[r4pt0x 10]

Problem gelöst - bin zufällig auf iscsicli gestoßen, das lässt sich zeitgesteuert per batchscript ausführen...

 

Zum Thema gebastel: Ein System auf dem tonnenweise Drittanbietersoftware verteilt rumliegt ist für mich eher eine Bastelbude (und eine Katastrophe bei der Wiederherstellung) als ein schlankes System das über gescriptete events eigenständig arbeitet.

 

Und eine Software die alle Anforderungen ins Detail unterstützt gibt es nicht - deshalb laufen die Backups über die debian-server per shellscript. Da kann ich auch sämtliche sicherheiten und feedbacks einbauen die ich benötige.

[Dukel 437]

Was hast du denn für außergewöhnliche Anforderungen?

[r4pt0x 10]

Die aktuellen Backuproutinen sehen folgendermaßen aus:

 

Das Hostsystem erstellt nächtliche snapshots von 2 OpenVZ containern und 2 KVM VMs, Snapshot für Windows-Server in KVM ist nicht konsistent möglich, daher sichert die W2k8-VM per WSS und zusätzlich nach dem fullbackup auch noch dei MSSQL-Datenbanken.

Zudem schreiben die linux-VMs Backups von Kundendatenbanken und einer firebird-Datenbank.

 

Backups werden 1 Tag lokal auf seperaten Platten im Hostsystem und 5 Tage auf einem dedizierten NAS vorgehalten, Datenbanken-Backups werden zusätzlich gepackt und zwischen den Standorten ausgetauscht, dabei muss bei Störung der VPN-Verbindung deren Status abgefragt werden und ggf per openvpn eine backup-verbindung aufgebaut werden. Schlägt das fehl, werden die Backups auf einen externen Server geladen und vom Server am anderen Standort sobald verfügbar abgeholt (so sichert bei Internet-Ausfall an einem Standort zumindest die andere Seite, die noch eine Anbindung hat nach draussen)

 

Die Windows-Server sind hier nur ein kleiner Teil der Serverstruktur (und trotzdem der Wartungs- und Nervenintensivste!), daher werde ich mich hüten diesen die Backup-aufgaben zu übertragen.

WSS tut seinen dienst und das auch recht gut da die Sicherungen sehr schnell und einfach wiederherzustellen sind. Ebenso sind die Backups aus MSSQL Server sauber und funktionieren, da lasse ich keine andere Software in den Datenbankserver fummeln, die beim nächsten Update dann wahrscheinlich nicht mehr sauber kompatibel ist.

Das gesamte "backend" für die restliche Verarbeitung der Backups läuft schon lange absolut zuverlässig und wird daher auch nicht ausgetauscht. Es ging einzig und allein darum, dass die Windows-VMs die Laufwerke nur verbinden wenn sie sie auch benötigen (während dem Backup!) und dann wieder trennen.

 

Für die "Hilfestellung" "Kauf dir ne Software" hätte ich nicht nach einer Skriptlösung für das verbinden/trennen von iSCSI targets gefragt...

[Dukel 437]

Mir solls egal sein, ich muss das Zeug nicht warten und betreiben.

 

Auch wenn man nach A fragt und B eine bessere Lösung wäre kann man dieses ansprechen.

[NeMiX 76]

Ich hoffe für deine Firma nur das du das ganze sauber und verständlich dokumentiert hast.

Ein sauberes Backupkonzept sieht für mich anders aus, aber ich komme auch aus der MS-Welt...

[bla!zilla 10]

Backupkonzepte misst man am Grad der Ergebniserfüllung. "Sauber" liegt im Auge des Betrachters. "Sauber" heißt auch nicht immer "einfach" (im Sinne von Komplexität).