Hallo,
aktuell werden Windows Hosts hier noch klassisch mit Data Protector gesichert. Es wird zuerst C über ein daily system backup mit WBADMIN auf ein anderes lokales Laufwerk gesichert, anschließend mit D und möglichen anderen lokalen Laufwerken vom Data Protector auf Band gesichert. Dabei gibt es keine Unterscheidung ob das System eine VM oder Blech ist.
Data Protector hat wohl (in der Version die hier eingesetzt wird - ich bin nicht im Backup Team) größere Probleme beim Backup von W2K8 Systemen, deswegen der Umweg über das daily system backup. Im Falle eines Restores ist das natürlich alles etwas aufwendiger als gewünscht (Mini OS -> Repair -> WBADMIN start sysrecovery ... usw.) und wie ich heute lernen durfte, kann auch ein Backup mit WBADMIN u.A, nicht zurückgespielt werden (error sysrecovery is not possible because all the critical volumes are not present in the specified backup). Ich sehe Potential für Verbesserungen...
Ich kenne vRanger von Quest und andere Lösungen die ein Backup der VMs auf Disk durchführen. Wie wird das in Umgebungen mit z.B. >400 VMs eingesetzt? Es wird ja zu dem Platz den die VMs auf dem Storage so schon benötigen, ein mindestens genauso großer Bereich für die Backups benötigt (abzüglich Kompression). Eher noch mehr, wenn man das Full + Diff + Ink Backup einer Woche liegen lassen will. Wie kann man das sinnvoll mit einem Backup auf Band kombinieren? Storage ist nicht unbedingt güstig in dieser Größenordnung, vor allem wenn das Backup auf Band wegen der Retention Time von ~6 Monaten nicht fallen gelassen werden kann/soll.
Wie viele VMs können max. z.B. mit einer vRanger Instanz gesichert werden? Eine Umgebung die ich kenne, hatte schon mit ca. 20 VMs Probleme im Backup Zeitfenster zu bleiben.
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Backup 2 Disk in größerer Umgebung
-
Nukite2007
- Member
- Beiträge: 356
- Registriert: 16.05.2007, 11:48
- Wohnort: Rosenheim / Obb.
Hallo,
wir setzen aktuell noch Dataprotector 6.0 ein. Probleme mit Win2008 sind uns auch nicht bekannt. Wir sichern die Blechkisten als auch die VM´s mit den normalen Diskagenten. D.h. wir haben keine VM-Integration.
Das erledigen wir über vRanger. Sind damit sehr zufrieden.
In ca. 4 Wochen wird Dataprotector durch Commvault ersetzt und von Backup to Disk to Tape auf Backup to Disk to Disk umgestellt.
Achja.. unsere Umgebung besteht aus 6 x ESXi 5 und ca. 100 VM´s
VG
Peter
wir setzen aktuell noch Dataprotector 6.0 ein. Probleme mit Win2008 sind uns auch nicht bekannt. Wir sichern die Blechkisten als auch die VM´s mit den normalen Diskagenten. D.h. wir haben keine VM-Integration.
Das erledigen wir über vRanger. Sind damit sehr zufrieden.
In ca. 4 Wochen wird Dataprotector durch Commvault ersetzt und von Backup to Disk to Tape auf Backup to Disk to Disk umgestellt.
Achja.. unsere Umgebung besteht aus 6 x ESXi 5 und ca. 100 VM´s
VG
Peter
Die Backup Kollegen testen gerade die DP Version 7. Auch da scheint es beim Desaster Recovery von phy. Windows Systemen wieder Probleme zu geben. Ein erster Restore Test einer VM war aber erfolgreich. Ein HP Consultant wird sich das alles noch mal anschauen.
Für VMs würde ich eine andere Lösung bevorzugen. Mit vRanger habe ich schon mal kurz Erfahrungen sammeln können. Diese Image basierten Lösungen haben keinen Agenten auf dem Client und sichern das VMDK File. Ein File Level Restore erfolgt dann aus dem gemounteten Backup Image heraus. Wenn ich mich richtig erinnere, bedeutet es, dass man einzelne Dateien auf den vRanger Server kopieren muss und von dort dann weiter auf das Ziel. Ggf. müssen auch noch die Rechte angepasst werden.
Ist das noch so? Welche anderen grösseren Umstellungen ergeben sich im Backup/Restore Betrieb? Also vor allem für die Backup Kollegen. Immer mit dem Blick darauf, dass seit Jahren mit einer klassischen Agenten basierten Lösung gearbeitet wurde.
Für VMs würde ich eine andere Lösung bevorzugen. Mit vRanger habe ich schon mal kurz Erfahrungen sammeln können. Diese Image basierten Lösungen haben keinen Agenten auf dem Client und sichern das VMDK File. Ein File Level Restore erfolgt dann aus dem gemounteten Backup Image heraus. Wenn ich mich richtig erinnere, bedeutet es, dass man einzelne Dateien auf den vRanger Server kopieren muss und von dort dann weiter auf das Ziel. Ggf. müssen auch noch die Rechte angepasst werden.
Ist das noch so? Welche anderen grösseren Umstellungen ergeben sich im Backup/Restore Betrieb? Also vor allem für die Backup Kollegen. Immer mit dem Blick darauf, dass seit Jahren mit einer klassischen Agenten basierten Lösung gearbeitet wurde.
man Ersetzt ein traditionelles Agent- und Filebasiertes Backup ja nicht komplett durch ein Image basiertes Backup Konzept. Eine gewinnbringende Koexistenz ist das Ziel.
Natürlich kann man auch mit Imagebasierten Backups einen Filelevel Restore machen, aber wenn das die Regel ist (z.B. bei einem Fileserver) ist das durchaus nervig.
Man kann z.B. auch die Systemplatten imagebasiert als VMDK wegsichern und die große Datenplatte in der sich recht wenig ändert wieder file basiert sichern. So erspart man sich das aufsetzen des OS und installieren des Backup Clients um das system, wieder herzustellen.
Wir haben bis vor kurzem iCCider der Firma mySoftIT verwendet, welches über die vStorage API die vmdks auf platte gesichert hat. Das können vRanger und Acronis und Veeam auch, nur konnte icCider auch direkt mit TSM kommunizieren und die VMs auf Band ablegen. Leider ist die Firma insolvent und das Produkt ist EOL.
IBM bietet mit dem TSM eigenen Tivoli Data Protector for virtualization eine eigene Backuplösung über die vStorage API, aber wie TSM nun mal so ist, sind die GUIs und Scheduler eine Qual im Vergleich zu den anderen genannten Lösungen.
Derzeit schaue ich mir den vRanger an (wegen der Replikaition auf einen zweiten Storage) und genau die Frage des benötigten Volumens für die Backup stelle ich mir auch. Da die VMDKs i.d.R. nicht voll sind, und die leeren Blöcke nicht gespeichert werden, ist auch ein Full Backup einer VMDK nicht so groß wie das Original. Durch CBT werden die Diffs auch deutlich kleiner, so dass ein tägliches Backup mit 7 Generationen eigentlich kleiner sein sollte als das Original. Wie groß oder klein das Backup aber tatsächlich ist, hängt eben von dem Datenfüllgrad des Sytems und der täglichen Veränderung des Systems ab. Eine Demo des vRangers steht noch aus, ich erhoffe mir noch Praxiswerte vom Hersteller.
EDIT:
Auch wenn das Image basierte Backup die Probleme mit den Zeitfenstern beim Backup extrem entschärfen, man sollte die Restore Zeiten im Auge behalten, eine einzelne VM wieder herzu stellen ist etwas anderes als einen ganzen Datastore mit 20 VMs oder gar den ganzen Storage.
Eine zusätzliche Bandsicherung ist auch trotz eines Mirrors und eines Diskbackups dann noch sinnvoll, wenn man keine getrennten Lokationen hat. Im Falle einer Katastrophe hat man immer noch eine Auslagerung der Backups, auf die man zurück greifen kann.
Natürlich kann man auch mit Imagebasierten Backups einen Filelevel Restore machen, aber wenn das die Regel ist (z.B. bei einem Fileserver) ist das durchaus nervig.
Man kann z.B. auch die Systemplatten imagebasiert als VMDK wegsichern und die große Datenplatte in der sich recht wenig ändert wieder file basiert sichern. So erspart man sich das aufsetzen des OS und installieren des Backup Clients um das system, wieder herzustellen.
Wir haben bis vor kurzem iCCider der Firma mySoftIT verwendet, welches über die vStorage API die vmdks auf platte gesichert hat. Das können vRanger und Acronis und Veeam auch, nur konnte icCider auch direkt mit TSM kommunizieren und die VMs auf Band ablegen. Leider ist die Firma insolvent und das Produkt ist EOL.
IBM bietet mit dem TSM eigenen Tivoli Data Protector for virtualization eine eigene Backuplösung über die vStorage API, aber wie TSM nun mal so ist, sind die GUIs und Scheduler eine Qual im Vergleich zu den anderen genannten Lösungen.
Derzeit schaue ich mir den vRanger an (wegen der Replikaition auf einen zweiten Storage) und genau die Frage des benötigten Volumens für die Backup stelle ich mir auch. Da die VMDKs i.d.R. nicht voll sind, und die leeren Blöcke nicht gespeichert werden, ist auch ein Full Backup einer VMDK nicht so groß wie das Original. Durch CBT werden die Diffs auch deutlich kleiner, so dass ein tägliches Backup mit 7 Generationen eigentlich kleiner sein sollte als das Original. Wie groß oder klein das Backup aber tatsächlich ist, hängt eben von dem Datenfüllgrad des Sytems und der täglichen Veränderung des Systems ab. Eine Demo des vRangers steht noch aus, ich erhoffe mir noch Praxiswerte vom Hersteller.
EDIT:
Auch wenn das Image basierte Backup die Probleme mit den Zeitfenstern beim Backup extrem entschärfen, man sollte die Restore Zeiten im Auge behalten, eine einzelne VM wieder herzu stellen ist etwas anderes als einen ganzen Datastore mit 20 VMs oder gar den ganzen Storage.
Eine zusätzliche Bandsicherung ist auch trotz eines Mirrors und eines Diskbackups dann noch sinnvoll, wenn man keine getrennten Lokationen hat. Im Falle einer Katastrophe hat man immer noch eine Auslagerung der Backups, auf die man zurück greifen kann.
Bei den Image basierten Lösungen denke ich auch eher an das Desaster Recovery, also an die Sicherung vom Systemlaufwerk. Solange ein Restore nur von einem System benötigt wird, geht das auch vom Band noch ganz gut. Ich hatte aber auch schon Fälle, wo ich 4h auf das Band gewartet habe, weil noch die letzten Jobs darauf geschrieben wurden. Nicht auszudenken wie das ablaufen sollte wenn ein ganzes Datastore oder die komplette Lefthand Umgebung wegbricht und das letzte inkr. Backup der Clients auf dem gleichen Band liegt.
Das bedeutet aber auch, dass zu den Kosten vom DP zusätzlich die Kosten einer zweiten Backuplösung hinzu kämen. Da muss man erst mal argumentieren.
Hier wird in einer kleinen Umgebung demnächst Sansymphony-V als Storage Virtualisierungslösung eingesetzt. Diese soll das bereits vorhandene FC-SAN (HP EVA) an die VMware Umgebung an einem Standort anbinden. Bisher steht aber nur die Spiegelung der LUNs, also das Thema Verfügbarkeit der LUNs beim Ausfall eines RZs im Vordergrund.
Ich bin in dem Thema nicht direkt involviert, wie sieht es bei Sansymphony-V mit Site Recovery oder auch einfach Ergänzung im Bereich Backup aus?
Das bedeutet aber auch, dass zu den Kosten vom DP zusätzlich die Kosten einer zweiten Backuplösung hinzu kämen. Da muss man erst mal argumentieren.
Hier wird in einer kleinen Umgebung demnächst Sansymphony-V als Storage Virtualisierungslösung eingesetzt. Diese soll das bereits vorhandene FC-SAN (HP EVA) an die VMware Umgebung an einem Standort anbinden. Bisher steht aber nur die Spiegelung der LUNs, also das Thema Verfügbarkeit der LUNs beim Ausfall eines RZs im Vordergrund.
Ich bin in dem Thema nicht direkt involviert, wie sieht es bei Sansymphony-V mit Site Recovery oder auch einfach Ergänzung im Bereich Backup aus?
ich kenne die _aktuelle_ Datacore Versionen nicht, hab aber noch die Sprüche von Falconstore im Ohr, nach dem Motto "mit uns braucht ihr kein Backup" mehr. Also ich bin der Meinung, dass Redundanz und HA niemals ein asynchrones und unabhängiges Backup ersetzen kann. Das schöne an den Imagebasierten Backups - so weit sie korrekt implementiert wurden - man muss sich im Restore Fall nicht den Kopf zerbrechen, wie man die VM wieder zum laufen bekommt. I.d.R. mit einem Mausklick wieder her stellen, warten, hochfahren, fertig. Aber man muss sich VORHER wirklich Gedanken dazu machen, Stichwort Datenkonsistenz.
TSM ist eine eigenständige Backup Lösung die inzwischen (lange hat es gedauert) neben des traditionellen agentbasierten Backups auch die Möglichkeit bietet, VMs über die vStorage API zu sichern. Diese Funktion (Tivoli Data Protector for virtual Environments) ist zusätzlich zum normalen TSM kostenpflichtig und wird wie bei IBM üblich pro pCPU lizenziert (je nach CPU Modell gewichtet). Inzwischen gibt es ein neues Lizenzmodell von IBM, welches fast alle Produkte zusammen stellt, das ist dann volumenbasiert. TDPVE ist da mit drin, lediglich das ansonsten auch interessante HSM ist leider nicht.
Ich habe das TDPVE hier zum testen und neben einiger offener Fragen bzgl. der Performance kann ich def. sagen, dass Backup und Restores ähnlich bequem vonstatten gehen wie bei icCider oder vRanger, aber das einrichten bei neuen VMs IBM typisch ziemlich lästig ist.
Es ist natürlich verlockend, wenn man bereits TSM volumenbasiert lizenziert hat (so wie wir) auch das TDPVE zu verwenden und sich die extra Lösungen wie Backup&Recovery oder vRanger zu sparen. Diese können je nach Umgebung ja locker einige Tausend EUR kosten. Aber man muss sich auch bewusst machen, dass jede Backup Lösung die Versicherung einer Firma ist. Diese muss 100%ig funktionieren wenn alles andere nicht mehr läuft, dementsprechend muss auch das Know How vorhanden sein. Unter diesem Blickwinkel betrachtet, kann sich die Investition in eine zusätzliche Lösung lohnen.
Ich habe das TDPVE hier zum testen und neben einiger offener Fragen bzgl. der Performance kann ich def. sagen, dass Backup und Restores ähnlich bequem vonstatten gehen wie bei icCider oder vRanger, aber das einrichten bei neuen VMs IBM typisch ziemlich lästig ist.
Es ist natürlich verlockend, wenn man bereits TSM volumenbasiert lizenziert hat (so wie wir) auch das TDPVE zu verwenden und sich die extra Lösungen wie Backup&Recovery oder vRanger zu sparen. Diese können je nach Umgebung ja locker einige Tausend EUR kosten. Aber man muss sich auch bewusst machen, dass jede Backup Lösung die Versicherung einer Firma ist. Diese muss 100%ig funktionieren wenn alles andere nicht mehr läuft, dementsprechend muss auch das Know How vorhanden sein. Unter diesem Blickwinkel betrachtet, kann sich die Investition in eine zusätzliche Lösung lohnen.
Ein Kollege hat sich nun bei HP die VMware Integration vom DP angeschaut. Das scheint immer noch nicht sinnvoll nutzbar zu sein. Was SanSymphony-V als Speichervirtualisierung angeht, haben wir inzw. die Rückmeldung aus anderen "Bereichen" bekommen, dass es damit auch viele Probleme geben soll, vor allem beim Aufsetzen und der Integration.
Hi pirx,
wir setzen ebenfalls das IBM TSM ein.
Das hat neben den bereits erwähnten Features ein Feature das für mich ein Killerfeature für Storages ist: Data-Deduplication. Zudem wirst Du die maximale Performance vergleichbar zu CommVault mit dem TSM erhalten. Aber der TSM hat nun leider seinen Preis.
Ob Du die ganzen Agents/Plugins von TSM brauchst hängt von den Systemen ab.
Die Sicherungen gehen mit dem TSM sehr schnell, da wirklich nur die geänderten Daten transferiert werden. Wenn Ihr Beratung zum TSM benötigt, schreibe mir eine PN. Ich schicke dir gerne die Kontaktdaten unseres Ansprechpartners zu. Das ist ein sehr fitter Trupp die auch uns sehr gut beraten haben.
Wenn Ihr dann noch ein Storage mit Data-Deduplication einsetzt, dann sollte das Storagevolumen für die Backups wirklich sehr schnell wieder in die Richtung der tatsächlichen Nutzdaten gehen.
my 2 cents
wir setzen ebenfalls das IBM TSM ein.
Das hat neben den bereits erwähnten Features ein Feature das für mich ein Killerfeature für Storages ist: Data-Deduplication. Zudem wirst Du die maximale Performance vergleichbar zu CommVault mit dem TSM erhalten. Aber der TSM hat nun leider seinen Preis.
Ob Du die ganzen Agents/Plugins von TSM brauchst hängt von den Systemen ab.
Die Sicherungen gehen mit dem TSM sehr schnell, da wirklich nur die geänderten Daten transferiert werden. Wenn Ihr Beratung zum TSM benötigt, schreibe mir eine PN. Ich schicke dir gerne die Kontaktdaten unseres Ansprechpartners zu. Das ist ein sehr fitter Trupp die auch uns sehr gut beraten haben.
Wenn Ihr dann noch ein Storage mit Data-Deduplication einsetzt, dann sollte das Storagevolumen für die Backups wirklich sehr schnell wieder in die Richtung der tatsächlichen Nutzdaten gehen.
my 2 cents
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo zusammen,
bringe mal einen ganz anderen Ansatz ins Spiel, der sich inzwischen bei vielen unsere großen Kunden durchsetzt.
EMC Avamar Backup and Recovery for VMware Environments
Gruß,
Ralf
bringe mal einen ganz anderen Ansatz ins Spiel, der sich inzwischen bei vielen unsere großen Kunden durchsetzt.
EMC Avamar Backup and Recovery for VMware Environments
Gruß,
Ralf
bla!zilla hat geschrieben:pirx hat geschrieben: Was SanSymphony-V als Speichervirtualisierung angeht, haben wir inzw. die Rückmeldung aus anderen "Bereichen" bekommen, dass es damit auch viele Probleme geben soll, vor allem beim Aufsetzen und der Integration.
Was sollen das genau für Probleme sein?
Wenn es läuft soll es durchaus brauchbar sein, der Weg dahin aber lang und steinig sein. Ich bin aber durchaus auch an anderen Meinungen interessiert.
kastlr hat geschrieben:Hallo zusammen,
bringe mal einen ganz anderen Ansatz ins Spiel, der sich inzwischen bei vielen unsere großen Kunden durchsetzt.
EMC Avamar Backup and Recovery for VMware Environments
Schaue ich mir morgen an.
Hallo!
Einer hat es ja bereits genannt: Veeam Backup & Replicate
Wir setzten das bei uns ein in der Firma ein, und ich bin recht begeistert. Ich sicher damit Windows 2K8R2 und Linux-Systeme gleichermaßen; darunter 2 Exchange 2010 Mailbox-Server, und 4 Fileserver mit 2TB Datenplatte.
Ich nutze kein Filelevel-Backup mehr, weil ich mit dem Veeam Enterprise Manager binnen Minuten jede beliebige Datei restoren kann.
Und wenn ich mal was testen will, kann ich mein gesamtes Backup in einer isolierten Umgebung starten, u.a. für AD und Exchange Single-Object-Restore.
Ich würd mir das mal angucken, die gewinnen nicht umsonst den VMware Innovationspreis.
Klaus
Einer hat es ja bereits genannt: Veeam Backup & Replicate
Wir setzten das bei uns ein in der Firma ein, und ich bin recht begeistert. Ich sicher damit Windows 2K8R2 und Linux-Systeme gleichermaßen; darunter 2 Exchange 2010 Mailbox-Server, und 4 Fileserver mit 2TB Datenplatte.
Ich nutze kein Filelevel-Backup mehr, weil ich mit dem Veeam Enterprise Manager binnen Minuten jede beliebige Datei restoren kann.
Und wenn ich mal was testen will, kann ich mein gesamtes Backup in einer isolierten Umgebung starten, u.a. für AD und Exchange Single-Object-Restore.
Ich würd mir das mal angucken, die gewinnen nicht umsonst den VMware Innovationspreis.
Klaus
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste