A recent client issue was the failure of Exchange Granular backups to a backup to disc (B2D) location using the latest Backup Exec 2010 R2 plus hotfixes and updates. On the surface it seemed quite strange. Tape based versions of the same backup job worked. For readers not familiar the GRT option is simply to allow individual mailboxes or contents thereof to be restored rather than the whole store.
The error reported was “-4005 Read/Write access is not supported on compressed files”. The assumption was that it was an issue with the target which was an Iomega NAS and that some form of compression was in use. Switching to an alternative disk location – a share within a SAN based VM gave the same error. Finally a backup to locally attached USB storage giving the same error suggested something odd about the media server.
Working with Symantec – we systematic tested the backups and grabbed debug logs that backed up the issue being about compression. We checked the target and Exchange server for any trace of compression. Finally when the issue was escalated we looked specifically at the temporary folders on the exchange Virtual machine (C:temp and c:windowstemp) to check if these were compressed locations. Nothing there.
Then we checked the media server – the machine with the tape drive attached. C:windowstemp not compressed but ….. the c:temp was compressed !!! The 2nd level specialist then mentioned that at the end of the job (where the failure happens) that there is a process to check the job and update the catalogs in Backup Exec and that for a backup to disk job – the c:temp folder was used to hold working files.
A check of the properties of the b2d folder used as the target for the job also revealed some changes in terms of the configuration. Recommendations were that the advanced properties should be changed from automatic to having buffered reads and buffered writes selected. The maximum size of the backup files created on the target was also discussed and a limit of 20GB agreed as issues with higher sizes is known about.
A retest of the job with compression removed on the media server c:temp folder and the changes to the B2D folder succeeded. So the solution is – find the source of the compression error and remove and configure the b2d properties to match the infrastructure i.e if the b2d folder is not local to the media server.