Unable to backup Exchange 2010 with BackupExec 2015
Hi Everyone, We're running into a pretty major issue after an upgrade to BackupExec 2015 and we're pretty much at our wits end and hoping for a solution. We were successfully using BackupExec 2010 to backup our Exchange 2010 configuration to tape. We were sold BackupExec 2015 and we've been attempting to implement it to simplify our backup configuration. We built a new server and then started running our backups to BackupExec 2015. We have not been able to successfully backup our Exchange configuration since then and we're getting very frustrated. We've had a ticket open with Symantec for weeks and the agents haven't been able to provide a resolution. They just had us run a debug and came back to us that our network drivers need to be updated. I checked the network drivers on both servers and they're both running the newest available driver. And again, we didn't have an issue with BackupExec 2010. Here is what happens: We have 3 datastores. One about 900GBs, one about 400GBs, and a new one that I created as part of this troubleshooting that's about 45GBs. We've attempted to run a full backup against all three datastores and in every instance it fails at the "Consistency Check" phase for all three databases. The error that we get is: Job Completion Status Job ended: Tuesday, June 30, 2015 at 7:05:23 AM Completed status: Failed Final error: 0xe000ff12 - A communications failure has occurred with an Exchange Store resource. Final error category: Resource Errors For additional information regarding this error refer to link V-79-57344-65298 Errors GRT backup set folder: \\.pdvfs\SERVERNAME\2\BEData\IMG000009 The consistency check of the snapshot for the Microsoft Exchange database Database was successful. V-79-57344-65298 - The Exchange Store service is not responding. Backup set canceled. V-79-57344-65072 - An error occurred while connecting to the Backup Exec Remote Agent on the Backup Exec server. Ensure that the job options are correct, and then submit the job again. The backup set was not created. So it backs up all of the data, passes the consistency check, and then fails on the step right after that, clears all of the data off. This issue has literally been going on for weeks. Our Exchange setup is running on older hardware and I'm getting very nervous about this issue. We've attempted disabling GRT. We've tried disk storage, deduplication disk storage, virtual tape storage, etc. We're successfully backing up Oracle, SQL server, and flat files to this new BackupExec server without issues. Any help would be GREATLY appreciated.
Disk-to-tape backup taking progressively longer for single job
Have a about a dozen various backup jobs and they all follow the same pattern, backup to a deduplication disk, then later the job is duplicated out to tape. This has been working fairly well but I've noticed an issue over the past 2+ weeks for a single job. This job backs up our Exchange databases to the dedupe disk, then later out to tape. The disk-to-disk portion has stayed consistent, 250GB transferred at 2500MB/min on average. The disk-to-tape part is where it has gotten out of whack. It started out taking an hour and a half to two hours to copy, but has gradually gotten longer and longer until now it is reporting over 6 hours to do the same amount of data. We haven't changed anything since this job was created, same dedupe disk, same tape library, same type of tapes, same encryption, etc. This is the only job that is doing this, all the others are running just fine in a fairly consistent time frame. Any ideas?
Exchange Backup Failure
We have a Backup Exec 2012 server (Version 14.0 Rev 1798) that every few days will fail on the exchange backup with the following error: Error category : Resource Errors Error : e000846b - The resource could not be backed up because an error occurred while connecting to the Agent for Windows. The correct version of the Agent for Windows must be running on the target computer. For additional information regarding this error refer to link V-79-57344-33899 this never happens near the beginning, always near the end of the backup. I made sure everything was updated, updated the agent on the Exchange server and even broke the job apart from the verify just to make sure that was not the reason for the failure.
Exchange 2010 Differential backup runs very slow when GRT is enabled and Destination Folder is on Dedupe
Hi, We have been running through this very slow backup problem on Exchange Differential for 6 weeks already. We are using Symantec Backup Exec 2010 R3 SP2 and Hotfix 180429 & 176937 installed. Our first setup was Weekly Full (GRT enabled) + Daily Differential (GRT Disabled) and it was running smoothly, the job rate of differential backup runs at 1,500MB/min and it completes successfully at about 15 minutes only. On July 29, 2012, we decided to create new backup templates for Exchange inside a policy so that we could also enable GRT on Differential. After we have successfully enabled GRT on Differential, we ran the Differential backup on July 2, 2012 and we observed a tremendous effect in job rate, it went down from 1,500MB/min to 22MB/min. In addition to this slow job rate, we are also experiencing a failure on our Wednesday(3rd day) differential backup with the following error message: Backup- \\DMCIMAIL.dmcinet.com\Microsoft Information Store\DATABASE01 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: '-1014 The database is out of page buffers. ' Backup- \\DMCIMAIL.dmcinet.com\Microsoft Information Store\DATABASE02 V-79-57344-759 - Unable to complete the operation for the selected resource using the specified options for the following reason: VFF Open Failure. This can be caused by low memory or disk resources. We have several discussions with Symantec engineers but we are still unable to fix this problem. If we look into the situation, we can easily solve the issue on job rate by just disabling the GRT feature but we would want to keep this as we are looking forward on using granular restore in the future. We are stuck in this situation are any suggestions or recommendations that would solve the issue would be greatly appreciated. We hope to solve this very soon as we are already running through this problem for 6 weeks already. Thanks in advance!
