Andre wrote:Is there any solution, so the monitors stay in sleep modus

Yes, but not until the next release.

A few users were complaining that their system was going to sleep during a capture. Code was added that tells the system it is busy and to stay awake while a command is running. This has the unfortunate side effect of waking up the display as well.

This happens to me too and I find it very annoying. An expert preference was added that will disable the notifications that tell the system to stay awake. Expect that version within the next couple of weeks.

Ralph Strauch wrote:2008-03-06 01:08:22.152 -0800 Failure Could not capture Localizable.strings
2008-03-06 01:08:22.405 -0800 Details archive I/O error
2008-03-06 01:08:22.406 -0800 Details Cause: <IO> cannot read envelope data { PkgNumber=2128924, Class=FileSource@0x133a70(/Volumes/spare/bu-archive.quanta/repository.data), API=FSReadFork, Pos=45118276456, OSErr=-5000, Length=8828, File=/Volumes/spare/bu-archive.quanta/repository.data }

As I suspected, the problem was not with the Localizable.strings file. The problem was that QRecall lost access to the archive (the root problem was "archive I/O error").

What's odd is the error code. Error code -5000 is normally an access error to a file on a network volume, not a USB device. But then again, you said that you're using some special USB drivers? That might be a factor.

Ralph Strauch wrote:Wednesday evening I initiated a backup to an external WD hard drive. Qrecall ran for a couple of hours and then hung. I unsuccessfully attempted to rerun it and eventually realized that my USB port had failed and the external HD was no longer mounted, so that was the cause of the backup failure. (The USB failure must have been a driver failure, because after a restart the port is working again.)

This will certainly cause the archive to be invalid afterwards. QRecall was unable to finalize the archive. Any subsequent attempt to use it will require that you first repair it so that QRecall knows that its in a valid state before it begins.

The archive was corrupted (header length invalid) and would not reindex. I didn't have enough free space to repair it, so I trashed it, started a new backup, and went to bed.

You could have repaired the archive in situ. The default repair options are conservative so the "Copy recovered data to new archive" is on by default. But for most situations this isn't necessary. Unchecking that option will allow you to repair the archive without copying it first. I have a to-do item to leave that option unchecked by default in the next release.

In the morning I found that it had hung at 1am with a "Cannot capture localizable strings" error referring to a Japanese lprog file in a printer driver. I excluded that file from capture (though it had been previously captured without error) and tried again.

Failing to read or capture a source file should not (by itself) cause the capture to hang or the archive to be corrupted. More than likely something else (like what happened earlier) occurred while the localizable strings file was being captured. I doubt there's anything wrong with that file. Your log files ? which you are welcome to send to me ? should explain the root cause.

Again, I found that my archive was corrupted with a "header length invalid" error. This time I repaired the archive and recaptured, and everything seemed to work -- except for the layer information in my current archive. My current archive is 87gb, and shows that it contains two layers. Layer 1, which I think is the repaired version of my 44gb corrupted capture, shows and unknown time of capture and 0gb in size, while layer 2 shows the time of my latest capture and 52gb size, the same size shown for the capture in the log.

This would be consistent with an incomplete layer that was recovered during the repair (although I'm surprised the layer doesn't say "-damanged-" or "-incomplete-"). The size of the first layer is impossible to determine because it never finished.

I tried reindexing the archive to see if this would correct the layer 1 info, and it doesn't.

Reindexing won't help, because that information doesn't exist. The first capture never finished, so the summary statistics (capture date, number/size of captured items, etc.) was never generated or recorded.

Since the layer is incomplete, I would suggest that you merge it with the second (complete) layer. Assuming that you don't have any files in the first layer that you need to preserve, merging it with discard the incomplete layer information.

So I think I've probably got a good archive now, and the layer info just got lost in the repair process. I'm a bit concerned, though, because the 44gb first capture and 52gb second capture together only give me an 87gb archive. Am I missing something here?

