VMware Cloud Community
hbowlin
Contributor
Contributor

Using VMware Data Recovery with Exchange 2007

I have an SBS 2008 VM with Exchange 2007 SP1 up and running. I have been backing it up with the data recovery appliance for about 5 days, but the Exchange logs don't seem to be getting truncated. VDR supports VSS so why aren't the logs getting truncated and why doesn't Exchange know its getting backed up?

0 Kudos
4 Replies
Rumple
Virtuoso
Virtuoso

Because you are only doing an operating system backup (think of Ghost images), not an applicaiton level backup. Until you have something that uses the exchange API to truncate the logs and complete the backup, then you are not backing up exchange in a supported fashion (according to Microsoft).

You need backup exec or another tool (or wait until Exchange 2007 SP2 when Windows Backup can start providing the exchange backup functionality like NTBackup used to.)

KBuchanan
Enthusiast
Enthusiast

You better take good advice - and read the other post regarding problems with VDR. I would NOT advice relying solely on VDR as a backup solution - at least until it has been through better testing and QA (from VWware and the customers).

There are numerous posts here in the community (including several of mine) that give good reason why VDR isn't stable yet. Trust me - I have spent hours and hours trying to get it to work. Oh sure - it will work fine for 4-5 days...then, jobs locks up, fail to run, or integrity checks fail.

VDR promises a LOT and I am VERY anxoius to see it work reliably. But until then, you should treat this for what it is: a v1.0 product. It needs to prove itself, and so far, it has only proven that it needs some improvement. The good news, is that I have spoken with the VDR product manager - and they are listening to us in the community forum (albeit, they as a Monday-morning quarterback).

But in regards to your question: The previous poster is right. VDR is completely agnostic of the OS and applications that are running within the Guest. VDR just takes a snapshot of the guest. It does NOT quiesce the datastores (such as SQL or Exchange)...neither does it clear the log files.

I suggest that if you schedule a NT backup job to do a backup of Exchange and then schedule a guest image backup to occur after the NT backup job has had enough time to complete. This will truncate your log files.

hbowlin
Contributor
Contributor

Thanks for the information. That is VERY helpful. I will do some more research on VDR before i make a final call on the strategy, but it looks as though I will be using agent-enabled backups in the short term.

0 Kudos
KBuchanan
Enthusiast
Enthusiast

Do you have the licensed version of ESX?

I use the following script to create guest image backups that is stored on a NFS share (hosted by Openfiler). There are numerous examples of backup scripts available. I have "future plans" to use VDR when it is stable; until then, we will do agent based backups and image-based backups for DR.

date +%a" "%x" "%X

for VMXFILE in $(/usr/bin/vmware-cmd -l)

do

FLDRNAME=`dirname $VMXFILE`;

VMXCFG=`basename $VMXFILE`;

GUESTNAME=`basename $VMXFILE .vmx`

BKUPDIR=/vmfs/volumes/ESXDataRecStore/$GUESTNAME

http:// -d $BKUPDIR.1 || ( mkdir $BKUPDIR.1 && touch $BKUPDIR.1/emptydir.txt; )

http:// -d $BKUPDIR.2 || ( mkdir $BKUPDIR.2 && touch $BKUPDIR.2/emptydir.txt; )

rm -f $BKUPDIR.2/*

mv $BKUPDIR.1/* $BKUPDIR.2/

cp $VMXFILE $BKUPDIR.1

/usr/bin/vmware-cmd $VMXFILE createsnapshot BackupSnap BackupSnap 1 0;

for VMDKFILE in $(find $FLDRNAME -type f -name "$GUESTNAME.vmdk")

do

VMDKFILENAME=`basename $VMDKFILE`

/usr/sbin/vmkfstools -i $VMDKFILE -d thin $BKUPDIR.1/$VMDKFILENAME

done

for VMDKFILE in $(find $FLDRNAME -type f -name "$GUESTNAME"_"?.vmdk")

do

VMDKFILENAME=`basename $VMDKFILE`

/usr/sbin/vmkfstools -i $VMDKFILE -d thin $BKUPDIR.1/$VMDKFILENAME

done

/usr/bin/vmware-cmd $VMXFILE removesnapshots

done

date +%a" "%x" "%X

This email including any attachments is confidential, and may be privileged by law.

Statements and opinions expressed in this message may not represent those of

Lexington Memorial Hospital. If you are not the intended recipient, please notify the

sender, and remove this message from your inbox.

0 Kudos