Christian,

Thanks for the reminder to document those settings. I've updated the advanced QRecall settings page. Look for the QRFilePreallocateDisable and QRFilePreallocateBugWorkaroundRule towards the bottom of the page.

I'd suggest starting by setting QRFilePreallocateBugWorkaroundRule to 1. This causes QRecall to assume that all volumes are affected by the pre-allocation bug and to use a workaround. This allows QRecall to continue to preallocate space (important to maintaining the integrity of the archive should the volume fill up), but avoids the pre-allocation bug in some versions of the OS and NAS drives.

If that fails to solve the problem, you can just turn off pre-allocation by setting QRFilePreallocateDisable to true.

Glenn Henshaw wrote:I run a weekly verify to ensure that the archive is stable. (I also flatten the archive weekly).

I approve.

This operation is now taking 9 hours for an archive that is about 126G (on a 150G disk partition mounted on an Airport Extreme). How long should this operation take?

The bulk of the verify action is consumed with reading every byte of the archive and checking its integrity. Most of the archive is read just once, but it is read from start to finish.

Doing the math:

126,000 (126GB in megabytes) / 9 (hours) / 60 (minutes) / 60 (seconds) = 3.89 MB/sec transfer rate

That sounds like an 802.11n wireless network running at close to its maximum capacity. If you're verifying the volume via a wireless network connection, then that's just about right.

- A verify over a 100Mb ethernet LAN would take about 3-4 hours.

If you have another computer on your network that's connected via ethernet, schedule it to preform the weekly verify. It doesn't matter what computer does the verify; that computer doesn't even need an identity key.

- An external drive connected via Firewire 800 should take about 30 minutes.

If you need to perform a fast verify, disconnect the drive from the Airport basestation, connect it to any computer with QRecall installed, verify the archive, then put it back.

Nicholas Sloan wrote:And on the subject of filters, is there any way to determine the path of a folder in the filters list?

And if not, can I suggest a contextual menu ?Show in Finder? or a tooltip giving the path? (Perhaps this is taken care of in 1.2?)

I'm improving the interface for filtered and captured items in 1.2. In the mean time, 1.1 already has a tooltip to the given path. I have found Leopard/Snow Leopard tooltips to be a little erratic. If you're not seeing a tooltip when you hover over the item, switch to another application (like the Finder) and then back to QRecall. That usually wakes them up.

Nicholas Sloan wrote:Would this be a viable feature request?

Honestly, that would be a little tricky. I have some other filtering features planned for a future version of QRecall which might obviate the need for such a feature. I'll add it to the request list and revisit it again after version 1.3.

Richard,

There's something wrong with your installation of QRecall. The error that you're getting is an internal error. It says that QRecall can't find one of its components inside the QRecall application bundle. That should never happen.

Follow these steps:

(1) Uninstall QRecall by opening the QRecall application, holding down the Shift and Option keys, and choosing the QRecall > Quit and Uninstall command.

