Sometimes when the Exchange database is inconsistent it stays mounted, most users don't even notice.
Our problem with Veeam not confirming that the Exchange database is consistent before purging the logs is as follows. Pretty simple, and gives us a second place to get at the logs. We use a simple script which monitors the log directory and rsyncs to a log server as soon as they drop. Assuming that the backup actually completes sucessfully, all is good, since the snapshot does contain the logs, but if for some reason that backup fails and the snapshot is removed, you can rerun the backup, but those logs would be lost forever. The problem I have is that Veeam takes the snapshot, then purges the logs, then starts the backup of the snapshot. Assuming you had a backup that completed successfully, it would include the Exchange logs. I'm not sure I followed your reasoning as to why this would be a major problem. The commiting logs issue is a problem, but since Veeam is almost 100% successful in making a backup it seems like it's not a major flaw. Wasn't killer stuff, but was nice to be able to get it with minimal effort via Veeam and Quest Recovery Manager. We rarely need to restore individual Exchange items, but we have had a few cases, including some corruption of a public folder and a problem with some Windows Mobile phones that was deleting everyones "notes" that people didn't notice right away. We also keep a 30 day Exchange retention and also have an archive server that logs each message which users can access their older mail and restore single items. Our exchange backups are primarily to allow recovery in case of a disaster.
With regards to message level restore, very rarely have a reason to use this as we have Exchange retention set to allow user recovery 30 days after deletion of a message. Not sure if Surebackup will as it doesn't seem to mention it will check the exchange database consistency before purging the logs, simply says it won't say the backup succeded if the exchange databases don't cvome on-line following backup. Have had a few customers in the past that experienced corrupt exchange stores, a proper Exchange backlup tool wouldn't purge the logs in this case so you can perform the recommended action of restoring the last good database backup and replaying the logs to ensure consistency. (Have had to turn off Veeam VSS processing for this, but the database is consistent in the BE backup so not a concern) We have reverted to using BE 12.5 to backup Exchange as we need to know that the database is being backed up correctly. Veeam does indeed commit the logs, even if you don't backup the drives with Exchange databases on it.
0 kommentar(er)
