Problem mit VM5.1 Backup und BackupExec 2010r3

[monster900]

Hallo,
ich betreue seit kurzem eine VM Infrastruktur aus 3 VM 5.1 Hosts (Ess. Plus).
Die Hosts hängen per FC an einem SAN.
Auf dem Backup-Server läuft BackupExec 2010R3 mit VM-Agent. Der Backupserver hat eine integr. FC NW-Karte.
Ich habe mir jetzt mal die Backup-Jobs genau angesehen. Einige Server werden per VM-Agent gesichert, andere wiederum ausschließlich per BS-Agent. Leider kann mir niemand mehr Auskunf darüber geben, wieso und weshalb das so eingerichtet wurde ...

Ich habe mich in den letzten Tagen nun ausführlich mit BackupExec auseinandergesetzt.
Und je mehr ich mich mit BE beschäftige um so rätselhafter wird das Ganze für mich:

Beispiel 1:
Lt. BE-Log wird Server 1 (210 GB) in 5 Minuten gesichert . Nur wenn ich mir die Einträge auf dem Host ansehe, so hat der Backup-Vorgang vom erstellen des Snapshots bis zum entfernen des Snapshots rund 3,5 Stunden gedauert!
Wobei 210 GB in 3,5 Stunden finde ich jetzt für eine direkte FC-Anbindung des Backupservers an das SAN nicht gerade berauschend!

Beispiel 2:
Server 2 mit 600GB-Daten.
Diesen bekomme ich per VM-Agent überhaupt nicht gesichert! Das Backup hängt sich irgendwann einfach auf bzw. es dauert ewig. Ich mußte das Backup nach 18 Stunden abbrechen...
Eine direkte Imagesicherung aus der laufenden VM heraus benötigt hier 4 Stunden über 1 Gbit-LAN. Da sollte es doch per Backupserver mit FC-Anbindung doch zumindest schneller laufen, oder?

Beispiel 3:
Bei der testweisen Rückksicherung von einigen VM's die zuvor per VM-Agent gesichert wurden konnte ich diese nicht mehr starten!

Mein Fazit:
Derzeit kann ich mich auf die Backups hier überaupt nicht verlassen!
Hat jemand von Euch die gleichen Erfahrungen mit BakupExec2010R3 und den VM-Agents gemacht?

Ich würde am liebsten sofort BE hier rausschmeißen und gegen Veeam ersetzen. Leider muss dass noch bis zum nächten Jahr warten, da die BE-Wartung gerade wieder um 1 Jahr verlängert wurde.

Gruß
Dirk

[Dayworker]

Meiner Erinnerung nach nutzen hier auch einige BE und vollkommen unproblematisch war es wohl bei keinem.
Aber wenn ihr Wartung habt, dann frag doch mal den Hersteller danach.

[weigeltchen]

"BE 2010 R3 SP3 which will support ESX 5.1 is currently in beta and GA is expected to be in July." Tante Google bringt noch mehr.

[mbreidenbach]

Etwas ausführlicher:

Irgendjemand hat seine Hausaufgaben nicht gemacht. Backup Exec unterstützt aktuell offiziell vSphere 5.1 nicht.

Selberlesen:

http://www.symantec.com/connect/blogs/q ... ort-update

[monster900]

@all
Danke für die Hinweise.

Ihr dürft mir glauben, dass bin absolut nicht begeistert bin mit BE arbeiten zu 'müssen'. Ist ja an und für sich eine gute Backuplösung, aber eben mehr für 'Blech-Server' bzw. für Tape-Library. Im VM-Umfeld finde ich das Produkt eher suboptimal. Aber die Kröte muss ich halt erstmal schlucken !
Kenne sowohl Triliead Explorer als auch Veeam und beide überzeugen mich im VM-Bereich weit mehr.

