Nit--missing *catalog* file error message

[awnews]

A minor nit.

 

I recently moved some catalog files from the C drive (getting too full) to one of the backup drives (still > 100GB free). I dbl-clicked on (almost) all of them, but I apparently missed one.

 

Last night the log had an error message telling me that the backup file was missing/inaccessible. Since I could see the backup file and it hadn't moved that didn't make sense. But then I remembered the recent catalog moves so I checked the backup set. As soon as I brought that set up (in the Retro panel), it asked me to point at the (missing) catalog file. And I soon as I did that it was happy again.

 

The nit--the error message is wrong and misdirects the user. It should report a missing *catalog* file (.rbc) rather than a missing backup/data file (.rbf).

 

+ Retrospect version 7.0.326

+ Retrospect Update, version 7.0.10.101

[natew]

Hi

 

I thought this error said "catalog file missing/inaccesable". Either that or gave an 1101 file not found error and listed the catalog file name in the log.

 

hmmmmm...

 

What kind of script were you using at the time?

 

Thanks

Nate

[awnews]

You're right about the error number, but not about the text (which never mentions the catalog file). It's a scheduled backup script.

 

Can't access Backup Set ND1_SERVER1_C, error -1101 (file/directory not found)

 

Again, it's the catalog file (rbc), not the backup "set" (rbf etc.) that it couldn't find.

[natew]

I see your point. It could be more clear.

 

FWIW if a backup set member cannot be located a media request window will come up, not the 1101 error.

 

Thanks

nate

[awnews]

A pseudo-followup.

 

I've got a backup script that won't run regardless of whether it's scheduled or if it's invoked manually (Run). This is one of the scripts that failed due to the inability to find its catalog file (after I moved it) but now fails even though I've "shown" it where the catalog file is (and it's correctly listed for that backup set.

 

Whenever the script tries to run, it always ends up under "Waiting" rather than "Executing"

 

Server1_C_ND1 Waiting for ND1_SERVER1_C

 

but, it's there....

 

The backup set is where it's always been (N: disk) and see the catalog file (S: disk)

1 member is use, 1 session, 1 snapshot

 

Properties & Browse on the Disk Backup set shows the contents and points to the expected location.

Member properties/Browse shows me this also.

 

A "Validate Script" says the script is fine and a Check Media say the media is fine.

 

The little red (X) for "Stop All Activity" is not checked. Other scripts (scheduled and proactive) run fine.

 

The backup target is a client running on another server which is set to allow backups according to schedule. The backup ran fine a month ago (11/9) before the client problem came up.

 

There's no blackout period for the script (which *normally* runs at 2AM). The general Prefs schedule is for "all times"

 

No other backups are running at this moment (so no disk is in use) but other backups had run earlier in the day and since I checked it this morning.

 

+ Retrospect version 7.0.326

+ Retrospect Update, version 7.0.10.101

[natew]

Hi

 

Odd indeed.

 

Does a media verify operation on this set work?

Do any immediate backups work on this set?

If you add a different destination set to your script will it run?

 

Nate

[awnews]

No, an immediate (by running the script manually) didn't work. A "check" of the backup script, including a media verify, said that everything was OK. But I'm wondering if it's grooming issue caused by me moving the catalog files and then trying to "reconnect" them (see below).

 

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

 

I haven't solved this "waiting" problem on the first PC (running RMS) but I've run into the "same" (?? can't yet tell if the circumstances are identical) problem on another PC. In the case of the second PC (running RPro), the destination harddrive ran out of space with a Disk backup and so Retro put the script in a "waiting" state. After canceling the the script, freeing up some space and then starting a Recycle to clean everything up, the program immediately tried to do a groom and then complained about a "missing member." I tried several options, including finally telling (agreeing with) it that the member was missing. It then "finished" but again complained about a missing member on the next manual recycle attempt. I also noticed a 0kB .rbf file as one of the latest Disk backup set files (confused the program?)

 

I finally resorted to just "Forgetting" the backup set (and deleting all the contents) and creating a new one.

 

Retro Pro, Windows XP SP2

+ Retrospect version 7.0.326

+ Retrospect Update, version 7.0.10.101

[natew]

Hi

 

So Retrospect esentially ignored the recycle command and did a groom instead?

Did you see if there was anything listed in the "waiting" tab of the activity monitor?

 

A missing member would explain why the backup was stuck waiting. Does anyone else ever work on this machine? Could someone have set the disk as missing?

 

Thanks

nate

[awnews]

In this case, the Waiting message reported it was waiting on the client machine. The Retro Client on that machine didn't show any problems. I don't think there was a missing member problem (Data backups to large IDE drives with lots of free space).

 

I finally resorted to rebooting both the server (running Retrospect under W2K Server) and the client (another server running W2K Server). At that point, the backups started to run again on their own. So I don't know which reboot of which machine "cured" the stuck backup. I *suspect* it was the the client machine since the server machine had been able to backup other clients (to local IDE drives) without getting stuck in the "waiting" state.