I have spent the last few days trying to find a free backup solution to the newly free ESXi for windows only enviroments (in particular Windows XP). The solution for me was the following:
1. Installing Windows Services for UNIX (WSFU)
2. Copying the ESXi Server password and group files to Windows
3. Configuring WSFU for accepting ESX Server connections
4. Sharing the Windows folder for NFS compatibility
5. Configuring the ESXi Server to mount the Window NFS Share as Datastore.
6. Setup Backup Script
Attached is the complete steps.
I take NO credit for any of this. This is just a complation of others work formated to suit my needs and felt others could benift from it as I have.
I just had a thought that may have already been considered. To make a long story short, the VI Client messed up my vmdks, and I was able to salvage them by running the VM through the converter to Workstation 6.5 and back to ESXi. However it did not escape my attention that the Workstation vmdk that was created was only 5.5 gigs uncompressed compared to the previous 42 gigs worth of files that came in from ESXi. The conversion to workstation was a lot faster than converting back to ESXi's 36 gig vmdk. We do a lot more backups than restores. If that concept plus compression could be applied to the backup process...
If you only need occasional copies for a single machine you can use the current Converter 4.0 tool. It doesn't schedule but you can basically rerun a previous conversion. It is reasonably quick and as an added benefit you can launch the "backup" and verify that it is viable.
Does anybody know if you convert to 6.5 while backing up if it preserves the ESXi snapshots?
If you ever want to see "Gigs Fly", and you are copying a VM between local disks or volumes, or moving/renaming a VM on the same volume, use the cp or mv commands at the ESXi command prompt. Volumes show under /vmfs.
Does anyone know of a backup script that correctly handles the sparse files that ESXi creates?
A sparse file is a file that does not have all of it's space allocated. So for example, if I create a new 8g VM, and I don't install any data on it, it may look like it has 8g of space in use, but in reality it is close to 0. "ls -l" should show the 8g, "du" should show something close to 0 (if you have a real du that reports actual space used).
I tried using ghettoVCB.sh, and while the script works great, it is not correctly handling the sparse files. an empty 8g sparse file should take a couple seconds to cross the network, instead, it is sending 8g of data.
If ghettoVCB were to encapsulate and/or compress the sparse file in a manner that the sparse file was created as a sparse file upon restore, that would be the best solution, and it would reduce the needless bandwidth consumption, pushing gig after gig of 0's across the wire.
If you don't understand what a sparse file is, check out this link:
I have moved 35 real machines into 35 virtual machines. My backups have gone from using 500g to using several terabytes. This is not a compression issue, it is an issue of storing data that should not exist.
And worse, now that non-existant data is real data, the ESXi server has to handle large blocks of 0's that used to not exist because the backups have filled-in what is supposed to be sparse data. This is having a performance impact on the network, and the drives themselves. Before a backup, vmware could clone a system in a couple seconds, and after restoring the backup, the cloning operation takes much longer. We must preserve the sparse files sparse state, otherwise it's not a real backup.
Sehr geehrte Damen und Herren,
Ich befinde mich in der Zeit vom 28. März bis zum 13. April nicht im Hause.
Ich werde Ihre Mail nach meiner Rückkehr beantworten.
Bei dringenden Anliegen wenden Sie sich bitte an Herrn Eisenberg.
Mit freundlichen Gruessen
Fon: (05622) 997-650
Fax: (05622) 997-654
Hospital zum Heiligen Geist
Am Hospital 6
I don't know if you are still monitoring this thread or not. I was following your directions for using WSFU and NFS to do backups in ESXi. Everything was going well until I got to adding the NFS storage in the VMI Client. I keep getting this error: +"error during the configuration of the host cannot open volume vmfs volumes"+, So I did some searching and found posts saying that to get around this error you needed to allow anonymous access to the NFS folder and give Anonymous Logon Full Control of NTFS permissions. I have done that and now the error I get is "error during the configuration of the host nfs error unable to mount filesystem unable to connect to nfs server"
Any ideas what I may be doing wrong. It seems I am on the verge but cannot get this to work.
I´m not in the office until 14.04.2009. Your E-Mail won´t be forwarded. In urgent cases contact "PTD DataCenter" email@example.com
With best regards,
GIO IT SHS 94
91058 Erlangen, Germany
Tel.: +49 (9131) 7-35210
Fax: +49 (9131) 7-31537
Mobile: +49 (171) 2296136
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.
Ich bin bis einschließlich 17.04.09 nicht im Hause. E-Mails werden nicht bearbeitet oder weitergeleitet. In dringenden Angelegenheiten wenden Sie sich bitte an meinen Kollegen Herrn Venker. Email: firstname.lastname@example.org Telefon: +49 2572 927 0. Über unsere Telefonzentrale werden Sie an Herrn Venker weitergeleitet.
Mit freundlichen Grüßen,
Schmitz-Werke GmbH + Co. KG
48282 Emsdetten - Germany
fon: +49 (0) 2572 927-198
fax: +49 (0) 2572 927-9198
KG, Sitz Emsdetten, Amtsgericht Steinfurt HRA 3133
Komplementärin: C.H. Schmitz Beteiligungsges. mbH
Sitz Emsdetten, Amtsgericht Steinfurt HRB 3612
Geschäftsführer: Justus Schmitz
Diese E-Mail ist revisionssicher archiviert.
This e-mail is legal audit proof archived.
I am not sure if this will help or not. The attached pics are how I have my windows NFS share and SFU set. One thing I remember that messed me up was that I had to give the logged in user full rights to the folder that I have set as the NFS share.
I am still using it just as I have originally set it up as, to be honest I have not touched it since. Though I am planning to try[ Veeam Backup|http://www.veeam.com/vmware-esx-backup.html] as it is now ESXi capable.
I had my SFU and NFS set up the same. But your mention of giving the logged in user full rights got me to thinking.
I had mapped the Unix root account to my domain account which is the account that I am logged in with and is a local admin. It was the "local" admin that got me to thinking so I added a mapping of the root account to my local account on the WSFU machine, and even though I am still logged in with my domain account I can now establish the NFS storage. Seems a bit backwards to me but it works.
Thanks for your help. Now I get to try the script.
I'm using the backup script on a esxi server. Yesterday we had a complete server crash. Now i noticed that the script made backups, but that i downloaded a ful flat file and 5 snapshot files of 1 kb. This is the case for all backups.
Is there any way to recover the data, i opened the file with vmware workstation, and it only shows me the orinigal state of the server;, and not the uptodate version
Wasn't there some delta files? Each snap creates a delta file and xxxxxxx_0000# numbered file...I cant remember the exact naming format...but there should be more than 1 kb.
Chief Information Officer
Lexington Memorial Hospital
There are idd snapshot files in the backup, but they are only 1 kb and the originals where 5 to 100 GB. It also seems that the snapshots are always 1 tot 5 and never more than that. Altough i notice that in the datastore that snapshops where going from 1 tot 13.
False, my ghettoVCB.sh will continue to work because it does not rely on the VI API, it's using the unsupported SSH console to initiate it's backups. Let me know if you run into any issues
IMHO it's a bad move to go to ESXi 3.5u4 if you heavily rely on automating configuration or backup process using the RCLI/VI Perl Toolkit/Powershell binding to the VI API, I would probably stay on U3 if you're quite happy with the full r/w access to the VI API.
VMware vExpert 2009