I just wanted to drop a note in here. I have been using the Qrecall trial key for 2 weeks now and just purchased my personal key.

I have been waiting for a "retrospect like" mac backup solution for a very long time now. Qrecall is the first of a myrdia of back up applications that acknowledges some of retrospect's strengths and aims to provide an equivalent or better back up strategy.

One of the main reasons I actually purchased a user key is to encourage the developer- I really hope the development continues. It appears the 1.0.1 has been around for awhile now.

Most of what I read about retrospect is a difficult user interface. I guess I was one of the few the grasped its strengths right away and went to town with it.

Despite the developers intentionality in creating a simpler user experience, I guess it has partly been the change of vocabulary, and partly just the change in doing things- but I haven't always found that QR does what I would have hoped or expected. Thats ok, its not my application under development.

But, as I use it more I hope to log my compliments and gripes here in this thread. Perhaps I can learn how to use QR better while doing so and perhaps the developer might also glean a few suggestions.

BTW, thanks for writing QR, it was dreadfully needed. I don't run leopard yet, I am avoiding it- but even if I ran it I would choose to avoid time machine. I love having an incremental back up with one archive file...

OK, off to play with QR more now that I have my personal user key...

cheers!

Welcome, David.

David Cretney wrote:I really hope the development continues. It appears the 1.0.1 has been around for awhile now.

If 5 months is "awhile now," then I guess 1.0.1 is getting long in the tooth. sigh Internet time moves so quickly.

Despite the developers intentionality in creating a simpler user experience, I guess it has partly been the change of vocabulary, and partly just the change in doing things

I've struggle mightily with the terminology of QRecall, and that's one of its consistent criticisms. The problem is that QRecall does do things differently. So the choice is to reuse teminology that's inappropriate, or introduce new terminology that's unfamiliar. I've decided that I can't win for losing.

but I haven't always found that QR does what I would have hoped or expected.

That's exactly what these forums are here for. If something's confusing, inconsistent, or unexpected, please share those experiences. It will either improve QRecall or your understanding of QRecall.

Hi,

I just noticed some of my last backups were 01 Sept, then there was a glitch when my trial key expired. I entered the new key and back ups continued happening, but in my archive all my layers prior to the last backup on 05Sept are greyed out. I thought maybe I had improperly used a merge action. But infact on my photos archive and my music backup archives I haven't even used an automated merge and those archives too have older layers greyed out.

I'm trying to find out why those old layers (going back about 2 weeks now, every 2nd day or so I ran a capture) are not accessible. I checked the log and there are no merges at all.

Did switching from trial to paid lock me out of captures that were created while I was using a trial key?

David Cretney wrote:Did switching from trial to paid lock me out of captures that were created while I was using a trial key?

No, they're still there. They just belong to a different user.

An identity key is just that: It identifies the owner of the captured items. When you changed keys, you changed identities. Items captured before September 1 belong to the trial key owner. Items captured after belong to your permanent key.

Open up the Owners and Volumes drawer (View > Show Owners & Volumes). There you will see the set of owners and volumes captured in the archive. Select a volume to switch between them. The layers that contain items belonging to that owner & volume are active. The layers that do not contain any items belonging to the selected owner and volume are grayed out.

Here is my first gripe. I don't like it how, while browsing an archive, double clicking restores a file or directory. It took me about 2 weeks to restrain myself from double clicking, but instead using the drop down arrows to drill down.

I'm so conditioned to open something that when I first browsed I started double clicking and restoring this that and the other.

Thankfully QR is set up to, by default restore to a secondary location- but it took me awhile to find it and delete the accidentally restored files.

Using the drop down arrows to navigate the library is cumbersome, I'd sure like to be able to navigate by double click and only use the task bar button for restore- or make it configurable.

David Cretney wrote:Using the drop down arrows to navigate the library is cumbersome, I'd sure like to be able to navigate by double click and only use the task bar button for restore- or make it configurable.

There are two alternate browsing modes that I've had on my to-do list for eons, but I've never gotten much feedback about the browser so I've left it be for now. That, and any change to the browser would be a huge amount of work.

I've considered a single-window browser. Opening a folder would replace the contents of the window with the contents of the opened folder. This is, more or less, how single-window browsing in the Finder works. But then there are navigation issues (i.e. how do you get back).

Another option, and the one I'm most fond of, is to implement a column browser mode.

Anyone have any input or reaction to these suggestions?

James Bucanek wrote:Another option, and the one I'm most fond of, is to implement a column browser mode.

Anyone have any input or reaction to these suggestions?

I'd be in favor of the column browser mode. It solves the "going back" problem with the single window, and avoids creating an increasingly cluttered window as you browse like the disclosure triangles do. Keeping the ability to see what layers contain a version of each folder/file is important, too.

Ralph

Hi Gents,

its been awhile since i've checked in which is good news as it means no hard drive failures or qrecall failures.

Unfortunately my wifes ibook died and it wasn't backed up. Needless to mention a few problems in the land of marital bliss.

Hence, I am trying to find an optimized strategy to get her new macbook backed up. My imac is using a single license qrecall to back up to my 2TB dual firewire drive.

I'd like to get her macbook backed up to the same drive- but not necessarily the same archive.

