iSCSI for VCB, and Proxy Server Disk Space requirements

[dmorgan]

We have a situation where we are basically out of ports on our Fibre switch. We have room for 8 additional GBIC's, but with the cost of GBIC's, plus licensing on the swith to enable that bank, it would cost a good chunk of cash to go this route. We have plenty of bandwidth available using iSCSI, however. Per the VMWare documentation, it would seem that the proxy server must be Fibre connected to the SAN. I don't think our SAN allows iSCSI AND Fibre connections to the same LUN, so we need to be consistant. I can switch the ESX servers over to iSCSI from Fiber easy enough, but if we cannot mix iSCSI and Fibre mappings to the same LUN, then I need to know if anyone has set up VCB over an iSCSI connection.

Also, I have been exploring options for tape backup software. I was poised to purchase NovaNet software from Novastor, but they don't offer any compatibility with VCB. I am currently using a trial version of ARCServe 11.5 to test the functionality of VCB. To anyone with VCB up and running, what kind of storage space is necessary on the Proxy/Backup server. From my understanding, the VCBMounter.exe is used to mount the SAN, and the pre and post scripts handle the snapshot of the virtual host being backed up. From my readings, there is temporary storage space necessary on the proxy/backup server. I am concerned that the server we are using doesn't have enough disk space to handle this swap. I would reason that you would need to have at bare minimum at least the amount of free space required to store your largest host VM, but this is just my assumption.

Thanks in advance for any help!

[cmanucy · Accepted solution]

1) Yes VCB works with iSCSI - we're doing that now and it is a supported configuration.

2) Yes the VCB server needs the 'free space' for the mounted VMDK. We have ours configured with about 3TB of cheap SATA storage which acts as a staging area. We also have a cheap iSCSI array (Promise SATA box) for storage of backups. All of these are committed to tape eventually.

3) We use a combination of vRanger, EsXpress and Veritas BackupExec (or is that Symmantec now?) for backups. BE handles all of the tapes and rotations, etc.

You should be able to throw a cheap SATA RAID controller and a bunch of 750GB-1TB drives on it - heck, even a couple big SATA drives would be good enough for some situations.

[dmorgan]

First off, thank you for the prompt reply. Secondly, I was just looking at vRanger and EsXpress. Can you tell me why you would want to use these in addition to a backup solution that integrates with VCB already? I am in the middle of putting together a proposal for the purchase of all of our backup needs. Any information as to the benefits of using these other software packages and what functionalities they provide that doesn't exist in backupexec would be helpful.

[patrickds]

Never tried it with Arcserve, but I do have some experience using VCB with Backup Exec.

The space required depends on the type of backup you want to take (i assume you have the same options with Arcserve as with BE, since it's the VCB framework doing the real work)

The pre and post scripts call the different scripts and programs required to create, mount (or export) and delete the snapshots.

If you want a file level backup of you VM, no space is used on the VCB proxy, the snapshot is mounted under the mountpoint.

For a FullVM image of a VM, all files that are needed to restore a VM to its state at the time of the backup (VMDKs, VMX,...) will be exported to the VCB proxy, in the chosen mountdirectory; so this will require at least the diskspace to contain the largest of the VMs you want to backup in this manner.

Since the VMDK will be converted to thin format, you will only need space for the actually used diskspace of your VM, not the entire VMDKs.

Patrick

[petedr]

Hey dmorgan,

I work for the company that makes esXpress so I figured I would give a brief description of it. First off we don't integrate with VCB, esXpress is an alternative to using VCB. You don't need a proxy server, instead we use the power of your existing hosts to run the backups. Our backups run in the virtual space using a VBA ( Virtual Backup Appliance ). Depending on the resources available on your host you can run multiple VBAs (basically tiny virtual machines) at one time to scale the amount of backups that can run.

esXpress can create Full Image backups or we do Delta Image Backups, we also offer File Level Backups, standard compression routines are used ( gzip and lzop ) for backup archives. EsXpress can send the backups to network targets ( ftp/ssh/smb ) or to a vmfs ( local or on a SAN/iSCSI ). Other features include, encrypted backups, template backups, backing up machines with existing snapshots, archice management etc.

One thing I always recommend is to try a couple of different solutions for your backup needs to determine what works best for your environment.

Thanks,

Pete@esxpress

[cmanucy]

Yeah... I second the comment about 'try before you buy' For us, we needed both Deltas and Fulls... and since vRanger was dragging their feet with delta support, we jumped on esXpress. So we use both, and are quite happy with both - each of them has their strenghts.

As for why not use BE or whatever... well, if you ever saw how BE 'supports' VCB (you write your own scripts), it wasn't exactly something we were willing to take on. We're streched pretty thin with IT staff as it is, and if 'the guy' who knows VCB scripting is out, you can have a hell of a mess on your hands. So we went with the KISS principal and stuck with the more GUI-based VCB/backup software.

Also, restoring VMs is another problem all-to-gether. If you've got the backed up files under BackupExec, it's a lot more awkward to work with than being able to restore a full VM. On the other hand, there are some VM's (like file servers) where you WANT flie-level restore capability... which puts both esXpress and vRanger at a disadvantage. So for a lot of our larger MS-based datastores (like our friggin' huge file server), we mount the volume (via iSCSI) from a snappeshotted session (from the SAN) and back it up that way - to BackupExec, it looks like another drive.

We try and leverage the best of each so we can get to what we need as soon as we can. This doesn't always amount to a perfect solution, however... our backup system is quite complex, despite our attempts to KISS.

And ohj, VCB is still in its infancy... things will be getting better, I'm sure!

[dmorgan]

Thanks for the information. I have tried to download the 3.x software, but the personal download page simply had a button to apply... That is what I thought i did initially. How does one get to the actual download so I can evaluate this software?

Thanks,

Don

[petedr]

The registration had to be approved, which has been. You should get an email with the download link.

Good luck with your evaluations and backup solution regardless of what option you choose.

Pete@esxpress

[PortugueseTech]

Hi Guys,

I'm having some problems in restoring the performed backup (file level or fullvm)of VM machines to an alternate location. I'm using ArcServe12 as the backup tool.

According to documentation i can restore only file level backup to the original VM, and only if it is a windows machine,but for that to work i need to install an ArcServ 12 windows client inside the Virtual machine.

Fullvm or raw mode can be restored locally and then converted with VMWare converter, however i'm not able to restore the files to an alternate location.

I'm getting errors saying "skip session (VMWARE) not supported.

Can someone give me some guidance please?

regards

Francisco Batista