backup solution

[menora]

Hello to all ESX Guru,

I know I'm silly but I've got this prblem and question. I used to use USB external HDD for doing file backup on a windows server 2003 machine, however since we converted that machine into esx server vm, we can't use the usb device anymore (even though the vm has usb controller in the settings). Of course!! esx server doesn't support usb at this stage, but is there any work around or can anyone recommend other file-based backup option? we currently have around 300GB of user data.

Pat

[Santhosh_vmware]

Hi,

you can try openfiler from www.openfiler.com.

regards

santhosh

[Zleipner]

Hi there,

You're correct, ESX doesn't support USB media and I seriously doubt it ever will as it would "lock" a virtual machine to a physical machine and that's something that isn't really cool (can't VMotion it to another host for example).

My first suggestion would be to look into a different backup strategy, depending on other circumbstances of course. Maybe you could use VCB to mount the diskfile on another physical machine and backup the data to the USB from that machine? Or maybe just copy the files over the network to the USB disk on some other machine. 300Gb is a decent amount to move over a network but maybe not all of it is needed to be backed up every day?

It's hard to tell what I would do personally when there isn't more information though, is there a Fiberchannel network to a SAN where the diskfile(s) are located? If so, I'd say VCB is probably the best choice and then you could run any normal backup application (or just copy/paste) from the VCB machine to wherever you want to store the data.

Cheers!

Thomas

[Erik_Zandboer]

Indeed the simplest solution would be to use a physical host you have somewhere to copy the files over the network. You could even try to use something like . This allows you to connect an usb2.0 device to a VM using the network (so you would not require a physical host). I do not know how well these perform in regards to speed.

Totally revising your backup strategy would propably be best. You could take a look at a spearate host with a backup product (symantec backup exec for example) so that it takes care of your backup-to-disk (and then connect the USB disks to that backup host). That would be the cheapest way to revise the way you do backups I guess.

As you pay more, you get more. But that's a nobrainer off course.

[dconvery]

Your best bet is to use VCB. You could back up the files to the USB drive from the VCB proxy. In the mean time, set up a scheduled ntbackup job to back up to a network share somewhere so you at least have a backup.

Dave

[petedr]

Erik's suggestion of physical host may be the easiest approach. I do something similar to that in my home lab where I have an external usb drive attached to my laptop running FileZilla has my Windows ftp server. Any physical windows box would work as well. In my case I use my company's backup product esXpress for the backups (VM Image level) and send them to my Windows Laptop ( acting as my ftp server ).

Pete@esXpress

[Erik_Zandboer]

esXpress works great, and if you are happy with full-backups only (no differentials) you can use the free edition. That might be a good idea to use, install a (freeware) FTP server on the physical host and have esXpress upload the backups of your VMDKs to it. That way you can use the free esXpress for your "virtual system disks", and/or use simple filecopies (Symantec backup exec or even robocopy??) for your file level backups. Upside to Symantec would be, that if you decide to add a tapeunit to your environment later, you could use Symantec to backup from disk to tape, and thus even backup the vmdk backups from esXpress to tape!!

[menora]

Thank you all of your replies,

We are currently running esxpress as our image based backup solution, but we also need to run a file backup too. We tried to backup the data over the network last night and it took 14+ hours to ntbackup about 50% of the data (about 300gb in total). Practically this is not the best solution since the backup still running during the day. Today we are going to try it again with backing up less data, hopefully that can finish in the early morning.

If anyone else has any other idea, please let me know.

Thanks, Pat

[petedr]

Hey menora,

esXpress 3.1 now has file level backups. Its our initial release for file level but is esentially creating seperate backup archives of folders inside your VM. We take the File Level at the same time as the image backup. Our web site has more information or you can contact our sales group.

Just another possible idea.

Pete@esxpress

[menora]

Thanks Pete, i'll give it a try. Do you know roughly how much longer it will take to backup 300gb data?

[petedr]

I'll talk with our other engineers and any additional information we have I'll send you a private message

[Erik_Zandboer]

Hi, given the amount of data and the time needed, you have been copying at 150GB/14Hrs = 10,7 GB/Hr. That is about 2,97 Mbytes per second, which could possibly be improved. Are you using 100Mbit somewhere in the network path? Try and find the bottleneck, because even to a USB harddisk you should be able to do better I think.

I have done some testing on file level backups using esXpress, it works quite well but it always creates a full copy of the data. No diffs, no incs. Shame really, it makes FLB (File Level Backup) in esXpress less useable for these kind of backups.

I think copying 300GBytes every single night is a bit too much for a setup like this. I would definitely look at differential backups somehow. That way you could make a full copy of the data in the weekend (and consume a lot of time), and settle for differentials (or even incrementals) during the week. Even xcopy has a feature for this (/A for diffs, /M for incs), allthough robocopy might do better with large amounts of data (robocopy is a free to use tool from microsoft and the extended version of the embedded xcopy):

Robocopy is part the Microsoft Resource kit:

There is even a GUI for creating scripts (which you then can schedule):