If you're using the release version, the log files are in ~/Library/Logs/QRecall. If you are using the beta, just choose Help > Send Report...

It sounds like you want to create a QRecall archive on the Linux server that's connected to OS X via Samba.

If that's the case, it should work. QRecall is designed to capture from HFS+ volumes, but it can write an archive to just about any filesystem (MSDOS, Samba, UFS, ...). The archive itself is just a package (directory) that contains a set of flat files. The principle prerequisite is that the filesystem that contains the archive be able to efficiently, and correctly, handle large (multi-Gigabyte) data files.

So everything captured from your OS X volume (file data, metadata, ACLs, and so on) ultimately just become data in a flat file in the archive package.

Rene Rasmussen wrote:Are there any updates with respect to "Make QRecall File Vault Friendly"

Not at the moment.

There are actually several issues related to this problem that have come up over the past month. Some are specific to FileVault and some aren't.

I was putting off addressing these limitations until support for encrypted archives was added (the theory being that anyone who's using FileVault wouldn't want their files copied to an un-encrypted archive). However, it's becoming evident that other users are dealing with related limitations that are unrelated to FileVault, so it might be prudent to address some of these issues sooner.

Just be aware that there are lots of other features in the development queue, so it could still be some time before this gets addressed.

Bob Tyson wrote:However now that I look, every one of my external drives has that feature checked. Is that a default that OSX or Disk Utility goes by?

Yes, the default is to create a new volume that ignores owners and privileges. The OS X installer always resets this option whenever you install the OS, so if you format a volume and then install OS X it will all work fine, even if you're oblivious of the ignore permissions option.

To review, ...

I re-formatted the disk - OSX - Journaled, and zero-ed all data. Then used QRrecall to 'Restore To' the system and all files, that is the existing startup volume, internal disk, on the iBook.

As I noted for you before, there WERE problems with permissions but minimal and things seem ok now. I'd have a hard time remembering just what I needed to tweak but it wasn't much, other than the Adobe licensing issues.

As I remember, it was initially a disaster.

In your original post, you said that after the Restore To... the volume wouldn't boot. You then reinstalled the OS getting it to work, but with some permission problems. That's consistent with Restoring to a volume that's ignoring permissions. When you installed the OS, the OS X installer fixed the setting and re-installed all of the system files with the correct permissions. The only thing left was your user files with default ownership and permissions.

That, by the way, did not surprise me, although it still seemed to be at odds with your presenting QRecall's Restore To as producing a ready-to-roll clone on the new disk. A detail.

It more than a detail, it's a bug. When testing QRecall I have always set the correct permissions option without thinking about it. It honestly never occurred to me that someone would try to restore a system volume without clearing that option. The hazards of testing your own software.

QRecall will be a ready-to-roll recovery application. My current plans are to either warn the user that they are restoring to a volume that ignores permissions or capture and restore all of the volume-level settings, which would automatically restore the permissions flag during the restore. There are technical issues with the later, which I'm looking into.

And now I have another question that arises from the same series of experiences.

I used QRecall to make a backup archive of the newly-christened firewire disk, but when I look to do a new capture or incremental backup it doesn't look the same as for the 'ordinary' kind of archive and backup, that is the options seem to break down to making a new capture of the whole volume or ???

I'm not quite sure what you mean. All captures are incremental. If you want to capture something other than the full volume, remove the volume from the list of items to capture in the action then add the individual folders you want to capture instead — or just create a new action.

What, for me, would make all of this moot is to have a feature by which one could 'Restore To' for any folder or portion of an ordinary archive, not just a full-volume.

That's a recall. Open archive, select item, drag to location with existing item. QRecall will ask you if you want to replace it. Click OK.

In fact in this case what I would have preferred would have been to have re-installed OSX from scratch on each volume, THEN 'Restored To' from the QRecall Archives. But you can't do that.

Absolutely. Once the OS is installed you can recall any portion (say a home folder or maybe just Documents) from the archive to the new volume.

And the issue of restoring to folders, and whether or not that replaces System-ordained folders such as 'Documents', or creates still ANOTHER set of folders, baffles me.

It's no more baffling than the Finder.

Recall (command or drag-and-drop): Copies items from the archive to the chosen destination. Like the Finder, if you drag it to a location that already contains an item of the same name it will be replaced.

Restore (command) - A shortcut for recalling an item to it's original location. If the original still exists, it will be replaced. No different than dragging an item back to where it was captured from.

Restore To... - A very special command for recalling a volume to a different volume. This command exists solely because there's no top-level container in the OS X interface where you can drag-and-drop a volume over another volume.

As I mentioned before, the permissions feature of the external volume is critical.

What you need to do is to erase the volume, then (from the Finder) perform a Get Info and make sure the "Ignore owner and permissions" option is NOT checked. Then, you can preform a Restore To...

If you restore a volume to a volume that is ignoring permissions, it will be non-functional. It will try to boot, but you'll get all kinds of errors and it will eventually hang.

If you then performed an upgrade or a archive install over that, it will still be a mess because none of the files (including the ones belonging to the admin user) have the correct permissions. So any files left over from the initial restore will have the wrong owner and permissions.

It sounds very much like this is the obstacle you've encountered. Now, if the volume was erased, the ignore permissions option turned off, then restored from QRecall and the still didn't work ... I'd be very interested in hearing about that.

Bob Tyson wrote:For James B, hope the feedback may be useful.

Feedback is good.

