Andrew Daws wrote:when I try to repair one it says it's doing it but never does.

Post, or e-mail me, your log files and I'll try to determine what the problem is.

The majority of the problems I see in your log are I/O errors. It appears that QRecall is simply losing connection with the server that it's writing to. As you've discovered, this has rather catastrophic consequences for the data integrity of the archive.

If Amazon SSS is anything like .Mac (I have no experience with Amazon SSS), it will appear to be blindingly fast at first. It's an illusion. Because of the slow transfer speeds of home Internet connections, these drivers buffer massive amounts of data locally. So you can write megabytes of data to the drive and it appears to be written instantly. But when it's time to close the file or disconnect the volume, it hangs for 20 minutes while it finishes sending the data.

I don't know why a local NAS volume would be that slow. Have you tried simply copying some very large files to the device? (QRecall archives make particularly good test subjects.)

$40? That's good news. I'm sure I could get several of my clients to stump up that much. Might there even be some kind of reseller discount???

Not at the moment.

Andrew Daws wrote:I'm currently backing up to a NAS, and so far it's taken 13 hours to do 7 Gb out of 130.

I'd be curious to learn what the network configuration is. Is this a remote storage via a DSL or Cable connection, or this on a LAN? Ethernet or WiFi?

The problem with Amazon SSS is that QRecall kept stopping working. sorry that's not more specific, but it did seem to get confused.

Zip up the log files in ~/Library/Logs/QRecall and either e-mail them to me or post them in the forum. There could be some clues as to what's going on.

How close are we to a release version and do you have any ideas on costing yet?

I initially planned to have the final release ready last month, but a series of Leopard compatibility issues has pushed that out. Baring any more castrophic bugs, I plan to have the first commercial release of QRecall ready by MacWorld in January.

An identity key is $40. You will need at least one key to capture data.

A household (all of the people/computers that share a primary residence) are permitted to reuse a single key to capture data to separate archives.

You will need multiple keys if you want to capture data from two or more computers to a single archive. This maximizes QRecall's ability to eliminate duplicate data in the archive. The unique identity keys on each system allow QRecall to organize the data in the archive by owner.

Multiple keys are required for business or institutional users, even if systems are captured to separate archives.

I've never used Amazon SSS, so I can't comment about that. I have used QRecall on .Mac and it works ... at least for small amounts of data. Any remote storage solution like .Mac is going to be seriously hampered by the data transfer rate, which is orders of magnitude slower than even networked volume on a local area network, which itself is going to be 10 times slower than a external hard drive. So, I can imagine it working for a few dozen megabytes of data. If you just want to capture a modest number of user documents, it should work.

I'd be curious to see what problems you're having, especially any error messages in the log file. One, all too common, problem with remote storage systems is their inability to deal with files greater than 4GB.

There are also a number of Network Area Storage (NAS) devices, which are essentially self-contained file servers or drive sharing devices, that you connect to your network.

A less expensive solution is an external Firewire drive. You can configure QRecall to automatically backup to the external drive whenever the drive is plugged in. Then, just periodically move the drive from one system to another for regular backups.

You can always use personal file sharing to set up one system as a file server and have the other computer backup to that.

Charles Watts-Jones wrote:Clearly I misread the instructions on upgrading

The instructions were, admittedly, a bit vague. They read "After upgrading it is recommended that you restart the system." So you can be excused for assuming that after reauthorizing that it was time to restart.

My apologies for the confusion.

Footnote:

You can test to see if the scheduler can start an action by manually running any action from Actions window. Select an action (something harmless, like a Verify it good) and choose Action > Run Immediately. If the action starts, then the scheduler and helper are both working.

The Run Immediately command tells the scheduler to start an action. The scheduler uses, essentially, the same mechanism that's used when starting an action at a scheduled time, confirming that it can start and communicate with actions.

Charles,