(2) Download a fresh copy of QRecall (http://www.qrecall.com/download/).

(3) Replace your existing QRecall with the new copy.

(4) Launch QRecall, choose QRecall > Preferences, go to the Authorization tab, and pre-authorize QRecall again.

Let me know if that solves the problem.

Nicholas,

It's a two step process:

I know how to add excluded folders to a capture action

(1) The first step is to do just that. Open your capture actions and add the file or folders you want excluded to the Filter section of the capture action.

In the QRecall Help (Delete Item) it tells you how to delete items from an archive

(2) Then do that; open the archive, select the item(s) you excluded in step 1 and choose the Archive > Delete Item... command.

Step 2 removes all traces of that item from the archive, and step 1 prevents those items from being recaptured.

Thanks, Ralph, for posting this issue to the forum.

Just to clarify, the issue I'm intimately aware of is when one Mac OS X system is acting a a file server (file sharing enabled) using a local QRecall archive and another is access that same archive via the network. There are cache synchronization problems—where changes made by one system aren't communicated to the other—if both computers are running an earlier version of 10.5 or one is running 10.5 and the other running 10.6. If both are running 10.6 or the latest version of 10.5, everything seems to work correctly.

The workaround is to periodically unmount the networked volume. This forces the remote computer to flush its disk cache and re-read the remote volume data. If you encounter this problem, eject your network volume and restart the action. If the volume remounts and the actions runs OK, then there was never anything wrong with your archive. (I should note that I have exactly that situation here, and have to restart the nightly capture on my 10.5 laptop about once a week.)

Ralph's situation is a little different in that he's using an Airport Extreme base station as the file server. The Airport runs a version of Apple's File Sharing service, but Apple doesn't document what version. Given that there are compatibilities issues between file sharing on 10.5 and 10.6, and between 10.6 and the latest Airport, I guess it's not surprising that there might be issues when one client is running 10.5 and the other 10.6.

I'm going to set up a similar configuration here and see if I can duplicate this problem.

I haven't invested a lot of time or effort into addressing this problems because (a) I keep hoping that Apple will simply fix the problem and it will go away and (b) it doesn't cause any data loss. It's just incredibly annoying.

Richard,

Please use QRecall to send a diagnostic report (Help > Send Report...) and I'll look into it.

Nicholas Sloan wrote:I was assuming that it would be a bad thing to run QRecall captures and SuperDuper clonings concurrently, ...

Not at all, that sounds perfectly harmless. Any number of processes can read the same files/folders simultaniously. It doesn't affect anything. Problems can occur when something is writing to the files being copied/captured, but that's not the case here.

It would simplify things (and save a little energy) if I could throw all my backup tasks into the same time slot.

Having two programs copy the same source items simultaneously can cause a phenomenon called "thrashing" where the disk heads spend a lot of time jumping around the volume trying to satisfy the requests of both processes. The result is that trying to do two things at once actually ends up taking more time than if you did them one at a time. But that's speculation; you'd actually have to observe your system to determine if running both at the same time is faster or slower than running them sequentially.

One last thought:

If you capture your home folder to both your USB drive and network volume, set up the merge schedule to you keep frequent layers on your network volumes (like every capture for the past week, then daily for 60 days or so), but only keep daily and weekly layers in your USB volume (say, daily for two weeks, weekly for two months, then monthly for a couple of years.)

This will keep both of your archives lean and mean, but still preserve a lot of near-term versions.

Prion wrote:I am somewhat new to this and would like to set up two different capture strategies that would
1) capture the entire system, preferrably overnight after which the system would be put to sleep or switched off
2) capture whatever might be worth capturing in terms of data in my user's space (Documents, Pictures, Movies, Music, etc.)

This should be easy, and you have a variety of choices on how you implement it.

But first, I'll answer your questions.

Question 1:
I imagine that capturing software while it is running is asking for trouble, so presumably I would need to be running a different operating system of the same type (10.6 in my case running on the 2.5 USB drive) to backup my main harddrive in the MBP. Likewise, I would need to be logged out for capturing my user data (task #2). Correct? How do I set this up then?
If so, this would limit my backup frequency in particular for task #2 because I would then let it run at noon and at night. Perhaps that is sufficient but I don't know. How do you handle this? I cannot imagine logging our every hour for my backup to take place.

Not at all. QRecall is perfectly capable of capturing your system while booted from that volume, and your home folder while logged in.

There are potential problems, but they're with specific applications. The usual suspects are Mail, Aperture, VMWare, Parallels, etc. These applications keep data cached in memory; capturing their data files create an incomplete picture of their state, that may possibly be invalid when restored. The solution is to quite these applications before starting a capture, but you don't have to log out. (Note that this particular problem applies to any backup solution, not just QRecall.)

If you really want to make sure your home folder is captured in a pristine state, you can capture it while logged out. QRecall can do this. You can even schedule a capture action to occur when you log out. If you regularly log out of your account after working, this might be your best solution.

Question 2:
Can I rename a drive that I previously captured data to with Qrecall and still continue capturing data to or restoring data from?

Yes. You may need to point the actions at the archive after you've renamed or moved it. To do this, open up any action that uses that archive and select the archive again.

Can I copy the content of the 2.5 drive to another drive (with a different name) and use that drive to boot from? I would assume that I would need to use CarbonCopyCloner to keep the new drive bootable (or can I use Diskutil?).

Yes. I've never used Disk Utility to clone a drive, but basically whatever results in a bootable drive will work. The QRecall archive is just a document. You can move, copy, or rename it as you would any document.

Question 3:
Playing around with the TimeCapsule it seems as though QRecall is perfectly willing to accept an external harddrive connected to the TimeCapsule's USB port.

QRecall is happy to use a QRecall archive on any mountable volume.

At least while I am at home (near the TCapsule) I would prefer to archive to that disk because then I would not need to connect and unconnect the drives used for backup.

I think that's the best solution, as I'll illustrate later. The less you have to remember about your backups the better.

Question 4:
I am unsure if I should include the user data also in the system backup to have some redundancy or if that just fills the thing up too quickly.

That's entirely up to you.

Since I cannot easily prune the user data if I find that the case it might be worth asking you pros here.

You can very easily prune the data. You can open an archive and completely delete any previously captured file or folder. So you can start by capturing your entire boot volume to your USB drive. If the drive begins to fill up too quickly (and I seriously doubt it will), you can delete the /Users folder from your archive and then exclude it from future captures by adding it to the "exclude" list in the capture action.

The advantages of capturing everything are convenience and redundancy. If you exclude you're /Users folder from the whole-volume capture, then when the need arrises to restore your boot volume you'll have to do it in two stages: first from the "system" archive and then your user data from your "user" archive. And you won't be able to boot until you've done both. Not a big deal, but worth noting.

The other advantage is redundancy. Having two backups is twice the security.

Question 5: What do I need to do to ensure that my backup is safe on the one hand but that I will be able to restore a backup and not fail because of insufficient privileges over the files to be restored?

To verify the integrity of your QRecall archive, create an action the periodically verifies the archive. I would suggest scheduling this to run once a week. I run them almost daily, but I'm paranoid and I'm always fiddling with the code, so my archives are more likely to get messed up more than yours.

When you install QRecall, you'll want to pre-authorize QRecall to use administrative privileges. This allows QRecall to run as the superuser (root), which gives it complete authority to capture and restore every aspect of your filesystem. When you restore from your emergency drive, you'll either want to pre-authorize QRecall or manually authorize it once to perform the restore.

I know, many questions and I would appreciate your help very much

Here's my suggestion:

1) Creata a capture strategy to capture your entire boot volume to your USB drive automatically when the drive is connected. The capture assistant will set this up for you (Help > Capture Assistent, choose your boot volume, the archive on the USB drive, tell the assistent it's on a removable volume and you want to capture when it connects).

Your daily backup routine: when you're done with work, quite your major applications and plug in the USB drive. The capture will start immediately.

2) Create a capture strategy to capture your home folder, or /Users folder, to your networked Time Capture volume. Again, use the capture assistent to set this up as before, but tell it to run at a particular time each day. After the capture assistent has created the actions, open the Actions window and change the schedule of the capture action to run more often (like every 4 hours), or maybe create duplicates that run at different times during the day (one at noon, another at 7PM, etc.).

