Jump to content

Moving Catalog Files To Non-Default Location Results In A Needs Media Error


Recommended Posts

I tried recently to move all of my catalog files to a folder on my external RAID to take advantage of its faster disk access during catalog reads/writes. This works, but only for a short time. After XX hours Retrospect seems to lose track of the catalogs and gives the insert media error. In order to get things working again, I have to remove the media set from Retrospect and then use Locate to add it back. It then works for XX hours again before the same thing happens. This doesn't happen when the catalogs are in the /Library/Application Support/Retrospect/Catalogs folder.

 

This is problematic because I have 20 media sets and they all randomly experience this problem. I also then have to go to every script and re-select the media set after it is added back into Retrospect.

 

Retrospect engine is running on Mac OS X Server 10.5.8. Retrospect version 8.2. External RAID is Caldigit HDPro.

Link to comment
Share on other sites

Your subject suggests you have come to the conclusion that _any_ location other then the default is problematic, yet your post references only a single different location on different physical media. And while your assessment may in fact be correct, perhaps you could test your theory with at least another variable?

 

- What happens if you put the catalog someplace such as "/" or "/Library/Application Support/Cheese/" or some other place on the boot volume?

Link to comment
Share on other sites

What type of media sets are you using? File, disk, tape?

 

These are disk media sets. The media sets themselves are located on the RAID unit. The catalog files were in their default location, then a few weeks ago I moved them into a folder on the RAID. I began experiencing trouble after moving the catalog files. Today, I moved them back to the default location and tried using the locate button to add them all back into Retrospect. About 3/4 of the media sets are now woringk after doing this. The remaining media sets still give the needs media error after putting them back into Retrospect using the locate button. I am rebuilding those now and creating the resulting catalogs in the default location and overwriting the original catalogs.

 

I will experiment with creating a new media set sometime soon and I will put it somewhere on the system disk. I am not sure why the RAID would introduce an error, but it makes sense to eliminate it as a possibility.

Link to comment
Share on other sites

The media sets themselves are located on the RAID unit.

 

 

To be clear, a Media Set is the set of _both_ the Catalog file and the associated backup media Members. In your case it sounds as if the Members are being stored on a volume or volumes on your RAID

 

 

The catalog files were in their default location, then a few weeks ago I moved them into a folder on the RAID.

 

You moved them to the same logical volume as where your Members are stored?

 

That's generally not optimal, and not how the program is designed to work (with the Catalog and the Members stored on different volumes (logical and/or physical)). This allows for online searching of the Catalog without having to have the media itself online.

 

If you want the catalog files in another place, try creating a dedicated locally attached RAID volume for them. That should work the best.

 

 

Dave

Link to comment
Share on other sites

To be clear, a Media Set is the set of _both_ the Catalog file and the associated backup media Members. In your case it sounds as if the Members are being stored on a volume or volumes on your RAID

 

 

 

 

You moved them to the same logical volume as where your Members are stored?

 

That's generally not optimal, and not how the program is designed to work (with the Catalog and the Members stored on different volumes (logical and/or physical)). This allows for online searching of the Catalog without having to have the media itself online.

 

If you want the catalog files in another place, try creating a dedicated locally attached RAID volume for them. That should work the best.

 

 

Dave

 

Thanks for the clarification. You are correct. The members are located on a local RAID volume. The catalogs were also located on the same volume as the members, but that caused the error I described. To work around the error, I have moved the catalogs back to the system volume. After doing so the problem stopped immediately.

 

Unfortunately, the system volume is much slower than the RAID volume. I would rather have all of the files that require frequent access on the higher speed RAID volume. Am I right in assuming that the catalogs are heavily accessed by Retrospect during a backup or restore? If not, perhaps the problem isn't worth worrying about much. It seems to me that performance will degrade noticeably on a slow disk when several jobs are running simultaneously.

 

At the moment, this seems like a bug in the software to me. Just to make sure I understand it correctly, there is no actual requirement that the catalog files must be located in a specific location, correct? There are best practices of course, and the scenario you outlined makes sense, but shouldn't Retrospect accept any local drive as a valid location for the catalog files?

 

I upgraded the server OS to Mac OS 10.6 Server over the weekend and plan on testing more with the new OS. Perhaps it didn't like something about 10.5 Server.

Edited by Bioheath
Link to comment
Share on other sites

Guest Steve Maser

You are correct in that the catalog files don't have to be located in any specific location -- I keep mine on the engine machine in "/Catalogs". There are different instances where automatic grooming of media sets will take place if a catalog file is on the same drive as the Members or not -- that *should* be the only real difference.)

 

As to "heavily accessed" -- well, they are *read from* for a restore and *written to* for a backup/groom.

 

 

Do you have your catalog files compressed? The only thing I can think of (possibly) where a slow volume might cause an issue would be if you have limited free space on the volume and/or the volume is highly fragmented. Compressing your catalog files (how I run mine) might help in this instance.

Link to comment
Share on other sites

...the system volume is much slower than the RAID volume. I would rather have all of the files that require frequent access on the higher speed RAID volume....

 

Then do. Just have them on a different _logical_ RAID volume, even if that volume is on the same physical RAID array. Any RAID hardware worth it's salt should be able to slice off a new volume for you.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...