Jump to content

Recatalog fails: Not Enough Memory


Recommended Posts

∆ Retrospect version 6.1.126

launched at 2/20/2007 12:05 AM

 

+ Executing Recatalog at 2/20/2007 12:11 AM

To backup set Backup Set F…

Not enough memory

2/22/2007 8:30:01 AM: Execution incomplete.

Completed: 2692612 files, 359.9 GB

Performance: 109.1 MB/minute

Duration: 56:18:14 (00:01:29 idle/loading/preparing)

 

<Rant>What am I most distressed at?

1. The catalog itself got damaged when the machine failed. How is it possible that Dantz wrote unsafe code for updating the Catalog file?

2. The performance is so abysmally slow. 109 MB/min to read and recatalog from Firewire hard drives. Sure I'm surfing and reading email on this machine, but I sure notice Retrospect hogging the CPU.

3. Out of memory. There's 10 GB of VM on this system, and the original catalog that Retrospect trashed was only 4GB, and besides if it could build the catalog in the first place during the backup, why can't it do the same during the recatalog?

</Rant>

 

My conclusion is that this product is no longer suitable for SOHO, never mind SMB.

Link to comment
Share on other sites

Stomping your little feet won't solve the problem.

 

You don't provide any details whatsoever about your configuration, so it's not possible to provide any suggestions to ease your distress.

 

Helpful info would be:

Your version of Mac OS X

Your computer model and speed

How much physical RAM you have.

 

For example, if you have an Intel Mac, then you are also running Rosetta (because Retrospect is not a Universal Binary). That takes an extra GB of RAM right there (not VM, but RAM). And the OS takes at least 1/2 GB.

 

And you are browsing and doing email at the same time. I bet that you are thrashing (paging) to death. And the paging is going through the same pipe as Retrospect's analyzing of your backup to build the catalog.

 

Be nice, give Retrospect some memory too.

 

Try running Activity Monitor, look at the paging statistics and free RAM.

 

If you are going to be doing all those things at the same time you have Retrospect running, you probably need 3 GB or so of RAM if you have an Intel Mac, 2 GB or so of RAM if you have a PPC Mac.

 

Russ

Link to comment
Share on other sites

The response on this forum always seems to be to give Retrospect more resources. But as I've posted in the past, this is a UNIX world, a shortage of resources reduces speed, but does not cause failure. IMO, the problems are the result of fundamental design flaws in the software (probably race conditions), that are merely masked by faster processors. But it wouldn't surprise me if there were lots of issues with malloc() as well.

 

If the solution is to buy new hardware, then the answer is a BRU appliance, NOT retrospect!

Link to comment
Share on other sites

> But as I've posted in the past...

 

...over and over again, what is your hardware/software configuration?

 

> it wouldn't surprise me if there were lots of issues with malloc()

 

Sounds as if we have a budding Cocoa developer here.

 

Of couse you realize that swap files are not RAM, and that Retrospect is not a pure unix process but is a Carbon application that is RAM intensive even under the best cirmstances.

 

Suggesting that a few precent of free disk space should compensate for not having enough physical memory is CrazyTalk.

 

> If the solution is to buy new hardware, then the answer is a BRU appliance, NOT retrospect!

 

Then do that. And discover how frustrating and limiting that particular program is in regards to Restoring data.

Link to comment
Share on other sites

Although you've recently claimed to Ric Ford that your first post to this thread would be your last to the Forum, we'd certainly like to know if you're still running Retrospect on unsupported, processsor-upgraded hardware and minimal RAM.

 

It would also be interesting to know what Type of Backup Set you are using, and what the make/model/interface of the backup Device you're writing to.

Link to comment
Share on other sites

The same problem just occured on an iMac G5, 200GB (mostly free space), 2 GB RAM. After cataloging 359 GB I get a message saying "Save the Partial Session" Save or Revert. Activity monitor showed Retrospect using about 250MB RAM and 2.59 GB VM.

 

I wasn't aware that DP G4 w/ 1.25 GB RAM OS X.4 was unsupported. I'm pretty sure it was a supported configuration when I paid for the software.

 

These are removable disk backups, with 3 disks of 250GB each. The last backup set is about half full.

Link to comment
Share on other sites

> After cataloging 359 GB I get a message saying "Save the Partial Session" Save or Revert

 

So just to be totally clear, you:

 

- Tools->Repair->Rebuild frrom removable disks

- Media Selection window shows your hard drive(s)

