Wayne Fruhwald wrote:I will attach each of the drives to my MBP and capture them interactively, one at a time.

If these are all removable drives, I would suggest creating a capture action for each volume. Use an event schedule to start the capture when the drive connects, repeating once or twice a day. Whenever you connect a drive, its changes will be automatically captured.

You can set all of the actions to capture to the same archive.

I want to set QRecall settings such that the searches will be as fast as possible (considering that I have 16 GB RAM).

Searching an archive is fundamentally bounded by I/O. Archive search speed is affected most by the seek time of the drive containing the archive.

I want to be able to perform the following searches:
1. Search across ALL drives using the most recent layer of each (i.e. the most recent capture of each drive which will be in different QRecall layers)
2. Search across ALL drives using ALL layers so that I can find deleted and modified files

When you perform a search, you are searching within the items contained in the navigation bar location (at the bottom of the browser window). So if the navigation bar location is My Computer > Main HD > Users, the search will be limited to the items in the Users folder of the Main HD drive.

To search a single volume, navigate to the root directory of that volume and perform your search.

To search multiple volumes (belonging to the same owner), navigate to the owner and perform your search.

I find the search option "Only Show Matching Items" useful when searching entire volumes or top-level directories.

To include or exclude deleted items in your search, choose View > Show/Hide Deleted Items.

The browser will display the timeline of the earlier versions of each item via the layers pane, whether you're searching or not. You don't really "search all layers"; that happens implicitly. You simply search for an item, and then browse the versions of that item.

3. Search across one or more drives using the most recent layer of each
4. Search across one or more drives using ALL layers so that I can find deleted files

You can search all volumes or one volume (as described), but not an arbitrary set of volumes. Of course, searches are interactive. You can start a search and switch volumes, which will resume the search in that volume.

Ralph Strauch wrote:Unfortunately, I didn't think to look at the dates of the files I deleted, and they don't seem to be showing up in "deleted files."

They won't show up as deleted files because you deleted them from the archive. A "deleted file" is a file that's been captured, but was later deleted on the source volume. But once removed entirely from the archive, it no longer exists in any form.

The second edition of Take Control of Backing Up Your Mac is now available.

Included in the book is a 40% coupon off your next QRecall identity key purchase, a $16 value.

Ralph Strauch wrote:It occurred to me recently that there's no reason to back up my sleepimage or my swap files, so I opened my archive and deleted those from the archive.

Your swap files and sleepimage file should be automatically excluded from captures.

One of the fixed, built-in, exclusion filters is the VM filter. When QRecall starts a capture, it examines the arguments passed to the dynamic_pager process. If a specific directory was specified, it excludes that directory from the capture. If it can't determine which directory the dynamic_pager process is using (or it can't find a dynamic_pager process), it excludes the contents of the /var/vm directory.

You can manually specify the location of the swap files by setting the QRVMSwapStorePath advanced settings to the path of your swap files. See the Advanced Settings page for the details. If you've set this property, and you're swap files are not being excluded, then consider changing it or deleting the setting and see if QRecall can determine the location itself.

If everything seems in order and QRecall isn't excluding the contents of your VM swap directory, I'd very much like to know about that.

Finally, when adding excluded items to a capture action, holding down one or both of these keys will modify the behavior of the + button:
Option allows you to exclude invisible items
Shift allows you to exclude items inside packages

Bob Tyson wrote:May I respond to your 'hint' also with this, a slight 'gripe' which is that searching the help on 'status window' produces nothing useful in this regard.

This might be your Spotlight system. A search in my QRecall help window results in two QRecall hits: Monitor Preferences and Status Window, which is exactly what I would expect.

Help indexing is performed by Spotlight, so your spotlight database might not be updating or it's just taking its time.

Bob,

You probably have stale status information. QRecall caches a copy of the archive's status (so it can be displayed when the archive is off-line). If the path/alias to the archive has changed, the copy of the status gets disconnected from the actual archive and you end up with two statuses—one active and one stale.

Bob Tyson wrote:One reason is that after formatting an archive volume and making a new backup that failed, and produced warning messages, I trashed that faulty QR archive file and re-created a new one in QR, then made an action that completed the new complete archive and subsequently an incremental backup. The whole process proceeded quickly and the status window reports this most recent archive and backup cycle as healthy.

