ESX backup naar andere ESX

[SCaRa1701]

Hallo,

Voor een test-project heb ik een ESX server draaien met daarop enkele Windows servers.
Nu speel ik met het idee om van de machines een backup te maken op een andere locatie.

Op die manier zou ik in theorie snel de infrastructuur weer werkend kunnen krijgen door een 2e ESX server te starten op een andere locatie met een recente back-up van de machines.

Dus de situatie is als volgt: ESX-server 1 staat in het bedrijf, ESX-server 2 (back-up) staat in een administratief gebouw. Beide servers zijn via netwerk (gigabit) verbonden met elkaar.

Met het ghettoVCB script ben ik er al in geslaagd een back-up te maken van de machines op een NFS store. Ik zit echter verveeld met het volgende probleem:

Het overzetten van de machine naar de NFS store neemt een lange tijd in beslag. En nu gaat het nog maar om server waar nog niet echt veel data op geplaatst is. Dus naarmate de data op de server groeit zal ook de tijdsduur voor het overzetten van de virtuele machines groeien.

Mijn vraag is nu, kan ik met ghettoVCB een soort van incremental backup maken van de virtuele machines zodat enkel de aangepaste data gebackupped wordt en over het netwerk dient gestuurd te worden?

[Tags NL]

Is ook wel snel/makkelijk : http://www.veeam.com/vmware-esxi-fastscp.html . Maar een soort incrementals naar een andere server te sturen? Hoe lang duurt het nu dan met de machines en data die je nu hebt?

[Tys]

VMWare Fault Tolerance is hiervoor een simpele oplossing. Er draait dan een 2e 'VM' als shadow op de 2e ESX server die de boel instant oppikt zodra de 1e ESX server op zijn bek gaat. Werkt uitstekend maar verbruikt redelijk wat bandbreedte bij intensief gebruik van server capaciteit. Voordeel is dus dat dit echt een instant back-up is van exact dezelfde machine, het nadeel is wel dat er een prijskaartje aan zit gezien FT niet in elke versie wordt ondersteund.

Edit: overigens is FT alleen makkelijk (lees: bruikbaar) als je centrale storage hebt. Gezien je post is dit waarschijnlijk niet het geval .. desondanks misschien de moeite waard. Het lopen knutselen met snapshots van virtuele machines heeft in mijn beleving nooit goed gewerkt.

[ Voor 21% gewijzigd door Tys op 15-10-2009 21:46 ]

[SCaRa1701]

In mijn testcase ging het om een VM van 16GB die overgezet werd via een 100mbit netwerk. Hier heb ik een uur over gedaan om de machine over te zetten.

In de praktijk zou het gaan om 500GB over een 1000mbit netwerk.

[SpamLame]

Tyson schreef op donderdag 15 oktober 2009 @ 21:43:
VMWare Fault Tolerance is hiervoor een simpele oplossing. Er draait dan een 2e 'VM' als shadow op de 2e ESX server die de boel instant oppikt zodra de 1e ESX server op zijn bek gaat. Werkt uitstekend maar verbruikt redelijk wat bandbreedte bij intensief gebruik van server capaciteit. Voordeel is dus dat dit echt een instant back-up is van exact dezelfde machine, het nadeel is wel dat er een prijskaartje aan zit gezien FT niet in elke versie wordt ondersteund.

Edit: overigens is FT alleen makkelijk (lees: bruikbaar) als je centrale storage hebt. Gezien je post is dit waarschijnlijk niet het geval .. desondanks misschien de moeite waard. Het lopen knutselen met snapshots van virtuele machines heeft in mijn beleving nooit goed gewerkt.

FT is geen backup. Het dient om bij hardwarefailure met minimale impact de dienstverlening (van de VM) door te laten draaien.
Indien er iets fout gaat binnen de VM (lees bv bestanden wegknikkeren door een doggy script) dan heb je niks aan FT aangezien die alles (dus ook fouten) vrolijk door repliceert.

Overigens heeft TS centrale storage in de vorm van een NFS server.
Of die ook als zodanig ingezet mag/kan worden is aan TS.

@TS 500Gig is in jou geval 3 uur over (natte vingerwerk).
/zomaar een id
Verder ken ik je setup niet, maar wat te denken van 2 esxen die elkaar backups met rsync overzetten?
Indien dat niet mogelijk is (beperking ESX) dan zou je er 2 nfs servers tussen kunnen schuiven.
Daar schrijft VCB dan naar toe en die 2 NFS servers gaan lekker rsyncen.

[ Voor 16% gewijzigd door SpamLame op 16-10-2009 08:02 ]

[jvanhambelgium]

Tyson schreef op donderdag 15 oktober 2009 @ 21:43:
VMWare Fault Tolerance is hiervoor een simpele oplossing. Er draait dan een 2e 'VM' als shadow op de 2e ESX server die de boel instant oppikt zodra de 1e ESX server op zijn bek gaat. Werkt uitstekend maar verbruikt redelijk wat bandbreedte bij intensief gebruik van server capaciteit. Voordeel is dus dat dit echt een instant back-up is van exact dezelfde machine, het nadeel is wel dat er een prijskaartje aan zit gezien FT niet in elke versie wordt ondersteund.

Edit: overigens is FT alleen makkelijk (lees: bruikbaar) als je centrale storage hebt. Gezien je post is dit waarschijnlijk niet het geval .. desondanks misschien de moeite waard. Het lopen knutselen met snapshots van virtuele machines heeft in mijn beleving nooit goed gewerkt.

Nadeel is dat dit een synchroon systeem is (lockstep mode)... als de VM1 crashed met een blue screen dan crashed VM2 ook enkele milliseconden later ;-)
Het zal tegen hardware-fouten beschermen maar applicatieve/OS shit vang je niet op...

Uiteraard ook wel wat bandbreedte nodig (min 1Gbps) , maar dat is met elke synchrone oplossing.

[Microkid]

SCaRa1701 schreef op donderdag 15 oktober 2009 @ 21:45:
In mijn testcase ging het om een VM van 16GB die overgezet werd via een 100mbit netwerk. Hier heb ik een uur over gedaan om de machine over te zetten.

In de praktijk zou het gaan om 500GB over een 1000mbit netwerk.

Dan zou ik als eerste maar eens je netwerk vervangen door een Gbit netwerk. Zaken als VMotion, VCPbackup, VEEAM Fastscp enz werken het beste op Gbit snelheid. Een test over 100Mbit is niet echt representatief.
Reken zelf maar uit: 16GB over 100Mbit = minimaal 26 minuten, over 1000Mbit minimaal 2.6 minuut

[SCaRa1701]

Hi,

Ik heb vandaag alles op gigabit aangesloten.
Aan beide kanten wordt aangegeven dat 1000mb snelheid mogelijk is. Echter bij het overzetten van een file van A naar B haal ik amper een snelheid van 1.701KiB. Ik heb al verschillende kabels en switchen geprobeerd tussen beide toestellen maar het probleem blijft bestaan.

Kan het zijn dat de snelheid van de adapter op mijn esx server op de een of andere manier toch nog beperkt is?

[SCaRa1701]

De oorzaak van het probleem is gevonden.
Het toestel waar mijn nfs share op stond (oudere workstation met gb ethernet) heeft blijkbaar een probleem. Met een nfs share op een ander toestel (wel maar een laptop, dus iets trage hdd) verloopt alles heel wat vlotter. 16GB overgezet in 7-8 minuten.

Dus als alles goed gaat zou ik 500GB moeten kunnen overzetten in minder dan 5uur. Ideaal om 's nachts te doen dus