Chris Caouette wrote:UPDATE: Problem Solved.

The sample was inconclusive, but the log file you uploaded was full of -36 errors. I'm satisfied that this is the same Airport bug that 1.1.3a6 works around.

I'm glad you were able to resolve the problem, and please post anything else odd that you encounter.

Chris Caouette wrote:Activity monitor was at 0 and I left it overnight. It definitely stops at iPhoto and 1.59GB.

That's definitely "stuck."

A good test would be to perform the same capture, to the same archive, on the same volume, but when it's connected directly to the Mac Pro. If that works, then it seems likely that this is a network/Airport issue.

If you want to help track down the problem, do this:

Let the capture run until it gets stuck.

Open the Activity Monitor.

Find and select the QRecallHelper process (I usually type "QRe" into the search field).

Get the PID number of the process.

Open a window in Terminal.

Issue the following command, replacing PID with the number from Activity Monitor:

sudo sample PID -file ~/Desktop/QRecallHelper.sample.txt

Enter your account password

When it's done, e-mail me the QRecallHelper.sample.txt that's now on your desktop, followed by a diagnostic report (Help > Send Report...).

Chris Caouette wrote:Every time the file gets to iPhoto at 1.59GB it stops.

My first question is "does it really stop?" My second questions is "how long did you wait?"

Some directories contain hundreds, even thousands, of items. This is especially true of folders containing music, pictures, and mail, were the application keeps lots of individual files in one massive folder. This requires QRecall to read and compare hundreds, if not thousands, of file records which in turn require tens of thousands of little reads from the archive.

On a local drive, this can be accomplished pretty quickly. But on some networked file systems this can take orders of magnitude more time. It may seem like the capture is "stuck," when in reality it's simply grinding its way through a bazillion file records.

The way to test this theory is to run an application like Activity Monitor. If the QRecall capture is still working, you should see a steady flurry of small network reads and sends. If you see that, and the CPU usage of QRecall Helper indicates activity, then it's probably still working. BTW, you can use the Activity Monitor to force quit the QRecall Helper process if you need to force an action to stop.

Chris Caouette wrote:I do hourly backups and want to keep the last 24 hours, then those would get merged to a single layer for the day and kept for 14 days.

Create a rolling merge action that:

Keeps most recent 1 day

14 Day layers

After that, what you keep, how often, and how long is up to you.

The "Keep most recent" setting basically ignores any layers created in that time period. So keeping 1 day will leave your last 24 hour's worth of captures alone.[*]

The "14 day layers" create 14 one-day time periods following what you keep. All of the layers within each time period (day) are then merged into a single layer, keeping only the last version of each file.

The logic repeats using successive periods of weeks, months, and years.

PS: I did a test full recovery to a temporary partition and it booted flawlessly!

Always good to know.

[*] Footnote: The rolling merge time periods are always calculated relative to midnight the morning of the day you run the merge (i.e. 00:00:01). So running a merge at 1:00 AM and 11:59 PM has the same effect. It also implies that any captures done between midnight and now are always ignored, since the ignore period always starts at the last midnight.

Gavin Petken wrote:Getting this error as well, after SL upgrade, but only on 1 out of 3 machines

Gavin,

Definitely try 1.1.3a6, at least on the computer that's getting the error. It's fixed the majority of problems with Snow Leopard. If you continue to have problems, send a diagnostic report.

Chris Caouette wrote:Can I restore the Qrecall archive to a new blank drive a be able to boot from it or do I need to install the basic OS first?

Either, as long as you're restoring from the same generation of Mac OS X. Changes in the filesystem make it impossible to restore a Leopard system using Tiger, or a Snow Leopard system using Leopard.

My recommended backup strategy is to install a minimal copy of your current OS on a bootable external drive. Strip off everything you don't need (apps, languages, printers, etc), install QRecall, and then use that drive to store your QRecall archives.

If disaster should strike your startup drive, boot from the external and restore your startup volume.

Glenn Henshaw wrote:I've sent a report as well.

Glenn, thanks for the feedback and the diagnostic report.

Just to confirm, is your archive on an Airport Express volume too?

As a follow up, I tested this a little on Snow Leopard. I've been meaning to do this as part of testing the as-yet-to-be-released Mac OS X 10.6.1, so now seemed as good a time as any.

I have a Snow Leopard installation on an external drive that's been running QRecall 1.1.3. It had been running 10.6, which I upgraded to the (pre-release) 10.6.1. I then captured the 10.6.1 system, rewound the archive, restored the 10.6 system, and restarted.

It booted just fine and I launched about a dozen apps to test it out. I confirmed that it was running 10.6. I then restored again, this time restoring the 10.6.1 system captured earlier, restarted, and was rewarded with another working system running 10.6.1 (again, pre-release).

So capturing and restoring the boot volume from Snow Leopard seems to be working still. I'll attempt to capture the same system later using Leopard. A second experiment would be to restore from the archive captured by the Snow Leopard system using Leopard and see what happens.

