That seems to have taken care of it. Thanks.

I noticed that each qrecall plist has a corresponding plist.locked. Are those the default values? The scheduler.plist.locked was last modified 6/24, which may have been when I update to b41. Some of the others were last modified yesterday morning, though, when I can't think of anything in particular that I was doing.

Ralph

I think I've had problems with beta 41 since I installed it, but that's also around the same time I upgraded to Lion, so that may also have been the source of the problems. It was running automatically and I wasn't paying much attention, so just noticed it this weekend.

My iMac seems to have a scheduler problem. When I try to run a backup it tells me that the scheduler could not be and I should quit and restart qrecall to install it. All the while the log is filling up with "unexpected problem; scheduler stopping immediately" messages, several each minute. I've trashed qrecall and reinstalled a new copy (still b41) and that didn't change anything.

My MacBook Pro had backup failures of a number of different kinds, including permissions problems for the repository.data file within the package, which Finder tells me has read-write permissions for everybody. I tried a number of different things to get it going and eventually corrupted the archive. Repairing the archive seems to have fixed it, and my last backup looks good.

I'll send problem reports from both computers. The MBP seems to be running OK now, so that one's just for your information if you're short on reading material. I still can't backup the iMac, because of the scheduler issue, and need a solution for that.

Ralph
Ralph

I'm finding that qrecall chokes and won't backup a Windows virtual machine that's suspended within Parallels. I had been excluding my VMs from my backups, but just switched to a larger hard drive and decided to eliminate that exclusion. The first failure occurred during my daily backup of User files on 7/2. It killed that backup but left the archive intact, so I added the exclusion back in and thought I'd solved the problem.

Then yesterday I ran a manual full back without the exclusion. This time the VM both killed the backup and screwed up the archive. I'm repairing it now, and will add the exclusion back into the full backup as well. I can live with keeping the VM excluded from my backups, but thought you'd like to know about this problem.

Here are the console log entries from the two failures. Let me know if you'd like a full problem report from Qrecall.

2011-07-02 12:36:12.594 -0700 Failure Could not capture Windows XP VM-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds [2.734320.1567.64]

2011-07-02 12:36:12.718 -0700 Details File: mbhd:Users:ralph:Parallels:Windows XP VM.pvm:Windows XP VM-0.hdd:Windows XP VM-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds [2.734320.1567.64.1]

2011-07-02 12:36:12.742 -0700 Details Path: mbhd:Users:ralph:Parallels:Windows XP VM.pvm:Windows XP VM-0.hdd [2.734320.1567.65.1.2]

2011-07-02 12:36:12.743 -0700 Failure Could not process folder Windows XP VM-0.hdd [2.734320.1567.65.1]



2011-07-04 04:44:16.250 -0700 Failure Could not capture Windows XP VM-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds [2.734321.7804.76]

2011-07-04 04:44:16.303 -0700 Details File: mbhd:Users:ralph:Parallels:Windows XP VM.pvm:Windows XP VM-0.hdd:Windows XP VM-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds [2.734321.7804.76.1]

2011-07-04 04:44:16.599 -0700 Details Path: mbhd:Users:ralph:Parallels:Windows XP VM.pvm:Windows XP VM-0.hdd [2.734321.7804.77.1.2]

2011-07-04 04:44:16.599 -0700 Failure Could not process folder Windows XP VM-0.hdd [2.734321.7804.77.1]

Ralph

OK, thanks. That's a good reminder that I should read things like release notes when something doesn't work, especially for beta software, rather than just hoping that doing the same thing over and over will produce a different outcome the next time I do it.

Ralph

I'm trying to search my archive and the search function just isn't responding. I type in a search key and it just sits there. No search is started. Hitting return puts my search key in the saved searches, but still doesn't start a search.

I'm using Version 1.2.0(35) beta (1.2.0.35), and this may be the first time I've tried a search with this version.

Ralph

ps: all the search options are grayed out, as are all the options under Edit/Find, if that matters.

One big disadvantage to using a partitioned drive to keep multiple backups of the same computer is that you give up the redundancy of multiple backups. If (when?) the drive fails, you lose both backups rather than just one. It's much safer to have separate drives for separate backup systems.