Now I know this is what's happened. Reformatting a volume is almost guaranteed to break the alias records that QRecall uses to locate archives.

Open the archive status window. Find the stale ones (they will report that they haven't been captured or verified in days or weeks), right/control+click on one, and choose Forget.

Forgetting a status is always harmless. It simply discards the cached copy of the archive's status. If you forget an active archive, there's no harm; it will reappear in the list the next time it's captured or verified.

Tip: Right/control+click on an archive's status. If the "Reveal in Finder" command is disabled, then QRecall can't locate the archive this status belongs to. Either it's off-line or the connection between the status and the archive is broken.

You can find a little more about the status window in Help > QRecall Help > Guide > The Basics > Status Window.

Ralph Strauch wrote:What can I do to "close" the archive so that I can access it again?

The surgical approach: Find out what process has the file(s) open. You can use the lsof (list open files) command-line tool. Run the command, as root, on the system that hosts the QRecall Archive. The following command lists all of the open files, and what processes has them open, inside the folder /Volume/Hard Drive/Archive.quanta:

sudo lsof +D '/Volumes/Hard Drive/Archive.quanta'

Once you discover the process that has the file open, restart it (probably your network file server).

The hammer approach: Restart your computer

If you've made sure that no other process has the archive files open, and the QRecall actions still won't run, you may have an orphaned .lock file. The Repair action will fix this, but you can also just delete it via the command line or any utility that will let you see, and trash, invisible files:

rm '/Volumes/Hard Drive/Archive.quanta/.lock'

Peter B. wrote:If QRecall knew that an original has changed, but it shouldn't have since the last capture (because the modification date of the original is the same as the one in the archive), then QRecall could alert the user that the original may be corrupted.

Unfortunately, the only way to do that would be read every file that didn't appear to have been modified, in its entirely, every time you performed a new capture. This would require (approximately) the same amount of work as recalling the entire volume, during every capture. It would make more sense—and be a heck of a lot less work—to just keep your incremental changes longer.

The only instance I can remember where this happens is with AppleScript Editor in Snow Leopard when modifying scripts saved as applications.

That's a different issue. An application is a bundle (a folder that appears to be a single file in the Finder). The modification date of the bundle is the modification date of the bundle's folder, which may, or may not, reflect the modification dates of its contents.

This is a non-issue for QRecall. QRecall does not use the modification date of a folder to determine if the contents of that folder have changed.

Peter B. wrote:Control option controls the top shade

The help has been corrected. Thanks!

control command controls bottom shade.

Control+arrow moves the bottom shade. The command key is ignored.

Peter B. wrote:I want to be able to define a maximum size of an archive in bytes (or KB, MB, GB, TB), independent of the space left on the volume.

I'll add that to the to-do list. It wouldn't be a difficult feature to include.

The archive settings sheet should specify that the leftmost position of the three sliders is "off." This would be helpful because users don't always read the manuals before starting to use software.

I've added that to the to-do list too.

I'd like a separate button for the menu which is normally available by right clicking the stop button in the QRecall Activity window. Recently, I accidentally left clicked the stop button for a process in the activity window, when I wanted to have right clicked.

This issue comes up occasionally. There's a wish-list item to split the button into two buttons: a stop button and an action button.

I want options to be able to delay an action more than 5 minutes, so I can perform 12 or more actions in a specified sequence when a volume connects. In my case it's because I'll be using two archives on the same volume, which have six actions each.

That's already in the works, to support new event actions being developed for the next release.

Peter B. wrote:I, too, would like to have source data validation.

The way QRecall stores data, source data validation doesn't make much sense. In fact, QRecall's archive structure is specifically designed so that is does not have to rely on comparing the data backed-up with the original as a means of validation.

All data in a QRecall archive is validated via interlocking layers of checksums and consistency guards. There's no need to compare the data in the archive with the orignal file, because the archive stores enough redundant information to determine if the data has been damaged or altered in any way.

You could compare the data in the archive with the original files, but that would only tell you if the original file had changed or not. That's a feature that's on the to-do list, but it won't improve the security of the data in the archive.

However, I think that not all applications or processes update the modification date of files that are written to.

Applications do not update the creation, modification, attributes, or access time of file objects. That's handled automatically by the filesystem. In fact, an application would have to go to extraordinary measures to modify a file in a way that made it appear that it hadn't. I'm not aware of any apps that do this.

Ralph Strauch wrote:It did not seem to be reading the whole drive this time, so whatever was causing it earlier didn't transfer to the direct mount.

It's also possible that the previous capture decided to resize one of the index files. This can be a very I/O intensive and time consuming process (especially over a wireless link). Index files in the archive are periodically resized/rebuilt for efficiency. This will happen a dozen or so times over the lifetime of an archive.

Ralph Strauch wrote:Is qrecall reading the entire archive? If so, why, and is it normal?

It sounds like it's recapturing all of the items on your drive. Why, I can't say (definitively). If that's what it is doing, then capturing to a drive directly connected to your MacBook is likely to be much faster.

There are a number of reasons why QRecall will rescan all of the items on a drive, or decide to recapture items.

QRecall periodically rescans all of the files on your volume looking for changes. This usually happens about once every 14 days. If a layer is damaged or incomplete, that will also force it rescan all of the items.

If you've reformatted or resized a volume, that may cause it appear as a new volume, which QRecall will dutifully recapture—in its entirety.

The short answer is (I'm hoping) that QRecall is just doing its job, re-capturing items to ensure that they're all backed up.

Dr. D wrote:Concerning older QRecall versions, where can I find those, please?

Sorry, I forgot to mention that.

Go to the Release Notes page. (You can also get to the release notes from the Download page.)

Next to each set of release notes is a download link for that version.

Dr. D wrote:1) "Standard" users every now and then don't execute the daily backup run - QRecall patiently shows "waiting for archive" even when the volume with the archive is mounted and the archive visible in the Finder and no other machine uses the archive. Restarting the machine generally seems to solve the issue but that obviously misses the backup window at night. Is this a result of several machines sharing the archive file? Is there anything one can do to avoid the issue?

QRecall uses the standard OS X sharing modes to detect if another process has a file open for reading or writing. It won't update (capture to) an archive if any other process is currently reading or writing the files in that repository package. You can use the lsof command line tool (on the server) to determine which process has the archive file(s) open.

More than likely, it's going to be the file sharing server process. A network file servers opens file on behalf of its network clients. What sometimes happens is the client momentarily loses its connection with the server. The server then leaves those files open forever, because there's no client to tell it to close the file. (When the client reconnects, it looks to the server like a new client.) All subsequent capture operations are then stymied by the phantom user that's keeping the files open.

Stopping and starting the file sharing process will usually resolve this situation. But that will also kick off all of the network users, which is a hassle.

2) "Special" users sometimes (but not always) have trouble mounting both the network volume and their dedicated sparse image file. Restarting or manual mounting seems to solve the issue but I wonder if there is a better way to do things.

