Jump to content

Continue on error, auto-repair (e.g. catalog)


awnews

Recommended Posts

I came into work (after a long weekend) to find Retrospect sitting with a dialog saying "Catalog out of sync for BackupX. To repair it, use Tools->Repair Catalog...blah, blah [OK]." "Behind" this backup were several backups that were still waiting for the dialog to be clicked before they were run. There was *nothing* wrong with these other backup sets nor any reason they couldn't have run.

 

1) The most important issue here => There is NO reason why those other backups, and other ones to follow on subsequenet days if I wasn't around, couldn't have been run. Retrospect is supposed to allow *unattended* backups, and not *require* that the program be checked daily to make sure all backups are being run, to make the user click on dialog boxes. Log the error and move on!

 

2) I don't know what caused the "Catalog out of sync" error (to another local harddrive. And I haven't seen that message in a while). But the program needs an option to auto-repair and recover from these kinds of errors (e.g. retry/repair [N] times before giving up and moving on to the next backup script [see #1 above]).

Link to comment
Share on other sites

So, even though I don't know the cause (alpha particles...?) of the "Catalog out of sync" error (to a File backup set on another IDE drive) for this backup set, I had to go ahead and repair it. I was able to repair the catalog using the Tools->Repair Catalog process, but this interface and the process is poorly implemented.

 

When you choose Tools->Repair Catalog, you're presented with several radio option button. When I choose the first most obvious one, "Update existing Catalog File" and choose from a list of known backup sets, I get:

 

+ Executing Recatalog at 2/18/2004 1:53 PM

To Backup Set V_Data_Short...

Bad Backup Set header found (0x64685654 at 11,146,994)

2/18/2004 1:56:36 PM: 1 execution errors

Duration: 00:02:49

 

You would think this would update *and repair* the catalog file but it doesn't seem to repair anything. Should "Repair" be an expected or separate option here?

 

------------------------------------

I then tried the "Repair file backup set" option. This says "Repair" but doesn't mention the word "Catalog" (unlike the first option) which is what I was trying to repair. This time I wasn't presented with a list of known backup sets but instead (asymmetrically) had to manually navigate to the (File) backup set.

 

When I selected the File backup, RP responded (paraphrase) "The Catalog portion appears to be valid, do you want to continue?" even though the thing that started all this was the RP log reporting "Catalog out of sync." I said yes, and the log shows that something *was* wrong with the backup set and it proceeded to do something (note the word "Repairing" or "Repaired" doesn't appear in the log).

 

+ Executing Recatalog at 2/18/2004 2:01 PM

To Backup Set V_Data_Short...

Bad Backup Set header found (0x64685654 at 11,146,994)

2/18/2004 2:14:30 PM: 1 execution errors

Completed: 275069 files, 10.7 GB

Performance: 853.7 MB/minute

Duration: 00:12:47

 

------------------------------------

After this, I again ran the "Update existing Catalog File" and this time it didn't report anything bad (didn't really report much of anything except that it had finished...).

 

Update existing Catalog File

 

+ Executing Recatalog at 2/18/2004 2:25 PM

To Backup Set V_Data_Short...

2/18/2004 2:25:52 PM: Execution completed successfully

Link to comment
Share on other sites

  • 1 month later...

I just got back to work from a long weekend (Sat-Mon), so this morning I checked my Retrospect (Pro [so only one execution unit], 6.5.336, RDU 4.9, XP SP1) system to see how it was doing. And, sure enough (moral--*never* turn your back on this program) it was sitting and waiting to run a backup since last Saturday. Why?--a server had been shutdown over the weekend and that server had a mounted harddrive to be used as a destination for a Saturday backup. So the program sat and waited...and waited...and waited..., not running the Sunday backups or Monday backups that would have worked fine since they were to be backed up to other destinations.

 

Continue on error!

Continue on error!!

Continue on error!!!!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...