Jeffrey Wilson wrote:I'm Using the Trial Version of Qrecall 1.1.3 and I have restored my Startup Drive Twice but everytime I do I get a kernal panic and the drive won't boot. I'm Using an external firewire drive with 10.5.8 on it to Restore Snow Leopard and I can see from the external drive that all of the contents have restored onto my startup drive but when I restart my imac it won't boot and gives the kernal panic.

Jeffery,

I've never tested that sequence of events, but I wouldn't be surprised if what you're trying to do is impossible. Snow Leopard (10.6) introduces a number of new file features, like compressed data and resource forks, that appear as non-standard or empty data when viewed from Leopard (10.5). It's entirely possible that capturing or restoring a Snow Leopard installation via Leopard will leave critical bits of information behind. Similarly, you can't capture or recall a Leopard installation using Tiger.

Did you capture the OS using Snow Leopard or Leopard? If you captured it using Leopard, you may be hosed?but again, I've never tried it so I don't know.

Have you tried restoring it using Snow Leopard? QRecall supports a "live" restore of your booted OS. You should be able to install a new copy of Snow Leopard, boot from that volume, restore over it (don't attempt to use the computer for anything else during the process), and then immediately restart.

John Heagy wrote:I suppose you never got my email last week reporting success, see below.

I got your e-mail, I guess you didn't get my reply.

That did the trick. I used the 1st setting and the 600GB proceeded at a healthy clip, as high as 320MB/sec from one volume to another.

That's good to hear. Thanks for taking out the patched version out for a spin.

The only odd thing is it keeps capturing 3 empty folders - see attached. I also sent a report.

Thanks for the diagnostic report. I can't tell from the log what it's capturing or why. If you really want to find out, there's a special QRecall setting that will shed some light on the issue. See the QRLogCaptureDecisions setting. Once you've captured everything and nothing (ostensibly) has changed, set this option and preform another capture. It will log the reason it captured those three folders. Make sure you turn it off when you're done, or it will produce a tremendous amount of log file activity.

It seems QRecall will not open an archive over a network share.. is that correct?

Absolutely, you should be able to open it. QRecall should be able to open an archive on any readable volume.

Looking through your log it appears that you're getting an error -61 (write access error) when you try to open the archive. I surmise that the archive is on a volume or in a directory which is not writable by the client. This is, unfortunately, a side-effect of a workaround for a file sharing bug in AppleShare.

If you change the access privileges so that the archive is writable from the client (which is the norm) you shouldn't have any problems opening it. Note that archive must be writeable from the client to perform almost any other action (repair, compact, merge, delete, etc.).

In the mean time, I'll add the error -61 problem to the bug list.

John,

I was wondering what success you'd had with the Xsan and 1.1.3a5, and if you were successful in opening an archive in a read-only folder?

Hmmm. I'm not see that here, but let's try this experiment. Open up a Terminal window and issue the command

defaults write com.qrecall.client QRFilePreallocateDisable -boolean true

See if that helps, or not. Either way, send me a diagnostic report (Help > Send Report...) after you've tried it.

Thanks

Chris,

The problem is definitely a bug in Snow Leopard, but turned out to be something with a fairly simple workaround. If you want to give it a try, you can download QRecall 1.1.3a6. As usual, follow these steps to upgrade (I swear I'll write a script for this someday):

- Drag your existing QRecall application to the trash (do not empty the trash).
- Download and open the QRecall disk image.
- Drag the new QRecall to your Applications folder, or wherever you have it installed
- Eject the disk image
- Launch the new QRecall. Follow any upgrade instructions.
- You can now empty the trash.

Let me know if this works or if you have any additional problems.

Chris Caouette wrote:I should also point out that this is on a drive attached to my airport extreme.

Thanks for mentioning that, Chris. I would have been scratching my head all day.

It's definitely a problem with the Airport Extreme and/or Snow Leopard. I have a fairly recent Airport Extreme running the latest firmware (7.4.2). I attached a spare drive to it and set up a capture. Within 10 minutes the capture failed with exactly the error that you're getting. I repeated it three times with the same results.

I unplugged the drive from the basestation, and plugged it into my USB hub. So it's the same drive, with the same archive, using the same interface, and capturing from the same computer. I started the capture action again and it ran flawlessly for over an hour (captured about 75GB).

I then moved the drive back to the Airport basestation and set up similar capture to the same archive from my laptop, which is still running Mac OS X 10.5.8. It's been running now for over an hour without any problems.

I'll try to perform some more specific tests this week to determine exactly where the failure is occurring, but for now I don't have much in they way of a suggestion. I suspect that this is a Snow Leopard bug, or Snow Leopard has exposed a flaw in the Airport Extreme. I suspect that there's not much I'll be able to do except reproduce the problem, report it to Apple, and hope they have a workaround or will fix it soon.

Chris Caouette wrote:I have snow leopard and 1.1.3 but suddenly I can no longer get Qrecall to run its automated back and I receive the error in the Subject.

Chris,

Send a diagnostic report (Help > Send Report...) and we'll see if there are any details in the log file that might help narrow down the problem.