QRecall mounts network volumes using the standard OS X alias resolution functions. Most of the time this works, but sometimes it doesn't. If network communications are a tad dicey (which they might be, given your first question), then it's a crap shoot. I used to have this problem all the time on my local area network, but recently it's been working flawlessly. I can't tell you why.

3) I noticed QRecall having trouble on Mac OS X 10.5.5 (odd crashes) but working well on Mac OS 10.5.8. We are dependent on specific OS versions due to legacy software for certain tasks. Are there any older versions of QRecall available that could operate using 10.5.5 or even 10.4?

Honestly, QRecall barely supports 10.5.8. Very little serious testing has been done on 10.5, and the next version of QRecall will drop support for PPC systems, bringing the minimum OS version requirement to 10.6.

You're welcome to try older versions of QRecall on your 10.5.x machines. If your archives haven't gotten too big, you can probably downgrade all the way to version 1.2.0 without running into compatibility issues. QRecall archive maintain compatibility flags, so it's always safe to try an older version of the application. If the format of an archive is not compatible with the running version of QRecall, QRecall will report that and refuse to perform the operation. There are different compatibility requirements for the actions, so a version might be able to read and recall from an archive, but not capture to it.

If you try to downgrade, you must uninstall QRecall before installing the older version. QRecall will automatically upgrade its components, but it won't downgrade them.