Tiger problems

[seidman]

I've recently upgraded to Tiger and have since been having problems using Retrospect 6.0. I just installed the latest version (212), and the program is not recognizing my hard drive. Every time, I get the message "volume Macintosh HD is unavailable". Has anyone else experienced this problem?

 

Steve Seidman

[CallMeDave]

Steve, your post is devoid of much specific information about your backup configuration. Can you provide a step by step description of what you're doing and what happens when you do it?

 

Dave

[seidman]

Dave,

 

Here's a complete picture of what I've been experiencing. I'm using a 17-inch G4 laptop running OS 10.4.1. My backup device is a LaCie FireWire hard drive. My version of Retrospect is 6.0.212. When I start Retrospect, I click on "backup". When I choose "destination" from the immediate backup window, I select "file" as the backup set type, since I want to back uo to the external hard drive. I then create a backup set. I then choose the laptop's hard drive as the source for the backup, and I request backup for "all files except cache files". I then click "backup", and I get the following message: "Volume Macintosh HD is unavailable. Please insert it and try again."

 

I hope that this detail helps toward obtaining a diagnosis of the problem.

 

Thanks,

 

Steve

[CallMeDave]

- Is "Macintosh HD" your internal Powerbook hard drive, or the external LaCie FW drive?

[seidman]

The text under the icons for the two drives are as follows:

 

Macintosh HD --- the internal hard drive

LACIE --- the external hard drive

[CallMeDave]

The steps you've provided would indicate that your internal drive is not mounted, which is quite unlikely.

 

- If, after you get the error, you go back to Immediate->Backup, do you see "Macintosh HD" as the Source?

- If you click on the "Source" area in the Immediate Backup window, do you see "Macintosh HD" as a choice?

- Are there more then one instance of "Macintosh HD" shown in Configure->Volumes ?

[seidman]

Dave,

 

Thanks for the suggestions. There are two instances of "Macintosh HD" shown in Configure->Volumes. Only one had shown my home directory as a subvolume, and this was the one I first chose (and the one that led to the problems I described above). When I chose the second instance, Retrospect ran fine. Do you have any idea why two instances of the HD appear in the volumes window?

 

Steve

[traderjim]

I've recently upgraded to Tiger as well, from 9.2.2 (finally had to do it!) and upgraded Retrospect to 6.0 as well. I also installed the latest version (212 upgrader), and the program is also not recognizing my main internal hard drive. I also get the message "volume Macintosh HD is unavailable". The log file indicates an "error -53", volume offline. Like you I am also backing up to an external hard drive where the backup set is located.

 

It is clear there is a real bug in Retrospect 6.0 when running under Tiger. I have seen references to this same bug in many other posts in this forum in different categories. It is a generic problem. It needs to be fixed.

 

One poster suggested that under OS X that some drives do not have a proper drive "create date" set, and that causes Mac OS X to report the drive as offline to Retrospect. However I checked my disks with techtool pro and they all have valid create dates, so that is NOT the cause of this problem.

[CallMeDave]

Quote:

---

There are two instances of "Macintosh HD" shown in Configure->Volumes ... Do you have any idea why two instances of the HD appear in the volumes window?

 

---

 

If one is grey, then it's left over from another logical volume that Retrospect saw at some point. Perhaps you've upgraded the machine, or moved your preference file from another machine. Retrospect is not fooled by different volumes that have the same name.

 

Select this "ghost" volume and press the Delete key to "forget" the volume. From then on you shouldn't have any problem

[seidman]

Thanks for the suggestion. As it turns out, I did move the preference file from another machine. I've now deleted the "ghost" volume and all seems fine noe.

 

Steve

[traderjim]

You also get grayed out versions of volumes in the Volumes list as a result of not deleting old (pre 6.0) backup sets and pre-6.0 backup scripts from Retrospect, even if the volume names have not changed and they are in fact the same volume as the drives you currently are using. This is why so many people upgrading to 6.0 are going to see this problem. It is practically guaranteed to occur for 100% of the people upgrading to 6.0 They will get the error message saying their backup set i s no longer writable and must now be read-only, after a quick conversion, but they won't get any clue that they need to go into their scripts and re-enter the source volumes, after first deleting the old ghost images of those volumes from the Volumes list. Chaos is assured here.

[blantyr]

While I haven't been having the problem described in this thread, I have been crashing when attempting to backup my internal drive to a file on an external LaCie Firewire drive.

 

Apple recently released a new upgrade to Tiger, 10.4.2. While it is too soon to be sure all my problems have cleared up, two volume backups that were consistently crashing under 10.4.1 just ran clean under 10.4.2. Those who think there might be bugs in Tiger's drivers might want to hit Software Update.

[pmacnerd]

Blantyr,

 

I have the same config (Tiger recently upgraded to 10.4.2 and Lacie FW Drive). Lacie has a firmware update for their firewire drives that fixes the crash problem, and supposedly prepares the drive for Tiger. I've loaded it and the drive is very stable, however the challenge I'm now having is that my backup performance dropped from 525 Mb/s to about 350 Mb/s!!!!!

 

