Jump to content
lunadesign

Error -105 (unexpected end of data) during recatalog

Recommended Posts

I'm using a slightly older version of Retrospect Professional (version 9.5.0.140) on Windows 7.  During a normal disk set backup the other day, I got a "Device trouble" "error -105 ( unexpected end of data)" error.  I tried doing a recatalog, but Retrospect racks up a bunch more of these errors and doesn't get anywhere.

 

I understand that this is usually due to one or more of the RDB files being corrupted.  I saw the forum post about changing device logging to level 7 and tried doing that but didn't get much info.  I ended up using the Sysinternals Process Monitor to watch which RDB files were being accessed when the errors are being generated.

 

I discovered that the recatalog was stuck on the first RDB file so I stopped the recatalog, moved the RDB file out of the directory, and tried again.  The recatalog then got stuck on the second RDB file, so I stopped the recatalog, moved that RDB file out of the directory, and tried again.  It kept getting stuck so I ended up removing the first 20ish files and it still gets stuck.  I have a hard time believing that all of my RDB files are corrupt so I'm wondering what else could be wrong.

 

I've checked the Windows Event Viewer log and don't see any file system issues.  I tried copying some files on the file system where the RDB files are stored and had no issues.

 

Any ideas?

 

Thanks in advance!

  • Like 3

Share this post


Link to post
Share on other sites

I've checked the Windows Event Viewer log and don't see any file system issues.  I tried copying some files on the file system where the RDB files are stored and had no issues.

 

How is this file system connected to the machine running Retrospect? (Internall HDD, External HDD, network share, etc.)

 

How much free space is there on the partition(s)/volume(s) of the machine running Retrospect and where the catalog file? (During a rebuild the catalog file can become many times larger than normal and Retrospect also makes heavy use of temporary storage space too.)

Share this post


Link to post
Share on other sites

How is this file system connected to the machine running Retrospect? (Internall HDD, External HDD, network share, etc.)

 

How much free space is there on the partition(s)/volume(s) of the machine running Retrospect and where the catalog file? (During a rebuild the catalog file can become many times larger than normal and Retrospect also makes heavy use of temporary storage space too.)

 

I have a pretty simple setup.  I have a single Windows 7 box that does all my backups.

 

The C partition is an internal HDD that contains OS, apps and the Retrospect catalog files.  It has about 78 GB free.  (For comparison, the catalog file for this backup set is in the 4-6 GB range.)

 

The D partition is an internal HDD that is only used for backup set RDB files.  It has about 344 GB free.  I typically do a groom operation when it gets down to about 50-80 GB.

Share this post


Link to post
Share on other sites

From your numbers disk space shouldn't be the problem.

 

Do you have any other backup sets on the D partition? Are these working fine?

 

Have tried forgetting the the backup set, manually deleting the catalog file with Windows Explorer then recreating it from the disk files? A restart of Retrospect before recreating the catalog may also be helpful.

 

Although Event Viewer is not showing any errors for the volumes running a thorough check disk on them may be worth a try.

Share this post


Link to post
Share on other sites

From your numbers disk space shouldn't be the problem.

 

Do you have any other backup sets on the D partition? Are these working fine?

 

Have tried forgetting the the backup set, manually deleting the catalog file with Windows Explorer then recreating it from the disk files? A restart of Retrospect before recreating the catalog may also be helpful.

 

Although Event Viewer is not showing any errors for the volumes running a thorough check disk on them may be worth a try.

 

Thanks for your help Scillonian.

 

I had not tried the forget-then-recreate approach, so I just tried that but encountered the exact same problem.

 

Unfortunately, I do not currently have any other backup sets on D.  My other backup set is on a removable drive that I periodically bring onsite from an offsite location.

Share this post


Link to post
Share on other sites

Try creating and using a test backup set on the D partition. If it works try a backup with a selection of around 10-20GB of assorted size files should give the drive a good test. If the backup completes without issue then see if you can recreate the catalog.

 

An outside possibility is the config77.dat file has become corrupted.

Share this post


Link to post
Share on other sites

Try creating and using a test backup set on the D partition. If it works try a backup with a selection of around 10-20GB of assorted size files should give the drive a good test. If the backup completes without issue then see if you can recreate the catalog.

 

An outside possibility is the config77.dat file has become corrupted.

 

Thanks again for your assistance....I really appreciate it.

 

I tried what you suggested and had no problems setting up another backup set and backing up roughly 35 GB of data.  I then went back to the problematic backup set and did the "forget-then-recreate" approach and it failed again exactly like before.  Like before, the error count racks up errors at roughly the rate of 2-3 errors per second.

Share this post


Link to post
Share on other sites

Have tried running a thorough chkdsk on the D: partition? I would recommend running "chkdsk.exe /f d:" from an administrator command prompt so you can see what is happening and any errors, if any, that have been found.

 

How much disk space does this backup set use and how many RDB files are in it?

 

When grooming backup sets I've had intermittent problems with backups from a particular volume on one client corrupting RDB files but in these cases it is only the RDB files for that volume. The only way I have found to solve this problem is to manually delete the affected RDB files. I've never had a situation where all the RDB files appear to be corrupt.

Share this post


Link to post
Share on other sites

Sorry for the delay in responding.

 

I ran "chkdsk.exe /f D:" and it found no errors.

 

The backup set that was causing the issues currently uses 2.4 TB and has 9,395 files.  I've been using this backup set for nightly backups for over a year so the # of sessions may be part of the problem.  However, its strange that it was working great and then suddenly stopped working and can't be recataloged.

 

What's interesting is that I just ran my weekly backup sets.  Both are at least a year old but get run only weekly.  The 1st weekly set gets groomed every 2 months or so.  It backs up a small number of huge files so the grooming operation is usually a few minutes long.  This time it took 35 minutes although I didn't see any errors in the log.  At this point, I was suspicious so I nuked this backup set and restarted it from scratch.  The other weekly set backs up a more typical mix of files but it never gets groomed.  It ran perfectly.

 

 

The bottom line is that I still don't know what happened but am seeing a possible pattern - backup sets with lots of sessions that employ grooming.

 

Any other ideas on how I get can resuscitate my nightly backup set?  Maybe updating Retrospect to the latest 9.x release?

Share this post


Link to post
Share on other sites

The bottom line is that I still don't know what happened but am seeing a possible pattern - backup sets with lots of sessions that employ grooming.

I have found that the older a backup set gets and the more sessions it has the more likely it is to have problems. These days if a backup set has problems I will try one catalog rebuild to see if that cures the problems and if it doesn't I retire the backup set as is and create a new one either by doing a backup set transfer from the old one or starting afresh.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×