Nun Gut, ich habe gestern abend endlich die Performance-Probleme einkreisen können. Ursache ist offensichtlich der Backup-Server.
Ich habe vom Dateiserver (VM mit 650GB) testweise mal ein Image mit Drivesnapshot (übrigens eine geile kleine Software ) über das LAN auf den Backup-Server gezogen.
Beim 1. Versuch der Imagerstellung habe ich die Dateigröße der Image-Dateien auf 100GB eingestellt.
Es fing auch Alles gut an. Aber je größer die 1.Image Datei auf dem Backupserver wurde, desto lahmer wurde die Imageerstellung bzw. die Transferrate...
Nach 2 Stunden war der 1. Image-Container mit 100 GB erledigt => 0,83 GB/min
Kaum begann Drivesnapshot den 2. Image-Container zu schreiben ging auch die Performance wieder kräftig hoch...
Ich habe dann abgebrochen und den Versuch wiederholt. Diesmal habe ich bei Drivesnapshot die Dateigröße der Imagedateien auf 4GB eingestellt.
Und schwups: Der ganze Server war in 190 Minuten gesichert:
Das Image des kompletten Servers hat 464 GB die in 190 Minuten gesichert wurden -> 2,44 GB/min (Die tats. Performance ist sogar größer, da das Image ja bereits komprimiert ist)

Ich habe mir dann auch die Logs von BE und VM mal genauer angesehen und konnte auch hier das gleiche feststellen. Je größer die vmdk-Sicherung des VM-Agents, desto lahmer wurde das Backup. Ein kleiner Server mit 7 GB war sehr schnell gesichert, während ein größerer Server mit 210 GB und 3 entsprechend großen vmdk 3,5 Stunden brauchte.

Stellt sich jetzt die Frage nach dem warum.
Bei dem Backupserver handelt es sich um einen Windows 2003x64 mit 4 GB RAM. Der Server hat ein lokales Raid-Array mit 5 TB und wird ausschließlich für BackupExec verwendet.
Wieso bricht die Schreibrate auf dem Server bei großen Dateien so extrem ein?

Gruß
Dirk

[irix]

Wie lange die Erstsicherung dauert ist doch sekundaer solange die dann folgende Inkremental Sicherung flott ist. Aus Erfahrung kann ich sagen das man an der Backup Hardware nicht am falschen Ende sparen sollte.

Gruss
Joerg

[monster900]

@Joerg
Sehe ich etwas anders! Schließlich muss es ja relemäßig ein Vollbackup geben. Derzeit machen wir am WE ein Vollbackup. Das wandert dann am Ende des Monats ins Bankschließfach. Dort liegen dann die letzten 6 Monate. Aber was nutzt ein Backup, wenn sich die Daten darauf nicht wieder herstellen lassen!?

Für mich ist am Backup das Restore am wichtigsten! Und da happert es hier leider. Mein Vorgänger hat sich keine großen Gedanken dazu gemacht. Als man hier im Unternehmen 2011 auf VMWare umgestellt hat, wurde einfach BE mit weiteren Agenten aufgerüstet und dann irgendwie ein Backup auf Band bzw. den Backupserver zu bekommen.

Ich versuche jetzt erstmal ein Backup/Restore so hinzubekommen, dass ich ruhig schlafen kann!

Gruß
Dirk

Gruß
Dirk

[irix]

@Joerg
Sehe ich etwas anders! Schließlich muss es ja relemäßig ein Vollbackup geben. Derzeit machen wir am WE ein Vollbackup. Das wandert dann am Ende des Monats ins Bankschließfach.

Dito.... 35LTO4|5s jedes Wochende.

Dort liegen dann die letzten 6 Monate. Aber was nutzt ein Backup, wenn sich die Daten darauf nicht wieder herstellen lassen!?

Was hat das mit der evtl. etwas langsamen Vollsicherung zutun? Hier haben wir Testplaene welche es abzuarbeiten gilt. Wenn euer Produkt die Anforderungen nicht erfuellt dann tauscht es aus oder aendert die Anforderung.

Für mich ist am Backup das Restore am wichtigsten! Und da happert es hier leider. Mein Vorgänger hat sich keine großen Gedanken dazu gemacht. Als man hier im Unternehmen 2011 auf VMWare umgestellt hat, wurde einfach BE mit weiteren Agenten aufgerüstet und dann irgendwie ein Backup auf Band bzw. den Backupserver zu bekommen.

Das ist erstmal nicht unueblich. Nur muss man dann irgendwann den 2. Schritt machen und pruefen ob man das Backupkonzept nun anpassen muss/will oder nicht. Ich persoenlich mag die Sicherung von VMs als ganzes. Aber ich kenne Kunden welche mit Agenten 100te von VMs traditionell sichern.

Ich versuche jetzt erstmal ein Backup/Restore so hinzubekommen, dass ich ruhig schlafen kann!

Ich schlafe auch so schlecht

Gruss
Joerg

