How can I backup ESXi with GhettoVCB + FTP?

[IT_Architect]

Mission:

I want to use GhettoVCB and ftp together to do a hot backup and copy VMs to the opposite server so I could start the VMs on the other machine should there be a failure on the one where it is normally hosted. E.G. ftp or some fast method to copy them to the an opposite server's vmfs volume.

Resources:

Two ESXi servers, one running ESXi 3.5u3, and the other ESXi 4.0 with a gigabit connection on the private side. They have local SCSI arrays.

A Windows 2003 Standard R2 32 bit, w/Windows Services for NFS that I serve ISOs from and serves as a repository for common software. I plan to use this for scheduling. There is not enough room on the NFS volume for backups would it have satisfactory performance.

Situation:

It appears the pieces exist on this forum, such as GhettoVCB, oem.tgz?, and wput?, but I don't really understand what they exactly do, how to install them, and what happens to them if ESXi ever needs to be rebooted. I'm under the impression that the oem.tgz file is what makes it possible for custom settings to survive a reboot. I'm guessing there are lots of oem.tgz files, depending on what you need, and they might be ESXi version-specific depending on what they contain. I don't understand what wput does other than perhaps fix some of the shortcomings of busybox software. The only sure thing I know is that GhettoVCB is one piece that I need.

Questions:

1. Where is the best place to get GhettoVCB?

2. Where is the best place to learn about GhettoVCB, the blog, theworldrunsontechnology?

3. What do I need to install for ftp to work in both send and receive, and where do I get them?

4. How would you implement a solution like this?

Thanks in advance for your help!

[DSTAVERT]

Ghetto is available here

FTP oem.tgz etc is available here

As a personal preference I see little value in copying VM between servers for DR. The process of constantly copying files back and forth between servers puts extra stress on a very little OS. The disks see double the load. Why not either add disk space to the NFS server or add an additional NFS server. NFS shares can be mounted by both servers simultaneously .

[IT_Architect]

I see a key item missing from what I wrote. Both machines have not only the SCSI array, but also a single high capacity SATA. My logic is this. If I lost a machine, I could startup the backup VMs stored on the SATA of the opposite machine to fill in. If I lost a local SATA, nothing would happen. I would simply need to replace the local SATA, and in a day or so it would be back where it was. The only other thing I have available is iSCSI. iSCSI would increase ESXi load vs. local drives, there would be more latency, and the cost of the iSCSI plus a backup solution would cost as much as another server.

The process of constantly copying files back and forth between servers puts extra stress on a very little OS.

It won't be happening constantly. I'm thinking more along the lines of off-hours backups of VMs and OS backups.

Why not either add disk space to the NFS server or add an additional NFS server. NFS shares can be mounted by both servers simultaneously

The NFS server is a VM itself on one of the servers. I would need to put one on each server. Judging from what I've read concerning NFS performance on a VM, I would think that being able to use vmfs directly via ftp on the opposite server would be way faster than going through an NFS VM, save disk space, allow more flexible use of the disk space, and reduce the load on ESXi.

What are your thoughts about this logic?

Thanks tons for responding so rapidly!

PS: The link for FTP oem.tgz doesn't work.

[K-MaC]

Hello. The link for the FTP oem.tgz is http://www.vm-help.com/esx/esx3i/customize_oem_tgz.php

Cheers

Kevin

[IT_Architect]

Thanks, I found it. I was looking at that site before, but the way it's laid out there it looks like the ftp link is a link to tell you what ftp is, but not so, it goes to the file.

I'm guessing the instructions there are not applicable. Based on the internal structure of the file, it appears simply need to copy it to root, and uncompress it. I'm guessing the outside is gzip and the inside is tar even though it is named .out.