Disaster Recovery with VCB

[vmproteau]

• Netbackup 6.51a

• ESX 3.0.2 Update 1

• Virtual Center 2.0.2 Update 1

• VCB 1.0.3 Update 1

We're in the begining stages of a VCB evaluation and I want to understand the options for disaster recovery. We have done successful full VM and file level backups.

Is there way to do disaster recovery on a Windows server (2003 in this case) that has only file level backups with VCB? I'm sizing my proxy and I need to decide how much space I'm goign to need. If I don't have to backup the full VMDK on every server for DR purposes, I could probably get by with less.

Also, Would it be possible to configure a VMDK backup for only the OS (C:) VMDK but, for the remaining VMDKs (D:, E:, etc.) schedule only file level backups. For instance we have a file server VM with a 20GB OS volume and a 2TB 😧 volume. I was thinking DR in this case would consist of a OS VMDK restore, then creating a 2TB additional VMDK and running a file restore onto it.

[dmorgan]

If the server you are referring to, the one with the 20GB OS partition and 2TB data partition is just a file server, then yes, your fullvm backup of the root drive and file level restore of the data drive should work fine. So far as you question regarding the recovery process from a file level backup: Essentially, you would have to re-install your OS first, then any applications. After the system is back and running, you would have to overlay your file level backup on top of this new install.

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[vmproteau]

You qualified thsi with "just a file server". What server role would this not be advisable to use this method on a Windows 2003 VM. I assume you are talking about SQL, Exchange or others that rely on transaction logs?

[dmorgan · Accepted solution]

Exactly. If this were a SQL server lets say, you could do a fullvm of all of the drives, however what you would end up with is just a crash consistent copy of the database, which is typically less than ideal. However, for a DR scenario this may or may not be OK for you. Best case Scenario, you want to be able to back up the database while it is in backup mode, so there is no loss of data.

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[vmproteau]

Two last hypotheticals:

Sticking with the SQL scenerio, should SQL, transaction logs, and database files be installed on seperate VMDK volumes (no the OS root VMDK), would you expect the original restore method to be valid in this case?

Lastly, if instead of wanting a point in time DR of an SQL VM, we just wanted the VM back up and were willing to just bring up the latest SQL dump backup. In this case, could a VMDK restore of the root OS VMDK and a restore the most recent SQL dump file to a seperate volume on a seperate VMDK also work. I'm assuming the SQL application, expecting to see the original DB would have to be flushed or cleaned at first boot, but then we could restore from the dump and be on our way?