Jump to content
Sign in to follow this  
Lennart_T

"Analyzing catalog file for grooming" takes forever

Recommended Posts

Running disk-to-disk-to-tape using Retrospect 7.0.326, driver update 7.0.12.105, Windows 2000 server, 2GHz Pentium 4, 1 GB RAM, Sony AIT-2 loader.

 

We have four disk backup sets on two different NAS servers, the catalog files are on a local PATA drive.

This weekend, only one backup set was groomed. That catalog file is now 4.9GB. The next backup set has been running since Saturday. This morning (Monday) utilizing 100% CPU now for the last two hours. This catalog file is 4.5GB.

I clicked the "Stop" button (and confirmed) an hour ago, but it's still running using 100% CPU.

Current RAM usage is 640MB.

 

Why is this happening and what can I do about it?

Share this post


Link to post
Share on other sites

After waiting four hours for the "Analyzing catalog file for grooming" to actually stop, I used Task Manager to "End Task".

 

How do I prevent this mess in the future?

Share this post


Link to post
Share on other sites

If you end task on a Retrospect while doing a grooming operation, you MUST do a catalog rebuild, otherwise the backup set will be corrupted.

 

Grooming can be slow, and it may take several hours to complete.

 

Grooming is much faster and much more stable in version 7.5

Share this post


Link to post
Share on other sites

Yes, I know grooming can take hours, but 48 hours? For a disk backup set that was recydled last week with a minimum of snapshots? And just for ANALYZING???

 

And since it was just analyzing the catalog file, do I still need to rebuild? How can I check?

Share this post


Link to post
Share on other sites

No easy way to check. Maybe it got stuck for 48 hours because of a catalog problem. A rebuild is recommended and so is an upgrade for speed and stability reasons.

Share this post


Link to post
Share on other sites

Recatalog incomplete!!!!!

 

I had some problem with this backup set last week, so I tried a recatalog which issued the same error message. So I recycled the backup set and thought that was the end of it. Now the same thing happened again. This backup set is used for Mac clients (desktops), running Mac OS X 10.3.9 or 10.4.8 and the Client 6.1.130.

 

Here's the log:

Code:


 Executing  Recatalog  at 2007-01-22 15:59 (Execution unit 1)

To Backup Set MacDesktops ...

TMemory: heap 625 19,6 M

virtual 6 19,0 M

commit 19,0 M

purgeable 21 zero K

Pool:pools, users 283 19

max allowed mem 716,0 M

max block size 8†192 K

total mem blocks 1 8†192 K

used mem blocks 1 8†192 K

file count, size 0 zero K

requested 631 6†789 K

purgeable 21 zero K

avail vm size 1†982†218†240 B

TMemory::mhalloc: VirtualAlloc(291,0 M, MEM_RESERVE) failed, error 8

TMemory: heap 626 19,6 M

virtual 6 19,0 M

commit 19,0 M

purgeable 21 zero K

Pool:pools, users 283 19

max allowed mem 716,0 M

max block size 8†192 K

total mem blocks 1 8†192 K

used mem blocks 1 8†192 K

file count, size 0 zero K

requested 632 6†789 K

purgeable 21 zero K

avail vm size 1†982†218†240 B

TMemory::mhalloc: VirtualAlloc(291,0 M, MEM_RESERVE) failed, error 8

$ Backup Set format inconsistency (6 at 139332651)

2007-01-22 17:49:24: Execution incomplete

Completed: 2855610 files, 132,9 GB

Performance: 1285,8 MB/minute

Duration: 01:49:59 (00:04:14 idle/loading/preparing)


Share this post


Link to post
Share on other sites

How much physical memory do you have on the backup server?

 

Retrospect 7.0 does not handle large numbers of files as well as 7.5. You should download a 7.5 trial and see if you have better success doing a catalog rebuild.

 

If you attempt multiple catalog rebuilds and it always fails at the same spot, you might have a bad .rdb file on the disk.

Share this post


Link to post
Share on other sites

We have 1GB physical RAM.

 

What would you say is "large numbers of files". I think the backup set contains less than 2 million files.

 

If we try 7.5, is the catalog files as well as backup sets compatible so we can go back to 7.0?

(We are already planning to buy 7.5 later this year as funds allow.)

 

Yes, I'm quite sure it's a bad .rdb file. But which one? Why did it go bad? What can we do about it?

 

I just recycled the backup set, just like last week, so we get SOME backups running tonight. (It's already 8 pm here in Sweden).

Share this post


Link to post
Share on other sites

We're now seeing strange errors in the log. Can these be related to the original problem?

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

MapError: unknown Windows error 4†390

TPCFolderLoc::GetPathForMountedVol: UGetVolumeNameForVolumeMountPoint failed, Desktop\My Computer, winerr 4390, error -1001

 

I just ran CHKDSK on all drives, which didn't report any errors.

Share this post


Link to post
Share on other sites

No, they don't.

And they don't appear in any script log, just in the "main" log.

 

It seems to have started yesterday and there were a LOT of them.

 

Since they started yesterday, they can't be connected to the grooming problem. So let's go back to the grooming problem. Any advice? (See my previous post, too.)

 

For tape backup set, there is the possibility to verify all members are readable. Isn't that available for disk backup sets? (I can't find it.)

Share this post


Link to post
Share on other sites

Quote:

Tools>Verify can be used for all backup media types.

 


Doh! Looking in the wrong place.

 

Thanks.

 

Correction about backup set size: The disk backup set for Mac desktops now contains 3.4 million files. We run tape backup sets with over 7 million files. Is this near the limit for version 7?

Share this post


Link to post
Share on other sites

1 file not verified just means that one file within the backup set was not readable. It will be hard to tell which file (unless it is found in the log). This could happen due to a prior failure of a backup or an error copying that file originally

Share this post


Link to post
Share on other sites

Quote:

Retrospect 7.0 does not handle large numbers of files as well as 7.5. You should download a 7.5 trial and

 


Just downloaded and installed the 7.5 trial. It started to backup a lot of files that hasn't changed since the last 7.0 backup (both from a Windows client as well as a Mac OS X client). Why?

 

So I will try 7.5 this weekend, when we do a "new media backup" anyway. But I'm concerned about the disk backup sets. There isn't room for backing up a lot of files again.

 

Tried to go back to 7.0. Apparently the 7.5 installer deleted the 7.0 program AND the RDU. Sigh...

Fixed that and up and running on 7.0 again.

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
Sign in to follow this  

×