[monster900]

@Joerg
Ich hoffe, dass es an einer heißen Frau liegt, dass Du so schlecht schläfts.

Aber nochmal zurück zum Thema.
Woran kann es liegen, dass der Backupserver bei großen Dateien derart einbricht!?
Es handelt sich um einen HP380G5 mit 4 GBRAM. BS ist W2K3 64Bit.
Am NW liegt es grundsätzlich nicht. Beim kopieren einer großen Datei auf einen anderen Server bleibt die Performance konstant.

Gruß
Dirk

[sam36]

Hi Dirk,

wir haben eine ähnliche Konfiguration hier BE 2010 R3., Fujtsu RX 300 S, 4G Speicher, B2D per FC und anschließend c2t. Die Sicherungen und auch die Wiederherstellung läuft fehlerfrei bei uns.
Gruß
Stefan

[Dayworker]

@monster900
Also das scriptbare Drivesnapshot bietet die üblichen drei Möglichkeiten (gesamte Platte, nur benutzte Sektoren oder inkrementell) eines Images. Bei der einzelnen Grösse einer Imagedatei bin ich wieder runter auf 2040MB, da sich ansonsten je nach Zieldateisystem und Plattengrösse die Datenrate stetig gen Null bewegte. Meine Vermutungen sind, daß entweder normale SATA-Platten aufgrund ihrer im Vergleich zu SAS/FC-Platten höheren Bitfehlerate damit Probleme bekommen, sequentiellen Übertragungen im 100GB-Bereich enbloc abzuwickeln oder aufgrund der Dauerlast entweder die Platten- und/oder auch die Controllertemperaturen stark ansteigen. Unter Umständen hat aber auch nur Drivesnapshot ein Problem mit einzelnen Imagedateien im Multigigabyte-Bereich...

[monster900]

@all
Bitte den ganzen Fred lesen!
Es geht hier nicht um den Einsatz von Drivesnapshot! Drivesnapshot habe ich nur genutzt um das Problem eingrenzen zu können!

Konkret habe ich das Problem, dass die BackupExec-Sicherung mit dem VM-Agent bei größeren Maschinen extrem lange dauert bzw. überhaupt nicht durchläuft. Auf einem Fileserver habe ich 650 GB zu sichern. Bei einer Vollsicherung ist das vmdk-File der Partition runde 500 GB groß. Hier läuft sich unser Backupserver einfach tot! Sprich die Schreibperformance auf dem Backupserver sinkt mit wachsender Dateigröße kontinuierlich ab. Irgendwann ist Sie so gering, dass nur noch der Abbruch der Sicherung bleibt, da quasi nix mehr passiert!
Das Problem liegt nicht an BE, sondern definitiv am Backupserver!

Hier die Daten des Backupservers:
HP DL380 Gen5
HP 400 Raid Controller mit 8 Anchlüssen
2 x 73 GB SAS (RAID-1) für BS (W2k3 64-Bit)
6 x 1 TB SAS (RAID-5) als Backupstorage

Gruß
Dirk

[Dayworker]

Das es dir nicht um Drivesnapshot geht, war mir schon klar. Ich hatte dir nur mal meine Erfahrungen damit beschrieben.
Ein Raid5 hat bekanntermaßen grosse Einbußen beim Schreiben. Mehr als 25% der Schreibleistung einer Einzelplatte sind damit nicht drin und zudem immer von einem aktiven Schreibcache im HW-Raidcontroller abhängig. Ohne BBU lassen sich einige Controller zwar trotzdem zu dessen Cache-Aktivierung überreden, daß Risiko einer Datenverlustes wäre mir aber zu hoch...

[monster900]

So,
nach langer Suche habe ich endlich was gefunden. Es handelt sich offenbar um ein bekanntes Problem: http://social.technet.microsoft.com/Forums/windowsserver/en-US/111d8f9c-c497-4610-b7fd-94addafa9452/large-file-copy-degradation-to-and-from-win-2003-r2-64-bit-servers
Muss man halt erstmal finden...

Muss ich nur noch eine Lösung dafür finden .

Gruß
Dirk

[Dayworker]

