Hi, I'm new to QRecall. I've downloaded the software, and used it a couple of times to backup to an archive using trial keys. It seems very full-featured and robust. I am wondering, though, about whether QRecall detects or protects me in the event that a file goes bad on the source disk I'm backing up; I recall seeing some articles a few months back about "bit rot," the possibility that old, seldom accessed files will silently fail by flipping a bit here or there. Since these files aren't accessed in normal use, the corruption lies possibly undetected for a long time, until one day you access it and you get a disk error, or your JPEG shows artifacts. I know that btrfs and ZFS maintain integrity on source disks by storing extra redundant data; I'm hoping that QRecall might give me some of that robustness and peace of mind, albeit in slices of backups.

So, I was wondering if QRecall reads entire source files (all the blocks that comprise file data) during the backup process, or just file meta data? If it reads entire files (of all files, not just files whose meta data indicated a change), what does it do when it detects that the underlying block data has changed, but the meta data hasn't changed?

Here is the article that got me thinking about this topic:

http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/

Thanks for your opinions and advice.

Kurt

Kurt,

All great questions. QRecall is primarily focused on detecting and protecting you from damage to the archive. Currently, all records in an archive are checksummed and QRecall tests those checksums whenever those records are used. This allows QRecall to detect if archive data has been corrupted, preventing you from recalling corrupted data or compounding the corruption with new data.

The next (as-yet-unreleased) version of QRecall adds data-redundancy. This allows QRecall to detect and correct limited amounts of data corruption in the archive.

QRecall cannot, however, do much about data corruption in the source filesystem. If you need that kind of protection, you should be using a RAID or other filesystem that supports data redundancy and correction.

It?s not practical to re-read every byte of data of every source file during every capture. QRecall is, at its heart, an incremental backup utility. To do that efficiently necessitates the use of monitoring filesystem change events and comparing file metadata to determine which items needs to be recaptured. Recapturing all of the source data every time would turn every capture into an initial capture, requiring many (many!) hours to complete.

If, however, you still want to do that sort of thing, I?ve had a "?force? capture option on the drawing board for awhile. This would force QRecall to recapture all of the source items in their entirely, as if they had never been captured before. If that?s important to you, let me know and I?ll give it a +1.

There?s also been requests for a verify/compare action that would perform a byte-by-byte comparison of data on the filesystem with the data in the archive and note any differences.