Looking at the logs, it appears that you upgraded to 1.0.0(54) and restarted immediately. After restarting, you then installed the scheduler, but there's no restart following the scheduler install. It's after replacing the scheduler daemon that OS X gets confused.

Please restart once more and see if the problems persist.

QRecall version 1.0.0(54) should address these issues, and a number of other ones.

Choose QRecall > Check for Updates... to upgrade to the latest version.

Eric Oshlo wrote:I gather then that Qrecall can do a push, but not a pull. In other words, I'll need to keep Qrecall running on all three machines (two laptops and a home server) so that Qrecall can automatically mount the Archive volume and "push" the data to it rather than run it on just the server and have Qrecall automatically mount and "pull" the data from the laptops as they connect to the network in order to back them all up.

That's correct. But just so we're clear, you don't need to keep the QRecall application open. QRecall installs background tasks that will take care of running your capture actions independent of whether the QRecall application is running or not.

Is this correct, or can it work either way? I presume if it were able run on just the server and pull the data, it would need a small client running on the laptops or some other way to know when the laptops were available to be backed up.

What you're describing is a master/slave system where an agent runs on each computer and supplies that backup data to the master server on demand. This is how Retrospect works. Eventually QRecall will get network savvy too, but not today.

I do plan to add encryption to QRecall (all of the archive data structures are in place to support it, it's just a matter of implementing it).

In the meantime, you might try placing your QRecall archive in an encrypted disk image. I haven't tried that here, but I think it should work.

Bruce Giles wrote:So the full volume restore worked, but it seemed a little like swatting flies with an atom bomb. Was there a better way to do this and just restore whatever files had been changed since the last capture? Or is that actually what the full volume restore did?

Restore is a "smart" atom bomb.

A Restore only recalls/replaces files that are different than the captured version in the archive.

QRecall compares the file information (size, attributes, modification dates, etc.) against the same item in the archive. If they are identical, QRecall assumes the file hasn't changed and doesn't need to be recalled. This is the same test used to determine if the file has changed during a capture.

Eric Oshlo wrote:Obviously, Qrecall has caught my eye; however, I haven't figured out whether it can perform in the same fashion as Retrospect with respect to automatically backing up the laptops when they are connected to our home network with out the need to manually mount the laptop volume on the server machine or vice versa manually mounting the server volume on each laptop.

QRecall will automatically mount a network volume that contains the action's archive, as long as these conditions are met:

- The user is logged in when the action starts. (The operating system does not permit network volumes to be mounted when you are logged out)

- You've saved the user name and password for the volume on your keychain. If you haven't, QRecall will prompt for the network volume's user name and password when the action runs.

Please be aware that there are still problems with QRecall and Leopard. The issue centers around the Leopard security model; it prevent the scheduler from communicating with the actions that have been started. This results in "Action could not be started/cannot establish a connection with helper" errors in the log and essentially prevents QRecall from running any actions.

The problem is oddly inconsistent. Some users are running Leopard without incident, for others the problem appears after a restart, while others can't get QRecall to work at all.

I've made a lot of progress towards solving this problem and have a conference call with the Apple engineers today to resolve the remaining issues.

An update should be available by the end of the week.

Several users have reported an issue where actions won't start following an upgrade to 1.0.0(53). The problem seems to be that Leopard doesn't like the upgrade process replacing the scheduler on-the-fly.

It appears that the problem can be fixed by uninstalling and reinstalling the scheduler. Open the QRecall > Preferences... and switch to the Authorization panel. Uncheck the "Start and run actions while logged out" option. Count to 10. Check it again.

This should uninstall, then reinstall, the scheduler. If that doesn't immediately solve the problem, try restarting. Please report any problems you encounter after following this procedure.

That's so cool!

Seriously, I have no idea why this is happening. Sometimes you get the huge icons and sometimes you get the regular ones. The size seems to persist until you close and reopen the Quick Start window.

It appears to be a Leopard issue. I can't get any of my Tiger machines to do this.