Can't write to file .... error -1116

[dthede]

In May, I received the following (sanitized) message during a laptop backup to disk over a network. I did not pay attention to this message apparently, or else I did not understand or appreciate it. "Can't write to file \\xyzSERVER\Users\<name>\BackupSetA-Container\Retrospect\Backup Set A (9100) [001]\1-Backup Set A (9100) [001]\AB000194.rdb, error -1116 (can't access network volume)". The trouble is further documented as a map error and resultant error communicating (-102), etc.

 

I continued doing scheduled backups to disk, to the same "Backup Set A (9100) [001]" identified above, via the network on a weekly basis. Each backup completed successfully on each subsequent occasion. During this time, I remained unaware of the lurking error.

 

I recently attempted to verify this backup set with the thought in mind of closing out the backup set and shifting to a new backup set. Naturally it failed to verify, and halted at the very location (AB000194.rdb) referenced by the error message in May in the backup history. I am surprised that after I ultimately declared AB000194.rdb as missing, that the verify did (can) not resume from that point on (say, AB000195.rdb) and verify at least the next 71GB of backup material which is presumably good.

 

What's a good strategy to salvage the remaining 71 GB of backup under these circumstances? Most of the help and assistance presently available in the forums & help concerns rebuilding corrupt catalogs. This is not that. By the way, this appears to be a similar behavioral weakness to that found in Veritas' Backup Exec, where an entire backup set appears inaccessible due to a very limited error in a well-defined location when spanning tapes: there appears no way to salvage that which remains good -- a kind of all or nothing approach to backup. I'm hoping I am misinformed regarding Retrospect... Naturally any significant help will be appreciated.

[dthede]

This is not a solution to the previous issue, but it follows up on the previous posting 'Can't write to file ..." in two ways: (1) There appears to be a conflict between Retrospect and the WinXP Pro SP2 file synchronization / working with offline files feature. My (mobile) machine syncs various files to the server. The machine gets backed up to the same drive on the server. Frequently during backup of the local machine to the server, it goes "offline" and the backup UNC target cannot be found. When this occurred recently, I inspected the Settings dialog box of the "work offline" message, and saw that there is a checkbox for preventing disconnection of the mobile machine from the server. When checked, subsequent backups went to completion properly.

 

(2) But note that in those cases where the target server went offline relative to the mobile sync'ing workstation (\\<UNC> not found, Continue working offline?) during a backup, being patient and reconnecting to the server via Explorer, then clicking "OK" on Retrospect's message, resulted in Retrospect resuming execution of the backup which had been interrupted. However, it seems that this backup can proceed with an undetected AND unreported error, since during the later verify phase, a specific backup set will be reported out as missing or corrupt, and after trying to deal with that issue, a file in the backup set will be more specifically identified as missing or corrupt -- e.g. AB000nnn.rdb. This brings me back to the main issue of a corrupt file in a member of a backup set, where the entire backup set becomes "poisoned" or is unusable after the corruption point. What is the proper way to deal with this?

[nekr0phage]

Hi Didrik,

 

Though the problem here does not actually reside in the catalog file, rebuilding the catalog may be the best way to work around this damaged file. If you remove the corrupt .rdb file from your backup set and initiate a rebuild of the catalog file, it should give you a prompt similar to "There appear to be missing files, continue catalog rebuild anyway?" If you accept this option Retrospect should be able to recreate a catalog file, omitting whatever data was stored in the damaged .rdb. This should allow you to work with the remainder of the backup.

[dthede]

Thank you!! Excellent suggestion which I had not thought of.

[dthede]

I have tried the procedure and variations as well. While time consuming, it initially provided very hopeful results. As of this writing, however, the method appears not to work.

 

Here's what happened. A specific .rdb was identified as missing or corrupt, as previously stated. When REPAIRING CATALOG (rebuilding the catalog from disk) by re-reading the backup set, Retrospect paused asking for the next disk. In the course of dealing with the various misleading dialogs -- such as there was no additional disk, I was ultimately forced to declare the named file missing -- even though it plainly existed. Thereby, Retrospect continued "around it," I guess, and eventually discovered another such file, say AA0000391.rdb, "missing or corrupt." This procedure continued until the catalog rebuild was complete, yielding about 14 "missing or corrupt" backup set chunks. I deleted these.

 

Subsequent attempts to VERIFY MEDIA (backup set) revealed yet other .rdb files which were "missing or corrupt." It should be noted that none of the subsequent files identified as "missing or corrupt" were consecutive with any of the previously deleted 14 files. The process was allowed to go to completion. The missing or corrupt files were deleted, similarly to before. The previously deleted, declared missing files, were gracefully skipped over as expected. The VERIFY MEDIA (backup set) was run again, and still more files were reported as "missing or corrupt. As you might guess the number of missing or corrupt files grew in raw numbers on each successive pass, such that after a few days, there were relatively few .rdb files remaining. Eventually, I threw in the towel and deleted the last 100GB of backup .rdbs.

 

What do you suppose was happening?

 

(1) I have a similar backup set size backing up the same files going to an external hard drive, and this has no corruptions and no other reported errors in it, plus restores randomly selected files properly. Additionally, VERIFY MEDIA on this external drive proceeds rapidly and properly to completion for the 250GB or so of files in its set, so the script or media, or a user application knowledge do not seem to be the problem.

 

(2) In attempting to back these files to a Small Business Server from a workstation, I wonder if the problem isn't a licensing or applicaiton compatibility one. CAN RETROSPECT 7.5 be used to back files from a workstation to a server? to SBS?

Regards,

[nekr0phage]

Hi Didrik,

 

I'll answer your second question first.

 

Retrospect can backup any networked volume, provided Microsoft (etc.) networking is correctly configured and there are no externalities which would adversely affect the process (such as a bad NIC corrupting data). In order to backup a server operating system as a Retrospect client, you would need a license that supports server operating systems - either multiserver or a server client license. Backups should work with either method, though certain functions such as open file backup or Exchange/SQL backups are not available via networking.

 

Since Retrospect can backup without any problems at all to a local hard drive it would seem your difficulties are network related. Aside from general troubleshooting (changing cables/ports/switches) make sure you have current drivers for your NICs from the *manufacturer,* the Windows drivers are not always adequate for handling heavier data loads.

[dthede]

Will check out the NIC and switch port aspects. Fortunately the server has dual NIC ports, and the switch is rack mounted at the server, so everything is completely and easily accessible.