This is what I have wanted my backup software to always do. You've made it, it seems to be blazing fast for me (8 core mac pro, 8GB (for now) RAM, and a RAID 0 with my data on it)

I'd definitely love to see more filter capabilities, especially finder labels. Though QRecall lets me not exclude things I used to with ChronoSync, since now it doesn't backup my entire iPhoto library at 22GB every time I modify a file. (I know ChronoSync could dissect bundles but that caused issues with other things.)

Overall so far I am extremely impressed, I'm running the latest beta on a beta key, but once I am positive this is going to work for me (give myself a week or so of backups, do some recalls, etc.) I will definitely be making a purchase.

All in all I love it!

Cody Frisch wrote:This is what I have wanted my backup software to always do.

Awesome.

I'd definitely love to see more filter capabilities, especially finder labels.

So would a number of other people; it's a common feature request. I have advanced filtering features tentatively scheduled for the 1.3 release (currently working on 1.2). A bit off in the future, but I'm sure I'll get there.

I just find it interesting that here is a program that seems to be written by one guy, and its far more capable than applications written by companies with several employees. (Not to mention much less expensive.)

One thing I was thinking could be useful, is compression rules on an archive. Exclude certain file types (mp3, mov, mp4) from being compressed at all since they aren't that efficient to compress again. Trade off by focusing the compression on those things which can really benefit.

Cody Frisch wrote:I just find it interesting that here is a program that seems to be written by one guy, and its far more capable than applications written by companies with several employees. (Not to mention much less expensive.)

I'm glad to hear that. I would certainly like to have several programmers working on QRecall; I know that I'd like to add features faster.

One thing I was thinking could be useful, is compression rules on an archive. Exclude certain file types (mp3, mov, mp4) from being compressed at all since they aren't that efficient to compress again. Trade off by focusing the compression on those things which can really benefit.

I seriously considered this when developing the compression feature. I know that Retrospect (and others) have compression filters. However, I ultimately rejected it for two reasons: (a) I think it's too complicated and (b) QRecall doesn't work the way that other backup programs do.

Hopefully (a) is obvious, but (b) requires a little explanation.

Instead of turning compression on/off on a file-by-file basis, QRecall measures the cost/benefit of compression on a block-by-block basis. When you have the compression level set low, QRecall uses a fast-but-not-necessary-efficient compression algorithm on every block of data. It then examines the results of that compression. If the compression really didn't save much, it throws it away and stores the uncompressed copy of the data record. The theory is that the little bit of data saved doesn't make up for the amount of CPU required to decompress it.

In this way, QRecall is self throttling, automatically opting to compress data is the highly compressible but not compressing data that isn't. This is smarter than file-by-file filters because it can even decide that some parts of a file are compressible while others aren't.

At higher compression settings, the compression algorithm used is slower and more CPU intensive, and the threshold of for accepting compressed data is lowered.

One of the big differences between QRecall and other file-based backup software is that the data in files is compared to that data already in the archive. Using Retrospect (or Time Machine, or whatever), if you edit the metadata of an MP3 file the software will copy the entire file again. If compression is enabled, it will compress the entire file again.

QRecall, on the other hand, reads the MP3 file and compares it to what's already in the archive. Most of the file hasn't changed, so almost no new data is compressed. If the duplicate data in the file wasn't compressible, then QRecall has already determined that (when it captured the data the first time), so no compression or decompression is performed. If the data was compressible, then it only needs to be decompressed (much faster than compressing) in order to compare it with the source data before a decision is made not to add it to the archive.

So in the end, I feel that QRecall's compression features is much easier to configure, smarter, and ultimately more effective than hand-tweaked per-file compression filters.

That does make sense. Since most of my data is already compressed i've decided its probably most efficient to just leave compression at the fastest setting anyway. About 550GB of my data is mostly mp3, flac, and Panasonic DVCPro HD video footage. The other 350GB is mostly video in various formats and PDF which are already compressed. I'm not going to gain much with higher compression.


Thanks for your explanation!