I did not attempt the partial restore, but instead worked from a volume capture and later a restore-to. It worked without a hitch, as to doing it. When I tried to boot from the 'restored-to' volume however OSX didn't make it past the gray screen with the apple. No twirly dealie.

One problem with QRecall is that it will happily restore a captured volume to another volume that is set to ignore ownership and privileges. This results in a copy of the operating system that's useless. I plan to add a feature so that QRecall will warn you (or fix the volume) when you attempt to do this.

So I Archive-Installed OSX and that cured that.

I can't tell you, after the fact, if that was the problem. The OS installer always clears the "ignore ownership" setting on the volume, which in turn fixes that problem.

The only other thing that seems amiss is that Adobe wanted me to re-install Photoshop, saying some elements were missing. And re-authorize my license.

Adobe detects that you've reinstalled the software on a new volume.

Only now after doing that, I remember that I did the Startup Volume capture FROM the startup volume, running the OS from that volume. Next time I'd run from a different volume and see if that didn't go any differently.

Should not be necessary. QRecall can preform "live" captures and restores of the OS.

"Restore To..." is a specialized command for restoring an entire volume to a different volume. Anything less is just a recall.

I want to use QRecall to 'restore' my startup volume to a new external drive, but NOT with the System and associated files. It's time to do a clean install and I want QRecall only to restore User files.

Install the operating system, set up a new account with the same short name (say "bobtyson") as your current system. Start QRecall and drag your archived home folder ("bobtyson") into your new Users folder so that it replaces the empty home folder you just set up.

The only potential problem you might have is if the User ID (UID) of the new bobtyson isn't the same as UID assigned to bobtyson on your existing system. If bobtyson is the only account on both systems, then they are likely to be the same. If not, post a follow up and I'll give you line of Terminal Voodoo that will fix up the mismatched UID.

Rene,

The problem turns out to be the location of your user account's home folder. It appears to be on a separate volume.

Security changes made to Mac OS X now prohibit the running of privileged executables on external volumes. So even though you successfully authorized QRecall to run with administrative privileges, the operating system is still preventing it because your application support folder (~/Library/Application Support) is not on your boot volume (the volume containing /System).

I hope to address this limitation in a future version, but for now QRecall can only be pre-authorized to run with administrative privileges if the user's home volume is on the boot volume.

Rene Rasmussen wrote:In the preferences the button "Preauthorize..." is enabled

If you see the "Preauthorize..." button and you don't see the message I mentioned above, then QRecall is not being preauthorized.

The log will probably explain what's going wrong.

I'm curious to learn if your QRecall installation was successfully pre-authorized. Open up the QRecall > Preferences... and in the Authorization tab, make sure it says "QRecall has been preauthorized to use administrative privileges when capturing and restoring items."

I'd also like to see your log file. If you are using the current beta, choose Help > Send Report... command. If you are using the release version, zip up the file ~/Library/Logs/QRecall/QRecall.log and either post it to the forum or send it directly to me.

Thanks

Bruce Giles wrote:I can send you the log if you're interested.

Yes, thank you. Try the new Help > Send Report... command.

If you've reindexed your archive there shouldn't be any missing names in the index. There's a recently discovered bug that could result in empty (null) names appearing in the index, but I'll have to go back and find out if that bug was in the latest public beta.

The effect of missing names is harmless, but thanks for the heads up. If you have a chance, please send a diagnostics report (Help > Send Report...) or e-mail the relevant log files.

Can I use QRecall to make a non-encrypted backup of files from my home folder when that folder is open (i.e., accessible)?

In principle, the answer is yes. I'd suggest configuring the QRecall scheduler to NOT start or run actions while logged out. If you are just capturing your own documents, you probably don't even need to authenticate it to run with administrative privileges.

However, I strongly suggest that your download QRecall and try it with a trail identity key first. I have not tested QRecall recently with File Vault and Apple has made a large number of security changes that impact what applications are allowed to do under File Vault. So try it out first and make sure it works on your system.

I have a long standing to-do item entitled "Make QRecall File Vault Friendly" which has been around for some time. I've been putting this off until I add archive encryption to QRecall, which would make it much more appropriate for using in conjunction with File Vault users.

Frankly, I wish I hadn't encrypted my home folder with FileVault. I don't have enough space to un-encrypt it

If you have the external disk space, you could probably copy or capture enough to your external drive to un-encrypt your home folder and then restore the documents.

Ralph,

Thanks running the reindex again and the for the diagnostic report.

The problem is a duplicate directory record. This is a subtle problem that was only recently brought to my attention by another user. The most recent versions of QRecall (version 1.1.0(7) and later) have new diagnostic code to detect and correct this situation.

My suggestion is to repair the archive. This should detect and repair the duplicate directory records. If you end up with a layer that's marked "Damaged", merge it with a subsequent valid layer to eradicate any trace of the anomaly from the archive.

Ralph,

If you have the time, please reindex the archive with QRecall 1.1.0(lucky 13).

I expect that you'll encounter a similar problem, but this version dumps more information to the log. I'm basically trying to figure out if the problem is in your archive (any why) or if it's a subtle flaw in the reindex procedure.

To upgrade:
- Download 1.1.0(13)
- Open your Applications folder
- Drag your existing QRecall application to the trash
- Open the 1.1.0(13) disk image
- Copy the new QRecall into your Applications folder
- Launch the new version

Reindex the archive, then choose Help > Send Report... to upload your log files.

Thanks,