TeraByte Unlimited

I'm running IFW 2.83 under Windows Server 2012. The server has Exchange 2013 installed.

My command is:

"C:\Program Files (x86)\TeraByte Unlimited\Image for Windows\V2\imagew64.exe" /usevss /b /uy /um /d:0 /f:"B:\Backup-w0-$~YYYY$-$~MM$-$~DD$-$~HHMM$" /purge:-2 /email:"smtp.isp.com*[email protected]*[email protected]*Success][FAIL*25" /vb

VSS fails, and IFW switches to PHYLock. I really want to use VSS!

In the Application Event Log, I get the following:

Info 2021, MSExchange Repl: "The Microsoft Exchange VSS Writer has successfully collected the metadata document in preparation for backup."

Error 2024, MSExchangeRepl: "The Microsoft Exchange Replication service VSS Writer (Instance 5411d83d-2f5a-497e-9420-cb4ae6c3c518) failed with error 0 when preparing for a backup."

Info 2005, ESENT: "lsass (780) Shadow copy instance 2 starting. This will be a Full shadow copy."

Error 2044, MSExchangeRepl: "The Microsoft Exchange Replication service VSS Writer (Instance 5411d83d-2f5a-497e-9420-cb4ae6c3c518) failed with error 80070015 when checking volume dependencies in preparation for backup."

Error 2026, MSExchangeRepl: "The Microsoft Exchange Replication service VSS Writer (Instance 5411d83d-2f5a-497e-9420-cb4ae6c3c518) failed with error 80070015 when preparing for snapshot."

Error 2026, MSExchangeRepl: "The Microsoft Exchange Replication service VSS Writer (Instance 5411d83d-2f5a-497e-9420-cb4ae6c3c518) failed with error 80070015 when preparing for snapshot." (yes, this error appears twice)

..and various other events after that.

I'm guess that the Error 2044 is the significant one. The volume I'm backing up has two partitions. The Exchange Server logs are on the first partition, and the main database files on the second one. But I'm specifying the whole drive for backup, so I'm surprised to see the error that it has a problem with "volume dependencies" - although maybe I'm misunderstanding the meaning of the error.

Can anyone shed some light on this, please?

I found this, which suggests that moving the Exchange logs to the same partition as the database would help:

http://social.technet.microsoft.com/For ... change2010


So I did it like this:

http://careexchange.in/how-to-move-data ... ange-2013/


...and the process was successful. The Exchange database and logs are now on the same partition. No change for Image for Windows - seems to fail in just the same way.

i may be wrong, but i doubt this is specific to IfW. I have found that generally third-party utils that try to use VSS fail miserably on databases with even moderately-high I/O. My company has a bunch of virtualized Exchange (~1600 users) and SQL Server instances, and trying to back them up using programs meant for VMs that either call the VMware Tools VSS writer or have their own VSS writer (e.g., vRanger's for Win2K8+) never works. We've had Exchange virtualized for 6-7 years and always had to back it up separately. We use NetBackup on all these high-I/O databases (Exchange/SQL) and vRanger for the rest.

just recently, I upgraded a pair of Win2K3 R2 vCenter servers to 2008 R2 so we could do in-place upgrades to vCloud 5.5. And I tried using IfW on those (SQL) before the upgrades and it never worked. Ultimately I booted with a IfL CD and took images to a NAS box.

btw, even if you get it working, i'd be wary. Just because something appears to back up successfully doesn't mean you have an actual good backup.

The only thing that matters in the end is if you end up with database-consistent restores. Active Directory boxes don't have a lot going on, but restoring a 'successful' VM backup of one taken with vRanger that uses the VMware Tools VSS writer will result in a corrupted AD database. So we use NetBackup for Active Directory VMs, as well.

Thanks 30075 (that's a very enigmatic name you have there!). I agree that it really looks like a problem with VSS rather than IFW - I just hoped that as IFW users are generally a pretty techy lot, somebody might have an easy solution!

The server in question is a single-server environment, and backup takes place out of hours, so there should be very little I/O going on. I - foolishly as it turns out - formatted the server's data partition with the new ReFS filesystem instead of NTFS, and that's causing all KINDS of compatibility problems with backup/imaging software. Even Microsoft's own Windows Server Backup can't create incrementals from an ReFS volume, it seems. I don't see any particularly clear link to the VSS problem above, but it wouldn't surprise me too much if it turned out to be related. I think I'm going to have to copy all the data off the data partition, reformat as NTFS, and copy all of the data back - in such a way as to preserve permissions and metadata in general. I've already started looking into how I might do this, and it seems that Microsoft's Robocopy utility doesn't support copying of security information from a non-NTFS volume. Sigh. XCopy does, but it's less good in other ways. Anyway, rant over! Thanks for your responses.