- You select the first Member (or Retrospect selects it for you)

- Save new Catalog to internal HD

- First 250 GB Member is cataloged

- Media Selection window shows; you select second 250 GB Member (or Retrospect selects it for you)

- Modal error window with the text "Save the Partial Session" and two buttons, Save and Revert

 

That's all?

 

> The last backup set is about half full

 

- You mean the last Member is full (it's just one Backup Set, right?)

 

 

 

Assuming that these are FireWire drives (since the iMac has no other expansion options) are they all mounted at the same time?

 

How is it "The same problem" when it's something different from your first post?

 

Is this the same machine/configuration as the one that gave you the out of memory error?

Link to comment
Share on other sites

Procedure is as you described.

 

Drives are mounted one at a time. After the first drive is cataloged, Retrospect asks for the second. I unmount the first and mount the second. Retrospect then chugs along until it barfs with the modal error window. It's the Ops log that reports "Out of Memory".

 

The procedure was run on two systems:

 

DP G4 400MHz, 1.25 GB RAM, about 13 GB free on the boot drive (where I was rebuilding the catalog).

iMac G5 2GHz, 2GB RAM, 260(?) GB HD, well over 200 GB free space.

 

How is it the same problem?

 

It's the same re-building the catalog process, using the same three disks, I get the same error message, occuring at the same point in the rebuilding process.

 

The point of the exercise is to de-bunk the assertion that my "unsupported" hardware is the issue.

 

There are three 250 GB FW drives in the BackupSet

1-BackupSet-F -- full

2-BackupSet-F -- full

3-BackupSet-F -- about half full (as reported by Retrospect)

Link to comment
Share on other sites

Quote:

The point of the exercise is to de-bunk the assertion that my "unsupported" hardware is the issue.

 


 

Ah, that's where I must have misunderstood; I thought the point of the exercise was to identify or solve the problem, and to get your Catalog successfully rebuilt. My bad.

(note that the link I used pointed to your old post where you were using older hardware; nowhere in this thread before that did you provide hardware configuration information)

 

Here's what I'd try (just guessing here on exactly how the steps will look):

 

- Allow Retrospect to work on the first drive.

- At the Media Request window, tell Retrospect that there are no more disks (not sure how this will look, if you'll be asked to mark the media as Missing or what).

- Configure->Backup Sets->YourNewCatalogFile->Members, mark the second drive as Set Found

- Tools->Repair->Update existing catalog file

If this is successful (again, I don't know if it will be, I've never tried it, and I don't have removable device storage available to test, plus it's lunchtime), mark the third drive as Set Found and repeat.

 

Dave

Link to comment
Share on other sites

This procedure did work to rebuild the catalog file, so thanks very much for the suggestions!

 

Of course, it's hardly intuitive that to re-build a multi-disk catalog file, you must give the incorrect answer (NO there are no more disks in the set), and then do an Update to add in the next set.

 

In observing this very slow process, it really makes me wonder why Retrospect fails. It's NOT a matter of the hardware, as it happened on two machines, at the same point in the re-catalog process. The slower 450 MHz DP-G4 had 1.25 GB; I double-checked the faster 2GHz iMac and it only has 512 MB.

 

Maybe it's an absolute number of files. But this would be the MOST troubling cause. Fortunately my disks were 250GB each, so the failure at about 375 GB could be managed with the above procedure. But what if I had been using 500GB removables. Would it still happen around 375GB? Does anyone know for sure. I doubt anyone wants to find out the hard way.

 

So I have to stand by my opinion that this product is no longer suitable for SOHO/SMB. It always seems to take a fair amount of time and effort to recover from one of Retrospect's problems. And as the size of our backups has increased, Retrospect's frailty is becoming increasingly apparent.

Link to comment
Share on other sites

Quote:

So I have to stand by my opinion that this product is no longer suitable for SOHO/SMB. It always seems to take a fair amount of time and effort to recover from one of Retrospect's problems. And as the size of our backups has increased, Retrospect's frailty is becoming increasingly apparent.

 


You just appear to want to rant. As previously explained, you don't have sufficient hardware to support your needs, and Retrospect is just a program that needs lots of RAM to deal with that many files. If you get more RAM, you will have better results. It's like trying to run a digital photo editing program in 512 MB of RAM.

 

Dave's suggestion decomposed the problem into a smaller problem that could be handled on your hardware. Your problem has been identified as not one with Retrospect, but one of insufficient RAM in which to do what you are asking of the program.

 

If you aren't willing to upgrade your hardware for what is needed, then, yes, you will be disappointed. Sorry that you didn't want to solve your problem because the solution is known and has been shown in your case.

 

Russ

Link to comment
Share on other sites

> It's NOT a matter of the hardware, as it happened on two machines, at the same

> point in the re-catalog process

 

While reproducing an issue on multiple hardware platforms helps to isolate software issues, consider the fact that if you get out-of-memory errors on two different machines it's perfectly possible that neither one had enough memory to begin with. Simply claiming that "unix never runs out of memory, it just slows down" isn't realistic.

 

> Fortunately my disks were 250GB each, so the failure at about 375 GB could be managed

> with the above procedure. But what if I had been using 500GB removables. Would it still

> happen around 375GB?

 

Perhaps, perhaps not. Perhaps attempting the procedure with 2 GB of RAM instead of 1.5 GB would have been successful without the workaround. Without testing, I have no way of knowing how Retrospect's memory requirements scale.

 

> And as the size of our backups has increased, Retrospect's frailty is becoming increasingly apparent.

 

Consider that Retrospect for Macintosh does not have Disk Backup Sets as its Windows counterpart does. The Removable Backup Sets you're using were originally created for floppy, Zip, Jazz and MO media. The option to treat fixed platter hard drives _as if_ they were removable media devices was added to the program to provide additional flexibility. But it has limits, such as a 1 TB limit on data written to any specific Member volume.

 

Contrast that with Tape Backup Sets, which were designed from the start for larger data storage, and which, as of version 6.0, have no Terrabyte limit. Russ will attest to the appropriateness of such Backup Sets to SMB, even though the hardware is more expensive and the storage is linear (thus slowing down Restores).

 

Still, refusing to feed your software the silicon it requires to perform the tasks you assign to it seems stubborn and short-sighted.

 

Dave

Link to comment
Share on other sites

Quote:

Russ will attest to the appropriateness of such (tape) Backup Sets to SMB

 


Saved our butts when we had a fire a couple years ago. Lost all of our computers, but the offsite backups and Retrospect had us up and running on new hardware in temporary offices on Monday after the fire on Friday night. No data was lost (but we had a plan in place that had been tested).

 

Quote:

even though the hardware is more expensive

 


It's all relative. Ask the value of your data and cost to recreate that data and cost if not able to replace the data. And, to me, lower end autoloaders are not that expensive. Exabyte has an entry-level 10-slot autoloader (Exabyte VXA-172 1x10 1u autoloader) that is functionally equivalent to their older VXA-2 technology drive in the same autoloader. Stores about 120 GB (compressed) on each X-23 tape using Retrospect (max tape rated capacity is 160 GB, if you believe marketing hype). The price is $1,720.54 (Exabyte model 119.00700 (SCSI)) or $1,634.96 for the VXA-2 version (SCSI) (prices in USD from MacConnection moments ago). The VXA-2 version is also available in firewire, and I understand the VXA-172 version will be out later this year in a firewire version. The nice thing about the VXA-172 is that it is a "crippled" version of the VXA-320 drive which has double capacity (320 GB per tape, compressed; realistically, about 225 or so GB) that, by purchase of a firmware upgrade that can be uploaded with a utility, becomes the double-capacity VXA-320 as your backup capacity needs increase. If you do the math, the VXA-320 version pays for itself in two autoloader fills.

 

Quote:

and the storage is linear (thus slowing down Restores).

 


Other peoples' needs may differ from ours. Restore is rare; backup is daily. Only time that the linear nature of the tape is notices is the rewind time before the verify pass and rewind on close/eject.

 

As one of my professors at MIT said back in the 1970s, "never underestimate the bandwidth of a station wagon full of mag tapes."

 

Russ

Link to comment
Share on other sites

Quote:

You just appear to want to rant. As previously explained, you don't have sufficient hardware to support your needs, and Retrospect is just a program that needs lots of RAM to deal with that many files. If you get more RAM, you will have better results. It's like trying to run a digital photo editing program in 512 MB of RAM.

 

 

 


 

On the contrary. I provided a clear test case that demonstrates that hardware is NOT the issue.

Case 1: 2x400MHz G4/1.25 GB RAM/~10GB free on boot

Case 2: 1x2GHz G5/0.5 GB RAM/~200 GB free on boot

 

Yet the same exact fault occured. The common factor IS Retrospect.

 

More to the point, it is not only reasonable to wonder whether Retrospect can handle re-catalogging larger removable drives, it is prudent to assume it cannot re-catalog until EMC proves it can.

 

In fact if other hardware is required, then it is incumbent upon EMC to provide a HCL that specifies the requirements. I don't care if it's a Beowulf cluster usng MPI.

 

The fact is Retrospect failed repeatedly (on both machines) at about 375 GB into a re-catalog. That's not a rant. It's a statement of fact based on my repeated experiments.

 

I'm sure others would welcome reports about re-cataloging terabyte-size drives, so we can determine the budgetary requirements needed to support this software.

Link to comment
Share on other sites

  • 4 weeks later...

I have been getting the same problem with retrospect failing to rebuild corrupt catalog files.

 

System: OS 10.4.8 server

RAM: 4GB

Powermac G5 - Single 1.8 GHz

Retrospect version 6.1.126

Retrospect Driver Update, version 6.1.5.102

Backup drive: Lacie big disk firewire 400 1TB

 

Boot drive free space: 215.55 GB

 

Backup drive free space: 112.63 GB

 

I am using a File Backup Set and am using the following command:

 

Tools --> Repair --> Repair file backup set

 

From the log:

 

Executing Recatalog at 3/21/2007 5:25 PM

To backup set 2007-16-02

> Not enough memory

3/22/2007 1:55:52 AM: Execution incomplete.

Completed: 2820887 files, 388.2 GB

Performance: 779.0 MB/minute

Duration: 08:30:08

 

Any ideas how to rebuild the backup catalog ?

 

This seems to be happening more often now. Not sure if this is due to a problem with the lacie, Retrospect crashing or a new OS X update.

 

Many thanks

 

James

Link to comment
Share on other sites

Quote:

Not sure if this is due to a problem with the lacie, Retrospect crashing or a new OS X update.

 


 

There have been other reported problems with the LaCie Bigs (this is two drives stripped by some custom hardware in the LaCie case, right?).

 

You don't say how large your Backup Set file is, but if you don't have any files on the drive other then the File Backup Set and it's companion catalog file, then with 112.63 GB free your file must be very, very large.

 

You may be pushing the limits of what the program can do with that Type of Backup Set.

 

What happens when you use "Update Existing Catalog File?"

 

Dave

Link to comment
Share on other sites

Thanks for the reply Dave.

 

I have tried the "update existing catalog" option after the failed rebuild and still get an out of memory error. See below.

 

Tools --> Repair ---> Update existing catalog file

 

Executing Recatalog at 3/24/2007 9:43 AM

To backup set 2007-16-02

> Not enough memory

3/24/2007 3:41:05 PM: Execution incomplete

Completed: 350268 files, 102.8 GB

Performance: 294.6 MB/minute

Duration: 05:57:10

 

Backup set 1: 531.83 GB

 

I also have 3 other backup sets on this drive, none of which have any problems:

 

Backup set 2: 257.39 GB

Backup set 3: 6.78 GB

Backup set 4: 17.53 GB

 

I currently have around 15 Lacie 1TB drives with Retrospect backups. When a drive is full, I just hook up a new one and start a new backup set.

 

Only 2 drives have had this error. I am starting to think that Retrospect simply can't cope with a large backup set as a single file, despite supporting 1TB drives.

 

If you partition the drive, is it possible to span a large backup over the partitions or will I get the same out of memory error ? I wonder if it is possible to span the backup catalog. It seems the problem is in rebuilding the catalog itself.

 

I see this as a bug in retrospect myself. Glad I have tape to full back on.

 

However, the worrying thing is that if Retrospect can't rebuild a catalog file from a large backup set, then are my tapes just as worthless as a my backup file if the catalog gets corrupted ?

 

I can't see anyway of getting the data back if you can't rebuild the catalog file. My tape backup sets regularly grow to close to 1TB (4 tapes) before starting a new set.

 

Is there anyway of assigning more memory to retrospect ??? I see this as a fatal flaw.

 

Thanks

 

James

Link to comment
Share on other sites

Quote:

I wonder if it is possible to span the backup catalog. It seems the problem is in rebuilding the catalog itself.

 


 

The question suggests either you're unfamiliar with how Retrospect works, or that this discussion has wandered from accuracy to assumption.

 

- ARE you using a File Backup Set?

If the answer is yes, then the data file and the catalog file are always together, like bread and butter.

In past times, a File Backup Set (and before that, a File Storage Set) lived as a single file, which included the data and the catalog information. The former was stored in the file's data fork, while the latter was stored in the file's resource fork. But apple's HFS file system had/has a limit to how much data can be held in a file's resource fork, and since catalog needs grow with larger file counts, OS X brought on a need to get past that limit. So splitting a File Backup Set was introduced with Retrospect 5.0. But in general, there shouldn't be a need to rebuild a File Backup Set's catalog file, since it should live alongside the data. So, why do you need to?

 

If you want to span backup _data_ across volumes, you can use a Removable Backup Set, and store the catalog file on another drive/volume/sharepoint. Note that Removable Backup Sets have a 1 TB limit per volume.

 

Catalog files cannot be spanned; they are a file that is activly read from/written to during backup or restore.

 

Other Types of Backup Sets are different; the catalog file is truly independant of the data, and can be lost even if the data is secure. Rebuilding is more likley necessary. It may be that the other Types of Backup Sets can rebuld large datasources easier then the special File Backup Set.

 

> I see this as a bug in retrospect myself

 

It depends on what "this" is. If your 531 GB File Backup Set has so many files that Retrospect can't get enough memory to handle them all (and note that it's the number of files, not the size of them that matters), then it's a limitation of the program as opposed to a bug per se.

 

- How many files in the Backup Set?

- How many sessions in the Backup Set?

Link to comment
Share on other sites

Hi Dave,

 

My point was simply that if retrospect cannot rebuild a large catalog file, then perhaps spanning the file into smaller sections might be a work around in the future.

 

The reason I need to rebuild the backup set catalog file is because it has become corrupted by retrospect crashing and is now no longer readable. Without a working catalog file I cannot recover any data from the backup set.

 

I would have thought it is reasonable to assume that retrospect can rebuild any catalog file, given the fact that the software offers this "feature". Surely it is obvious that if Retrospect offers the ability to make large backup sets, then the number of files and sessions in that set will also be large ?

 

As the original backup catalog is corrupt, I can only give you the figures from the attempted repair (which failed)

 

Used size on disk: 531.83 GB

Used size according to failed repair of catalog: 490.7 GB

Number of files in the backup set: 3,171,004

Number of sessions: 287

 

Attempting a restore using this catalog seems to work, although the last few weeks of backup appear to be inaccessible and I don’t get any out of sync error.

 

Any advice on how to solve the problem would be appreciated.

 

Thanks for the feedback.

 

James

Link to comment
Share on other sites

You indicated that you tried to repair the catalog file, and that you tried to "update existing" at least once. Did you then try again to update the existing catalog and fail? If not, I'd suggest trying again to "update existing." By the stats you supplied above, your first attempt at updating after the rebuild clearly got you closer to a complete catalog, and it may be that, through repeated iterations, you can eventually complete the catalog update.

Link to comment
Share on other sites

Hi Dave,

 

Yes I was also thinking this. I have copied the partially working catalog file (so I don't have to recreate it again) and set the server to update after my last post. I will post the results when it finishes the "update existing" cycle. I hope it works.

 

Thanks

 

James

Link to comment
Share on other sites

Quote:

> I would have thought it is reasonable to assume that retrospect can rebuild any catalog file, given the fact that the software offers this "feature"

 


 

Perfectly reasonable.

 

Except that is not what you are trying to do.

 

You are having difficult _repairing_ a File Backup Set. Such sets are special, as I noted in my post #95632 above.

 

So much of Retrospect 5.0, 6.0 and 6.1 are the same as good old version 4.3, including the Repair options. Before File Backup Sets broke the catalog out of the data, having a "Rebuild from File Backup Set" option would not have made any sense. So while Retrospect does appear able to re-create a missing catalog portion of a separated File Backup Set, this was not part of the program's initial design (and may never have been sanity tested or stress tested).

 

All other Backup Sets were designed from the ground up to support the recreation of a Catalog file from the data on the Media. These seem to be rebuildable pretty dependably, either from scratch or from an older existing copy, provided the data on the Media is sound.

 

I also hope that using both the "Repair" and the "Update" options work for you.

 

 

Dave

Link to comment
Share on other sites

Quote:

The reason I need to rebuild the backup set catalog file is because it has become corrupted by retrospect crashing and is now no longer readable.

 


 

Can you please explain this more thoroughly? What does "no longer readable" mean exactly? What steps do you take, and what errors do you receive.

 

Dave

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...