DLO Restore fails via Console or EmergencyRestore with the following message: 'failed to restore. Error reading the source file'
DLO restores of user data, either via the DLO Administration Console or when using the Commandline utility 'dlocommandu -EmergencyRestore' will fail, even though the backups were successful and the restore data is shown in the DLO Console.
This issue can only occur when Dedupe is configured for user backups.
DLO Console Restore of files will fail with the following error:
<file path\name> failed to restore. Error reading source file
Verbose logged DLOConsoleu.Log will show the following error for the restore operation:
multicopier.cpp( #### ), Dedupe - Shadow::MultiCopier::Copy - pDedupeEngine()->GetDecoder - Decoder failed with Error: 0x 21005For file: <file path\name>
Dedupe DDEngine_# log will show similar to below, with %5C as part of the path reference, causing the subsequent 'The network name not found' and 'Failed to open the file' errors:
[Error],"CSparseFile::OpenFileForRead: Failed to open the file '\\<DSL server>\<DSL path>%5C#ECF#HFWBFOADLLYPHI-ALIFNCG\#ECF#HFZK123\1\01\01\CF##'. Error = 67. This could be because GC is in progress."
[Error],"CChunkStore::OpenForRead : G/(ERRORLOGGER): --- [GetLastError()]: The network name cannot be found., 67"
[Error],"CChunkStore::OpenForRead : G/(ERRORLOGGER): Error Code = 21005; Error Message = Failed to open the file."
As a result of an incomplete DLO upgrade, the DLO application had been upgraded, but the Apache Tomcat engine and dedupedb SQL database were still at the lower version.
When dedupe enabled user backups are run, reference to the data chunks are encoded by the Apache Tomcat engine, used by Dedupe and written into the dedupedb.
Due to the mismatched DLO and Apache Tomcat version, the chunk information was being written with the ASCII code reference %5C instead of the ' \ ' character that ASCII code relates to. That meant any restore of those files failed, as the path could not be read correctly.
If this issue has occurred, please contact Veritas Support for assistance resolving this, as it will require upgrades of individual components and database records to be changed.
Please ensure that when an DLO upgrade is carried out, when the Summary screen is shown at the end, that all items are shown as upgraded successfully and that both the DLO and dedupedb SQL databases show at the same version.
Was this content helpful?
Rating submitted. Please provide additional feedback (optional):