Jump to content

Retro 5 under OSX -- 2G catalog file error? HELP!


Recommended Posts

Since I've done my upgrade of my clients to 10.2.1, and rebacked up everything, my catalog files have hit "1.98G" in the Finder.

 

 

 

Once they get there, I can't add anything to the catalog file.

 

 

 

I'm getting a "Can't save Snapshot in , error -39 (unexpected end of file)

 

Can't save catalog, error -24204 (chunk file damaged during access)

 

 

 

This is with Retro 5.0205 running under OSX 10.1.5

 

 

 

This has happened twice now -- both times when the catalog file has hit 1.98G.

 

 

 

Is there something in 5.0205 that's limiting the size of the catalog file to 2G?

 

 

 

If so, why?

 

 

 

If not, what else can be going on? This was a *new* catalog file. I have 24G of free space on my hard drive where the catalogs are.

 

 

 

HELP! I can't back up anything if this limit is there.

 

 

 

- Steve

 

 

 

 

Link to comment
Share on other sites

Does *anybody* have any catalog files/storage sets that are greater that 1.98G on OSX 10.1.5?

 

 

 

I've just ran Norton Disk Doctor -- there's nothing wrong with my hard disk media and I've got 24G of free disk space on the hard disk, so I'm not running out of any disk space which would stop a "temp" version of the catalog file being created.

 

 

 

So, I'm wondering -- is this a limit with Retrospect 5?

 

 

 

Or is this a limit with OSX 10.1.5 that I might get around by upgrading the operating system?

Link to comment
Share on other sites

No. I've backed up to file backup sets greater than 2 GB without a problem. Can you claify though? Is this a file backup that has split into a separate catalog file and data file? Is the catalog portion of that set approaching 2 GB?

 

 

 

Can you repair the file backup set (from the Tools menu)?

 

 

 

Can you reproduce this on another machine?

Link to comment
Share on other sites

You asked:

 

 

 

> No. I've backed up to file backup sets greater than 2 GB without a problem. Can you claify though? Is this a file backup that has split into a separate catalog file and data file? Is the catalog portion of that set approaching 2 GB?

 

 

 

This is what's there:

 

[mebackup2:/applications/Retrospect 5.0] admin% ls -la

 

total 22538656

 

drwxrwxr-x 14 admin staff 476 Oct 1 13:23 .

 

drwxrwxr-x 26 root admin 884 Jul 27 03:59 ..

 

-rw-rw-rw- 1 admin staff 6148 Oct 1 11:49 .DS_Store

 

drwxrwxr-x 7 admin staff 238 Apr 25 09:28 AppleScript Utilities

 

-rw-rw---- 1 admin admin 1958848288 Sep 16 12:26 Mac Backup Aug02

 

-rw-rw---- 1 admin admin 1916431420 Aug 26 08:47 Mac Backup Jul02

 

-rw-rw---- 1 admin admin 1977595036 Jul 22 11:57 Mac Backup Jun02

 

-rw-rw---- 1 admin admin 1620539628 Jun 26 13:52 Mac Backup May02

 

-rw-rw---- 1 admin admin 2133802408 Oct 1 11:46 Mac Backup Oct02

 

-rw-rw---- 1 admin admin 1921026436 Sep 24 16:54 Mac Backup Sep02

 

-rwxr-xr-x 1 admin staff 188498 Mar 12 2002 Mac_Client_Update_5_0.rcu

 

-rwxrwxr-x 1 admin staff 11165 Mar 15 2002 Read Me-Retrospect.htm

 

drwxrwxr-x 4 admin staff 136 Apr 25 09:28 Retrospect

 

-rwxrwxr-x 1 admin staff 11020516 Mar 15 2002 Retrospect User's Guide.pdf

 

 

 

 

 

The problem is the "Mac Backup Oct02" catalog file. It shows as 1.98G in the finder, but is obviously bigger than 2G.

 

 

 

The "Mac backup Sep02" is approaching this and it's one of my "current" sets, so I'm concerned it's going to die as well.

 

 

 

 

 

> Can you repair the file backup set (from the Tools menu)?

 

 

 

I did the "update existing catalog file". That seemed to run as expected. Subsequent backups to the 1.98G catalog failed the same way.

 

 

 

When I say "I did this twice" -- I mean this also happened with another 1.98G catalog file for another backup set (same machine, though)

 

 

 

> Can you reproduce this on another machine?

 

 

 

None of my other machines have any storage set files approaching that size, so I can't attempt to reproduce this (I'd need to spend days backing up OSX machines to push things to 2G of a catalog file...)

 

 

 

 

 

 

 

I'm attempting to upgrade to 10.2.1 as I type this. If that makes any difference, I'll let you know.

 

 

 

 

Link to comment
Share on other sites

10.2.1 made no difference.

 

 

 

One thing you said to try:

 

 

 

>Can you repair the file backup set (from the Tools menu)?

 

 

 

I may not have made this clear: I'm backing up to DLT. The 2G file is the catalog only.

 

 

 

The only option I can do under "tools" is to "update existing catalog file" -- which I've done.

 

 

 

But I still get the same errors when I then try to write to that set of backups again.

 

 

 

 

Link to comment
Share on other sites

The only other thing I'd mention about my setup:

 

 

 

My copy of Retro 5 on OSX was using the "upgrade from the 4.3 Prefs file" method.

 

 

 