Your daily backup routine: make sure your Time Capture volume is mounted at the times when the capture is scheduled to run.

If you want QRecall to remind you of these things, consider the following changes:

Change the schedule of the USB drive capture to a specific time and add a Hold While No Archive condition. QRecall will start the capture every day, where it will appear in your QRecall Activity window, and wait patiently for you to plug in your USB drive.

Remove the Ignore If No Archive conditional from the hourly capture of your home folder. The action will run regardless of whether your network volume is mounted or not. If the volume can be mounted, QRecall will mount it and run. It the volume isn't available, QRecall will complain.

Install Growl.

I hope that all makes sense. Write again if you have more questions.

Thanks for the suggestion.

I will add that to the to-do list.

I'm trying to keep the good stuff and add more good stuff.

Specifically, a column view and better ways of navigating between volumes and users. I want to keep the timelines, but introduce a much richer interface for exploring the history of individual items.

If there's anything that you (or anyone) really like, or hate, about the current interface please chime in now.

Nicholas Sloan wrote:It would be neater if I could let QRecall off once SuperDuper had finished, but I am not sure how to achieve this. SD can be set up to fire a script on completion, but I can see no obvious way to make a script initiate a QR action, especially since QR itself is not scriptable. I was wondering whether I could script something to create a condition that QR would recognise and respond to. The only thing I can think of is to have SD's closing script unmount and remount the archive drive, but this seems a bit clumsy. A condition: hold if [xxx.app] running would do it too, but of course there is no such condition.

Nicholas,

Thanks for the feedback.

I'm planning a number of new QRecall features, one of which is more scriptability. I also have plans for a "Perform action when application X starts/stops" action schedule, but that's intended more for applications like Aperture and Parallels where their content can't/shouldn't be captured while the application s running.

I currently have plans to add AppleScript support to the QRecall application, create a QRecall Automator action, and include a command-line version of QRecall. I think either the Automator action or a command-line QRecall tool would solve your problem.

Right now these were all planned for version 1.3. Version 1.2 is going to concentrate on new capture features, performance, and a completely redesigned user interface. Version 1.3 is going to focus on automation, scripting, and filtering.

Nicholas Sloan wrote:I don't think I mentioned that I find the interface of QRecall, especially the archive listings, to be a thing of beauty.

Thanks.

Stay tuned, because I plan to add a lot of new interface features over the next few months.