So I started a new capture action after mounting the macbooks HD on my imac. I started the capture process. Both macs are connected by wireless N to a router. The speeds are disapointingly slow- likely a wireless thing, not a qrecall thing.

So, this got me thinking about other angles on this problem. I think once the initial back up is done, incrementals over wireless won't be a big deal.

I'd like to hear suggestions or what others are doing in a case like this.

David Cretney wrote:So I started a new capture action after mounting the macbooks HD on my imac. I started the capture process. Both macs are connected by wireless N to a router. The speeds are disapointingly slow- likely a wireless thing, not a qrecall thing.

You would probably be better off installing QRecall on the MacBook, then mounting the iMac's backup volume on the MacBook and capturing to that. For speed, you could attach the drive directly for the initial capture.

Capturing a remote (vs. a local) volume runs into two problems. The first is speed, which you've already encountered. The second is that you do not have unfettered access to remote volumes. This makes it impossible to capture some files and information. Preauthorizing QRecall gives it complete access to local devices, but remote volume access is always filtered through the security of the file server. Granting QRecall administrative privileges makes no difference.

I think once the initial back up is done, incrementals over wireless won't be a big deal.

Subsequent captures should be much faster.

James Bucanek wrote:

Another option, and the one I'm most fond of, is to implement a column browser mode.

Anyone have any input or reaction to these suggestions?

Hi james,

column mode sounds very good to me also. I had my initial problems understanding the interface of QR. Seems to me that this would help new users a lot.

I'm trying to attach screenshots of a qrecall problem I have but I get this:

An error has occurred.

For detailed error information, please see the HTML source code, and contact the forum Administrator.

java.io.FileNotFoundException: /Users/quantumrecall/Sites/forum/./upload/2010/4/10/a2a2e8f9c1ce876b7a138eecfba4d037_771.png_ (No such file or directory)

I am having a qrecall problem with one of my captures. I am getting the following bad checksum errors:




It seems random but the qrecall error is consistent. Is this a disk failing? I ran disk util repair permissions. Do I need to repair more?

I have been repairing the qrecall archive and I have another capture script that backs up the same imac disk to a different external drive and that one has not been producing these errors.

David Cretney wrote:I'm trying to attach screenshots of a qrecall problem I have but I get this:

Apparently, the forum software is having directory permission issues. I'm looking into it.

David Cretney wrote:It seems random but the qrecall error is consistent. Is this a disk failing? I ran disk util repair permissions. Do I need to repair more?

I have been repairing the qrecall archive and I have another capture script that backs up the same imac disk to a different external drive and that one has not been producing these errors.

When encountering a data corruption error, here's my suggested course of action:

(1) Repair the volume. You did that, and that's good. Repairing a volume corrects volume and directory structure problems which can wreak havoc with other software (i.e. QRecall), and report all kinds of erroneous errors.

(2) Repair the archive using the default repair settings. Unlike most software, QRecall does not trust the reliability of your computer system or your disk drive. It confirms that every bit of information in an archive is correct and unaltered before using it. Repairing the archive will test every byte, discard anything that looks suspicious, and turn all of the vetted data back into a usable archive again.

Now, why is this happening? There are a number of situations where data can get damaged/lost:

Transient memory (RAM) errors can corrupt the data before it's transported to the disk drive.

The data can be corrupted while being transported to the drive's controller (via USB, Firewire, etc.)

The drive can fail to write the data correctly to the disk surface.

The data can degrade over time and become corrupted on the drive.

Perfectly good data on the drive can be overwritten with other perfectly good data because the volume's directory structure has become damaged, corrupting the archive.

The data could be misread by the drive.

The data read could be corrupted while being transferred (USB/Firewire) back to your computer.

The data read into memory could be spontaneously corrupted by a transient memory (RAM) error.

If the data is corrupted before it's written to the archive, or the data is changed/overwritten/corrupted on the disk drive surface, this creates a permanent data error in the archive. QRecall will complain that this particular bit of data is corrupt every time it attempts to read it. You can tell this is the problem by running a verify and looking at the log. Expand the "bad envelope whatever" message and look at the file position of the error. A permanent error will report the same file position every time.

An error that occurs while reading or transferring the data back to your system can cause transient errors. QRecall attempts to work around transient errors by re-reading any data that looks corrupt. If it's successful, QRecall will log a "Transient data error" in the log. If you find these, then your system is spontaneously damaging data as it's being read. The culprits are often the drive's controller, your USB/Firewire/etc. bus, or flaky RAM.

If the failure is transient but unrecoverable, then the problem is most likely the drive controller or data buffer. If you verify the archive multiple times and it fails in different locations, then it's a transient data problem that QRecall can't automatically recover from.

If you have one computer system that doesn't encounter any problems while a second computer system encounters data corruption errors—and you've verified that the volume's directory structure is OK—then the source of the problem is likely to be the second system's I/O or RAM.

Keep in mind that repairing a volume using Disk Utility or similar programs only corrects volume and directory structure problems. It does not verify the integrity or reliability of drive's data storage. This is largely due to the time and effort involved; a complete surface test of a modern drive would take days to perform and most modern drives have automatic data correction and sector sparing making testing somewhat redundant. But this doesn't mean that data is never lost, and is why QRecall is so untrusting of data storage devices.