VDR quiesced snapshot question

[apohlgeers]

From VDR's admin guide (page 8)...

-

---

For virtual machines created in vSphere 4.0, the Data Recovery appliance creates a quiesced snapshot of the virtual machine during the backup. The backups use the changed block tracking functionality on the ESX hosts. For each virtual disk being backed up, it checks for a prior backup of the virtual disk. It uses the change-tracking functionality on ESX hosts to obtain the changes since the last backup. The deduplicated store creates a virtual full backup based on the last backup image and applies the changes to it.

NOTE These optimizations do not apply to virtual machines created with VMware products prior to vSphere 4.0. For example, change tokens are not used with virtual machines created with Virtual Infrastructure 3.5 or earlier. As a result, virtual machines created with earlier VMware versions take longer to back up.

-

---

I have questions about this statement. It sounds like quiesced snapshot doesn't work in vm's that where created on 3.5 or earlier right? So what about VM's that are created on 3.5 then moved to 4.0 and updated (I.e. vm tools and hardware)?

If this is the case then how does VDR save the non-quiesced snapshots? Does it not check for changes in the snapshot thus the backup is larger (and subsequently longer to backup?) and if that's the case how would you go about fixing each VM to be able to create quiesced snapshots? Do you create a VM in 4.0 and have it be a "fresh install" of the OS or can you use a program to image the drives and restore the data to a 4.0 VM or can you bring over the virtual drives to a new vm?

[RParker]

> I have questions about this statement. It sounds like quiesced snapshot doesn't work in vm's that where created on 3.5 or earlier right

Not that I have seen, it works fine, what DOESN'T appear to be working is Windows 2008 (R2 or NOT). Those don't quiesce the snapshot properly, others ALL work fine. Whether they were created previous to ESX 4.0 or not. Besides you can't create a snapshot then create it again, it's either done as ESX 3.5 or not, but maybe you create 3.5 THEN RESTORE under ESX 4.0, that's a different story, but that doesn't appear to have issue either.

Also keep in mind what that statement is referring to is the VM Version which CAN be updated to Version 7 (ESX 4.0). so you can convert your VM's to be compliant with ESX 4.0.

If this is the case then how does VDR save the non-quiesced snapshots?

It doesn't it ALWAYS creates a quiesced snapshot, it creates a NEW shapshot at the time of a backup at any rate, previous snapshots are retained.

Also it doesn't save the state of ALL the snapshots, ONLY the current version of the VM. So VM-A has 2 snapshots. Whichever snapshot is the CURRENT state is the backup that is created. snapshots are there but they are NOT backed up. Same with any backup producut, they don't save ALL the snapshot states.

[Innuendo]

Just to let me know : how are you supposed to work with this quiesced snapshot when you try to backup a windows 2000 server VM ?

VSS doesn't exist on Windows 2000 and quiesced snapshots will freeze to hell a poor I/O demanding VM so a huge one will just plain fail...

vDR lacks MANY features, like the ability to launche some script or dunno what before this snapshot, vDR is just useless for this kind of VM nowadays.

Works perfectly with VSS btw...

[admin]

What the statement is talking about is change block tracking - and not about quiesced snapshots.

1) VDR performs a full backup for backup #1 of any VM. Any subsequent backup (#2 and later) is an incremental backup

2) For HW7 VMs running on vSphere 4.0 , the incremental backup is calculated using the change block tracking functionality that is native to vSphere 4 and HW 7 VMs. Since this change block is list is "presented" to VDR, the backup time is decreased since there is no need to scan the disk.

3) For HW4 VMs running on vSphere 4.0, the incremental backup is calculated by VDR scanning the VMDKs everytime an incremental backup is performed. The increase time for backup is a result of having to scan the disk to find the change blocks.

4) VDR supports backing up both HW4 and HW7 VMs. The difference would be how the incremental backup is calculated.

5) If you upgrade a VM from HW4 to HW7, then the upgraded VM will now have its incremental backup calculated using the change block tracking functionality

[admin]

VDR can protect any VM that can be snapshot - quiesced or not. The difference is on the restore side, especially around granular restore of application specific files.

There are few ways to get quiesced snapshots

1) For supported Windows VMs, VSS support in VMware tools provides a framework that any backup product (inclulding VDR) to use the Microsoft recommended method to quiese Windows machines.

2) For all other VMs, you can use pre/freeze and post/thaw scripts - obviously, this is not provided by VMware. However, if these scripts exist. then VDR can take advantage of them.

[Innuendo]

I wasn't dealing with block tracking, I know how it works, I'm vcp 410 too after all

I was just stating that backuping non VSS able VMs isn't that easy, especially when this VM is very I/O intensive, since snapshot will put the VM in complete freeze.

Now, I heard about those pre freeze script but I don't know how they work, if you have a link, that may interest me. Will look deeper when time permits btw.

Regards.

[jjahns]

Yes, we use it to backup a high I/O SQL 2000 VM that averages around 30,000 KBps on the performance charts. We use pre-freeze and post-thaw scripts to do the job. In fact, we run a SQL backup job in the pre-freeze script.

The success of this was not what we expected. We expected a large amount of problems, so obviously we were pleasantly surprised.

[Innuendo]

how do you use those pre and post freeze scripts ?

Any link for documentation ? (sorry, have to search I know but for the moment, I am under heavy load of work)

[jjahns]

My pre-freeze script performs a full backup of all databases on the SQL 2000 server. After all of that has finished (these are big databases - 20+ GB each), I have 2 different scripts I have been experimenting with. The first pauses the MSSQLSERVER service. The second stops the service along with any other dependent services. It doesn't really matter what I do, since I just need I/O to freeze for a moment. This does the job. The post-thaw is handled in similar fashion. Issue a net continue or a net start for all the services.

As for the documentation, refer to the ESX docs about LUN sizing and the VDR documentation for the destination sizes.

Link for ESX: http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esx40_u1_vc40_u1.html

I don't know the specific doc anymore, its been a while.

Link for VDR: http://www.vmware.com/support/pubs/vdr_pubs.html