Unlike a regular file system, a QRecall archive is a database of file information and data. Sizes get confusing, because multiple items can all share the same data. So capturing 30GB, 20GB, then 10GB won't produce a 60GB archive. The archive could be much smaller than that. In the extreme case where all of the files contains zeros, the archive could be less than a megabyte.

QRecall is conservative. Since the first layer wasn't captured completely, there's probably lots of missing file and directory information. When the second layer was captured, all of those missing items would have been captured again. But QRecall first captures the data of a file and then records the file information, which means that a significant part of second 52GB capture was already in the archive and would have been considered duplicate data.

If you're interested the details, increase the detail level in the log viewer and expand the "Captured X items, X.XX GB (XX% duplicate)" line. Inside this record you'll find the amount of data captured (the total data read in new items or items that QRecall suspect have changed), written (the amount of new data written to the archive), and duplicate (captured data that turned out to already be in the archive). Adding up the written values should approximate the total size of your archive, assuming you haven't compacted it.

David Stevens wrote:If I understand correctly, a single key would allow me to back up all 3 machines to their own individual archives.

You understand correctly.

What is the advantage of having 3 keys and a single "accessible to all machines" archive?

At this time, the primary advantage is space efficiency. For example, most of the operating system in the G4 iMac and the Mini are the same. QRecall would only store one copy of the (common parts) of the OS in the archive. Similarly, if you duplicate large iTunes or iPhoto libraries by copying them to each computer, you could have gigabytes of duplicate data.

Disadvantage: only one computer can capture to the archive at a time.

So it primarily depends on how tight your archive storage space is. I'd suggest starting with one key and three archives. See how much space the archives use. You can then decide if you're going to run out of backup storage space. You can always buy one or two additional keys later and switch to using shared archives.

Judith Blair wrote:My question/problem: the hourly capture of my internal drive takes about an hour, even after the first capture.

QRecall is reexamining every item on the entire volume to determine what has, and has not, changed. There are literally hundreds of thousands of files in the operating system, and every one has to be checked.

I suggest creating two captures: One that runs hourly (or semi-hourly) that captures only your Documents or home folder. There's little reason to recapture your entire operating system every hour. Have the second capture run once a day and capture your entire boot volume.

Time Machine avoids this problem by using something called "File System Events" which keeps track of which folders on a volume have recently changed.

A future version of QRecall will use this same facility to quickly determine what has, and has not, changed on the volume making large recapture actions substantially faster. (Sorry Tiger users, the FSEvents service was only made available to third-party developers in Leopard. QRecall will still have to do it "the hard way" in Tiger.)

I also wanted to make one comment about performance. I appreciate what you're trying to accomplish by storing the archive on an encrypted disk image, but speed is not one of the benefits.

Besides writing to a network volume, every access has to go through the disk image driver which is notoriously slow. Add to that the encryption/decryption overhead and you have a recipe for truly mediocre performance.

Rodd,

Thanks for sending me your logs and additional information privately. The problem is indeed related to a single folder with over 100,000 files.

The solution was remarkably simple: I just delete the code that throws an error when there are more than 63,000 items in a package list. It turns out this was old code, left over from the days when package lists couldn't exceed that number. But package lists were reworked ages ago and can now grow to more than 30,000,000 records.

If you have a folder with more than 30,000,000 files, then we might be in trouble.

Please download QRecall 1.0.0b4 and let me know how it does. To replace your current version with the new one:

- Open your Applications folder
- Drag your existing QRecall to the Trash
- Open the disk image
- Copy the new version from the disk image to your Applications folder
- Launch the new version

jch wrote:What if I used external hard drives instead and just rotated those off-site??

That would work just fine.

Does QRecall support multiple backup sets (one per external drive)?

QRecall doesn't care how many archives you have or how you organize them.

