Hi guys,

I have recently inherited a site with roughly 150 VM's, ESXi 4.1 on Dell Equalogic storage and CommVault 9 SP2b.

Nearly all the VM's are being backed up using the File System iDataAgent, which is obviously not ideal.

I want to migrate the environment so all the VM's are being backed up at the VMFS level so I can take advantage of the benifits this brings.

Can someone advise on where I should start with this process, documents I should be reading and any gotcha's to be aware of?

Doug.

Doug,

Here are some links to get you started. Also please make sure you are at the latest Service pack (SP4).

Using Disk level will provide you with the best protection as you can restore via file level and disk level.

Overview - Virtual Server iDataAgent:

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/prod_info/virtual_server.htm

Quick Start - Virtual Server iDataAgent:

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/prod_info/virtual_server/quick_start_vmware.htm 

System Requirements - Virtual Server iDataAgent:

http://documentatiocommvaultn..com/commvault/release_9_0_0/books_online_1/english_us/system_requirements/vs_vmware.htm

Backup - Virtual Server:

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/backup/vs_vmware_basic.htm

Restore - Virtual Server iDataAgent

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/restore/vs_vmware_basic.htm 

Thanks Willie.

As I slowly change each of my 140 odd VMs from 'File System' to 'Virtual Server' iData agents, is my de-dupe database going to remain valid across both backup methods, or am I going to have a rather large increase in data during the transition period?

How will that work?

From my experience, data usually doesn't dedupe very well between agents. I wouldn't be surprised to see an increase of your DDB and the space used by your backups until your FS agent backups age off.

Phil

DougJnr:

Thanks Willie.

As I slowly change each of my 140 odd VMs from 'File System' to 'Virtual Server' iData agents, is my de-dupe database going to remain valid across both backup methods, or am I going to have a rather large increase in data during the transition period?

How will that work?

No the VSA uses block level so we will need to populate the DDB with this new data from the VSA.

Thanks guys.

I am doing the System Admin 3 day course next week so I can hopefully progress my skill set a lot more beyond that.

Another question....SnapProtect and my Dell Equalogic. Do I want to be using that tech?

Doug.

We use snapProtect as a spool copy. I find that VMWare reacts much better to the backups using SP than without it. When there is too much I/O, VMWare snapshots get left behind. This is a VMWare bug, not CV bug. At least, it doesn't have any impact on the backup job, just annoying.

Using SnapProtect, I never had this issue. I then copy from the SAN snapshot to my primary storage. If you want/can keep some SAN snapshots for a couple days, it can really speed up the whole recovery process too and if you don't require to copy your data from the SAN snapshot to your primary storage on a day to day basis, it will greatly speed up the backup process as well.

Phil

Is the term 'snapshot' the traditional VM snapshot I take using the vSphere client?

Are they always, one and the same?

The VMWare bug I am referring to is the VM (vSphere) snapshot yes. Under high I/O, it can fail to be removed leaving a snapshot named "Consolidated 0" in place which you will either need to delete manually or wait for Commvault to delete it eventually. Because of the VMWare bug, they implemented a "snapshot retention" which will auto delete snapshots that failed to be deleted after 24 or 48 hours, can't remember the exact delay.

During backup (with our without SnapProtect), a VM snapshot is created for each VM with a name "GX_Backup". This is the same for all VMs.

Phil

PhilippeMorin:

The VMWare bug I am referring to is the VM (vSphere) snapshot yes. Under high I/O, it can fail to be removed leaving a snapshot named "Consolidated 0" in place which you will either need to delete manually or wait for Commvault to delete it eventually. Because of the VMWare bug, they implemented a "snapshot retention" which will auto delete snapshots that failed to be deleted after 24 or 48 hours, can't remember the exact delay.

During backup (with our without SnapProtect), a VM snapshot is created for each VM with a name "GX_Backup". This is the same for all VMs.

Phil

@PhilippeMorin - One thing worth mentioining is that this will typically happen when you use a VM to install the Virtual Server agent. If you are installing on a physical box then it is less likely to happen.

DougJnr:

Thanks guys.

I am doing the System Admin 3 day course next week so I can hopefully progress my skill set a lot more beyond that.

Another question....SnapProtect and my Dell Equalogic. Do I want to be using that tech?

Doug.

@DougJnr - If you have the ability to use the hardware snapshot (Snap Protect) then I would recommend it as you can run your backup copies at any time and not affect your production environment. We do support the Equal Logic arrays for Snap Protect.

Here is a link to get you started with it if you are interested.

Getting Started - VMware Deployment

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/prod_info/snap_vmware.htm

SnapProtect^™ Backup - Dell EqualLogic

http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/snap_backup/vs_vmware/dell_equallogic.htm

Willie_F:

@PhilippeMorin - One thing worth mentioining is that this will typically happen when you use a VM to install the Virtual Server agent. If you are installing on a physical box then it is less likely to happen.

I don't know how more often this would happen using a virtualized VSA but we had some minor issues the other day with our SAN which forced us to revert back to "standard" backups for a week.

During that time, we had a couple of "Consolidated 0" snapshots left behind each day. Our VSA is a physical Win2k8 2*quad core with 16gb of RAM and dedicated storage. This could have been caused by the SAN issues which didn't help VMWare though...

Using a VM as the VSA the default transport mode is going to be HOTADD as long as the VSA can see the storage.

VMware has a known issue (documented in their release notes of the VDDK) Where HOTADDed disks may not clean up correctly.

This causes the snapshot when getting released to have an error and fail to remove the snapshot with the file is locked.