I backup both Leopard and Snow Leopard machines to the same archive. Before I install v1.2.0(35) beta on the Snow Leopard machine I want to confirm that it's OK to run different versions on the two OSs.

Ralph

I think I know the answer to this, but would like to confirm it. According to Qrecall help:

"The item is deleted from every layer of the archive as if it had never existed or had never been captured."

I'm interpreting that to mean, more precisely, that the item is deleted from the same location in every layer of the same volume in the archive. I.e.,

1) if an item was moved from its original location to a new location and the original is deleted and the moved copy remains in the archive, and

2) if the archive contains more than one logical volume for the same physical volume, then removing an item from one of those logical volumes does not remove it from layers in other logical volumes.

The second issue comes about because my archive contains three logical volumes for my MacBook Pro hard drive. The first contains layers over a year old, the second contains layers up to last week when my failed hard drive was replaced, and the third contains layers since then. The second layer was possibly created when I move from my prerelease beta key to a regular key and the third seems to have been created by the hard drive replacement.

I want to keep old versions of my user files in the first two layers, but am not interested in keeping old copies of my apps, system and library files, etc. I think I should be able to delete these things from the first two volumes without affecting my current versions of those files, but would just like to confirm that before I make the deletions.

Ralph

I'm glad you like the idea. It will be really convenient for people moving to a new computer, or, as I was doing, recovering after a major crash and wanting to start with a fresh system. Hopefully I won't need it again before v1.3 or 1.4.

Another advantage to mounting the archive as a volume would be that it would provide a column display, making it much easier to browse the archive. If you did that, would be mounted volume also allow browsing of layers, as the current display does? That would make it much more of a competitor for Time Machine for users who like the simplicity of that interface.

BTW, I've just found that backing up my new drive -- with the same name as the old one -- has created a new volume in the owners and volumes list. I already had two, I think because one was from my original beta ID before the qrecall release, so now I have three volumes with the same name, covering different chronological periods.

Ralph

Apple just replaced the hard drive in my MacBook Pro, returning it to me with a new system installed but with none of my other apps or files. I could have used Qrecall to restore it to it's previous condition (old system plus my other files), but it seemed to make more sense to keep the newly installed system and migrate the rest of my files over on top of that. I don't see any way of doing this with Qrecall, though I was able to do it using Apple's Migration Assistant and a SuperDuper clone of the drive.

Did I miss this this option in Qrecall, or is this an option that Qrecall just doesn't have. If that's the case, please consider adding it. It would be highly useful in situations like I just encountered, or in any move to a new computer.

Ralph

Are v1.2 archives compatible with earlier versions, or does the index changes preclude that? What I'm really asking is whether or not I could install 1.2 on my MBP and leave 1.1.4 on my wife's G4 iMac, both of which back up to the same archive?

Ralph