there's nothing about doing things this way that would bring in some inherited 2G catalog file limit, is there?

 

 

 

I'm stumped.

 

 

 

I could clone the drive, reformat the hard disk and clone it back.

 

 

 

I could set the last tape in the set as "missing" and try to append a new tape.

 

 

 

Offer me some suggestions. I'll give anything a shot.

Link to comment
Share on other sites

In reply to:

Does *anybody* have any catalog files/storage sets that are greater that 1.98G on OSX 10.1.5?


 

 

 

Oh my, I certainly do not!

 

 

 

How large is your data set? How many tapes does it take to get a catalog that large?

 

 

 

You could probably get around this by enabling catalog compression. But remember that as soon as you turn on the radio button in

 

Configure->Backup Sets->Options

 

Retrospect will begin to crunch the data in your catalog file, which will probably take a _long_ time for such a large file. But in the end your catalog file will be _much_ smaller.

 

 

 

After that the compression will only be for new catalog data. It will be slower to finish then it was before, but at least it will work!

 

 

 

Dave

Link to comment
Share on other sites

You asked:

 

 

 

>How large is your data set? How many tapes does it take to get a catalog that large?

 

 

 

 

 

My data set is 150G -- not that large.

 

 

 

It's only 2.5 DLT tapes.

 

 

 

Problem is, doing a backup of all these OSX machines -- while the amount of "unique data" on each machine that's being backed up is *not* large -- the catalog files keeping track of all the files becomes huge.

 

 

 

I run 4 different backup machines here. 3 of them back up only Windows machines -- none of the catalog files reach more than 800M -- and those data sets use *6* DLT tapes.

 

 

 

This is just my Mac backup set doing this.

 

 

 

I'm going to try to rebuild the catalog from tape and see if that works -- I did that with the first set that did this and eliminated the last tape: So right now, the catalog is at 1.78G. I would imagine this will balloon up to the magic "1.98G" size before the day is over.

 

 

 

If it does, then there's a real problem with this.

 

 

 

 

 

One other data point: I'm running Retrospect *only* in backup server mode 24x7. If it's some kind of "caching" of the catalog file that's corrupting things (based on the other RAM issues that have been pointed out running in backup server mode with 5.0.2.05), then this is a serious problem.

 

 

Link to comment
Share on other sites

In reply to:

This is just my Mac backup set doing this.


 

My guess is that you have more OS X machines then ever before. Each OS X install has way more files then any Windows system install.

 

 

 

It's not the amount of data on the tapes, its the number of files. Instead of asking how many tapes you're filling I should have asked you how many files in your Backup Set.

 

 

 

I've got a set here with 2.5 million files taking up 31 Gigs on 2 DLT tapes. The catalog file was about 500 MB before compression. After compression it was 125 MB.

 

 

 

If you are reaching a 2 Gig catalog with 10 million files, perhaps compression will allow you to extend that 4X.

 

 

 

Dave

Link to comment
Share on other sites

I may try that.

 

 

 

The only other possibility (and this might be some sort of OS problem):

 

 

 

Norton Speed Disk indicates that -- while I have 25G free disk space on the drive, my current "largest fragment" on the drive is only 1.3G

 

 

 

 

 

So I'm going to optimize my drive and see if that helps.

 

 

 

Not that I *should* have to do this -- and I don' t necessarily believe this is the problem.

 

 

 

But if that doesn't work, then I'll try compressing the catalog files (which would slow everything down), but might address my problem.

 

 

 

I'm at 1.94G on my other catalog file as I'm "optimizing" the drive right now. More later (if that craps out at 1.98G again...)

Link to comment
Share on other sites

Hi,

 

 

 

Sorry I misunderstood your initial post! Here's some information from our developers:

 

 

 

Macintosh chunk files (upon which catalogs are based) are limited to 2GB. This was the design specification for chunk files initially. The Windows product uses a newer version of chunk files that works with truly gargantuan amounts of data.

 

 

 

You should be able to nearly double the capacity of your catalogs by turning on catalog compression in backup set properties. Since compressed chunks are 30-50% of the original size then more of them fit into the 2GB space available.

Link to comment
Share on other sites

Will this be fixed in "5.1" -- or whatever the Jaguar compatibility release is?

 

 

 

If not, can I set my *existing* 1.94G catalog file to compression and have it work?

 

 

 

Or must I start with a new storage set to have this work properly with compression?

 

 

 

 

 

Thanks for the information.

Link to comment
Share on other sites

In reply to:

must I start with a new storage set to have this work properly with compression?


 

Nope. As I suggested above:

 

 

 

... as soon as you turn on the radio button in

 

Configure->Backup Sets->Options

 

Retrospect will begin to crunch the data in your catalog file, which will probably take a long time for such a large file. But in the end your catalog file will be _much_ smaller.

 

 

 

After that the compression will only be for new catalog data. It will be slower to finish then it was before, but at least it will work!

 

 

 

Dave

 

 

Link to comment
Share on other sites

Yeah, I got this to work by finally restoring an older catalog file that was smaller than 1.96Gigabits (1.7G in the finder) and "set missing" the last tape.

 

 

 

Then I could compress it.

 

 

 

But I couldn't compress any storage set -- even working ones -- that were larger than 1.8G in the Finder.

 

 

 

thanks for all the tips. Now I know better.

 

 

 

Consider this a request for the next version!

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...
 Share

×
×
  • Create New...