Hi James,
Thanks for taking the time to work through my catalogue of questions and suggestions
I have this crazy dream, from time-to-time, of writing a file system plug-in that would mount a QRecall archive as though it was a volume containing the original files (read-only, of course)
There may be something that could serve as a basis of this at google code.
One implementation makes .flac files appear as .wav. And this is read & write.
Keep reading; you might change your mind.
There are many reasons why I don`t want any archiving in open or proprietary standard.
A few of these:
I want to be independent of a particular backup solution, comparing backup and original with other software, the more complex the storage mechanism, the more severe damage might be the consequence if there is a bug, backups surely require more time using packeging (be it for compression or for your method to make the most use of storage space), manual checks of individual files for piece of mind, a damaged backup archive always endangers more than one file.
QRecall`s storage mechanism is more complex than 1:1 copies as it does store fragments of files and relies on it`s database what piece of the puzzle belongs where to re-assemble the pieces in case they should be restored.
I think the benefit is supposed to be able to backup and store a total amount of data that is virtually bigger than what would be possible to store within the particular storage device`s capacity even if compression would be used.
I admit the potential is great if you are using versioned backups or archiving.
I've considered implementing a "compare" feature that would compare the file information in a QRecall archive with what's on the disk. Surprisingly (up to now) no one has requested this feature.
I am not surprised. I wasn`t interested in this prior to 3-4 days ago when I read why this is an issue at taobackup.com
This is clearly something that is not totally obvious.
Nevertheless I agree with the author of taobackup that this is an important issue.
The problem with a compare function as an integrity tool that that files change all the time. ... a compare feature can't tell you if one of your source files is damaged, only that it's different.
...No software ... can tell you if a document has become damaged. Comparing the files on your disk with the copies in your backup only tell you what's changed, not what shouldn't have changed but did.
The modification date is changed by the operating system whenever there is write access.
If the modification date does not indicate write access since a hash signature was generated but the file has changed, then it is corrupted.
By keeping efficient multi-generational copies of files, should you find a corrupted copy of a source file you can go back to the archive, go through its history, and retrieve a good copy of it before it became damaged.
The problem is that it is very likely that you won`t notice the difference.
While you can very often *see* the difference in a picture file, in case of software for instance that you bought as download and not on a DVD-Rom you can`t tell it was damaged. The software may now crash often but you will blame the developer.
There are more examples. Chances are that you will not discover it.
A Verify action can be scheduled to run on whatever schedule you choose.
So far for the destination only.
A transient permission or read error with a single file will be logged, but won't stop a capture. Errors with the archive itself will immediately stop a capture, in order to prevent further damage to the archive.
That`s what I aim at when I want 1:1 copies:
If there is just a small defect in the archive, maybe due to a bug or just a powercut when writing the backup, a large number of backed up files may not be possible to restore any longer (if data fragments where damaged which are required for re-assembly of many files (versions)).
That`s why my approach is to keep it as simple as possible. But I also think that verification is necessary (some backup solutions for the Mac with 4 star ratings don`t even check the destination after writing. Funny: the developer almost seemed to present this as a feature because it speeds up the backup process. well, I hope he has a harddrive crash soon and learns that his complete backup is useless
).
So there are many simple 1:1 copy tools (free) and commercial solutions. But some have other shortcomings. Command line tools are not for me.
QRecall has "event" schedules that can start a capture when the volume containing the items to capture is mounted, or when the volume containing the archive is mounted.
Very flexible
If the application write a monolithic file using the common "safe save" technique, QRecall will capture the old copy of the document intact. If not, then the captured copy may be inconsistent and you'll have to perform another capture of the document while it isn't being modified before you have saved a valid copy. All file copy and backup program suffer from the same problem, even Apple's Time Machine.
Is there no way for a backup application to check if a particular file is currently being saved?
In the activity window, you have two choices. Stop and Reschedule cancels the current action and schedules it to run again at some future date. Or, you can pause a running action for varying amounts of time from between 5 minutes and 4 hours. The action will automatically resume after that time, or you can manually resume it at any time.
This is very thoughtful. The perfect option for any occasion
There are many things that speak for QRecall. The lack of a more simple 1:1 copy sort of spoils it for me. An archive or versioned backup is more or less an afterthought for me while I consider simple 1:1 copies to be important.