Facebook.jpg linkedin-icon.png icon_twitter.gif  
 

Business Continuity and Disaster Recovery
651-288-2822

  

tools-icon.pngTroubleshooting

These are some errors we encounter with some frequency and how to deal with them quickly to guarantee that all data is backing up correctly.

File Backups

  1. Uploaded file size incorrect

    This error occurs when a backup file uploaded to the server is corrupted due to an issue in the file transmission. Corrupted backup files would not be stored on the backup server but will be uploaded to the backup server again in the next backup job.

    If the same backup set is being run on more than one computer at the same time, you might get this error. If you have installed Reliable Data Protection on more than one computer, make sure that each is configured correctly to run separate backup sets.

    Also, please check the file C:\Program Files\Reliable Data Protection\home.txt and see if you have more than one “.obm” record (e.g. C:\Documents and Settings\Administrator.obm) in this file that refers to the same backup account. If you can find such entries, simply remove the redundant lines from this file and restart the computer.

    Sometimes, this problem could be caused by network instability. If this only happens occasionally, you can safely ignore this error.

Microsoft Exchange Information Store

  1. CExBackup::backupService:HrESEBackupSetup: Error Number 0xc800020e: An incremental backup cannot be performed when circular logging is enabled.

    This error results most often on Windows SBS 2003. The default installation of Exchange on these servers is configured to perform circular logging, that is, to overwrite old log entries with new ones. Thus, it is impossible to recover a full information store using these log files. The backup software thus will not perform a transaction log backup, as such at thing would be useless.

    There are two solutions to this issue. One is to disable circular logging on the Exchange server. This is done by viewing the properties for each server, and under “General” un-checking the “Enable circular logging” option. After changing this option, the server will need to be restarted.

    The other option is to, rather than the default of weekly full backups and daily log backups, simply perform a full database backup every day. Which of these is more reasonable depends on the amount of data in the Exchange information stores. Smaller stores, or stores on faster connections will more easily be able to perform fully daily backups.

  2. No *.stm found for database ‘ServerX\Microsoft Information Store\First Storage Group\Mailbox Store (ServerX)’

    This suggests that the .stm file on server may have been corrupted or found missing. To resolve this error, please perform a Full MS Exchange backup manually via OBM.

  3. The last backup jobs of *.stm (2006-10-30-13-40-21) and *.edb (2006-11-04-03-05-00) don’t match for database ‘ServerX\Microsoft Information Store\First Storage Group\Mailbox Store (ServerX)’

    For MS Exchange backup, *.stm and *.edb are backed up in pairs, if this error occurs, it implies that during a previous backup, there was a problem with either the *.stm or *.edb file. If this happens, please perform a Full MS Exchange backup manually via OBM to resolve this problem.

  4. Expect log sequence ‘xxx’ but found ‘SERVERNAME\Microsoft Information Store\First Storage Group\E000xxx.log’

    This error occurs when the log sequence of MS Exchange was altered by other backup software, e.g. NTBackup. Thus when OBM next performs a MS Exchange backup, the Exchange log sequence would not match the one that it is expecting. With the broken sequence, the Exchange server cannot be restored to its latest state.

    To resolve this problem, you need to deactivate all other backup software that is operating on MS Exchange, and then you need to perform a Full MS Exchange database backup manually via OBM.

    Alternatively, instead of backing up transaction logs during the weekdays, you can consider performing a full Exchange database backup on a daily basis with the In-File Delta option enabled. This should avoid interference from other backup software while keeping the amount of upload data to minimal.

    This error could also occur if the user has changed the minimum size for In-File Delta to a value smaller than the corresponding Exchange log file size, i.e. 1MB for MS Exchange 2007 and 5MB for MS Exchange 2000/2003. OBM would then generate deltas for Transaction log backups, thus causing the expected log sequence error.

Microsoft Exchange Brick-Level

  1. E-mail Account Quota exceeded! Unable to add “MSExMailLevelBackupSet-1”

    This error results from setting up a brick-level Exchange backup set to back up more mailboxes than the account has licenses for. This prevents the brick-level exchange from running at all, so when signing up for a new account, or for the brick-level service on an existing account, make sure it is licensed for a sufficient number of mailboxes.

System State Backups

  1. File size of “C:\Backup\1234567890123\ SERVER\SystemState.bkf” does not appear to be correct. This error is a result of some new checks that went in in recent versions of the backup software. It suggests a problem exists with the Volume Shadowcopy Service which creates the system state backup file that is then uploaded to the backup server. Possible solutions to this include re-registering that service by running a batch file that does the following:
    cd /d %windir%\system32
    Net stop vss
    Net stop swprv
    regsvr32 ole32.dll
    regsvr32 oleaut32.dll
    regsvr32 vss_ps.dll
    vssvc /register
    regsvr32 /i swprv.dll
    regsvr32 /i eventcls.dll
    regsvr32 es.dll
    regsvr32 stdprov.dll
    regsvr32 vssui.dll
    regsvr32 msxml.dll
    regsvr32 msxml3.dll
    regsvr32 msxml4.dll
    After running that script, reboot the machine and try running the backup manually.

    Other options include backing up the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions deleting that key and all of its subkeys, and rebooting the machine. A much simpler possible solution would be to make sure the system state backup is not running at a time that a file backup set would be generating its shadow copy (apparently VSS has difficulties doing multiple tasks simultaneously).