Lennart_T Posted January 22, 2007 Report Share Posted January 22, 2007 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? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2007 Author Report Share Posted January 22, 2007 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? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 22, 2007 Report Share Posted January 22, 2007 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 Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2007 Author Report Share Posted January 22, 2007 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? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 22, 2007 Report Share Posted January 22, 2007 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. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2007 Author Report Share Posted January 22, 2007 OK, recatalog started. Thanks. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2007 Author Report Share Posted January 22, 2007 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) Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 22, 2007 Report Share Posted January 22, 2007 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. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2007 Author Report Share Posted January 22, 2007 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). Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 23, 2007 Author Report Share Posted January 23, 2007 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. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 23, 2007 Report Share Posted January 23, 2007 I have not seen these errors before. Do they have red arrows in the left margin? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 23, 2007 Author Report Share Posted January 23, 2007 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.) Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 23, 2007 Report Share Posted January 23, 2007 Tools>Verify can be used for all backup media types. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 23, 2007 Author Report Share Posted January 23, 2007 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? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 23, 2007 Author Report Share Posted January 23, 2007 "1 files were not verified" But which one? Why? And what can I do about it? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 23, 2007 Report Share Posted January 23, 2007 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 Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 23, 2007 Author Report Share Posted January 23, 2007 Ah. So it's not one of the .rdb files that is bad? No, that is all the log said. I say it's too sparse. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 23, 2007 Report Share Posted January 23, 2007 It isn't the RDB, it is an actual file within the rdb that didn't compare. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 25, 2007 Author Report Share Posted January 25, 2007 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.