Which means my backups (recycle anyway) are taking about 12 hours with verify and compression on.

 

I'm about to go back to the Lacie website to see if anyone else is having this issue. Anyone here seen the same thing? How is your performance Blantyr?

 

Thanks.

[traderjim]

I have seen backup performance drop from a previous 800 MB/min under MacOS 9.2.2 with Retrospect 5.1 to an external SCSI-320 drive to 160 MB/min under OS X with Retrospect 6.0. A huge drop. Total backup time is going to be simply unacceptable at that speed, as I have over 40 GB of stuff that has to be backed up.

 

Currently however I can't get past the first 800 MB of the backup, since Retrospect gets an "internal consistency check failed - tree.c-3444" error and then quits. So you might say I am really getting 0.0 MB/min performance.

 

I am now questioning if I can stay with Retrospect. I think the time has come when I will have to switch to a competitor's offering.

[traderjim]

I have now upgraded Tiger to 10.4.2, run all the available software updates, ran Disk Utility and repaired permissions on all disks and verified/repaired all disks (booting from the OSX install CD to do this on the boot hard drive, of course), disabled spotlight indexing via Spotless, and I STILL get the "internal consistency check failed: tree.c-3444" error every time. I even tried booting in "safe" mode and I get the same error at the same point.

 

So it appears that there is nothing that can be done at this point. Retrospect is just fatally flawed.

[robross]

I just bought Retrospect Desktop 6.0 three days ago, and downloaded the upgrade so I'm now running 6.0.212. It's the first time I'm running Retrospect on Mac OS X. (Although I used to run it many years ago to back up a small network of Mac OS 8 and Windows PCs).

 

I have a PowerBook G4 15" 1.67Mhz (the latest model) with Tiger v10.4.2 (with all the latest updates as of 7/16/05. My backup volume is an external LaCie 512GB drive, partitioned into 5 volumes, connected via FireWire800.

 

I was able to do a full backup one time, but after this I continually get the "Internal consistency check failed: Assertion check at "tree.c-3444"" any time I try to do any kind of backup, whether Normal or Recycle, even when I create a new Backup set.

 

I've been trying for 3 days to get this to work with no luck. I think the latest retrospect "patch" still has major issues with Tiger.

[traderjim]

I have been able to figure out that the" internal consistency check failure: tree.c" error is associated with specific files or folders deep within some application's packages. Just about every package has a ton of folders and files within it, all hidden from the finder unless you hold down the control key and open them explicitly. Deep within them there is a "Resources" folder. I am finding that this error occurs always at the exact same point, on one of those Resource folders. I suspect that the file structure inside that folder is doing something to Retrospect that causes the problem, even though Disk Utility, TechTool Pro, etc all report the disk strcuture and directory structure as being fine on that volume.

 

Unfortunately the log file has no verbose option to be able to tell which specific Resources folder this occurs on.

 

I would like to hear from anyone else who has seen this error message. Specifically, does Retrospect indicate it was in the process of backing up a "Resources" folder on the main status display window when the error occurs for anyone else?

[blantyr]

Pmacnerd inquired about my performance. My system does seem to have slowed. I am only backing up a single machine. I generally trigger the script and let it run over night. Thus, this is more gut feel than hard numbers.

 

One other recent change for me was from Norton Utilities to TechTools Pro. Symantic apparently decided that the effort in handling changes in disk file structure in going to Tiger wasn't worth staying in the Mac market, so I switched utilities programs.

 

One thing I learned during the switchover was 'journaling.' Apparently, if you enable journaling -- active by default -- every action taken on the disk is saved to the disk. If one suddenly loses power with journaling enabled, the OS can recover much cleaner than it used to, as it knows exactly what was going on at the time of the sudden shutdown. I would think the downside would be performance. TechTools Pro makes you turn off journaling before it will fully de-fragment a disk. (Disk defragment is slow enough with journaling disabled.) TechTools has a menu which allows you to enable / disable journaling through a GUI. You might also go to command line and do a "man" on "diskutil," looking for the commands "enableJournal" and "disableJournal". This might or might not help your performance in the highly IO driven business of backups. Note, it is not just MacOS which has added journaling. Other UNIX based systems also have the 'feature.'

 

I fear I also got a crash without error message while running Tiger 10.4.2. While I am having much more success running Retrospect .212 now than under 10.4.1, I have had one Assertion Check at Tree.c-3444, one crash with no error message, and about 4 good runs. Both errors came when backing up my internal boot drive. I have consistently been able to back up my smaller external LaCie Firewire drive to the larger LaCie Firewire drive without trouble.

 