I just restored a folder that showed up in the Qrecall info window as 1.85gb in my archive and it turned into a 9gb folder on my hard drive. I guess that means that the size in the info window is the size of total data in the archive and the original data contained enough redundancy to cause it to balloon up like that. Is that right? (The original folder contained a bunch of DVD Studio Pro templates, etc., so I guess it could have been highly redundant.

The help file says that "Selecting multiple items shows the total size of all of the selected items . . ." It might be worth saying that that's the total size in the archive, and it might take a lot more space than that to restore the original files. Without knowing that, it was quite a surprise.

Ralph

James Bucanek wrote:You've run into another known problem with OS X and the Airport basestation. Basically, some Apple File Servers don't handle file pre-allocation requests correctly. The bug is in older versions of OS X, the Airport basestation, and some NAS storage devices.

Your "disk full" problems can probably be solved by setting the QRFilePreallocateDisable expert setting in the Terminal:

defaults write com.qrecall.client QRFilePreallocateDisable -boolean true

You'll probably want to do this on all of your systems, particularly those encountering the out-of-disk-space problem. This problem was recently mentioned in the Preallocation failed thread.

Done! If it doesn't solve the problem, I'll be back. I don't know if it's significant, but I find it interesting that the problem manifested differently on a PPC iMac running Leopard (disk full error) and on an Intel MBP running Snow Leopard ("Problem closing archive . . . Capture failed . . .").

BTW, the "copy to clipboard" link for your code above doesn't work. I get an alert telling me that the code is now on my clipboard, but it isn't. I used the "view plain" link to display the code and then copied it from there.

The two volumes in the Owners & Volumes drawer is odd. This usually happens when you resize/reformat a volume. Even though it has the same name, QRecall identifies it as a different disk drive. I'd be interested to know if QRecall continues to add layers to the "new" volume or the old one.

Having two volumes in the Owners & Volumes drawer isn't new. I've had them for some time, I think since I switched from the beta registration key to a normal key when qrecall was officially released. What changed, though, is that the earlier volume now contains everything up to 12/11/09, which was my last full backup and the the latest layer that was included in a merge, while the later volume contains only partial backups since then and the full backup I did last night. It isn't because I merged lots of older stuff into the 12/11 layer, though. I still have several earlier 2009 layers that I'm sure used to be in the newer volume.

Having the two volumes isn't a problem and I don't need to do anything about it, but just thought it was worth mentioning.

Thanks again for your extremely prompt and useful reply. The support you provide is outstanding.

Ralph

I'm continuing to have problems backing up to a network drive connected to an Apple Airport Extreme. I run scheduled partial backups on my wife's iMac at 1am and on my MacBook Pro at 3am, into the same archive. Both have Qrecall 1.1.4.5 installed. Up till 12/22 both seemed to be working fine. On 12/22 the iMac log shows a "Scheduler Version mismatch" and "Autoupdate system components," so that may have been when I updated the iMac to 1.1.4.5. From the log, it looks like I had updated the MBP on 12/19.

On 12/23, the 1am iMac backup failed due to "disk full -- Capture ran out of disk space." The disk had more than 20gb free and the backup would have been less than 100mb. The 3am MBP backup later that night ran fine. Later that day I merged a bunch of layers to free up additional space in the archive, then turned the iMac and AE off and left for a vacation. When I came back on 12/31 I started things up again.

Since that restart, all the backup attempts on both computers have failed. The iMac shows "disk full" as the reason for failure, though there's always been plenty of space on the drive. The MBP shows capture as happening, followed by "Problem closing archive," followed by "Capture failed -- network or disk error encountered."

I unmounted the drive from the AE today and mounted it directly on the MBP. Qrecall was unable to open the archive. I scanned the drive with Disk Utility and it appeared to be OK. I then scanned it with TechTool Pro which reported "Validation Error Encountered -- Allocation File (Bitmap)" I repaired the volume structure and qrecall then opened the file and said the archive needed to be reindexed. Halfway though the reindexing it stopped and said the archive needed to be repaired, so I repaired it.

After the repair I have two distinct entries in the "owners and volumes" list for my MBP hard drive. One contains only recent layers which I haven't merged yet and the other contains all the layers that have been merged at some time with another layer. I also had one damaged layer at the end, with no date and only damaged content. I then did a manual full backup of the MBP. Both that and the scheduled partial backup look fine. I haven't yet reattached the drive to the AE for a backup of the iMac.

I don't know if this is a recall problem or some instability in my system or backup drive, but it does seem related to the 1.1.4.5 update. I'm sending you reports from both machines with the logs.

Ralph

I'd like to pass on some experience with Leopard and Snow Leopard in case it's useful to anyone. I back up two computers to the same archive, my MacBook Pro (Snow Leopard) and my wife's G4 iMac (Leopard). Until recently I had been switching the backup drive between machines, or sometimes leaving it attached to the iMac and backing up the MBP over the network, which worked fine. I've just installed an airport express and connected my backup drive though that, which caused problems.

I found that if I tried to back up the iMac after backing up the MBP, the archive header was corrupted and the archive needed to be reindexed. I reported it to James and he explained that it was caused by an OSX network volume cache bug where Leopard and Snow Leopard use different ways of caching as they move data to the hard drive. It's not a problem when the drive is dismounted and remounted between backups, apparently, but only when both computers alternately access the drive while it is connected to the same network. So dismounting and remounting the drive between backups would eliminate the problem.

That's not a good solution, though, because it would make it difficult to schedule backups for both machines while I'm asleep. But fortunately, the problem only seems to occur in one direction -- when I backup the iMac after backing up the MBP. So far, at least, dismounting and remounting the drive after backing up the MBP, then scheduling the nightly backups with the iMac first and the MBP second, seems to be working.

Ralph