In NetBackup 184.108.40.206, some Exchange 2013 CU1 or CU2 backups may appear to succeed, but restore attempts fail.
|Article:TECH211876|||||Created: 2013-10-24|||||Updated: 2013-11-13|||||Article URL http://www.symantec.com/docs/TECH211876|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
Backups of Microsoft Exchange 2013 may not be restorable with roll-forward of transaction logs due to invalid metadata accompanying the Exchange snapshot. In NetBackup 220.127.116.11, this invalid metadata is not detected at backup time, which means that backups may appear to succeed but not be restorable.
The following restore operations fail:
- Restoring a database from a FULL backup with the roll-forward option
- Restoring a database from a FULL backup plus either a cumulative incremental backup or one or more differential backups - in this case, NetBackup fails when it applies the incremental backups as roll-forward restores based on the restored FULL image
Future NetBackup releases will avoid these potential data loss conditions by failing the backups after detecting the flaw in the snapshot.
A restore failure from a NetBackup 18.104.22.168 backup produces the following entry in the Application Event Log:
Log Name: Application
Event ID: 4356
Exchange Replication Service VSS Writer failed restoring a backup for '<database name>' because an unexpected error (-2147023286) was encountered while attempting to locate existing log files in the log file directory '<database path>'.
This issue only affects Microsoft Exchange 2013 CU1 or CU2 (Cumulative Update 1 or Cumulative Update 2) backups taken under NetBackup 22.214.171.124.
When the snapshot is taken, the Microsoft Exchange VSS Writer produces a Backup Components Document that lacks the LOG_SIGNATURE_XXXX information needed to apply the transaction logs to the database at restore time. This has been seen to occur after the Exchange server was restarted and on other occasions.
Symantec expects that a forthcoming Microsoft Knowledge Base article will be published containing more information on this Exchange issue and how to correct it. A hyperlink will be attached to this article when it is available.
The formal resolution for this issue (Etrack 3187083) is included in the following releases:
- NetBackup 7.6 General Availability (GA)
- NetBackup 7.5 Maintenance Release 7 (126.96.36.199)
When these versions are released, please visit the following link for download and readme information:
In NetBackup 188.8.131.52 and 7.6 GA, jobs affected by this issue will fail with status code 124 (NB database backup failed, a path was not found or is inaccessible) reported as well as the following log message:
FTL - snapshot creation failed - The LOG_SIGNATURE_ID and LOG_SIGNATURE_TIMESTAMP in the Backup Components Document for <database name> are both 0. This is a known Exchange 2013 problem.
Note that while the Symantec resolution corrects the reporting of the issue, it does not resolve the underlying Exchange issue. It is expected that this issue will be addressed in a future update to Exchange.
Symantec strongly recommends the following best practices
1. Always perform a full DR backup prior to making any changes to your environment.
2. Always make sure that your environment is running the latest version and patch level.
3. Perform periodic "test" restores.
4. Subscribe to technical articles.
How to Subscribe to Email Notification:
Directly to this Article:
Subscribe to this article by clicking on the Subscribe via email link on this page to receive notification when this article is updated with Release Information.
If you have not received this TechNote from the Symantec Email Notification Service as a Software Alert, you may subscribe via email and/or RSS using the links provided at the following page:
Exchange 2013 Differential restore failed, E0xRestore.env contains LOG_SIGNATURE_ID 0, Event Log 4356.
Article URL http://www.symantec.com/docs/TECH211876