I have since got a good backup of my boot drive. I went into paranoid mode. I declared my small external disk to be my data disk, moving my data off my internal disk, reserving my internal disk to be system and applications, thus freeing up some space on the internal drive. I used TechTools to verify the boot drive's directory structure, rebuilt the boot disk's directory structure, then de-fragmented the disk. After all that, I could see and hear spotlight re-cataloging the internal drive, so I just let my machine sit overnight, until spotlight idled. THEN I ran Retrospect, and got a good backup. I don't know what I did that helped, or if I was just lucky, but I am not feeling happy, that all is right with the world. Even if this continues to work for me on a single system, I doubt folks trying to keep a large group of machines backed up will be happy.

[traderjim]

After doing a bunch more experiments, selectively excluding some folders and files from backup, I now know that the problem with the internal consistency check failed: tree.c-3444 error is associated with having a very large number of folders and files deeply nested within the Appications folder. As long as I exclude several application's packages from the backup, it now proceeds without this error. It does not matter which application's I choose - I just have to randomly exclude 2 or 3 of them, and it will work.

 

If I try to back up the disk while leaving the entire Applications folder enabled for backup, I always get the tree.c error, and it always occurs exactly after 896 MB have been backed up (of the 21 GB to be backed up for this disk).

 

So it appears that having a very large numbers of files and folders inside the Aplications folder (presumably this would also apply to any other folder on the disk) triggers some sort of overflow of some fixed limit within Retrospect's internal data structures dealing with the directory tree. Once the limit is reached, the data structure gets corrupted in some way, giving the internal consistency check error.

 

It's definitely a fatal bug. I hope someone at Dantz reads these forum postings and takes notice.

[traderjim]

Made it all the way through a backup last night OK. Backed up two disks and over 40 GB of data without errors.

 

In order to do this I ultimately had to exclude only two files from the backup: DVDPlayer, and Dictionary, in the Applications folder. That was the minimal set, discovered via a binary search where I selectiely excluded applications from the backup in groups and treid it over and over. If either of them was included, I got either a crash or a tree.c error.

 

Disk Warriror, Disk Utility, and TechTool Pro (all latest versions with Tiger updates) all report the directories and files are fine, so if this is some sort of corrupted file/folder issue that is triggering this assertion check in Retrospect, then it is something that none of these utilities can detect.

[CallMeDave]

The next test is to do a backup of _just_ these packages.

 

Put one in an empty folder, define the folder as a subvolume, and use that subvolume as the Source of a backup.

 

- What happens?

[traderjim]

I'll have to give that a try when I get a round TUIT....

 

I am pretty sure it will work though. In previous iterations of this binary search, I was able to also get the backup process to work by excluding other groups of applications, and having DVDPlayer and Dictionary included. Sometimes it took up to four applications being excluded to make it work. However it did not appear to be necessary to exclude any particular application. It just requires that several be excluded. Excluding these two was the minimal set.

 

It is possible that with enough time, I could find another pair of aplications to exclude that would also make it work. Howver it takes a while to do each test, since Retrospect must scan the whole catalog (of 240K files) before it even gets started copying data.

 

This is why i think there is an overall directory tree size issue that is in fact triggering the tree.c assertion, as opposed to some sort of directory or file corruption.

[traderjim]

OK, I just tried your suggestion. I put DVDPlayer and Dictionary in a folder, defined the folder as a subvolume, then did a backup of that subvolume to a new backup set on another drive. It worked fine including the verification, with no errors.

[Guest]

On a Power Mac G4 (Quicksilver) with 1.12 GB memory, updated firmware on external LaCie d2 firewire hard disk HFS+, did an "Archive and Install" of Tiger on internal disk, applied 10.4.2 combo update, applied other updates, downloaded and installed Retrospect 6.0.212.

 

New media backup of internal disk onto external FW drive dies with assertion check at elem.c-821 after backing up less than 10%:

 

? Retrospect version 6.0.212

launched at 7/21/2005 5:19 PM

+ Retrospect Driver Update, version 6.3.102

 

+ New Media backup using garage d2 at 7/21/2005 5:20 PM

To backup set garage on d2 [002]…

7/21/2005 5:20:23 PM: New Media backup: The backup set replaced with garage on d2 [003]

 

- 7/21/2005 5:20:23 PM: Copying Tofari…

* Separating file backup set:

Data file name: garage on d2 [003]

Catalog file name: garage on d2 [003].cat

Internal consistency check failed:

Assertion check at "elem.c-821"

7/21/2005 5:48:51 PM: Execution incomplete.

Remaining: 478112 files, 21.5 GB

Completed: 17667 files, 1.6 GB

Performance: 330.9 MB/minute

Duration: 00:28:28 (00:23:47 idle/loading/preparing)

 

Quit at 7/21/2005 5:48 PM

[CallMeDave]

It appears that someone from Dantz has posted a comment about this:

 

http://forums.dantz.com/ubbthreads/showflat.php?Cat=&Number=58564&Main=57997#Post58564

 

Odd though "Michaeln" doesn't identify himself as a Dantz representative, his language seems to imply his status:

 

The second issue (tree.c-3444 and elem.c-821) is a Retrospect bug which our engineers are working to track down and resolve. This is a high priority issue and we will notify you of any fixes as soon as they are available.