cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange back up failing, V-79-57344-759 with -4005 Read/write access is not supported on compressed files.

ekeeling
Level 3
Partner Accredited

I am having an issue with BEX 2010 R2 and exchange 2007.  I have combed over everything and there were no system changes between the point it was working and the point it started failing.

Backup destination was to a B2D netwrok target on a deduplicaiton appliance. One day the errors started.  I was getting ready to migrate the BEX server to 08R2 so that I could make use of the onboard deduplication feature which required a 64 bit OS so I allowed the error for a couple days.  After moving servers the error remianed.  We changed the B2D destination to a deduplication folder, the error remained.

Exchange logs are being backed up and truncated, datastores are not.

BEX is fully patched.

GRT is enabled as it is needed in our environment.

I have scanned both exchange and BEX for compressed folders and drives, there are none.

I have disabled "compression" for both hardware and software within the backup job.

The Exchange program directories on both servers are confirmed to have no compressed files.

The Backup job history is showing the data being backed up.

I have a support case open at this time but it appears that the assinged tech is unresponsive for a week now.

 

Error-

Backup- \\EXCHANGE_SERVER\Microsoft Information Store\First Storage Group
V-79-57344-759 - Unable to complete the operation for the selected resource using the specified options. The following error was returned when opening the Exchange Database file: '-4005 Read/write access is not supported on compressed files. '

7 REPLIES 7

ekeeling
Level 3
Partner Accredited

Last night I upgraded from BEX 2010 R2 to R3 and fully patched.  The exact same error is present. This leads me to believe that it may be something on the exchange server.

The problem is i know of no way to compress a live exchange database, and this is the file throwing the error.

newsolutionBE
Level 6

Hi

 

What happen if you run job to normal backup to disk folder does it work also it would be worth upgrading to BE 2010 r3 sp1 &  one recent hotfix released which have several issue resolved for exchange you can click on link below to upgrade to BE 2010 r3 sp1 & using live updates installed all updates to get the s/w patched up & then update remote agent on your exchange server & then try running backup job to see if that helps

 

https://www4.symantec.com/Vrt/offer?a_id=93355

 

Thanks

VJware
Level 6
Employee Accredited Certified

Is compression enabled on the target B2D folder ? if yes, uncheck the compression option & re-try the backup.

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

You may try running the B2D test tool to check the compatibility of the device for Exchange GRT backups,

http://www.symantec.com/docs/TECH69107

Also try running the non GRT job of Exchange to isolate the issue. Another thing you might want to check is the block size of disk on the exchange server and the block size of the disk being used for B2D.

Hope this helps.

ekeeling
Level 3
Partner Accredited

 

@newsolutionBE - already fully patched at most recent SP.

@VJware - Per my first post, nothing is compressed anywhere that I can find on either system. BEX does backup the databse, but fails out the backup as it can't read from it. I my experience a compressed exchange database is a broken exchange database.  I know of no way a running/live DB can be compressed.

@ Riyaj - yes the B2D is compatible, the backups were running as configured for several months.  I can honestly care less if the backup works without GRT, I have no use for this solution if I need to restore an entire database to retrieve a single email from a week ago there are better options for that.

 

 

The B2D folders have changed and the server has changed since this started.  We went from working to not working with no appearent changes to the system, the only consitant factor is exchange.  Change steps are as follows:

Working @ server 2003 R2 SP2, BEX 2010 R2, destination B2D via UNC path. Then suddenly stopped.

Step 1 Server 2008R2, BEX 2010 R2, destination B2D via UNC path.

Step 2 Server 2008R2, BEX 2010 R2 fully patched, destination B2D local dedupe folder.

Step 3 Server 2008R2, BEX 2010 R3 fully patched, destination B2D.

viny
Not applicable

I am sharing this information because it drove me crazy and I *think* it is solved. If it's solved, that's really tricky...

Okay, my environnement is the following:

1 exchange 2010 server with 3 roles: CAS, HUB, MB. We started our migration from 2003 to 2010 some months ago (this information sounds useless but there is an inpact).

1 backup server with BUE 2010 R3 and a dell auto loader (supposely, we do exchange-to-tape backups, using GRT).

At the beginning, everything was running fine with a few mailboxes: PST export were nicely done through the known script at stevie.org and our GRT backup to DISK (at that time) worked fine.

Then many mailboxes were migrated (from 1 to now 300 and still increasing), especially on the largest database, hosting 243 mailboxes for an amount of about 105 gigs. 

Suddenly, backups-to-tape shown this error "e00002F7 - Cannot extract mailbox messages from the Exchange backup" ONLY on the large database (the 4 others are really smaller, with so less mailboxes). We do have the really annoying "-4005 Read/write access is not supported on compressed files" .No, there is no compression on any database, and no antivirus installed.

My first feeling was that, maybe, the schedule was wrong and the PST export was interfering with the GRT backups (after all, that sounds logical). So I took a look at my exchange server and realized that my PST exports were screwed: only about 150 mailboxes were exported instead of my 300. So I changed the way my script was ran to choose every night (yeah, we did every night export :) ), to select every database rather than the whole server.

And guess what? My PST were back on the road and my backup-to-tape were successful again!

I decided to change the schedule of PST, to have it only once a week, but I was not very happy with the performance. After reading some bits and pieces on the World Wild Web, I came across an article stating to increase some values in the file c:\program files\microsoft\Exchange Server\V14\bin\MSExchangeMailboxReplication.exe.config

like this one: http://zahirshahblog.com/2011/03/24/how-to-increasing-simultaneously-number-of-mailbox-move-in-excha...

Well, that's really sweet, isn't it? So I decided to increase the value to have 50 mailboxes export at the same time. I restarted the MSExchangeMailboxReplication service, and after a short test, it worked, so I left it like that (5 different jobs with my 5 exchange DB, in sequential order). 

And guess what? My backup-to-tape got screwed again! Again, on the large database...

So I tried different things (Christmas holydays, I was wondering how to make myself occupy): backup-to-disk worked fine (???), backup-to-tape with VSS snapshot not. All other backup-to-tape (files or the 4 other exchange database) worked flawlessly. So I was wandering the internet without no info for my case until I realized that my PST export were AGAIN screwed also!

That was a clue. I realized that tuning the file mentionned above screwed the export (again the "cannot connect to the source mailbox" exchange error). So I tried to fix the problem and I realized that a client antivirus was installed on the server! Could it be the culprit for my backup issue... ?

Anyway, I recovered the original MsExchangeMailboxReplication.exe.config file and

1) PST export are alright (and MUCH faster withhout this antivirus)
2) My Exchange GRT backup-to-tapes are back working!

I will wait some days to see if it is solved, but it looks like there are interactions in all of these mecanisms.

Anyway, I strongly suggest you to test seriously the parameters in the MsExchangeMailboxReplication.exe.config (unlike me) as it seems very fussy AND backup exec seems to take into consideration, somewhere, the mailbox replication process

 

cheers

ekeeling
Level 3
Partner Accredited

Viny,

Thank you for your input. I however am not in the midst of an Exchange 2007 to 2010 migration or at Exchange 2010.  I have been able to get Exchange backups to disk working again to a UNC path but am still unable to get GRT backups to the local dedupe folder to succeed.