If you did this I would suggest creating two sets of capture and maintenance actions, one for each archive (let's call them A and B). In each action, add the "Ignore If No Archive" condition. When the drive with A is plugged in, all of the A actions will run and the B actions will be ignored. When you remove A and replace it with B the opposite will happen.

Remember not to leave a hard drive sitting unused for too long. The surface of a hard disk is (literally) fluid and is not designed for extended storage without being turned on. As long as each drive gets spun up and used at least once a month, you should be OK.

The "missing file icon" messages aren't serious. They just mean that when asked for the icon of a file, the operating system returned an error instead of an icon. This typically means inconsistencies in the launch services database.

The $64,000 question (no pun intended) is, "do you have a directory with more than 63,000 files in it?" I'm honestly not sure if I've ever tested that case.

The "package list exceed 63K elements" just means that a package list exceed 63K elements. Package lists are lists of packages; They could represent a list of file or directories, but are most often used to list the data blocks that belong to a file. When they get too big they transform into a tree of packages lists, so they should never exceed the 63K limit.

There's a couple of potential problems here. It could be that some geometry of your hard drive has found a flaw in QRecall's package list management, be it a directory with 63,000 files or who knows what. However, it could also be a problem writing to a disk image. It would be easy to test that by repeating your test writing directly to a volume instead of a disk image on a volume.

I'm going to assume that the 63K error occurred during the capture, which means that the archive is most likely damaged. If you want to continue to use this archive it will have to be repaired.

It would also be helpful if you could send me your complete log file, via private mail if you prefer, following the repair. I'm interested in exactly what the complete order of events was and what problems the repair finds.

A few users have written about (apparent) anomalies when using QRecall with Leopard's Spaces feature. This affects the appearance and placement of the QRecall Activity window.

The problem is that QRecall Activity window belongs to a hidden application named QRecallMonitor. As such, the QRecall Activity window will appear in whatever space was active when the monitor started (typically when you log in). Opening the activity window from the QRecall application or by starting an action may switch spaces. This can be disconcerting, to say the least.

To fix this:
• Open the Spaces panel in the System Preferences
• Click the plus button to to add a new application assignment
• In the open dialog, press Command+Shift+G to get the "Go to" panel
• Type, or paste in, the path "/Applications/QRecall.app/Contents/Resources" (without the quotes). If your QRecall application is someplace other than the /Applications folder, change that portion of the path as necessary.
• Click the Go button
• In the Resources folder, scroll down and select the QRecallMonitor application
• Click the Add button
• Find QRecallMonitor in the Application Assignments list and change its Space assignment to "Every Space"
• Log out and log back in

The QRecall Activity window will now appear consistently in all spaces.

QRecall has been extensively tested on Mac OS X 10.4 (Tiger), both client and server, as well as Mac OS X 10.5 (Leopard) client.

I know of a handful of users running QRecall on Mac OS X 10.5 Server, so I can't say it's been heavy tested there, but there haven't been any reported problems either.

QRecall doesn't directly support write-once media like DVD or tape. How QRecall manages rolling incremental backups is fundamentally incompatible with this type of media.

If your archive fits on a DVD, or you have software what will span data across multiple DVDs (such as Toast Titanium), you can simply burn your working archive to DVD(s) once a month and keep that copy off-site.

There have been a few requests to add this capability directly to QRecall, and it's being considered.

sjk wrote:

James Bucanek wrote:"Usable" is a subjective term.

Was there a more objective one for describing what I meant?

I have no idea.

When people say "usable" it's hard to know if they mean it in a technical way ("I can open and view the contents of an archive") or an subjective way ("I can recover all of my damaged files").

You're clearly a savvy enough user to know that if data in an archive has been lost due to media failure, there's simply no way of getting it back. But I can't always assume that. Some people might think that the Repair command should simply fix the damaged drive and recover all of the lost data!

sjk wrote:Has anyone run a thorough Backup Bouncer test for QRecall?

I just wanted to say that I'd be very interested to see how QRecall performs on this test.

I do know of couple of things things that it will fail on, but I'll let that be a surprise.

Bruce Giles wrote:For those of us who have been through multiple alphas and betas, would it be a good idea to start new archives with 1.0? Or are we OK with our older archives, as long as they verify?

If the archive verifies, you're fine.

There's very little in the way of legacy data structures in the archive itself. Even if you've been using QRecall from the very beginning of the beta program.