Das Problem haben aber nicht nur alle XP-artigen Windows, es mag nur unter Server2k3 am deutlichsten Zutage treten, ansonsten hätte man bei XCOPY unter Win7 bzw Server2k8-R2 nicht noch extra den Switch "j" zum Ausschalten des Buffering eingeführt.
Eine allgemeine Lösung wirst du vermutlich nicht mehr finden, ausgehend von http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Windows+Server+2003+R2 läuft der Extended Support nur noch bis 14.07.2015 und im Extended Support werden eigentlich nur noch Sicherheitsprobleme beseitigt oder irre ich da?

[skneo]

Zwar Dell Server aber Vielleicht Hilft es dir ja. Ahnlich Raid5 und Win 2003 64 Bit. Dort musste man z.b immer so ein storeport Driver Update einspielen das gab es bei Dell zum Download zum Server. Das hatte die Performance Probleme gelöst. Nach der Umstellung auf 2008 hatten wir nichts mehr Installiert und auch eine bessere Performance.

[Dayworker]

Spielst du auf ftp://ftp.dell.com/scsi-raid/Storport_readme.txt und den darin genannten M$-KB-Eintrag http://support.microsoft.com/kb/943545 an?

[skneo]

Ja genau, das Hauptproblem worum wir den Patch Installiert hatten war ein SAS Bandlaufwerk wo der Fehler dann hochgekommen ist beim Schreiben auf das Band gab es dann den besagten Fehler. Nach dem Installieren war aber auch die Performance vom Raid normal für 15k SAS Platten und die Backup Zeit war dann von 12h auf 3h gesunken. Auch sonst ist die Erfahrung mit dem Windows 2003 64 nicht toll und würde auf jeden fall eine Migration auf 2008 machen.

[Dayworker]

Je nach HW, wie beim Dell T110ii, ist Server2k3 offiziell egal in welcher Version nicht mehr supportet. Von daher stellt sich die Frage des Patcheinspielens eventuell überhaupt nicht mehr.
Allerdings hatte auch Emulex empfohlen, diesen M$-Patch noch vor dem Einspielen seines HW-Treibers zu installieren.

[monster900]

Hallo,
ich habe zwischenzeitlich mal weiter getestet.
Das Problem tritt definitiv bei 2003R2 x64 auf. Sowohl auf realem Blech, als auch auf VM's.
Unter 2008R2 oder unter Windows 7 tritt das Verhalten jedenfalls nicht auf. Sowohl unter realem Blech als auch als VM.

Ich habe jetzt die Suche nach einer Lösung aufgegeben. Im nächsten Jahr stellen wir auf neue HW und Veeam um. Bis dahin müssen die großen VM's eben per BS-Agent gesichert werden.

Gruß
Dirk

[Dayworker]

Das der Fehler unabhängig vom Ausführungsort auftritt, war mir klar. Der Storport-Treiber kommt ja sowohl auf Blech als auch VM zum Einsatz...
Eigentlich sollte es dir helfen, wenn du den Treiber aus dem M$-Link einspielst.

[monster900]

@monster900
Also das scriptbare Drivesnapshot bietet die üblichen drei Möglichkeiten (gesamte Platte, nur benutzte Sektoren oder inkrementell) eines Images. Bei der einzelnen Grösse einer Imagedatei bin ich wieder runter auf 2040MB, da sich ansonsten je nach Zieldateisystem und Plattengrösse die Datenrate stetig gen Null bewegte. Meine Vermutungen sind, daß entweder normale SATA-Platten aufgrund ihrer im Vergleich zu SAS/FC-Platten höheren Bitfehlerate damit Probleme bekommen, sequentiellen Übertragungen im 100GB-Bereich enbloc abzuwickeln oder aufgrund der Dauerlast entweder die Platten- und/oder auch die Controllertemperaturen stark ansteigen. Unter Umständen hat aber auch nur Drivesnapshot ein Problem mit einzelnen Imagedateien im Multigigabyte-Bereich...

@Dayworker
Eine solche Problematik ist mir beim Einsatz von Drivesnapshot bisher nicht untergekommen. Ich habe DS bei diversen meiner ehemaligen Kunden im Einsatz. Hier wird zumeist auf ein NAS (QNAP, Buffalo, Iomega) gesichert. Bei einem Kunden läuft die Sicherung von 2 Servern (Windows 2008x64) mit DS auf ein RD-1000 Laufwerk. Als Größe der Dateien habe ich bei allen Kunden 100GB eingestellt. Das Größe der Dateien hat überhaupt keine Auswirkungen auf die Performance von DS.

Gruß
Dirk