https://forums.qrecall.com/posts/list/3.page JForum - http://www.jforum.net
To get started, go to the [url=http://www.qrecall.com/download/]QRecall Download[/url] page.

If you already have a permanent or trial identity key, you can continue to use that. If don't have a permanent key, or your trial key has expired, you can obtain a free Beta Identity Key that will be valid for the entire beta test period.

The theme of QRecall 1.2 is "performance and interface." The performance part involves a lot of under-the-hood changes and the bulk of that work is complete. Later beta versions will begin to incorporate a new interface, but I wanted to get the mission-critical code changes done first so they can get as much testing time as possible.

As always, feedback is welcome and encouraged.]]> https://forums.qrecall.com/posts/preList/252/1143.page https://forums.qrecall.com/posts/preList/252/1143.page GMT https://forums.qrecall.com/posts/preList/252/1144.page https://forums.qrecall.com/posts/preList/252/1144.page GMT Excellent news!

[quote]I didn't however noticed a faster Verify (1:07:12 for a 237.6 GB archive) than I got with QRecall 1.1.4. Don't know if I should have expected this(?).[/quote]
Verify was highly optimized a couple of versions back, and will be I/O bound for most users. In other words, QRecall can verify the archive as fast as it can be read from the drive. So until you get a faster hard drive/interface, verify won't get any faster.

The principle improvements in QRecall 1.2 are more efficient use of the quanta and packages indexes, expanded RAM usage (thanks to 64-bit addressing), and multi-processor load balancing. These changes improve capture performance the most, and impact compact and merge actions to a lessor degree.]]> https://forums.qrecall.com/posts/preList/252/1145.page https://forums.qrecall.com/posts/preList/252/1145.page GMT Had a quick check in the log. Version 1.1.4 captured 1.12 GB (75% duplicate) in 12:53 while the beta managed 1.15 GB (73% duplicate) in 09:56. Looking good.]]> https://forums.qrecall.com/posts/preList/252/1146.page https://forums.qrecall.com/posts/preList/252/1146.page GMT
Ralph]]> https://forums.qrecall.com/posts/preList/252/1147.page https://forums.qrecall.com/posts/preList/252/1147.page GMT No. Writing to an archive using version 1.2 will mean that earlier versions will not be able to use the archive.

For what it's worth, the core data format has not changed. If you use QRecall 1.2b1 to modify an archive and later want to revert back to using 1.1.x, reindexing the archive with 1.1 will make it usable again.]]> https://forums.qrecall.com/posts/preList/252/1148.page https://forums.qrecall.com/posts/preList/252/1148.page GMT
-- Current Stable --
Captured 8668 items, 19,8 GB (29% duplicate)
Capture finished (16:03:19)

-- Current Beta --
Captured 11914 items, 24,5 GB (24% duplicate)
Capture finished (3:04:10)

A more than 5-fold speedup!!!
Is this actually expected?

I did actually use the machine while the capture ran and I didn't see much slow downs or something like that. And by the way: Yes this was a full capture with ignoring of the filesystem change history.

So I guess this beta is quite promising! Good Work so far!

ciao,
Jochen]]> https://forums.qrecall.com/posts/preList/252/1149.page https://forums.qrecall.com/posts/preList/252/1149.page GMT Is this actually expected?[/quote]
Performance improvements for individuals is really hard to estimate. It all depends on your circumstances and configuration.

For most users, I expect mostest performance improvements. But in specific combinations of OS, archive size, RAM size, CPU type, and I/O configuration, the speed increase can be dramatic. I've created test cases here where the beta runs 40x faster than the previous version, capturing a test folder in 40 minutes where version 1.1.4 took over a day.
]]> https://forums.qrecall.com/posts/preList/252/1150.page https://forums.qrecall.com/posts/preList/252/1150.page GMT
I just wanted to provide my feedback with respect to performance using the new Beta 1.2 of QRecall.

I have a nightly scheduled QRecall backup that was consistently running in excess of 8 hours to an external Firewire drive...that same backup...using the new Beta 1.2...is now running in less than 55 minutes...a [b]huge[/b] 8X performance increase.

This is really outstanding...your product has always worked very well for me...it has saved my "backside" on numerous occasions...but with this new update...it is truly an amazing utility.

As always...I have recommended your application to all of my mac clients...thanks again for all of your dedication!!

GKG

]]> https://forums.qrecall.com/posts/preList/252/1198.page https://forums.qrecall.com/posts/preList/252/1198.page GMT
Thanks for the feedback. It's always good to see real-world numbers—especially when those numbers show improvement. :)]]> https://forums.qrecall.com/posts/preList/252/1199.page https://forums.qrecall.com/posts/preList/252/1199.page GMT
During the past week...I had a chance to test some additional captures using the beta 1.2 version. I seem to have hit on an issue that I am hoping you can shed some light on.

Last Wednesday...I restarted one of my MacBook Pro's in target disk mode...and performed a QRecall capture of the entire laptop's hard drive via Firewire to another MacBook Pro. The initial capture went smoothly....no issues.

I continued using the first laptop normally since last Wednesday...including a VMWare Fusion virtual machine. This morning...I performed the exact same procedure...I restarted the laptop in target disk mode...attached it to my second laptop using a FireWire cable...and attempted a QRecall recapture of the entire drive...the recapture finished in about 10 seconds...unfortunately, QRecall did not recognize the fact that the VMWare virtual machine had changed over the past 3 days...and so it did not choose to recapture it. The modify timestamp on the VMWare virtual machine package is today's date...and thus...I would think that QRecall should have certainly included it in its recapture operation.

Any ideas?


Thanks...]]> https://forums.qrecall.com/posts/preList/252/1200.page https://forums.qrecall.com/posts/preList/252/1200.page GMT
[quote=Gary K. Griffey]This morning...I performed the exact same procedure...I restarted the laptop in target disk mode...attached it to my second laptop using a FireWire cable...and attempted a QRecall recapture of the entire drive...the recapture finished in about 10 seconds...[/quote]
I suspect that you've been bitten by the file system events (a.k.a. FSEvents) service. I'll quote from the [url=http://forums.qrecall.com/posts/list/66.page]Advanced QRecall Settings[/url] page:
[quote]Leopard's folder change detection is not foolproof. There are a number of obscure situations where the file system will not accurately report the changes on a volume.[/quote]
One situation where it isn't foolproof is (drumroll) moving a drive between different systems—[i]especially[/i] if those systems aren't running the exact same version of the OS.

What happens is that the volume's file system change log gets reset, and when QRecall queries the volume for changes it comes back with nothing (or very little), and QRecall skips capturing items that have, in fact, changed since they were last captured. You can verify this by looking in your QRecall log. Open the QRecall log window and slide the details control all the way to the right. In the log messages for the capture you'll find something like this:
[code]Locating changes since Tuesday, August 3, 2010 7:30 PM
Collected 117,752 folder changes[/code]
If the number of changed folders was zero or very small, then the operating system has lost the history of changes for that volume.

QRecall knows that the file system change log isn't reliable and will periodically ignore it. Unfortunately, the default period is about a week:
[quote]To guard against this, QRecall only trusts the operating system for a limited amount of time. After that (approximately 7 days) the capture will ignore the system and perform a deep, exhaustive, scan of the entire directory structure looking for changes. Once the deep scan is complete, QRecall will again trust the operating system's change detection for another 7 days.[/quote]

You can work around this problem be reducing the amount of time QRecall trusts a volume, or disabling the feature altogether, by setting the [b]QRAuditFileSystemHistoryDays[/b] advanced settings. Put your MBPro into target disk mode, plug it into your other system, open a Terminal window, and issue the command:
[code]defaults write com.qrecall.client QRAuditFileSystemHistoryDays -float 0.0[/code]
This will completely disable QRecall's use of the file system change events log. It will, instead, check every file and folder for changes on every capture. Note that this can significantly increase the amount of work QRecall does on each capture.

Capture your MBPro. QRecall should find and capture all changes on the volume. When you're done, restore the default be deleting your custom setting. Again in Terminal, issue the command:
[code]defaults delete com.qrecall.client QRAuditFileSystemHistoryDays[/code]

In the future, you have the option of repeating these steps each time you capture your MBPro or you could leave QRecall's "trust" period set to something much smaller than its default value of 6.9 days. For example, setting it to 0.9 would mean that a second capture that's more than 22 hours after the previous capture would trigger QRecall to perform an exhaustive scan for changes.]]> https://forums.qrecall.com/posts/preList/252/1201.page https://forums.qrecall.com/posts/preList/252/1201.page GMT
I proceeded with the steps that you outlined...and sure enough...the files were captured correctly with the subsequent attempt.

This does, however, raise some rather disturbing questions in my mind...most notably...is this happening with other QRecall captures that I rely upon...and am I simply not aware of it? Both of the MacBooks in this case are running 10.6.4...with no outstanding updates...so it would appear that OS version incompatibility is not the issue at least in my case.

I understand that this is an Apple issue...not a QRecall issue...but it is really scary to think about how many folks could be missing deltas in their QRecall archives.

Thanks again for your time...your product rocks!

]]> https://forums.qrecall.com/posts/preList/252/1202.page https://forums.qrecall.com/posts/preList/252/1202.page GMT It's entirely possible. If you are regularly moving source volumes from one system to another, then any software that relies on file system events to detect changes on those volumes should be treated with suspicion. This issue will also impact users who maintain multiple instances of the operating system (often for testing) and who regularly reboot their system from alternate volumes.

These are, however, uncommon scenarios so it isn't a problem for most users. Most of the volumes/devices uses to store documents—the kind of volumes that you would capture to an archive using QRecall—do not get passed around from one system to another. For volumes that are occasionally shuffled between systems, the 7 day setting of QRAuditFileSystemHistoryDays insures that they will get captured correctly sometime in the next few days.

The volumes that are regularly shared between systems are more likely be used to backup to (rather than from). The volume containing the archive is immune to this issue.

The best I can recommend is to be aware of the limitations of OS X's file system events log; if it's a problem for QRecall, use the QRAuditFileSystemHistoryDays setting to limit its impact or ignore it altogether.]]> https://forums.qrecall.com/posts/preList/252/1203.page https://forums.qrecall.com/posts/preList/252/1203.page GMT
Thanks for your valuable insight...I agree...when volumes are unmounted, moved, mounted to another system, etc., there can be issues with file system events and their accuracy.

I know that I have also encountered issues in the past with Time Machine losing track of various file/folder updates if certain system volume actions were performed. This would appear to fall in the same category.

As long as this is known...and QRecall is configurable using the simple line commands that you provided...I think my concerns are no where near as "dire" as I thought. I have never encountered a problem recalling a file, folder or even an entire volume with QRecall if the captures were made on the same source machine, i.e., without using TDM, etc.

Possibly, in a future release...QRecall could provide the ability to override the use of the file system events via preferences...but now that I have the terminal commands...I am happy.

Thanks again...

GKG


]]> https://forums.qrecall.com/posts/preList/252/1204.page https://forums.qrecall.com/posts/preList/252/1204.page GMT I will add that to the wish list.]]> https://forums.qrecall.com/posts/preList/252/1205.page https://forums.qrecall.com/posts/preList/252/1205.page GMT
I hope you may be able to shed some light on a error situation that I ran into yesterday using the Beta 1.2 version. I have been capturing my primary laptop's entire hard drive every Saturday using QRecall installed on another laptop for the last 4 weeks. Yesterday, I added the 4th layer. The capture appeared to run normally. The primary laptop is started in target disk mode...then mounted to the second laptop. This way the entire drive of the primary laptop is quiesced at the time of the capture.

This is the same laptop image that I had discussed with you in a previous message in this same thread. Yesterday, after adding the 4th layer...I ran a QRecall Verify...as I always do...and the verify failed...I tried to Repair the archive...but this also failed.

In looking at the Repair log entries...it appears that the rather large (about 30 GB) virtual machine disk file caused the error. I know from other threads that you have written...that a virtual machine must be suspended or shutdown to make a valid backup of it. In this case, however, the laptop that contained the virtual machine was operating in target disk mode...and was mounted to my second laptop where QRecall is installed...thus...not only was the virtual machine shutdown...but OSX was quiesced on the source drive as well.

I have attached the log file from the Capture, Verify and subsequent ReIndex/Repair operations. Now, I did run a Compact operation on the archive during the week with the 3 existing layers...and I also changed both the Compression and Shifted Quanta detection on the archive...but I never had issues doing this before to an existing archive.

As always...your assistance would be greatly appreciated.]]> https://forums.qrecall.com/posts/preList/252/1213.page https://forums.qrecall.com/posts/preList/252/1213.page GMT That's correct. The verify detected corrupted data in the archive and/or on your hard disk.

[quote]I tried to Repair the archive...but this also failed.[/quote]
Actually, the repair was successful. QRecall did log [i]warnings[/i] about the problems it found and what items were affected, but the repair finished successfully as was confirmed by the verify action that you performed afterwards.

Note that many (many!) archive corruption errors are often the side effect of a corrupted volume structure. I would encourage everyone to use Disk Utility to repair the volume containing the archive before repairing the archive. If your volume has cross-linked file allocations (for example), repairing will just set the archive up for future failure.

[quote]In looking at the Repair log entries...it appears that the rather large (about 30 GB) virtual machine disk file caused the error.[/quote]
Also correct. If you did not select the option to recover damaged files, then the damaged version of that file has been deleted from your archive.

[quote]I know from other threads that you have written...that a virtual machine must be suspended or shutdown to make a valid backup of it.[/quote]
That's very true. There is no backup system that can correctly copy a file that is being actively modified.

[quote] In this case, however, the laptop that contained the virtual machine was operating in target disk mode...and was mounted to my second laptop where QRecall is installed...thus...not only was the virtual machine shutdown...but OSX was quiesced on the source drive as well.[/quote]
The problem wasn't that the file was being modified, but that QRecall detected that data [u]previously[/u] stored in the archive failed its validity check(s). This can happen for a score of different reasons (data corrupted during transfer to the drive, random data loss on the drive, intermittent RAM errors, ...). But it has nothing to do with the source file or what condition it was in.

I also applaud the rigor of your backup methodology, but I personally think it's a little overkill. While it's true that you can't make a "perfect" copy of your boot volume while OS X is running, QRecall works really hard to successfully perform live captures and recalls from/to your startup volume. It's certainly problematic, and you definitely want to quit as many applications as possible (certainly any VM and disk images that you might be writing to), but it's not absolutely necessary to shutdown the entire OS to make a decent backup. QRecall has the ability to capture while you're logged out, and you can even schedule captures to run while you're logged out (or not run while you're logged in). Just food for thought.

I only mention this because I firmly believe that the back up strategy that works best is the one that gets used, and the one that gets used is usually the one that runs automatically, independent of the user. I'd be much happier with an imperfect backup that occurs every day than a perfect one that I get twice a week—if I remembered to do it. You also might consider a two-tiered backup strategy. Make regular (even hourly) captures of your regular documents, excluding things like your movie library and virtual machine images, and then continue with your complete backup strategy on a weekly or bi-weekly basis.

[quote]Now, I did run a Compact operation on the archive during the week with the 3 existing layers...and I also changed both the Compression and Shifted Quanta detection on the archive...but I never had issues doing this before to an existing archive.[/quote]
That shouldn't have had any bearing on the problem you described.
]]> https://forums.qrecall.com/posts/preList/252/1214.page https://forums.qrecall.com/posts/preList/252/1214.page GMT
Thanks for your quick reply and informative comments. If this happens again...I will try a disk repair prior to the QRecall Repair operation...

One other somewhat odd occurrence...I observed a system log message being repeated literally thousands of times during the capture operation. The messages were similar to the following:

8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter /Users/Gary/Downloads/melsLaptop.quanta/filename.index
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter eof=6534416, contentPosition=48
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 48, length=61464
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2822 names, document size now 47343
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 61512, length=61464
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2504 names, document size now 96272
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 122976, length=61448
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2489 names, document size now 145261
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 184424, length=61464
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2564 names, document size now 193893
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 245888, length=61456
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2257 names, document size now 244054
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter envelope at position 307344, length=61464
8/22/10 1:34:25 PM mdworker[196] _RepositoryNamesImporter added 2471 names, document size now 293148


I know that mdworker is a process used by Spotlight...I am just not sure why this type of message would be generated almost continuously during the Capture...in any event...it probably has no bearing on my corrupted archive...I just thought it might be worth a mention.

Thanks...
]]> https://forums.qrecall.com/posts/preList/252/1223.page https://forums.qrecall.com/posts/preList/252/1223.page GMT Welcome to beta testing. :)

The beta version of QRecall spits out tons more console and log messages than the release version, mostly so I can diagnose problems reported by beta testers. In this case, it's the QRecall Spotlight plug-in, which is normally quite laconic.

But you make an interesting observation. (And see, one that you wouldn't have made if I left those messages off!) Normally, Spotlight shouldn't reindex the archive until the capture (or whatever) is finished. I'm surprised that it would repeatedly be reindexing the archive while a single capture was in progress.

But it's hard to tell from the fragment that you've sent. All of that activity is a single reindex. You'd need to look for multiple occurrences of the message "mdworker[xxxx] _RepositoryNamesImporter /Users/Gary/Downloads/melsLaptop.quanta/filename.index" during the course of a single capture.

If that was happening, then that's something I need to look into.]]> https://forums.qrecall.com/posts/preList/252/1224.page https://forums.qrecall.com/posts/preList/252/1224.page GMT
By the way...I ran Disk Utility on the target laptop's hard drive...the one that experienced the corrupted archive...and there were no issues with the drive at all. I also checked disk permissions...no issues. So...I guess at this point..there is really no known explanation for what occurred with this particular incremental Capture that evidently corrupted the entire historic archive.

I guess that is the issue that I see moving forward using QRecall for backups with my clients...it would appear that each and every incremental Capture basically puts the entire historic archive at risk of total loss...this is unlike many other imaging products that I have used in the past where incremental backups are always written to a new physical file...and thereby do not jeopardize the integrity of the historic backups currently in existence.

I realize, of course, that I could simply make a copy of an existing archive each and every time before a subsequent Capture is performed...and then use the copy for the incremental Capture attempt...by doing so...one would not risk the entire historic archive should the new capture experience issues. This seems like it almost defeats the general "theme" of QRecall though...because duplicate archives must be created and, at least temporarily, be maintained.

Don't get me wrong...I think your product has some great features...and I do appreciate your thoughts and guidance.

Thanks,

Gary

]]> https://forums.qrecall.com/posts/preList/252/1225.page https://forums.qrecall.com/posts/preList/252/1225.page GMT It's often hard to isolate the cause of a single, or even a series, of random data failures without more information. The basic problem is that "stuff happens." Data storage and transfer is not nearly as perfect and repeatable as most people assume. Data in magnetic media—despite all of the clever tricks employed by modern drives to avoid it—gets lost from time to time. Data flying through USB, Firewire, SATA and over WiFi doesn't always arrive the way it was sent. And consumer-grade dynamic RAM is susceptible to the occasional bit-flip and corruption by cosmic rays.

The "problem" with QRecall is that it is almost alone as a backup solution in that it attaches 64-bit checksum to every record of data it creates, and verifies the integrity of that data [i]every[/i] time it reads it. When QRecall reports damaged data, it inevitably results in the initial impression that QRecall is failing or is somehow failing to protect your data, when in fact it's most likely the media/controller/interface/RAM/CPU/OS that's damaging the data. What is (or should be) frightening is that so many other so-called "reliable" backup solutions make no attempt whatsoever to protect against, detect, or report any data loss. Solutions like Time Machine simply copy files and hope for the best. They couldn't tell you if your files were successfully and accurately copied if you wanted them to.

[quote]I guess that is the issue that I see moving forward using QRecall for backups with my clients...it would appear that each and every incremental Capture basically puts the entire historic archive at risk of total loss...[/quote]
Not true at all. QRecall is specifically designed to protect against partial loss of data in an archive. Damaging part of an archive in no way impacts the integrity, or recoverability, of the rest of the archive.

[quote]this is unlike many other imaging products that I have used in the past where incremental backups are always written to a new physical file...[/quote]
QRecall doesn't write files, it writes data records. Each data record is small, self contained, and independently verifiable. When the data in an archive is damaged, the repair process reads and verifies every record. It then reassembles the valid records into a usable archive again.

It doesn't matter if a million records were written to a single file or a million individual files. (Writing to a single file is more efficient and ultimately safer, which is why QRecall does it that way.) Either each individual record is valid or it isn't. QRecall does not relay on the file system's directory structure to organize its information.

[quote]and thereby do not jeopardize the integrity of the historic backups currently in existence.[/quote]
The integrity of the archive's history is never in jeopardy. QRecall's layer records are specifically designed to resist corruption through partial data loss. It employs a method of "positive deltas" that re-record critical directory structure information in every layer. So the loss of data in an older layer won't impact the structure or integrity of subsequent layers.

[quote]I realize, of course, that I could simply make a copy of an existing archive each and every time before a subsequent Capture is performed...[/quote]
No need, QRecall's already doing that behind the scenes. Most actions begin by duplicating key index files within the archive (if you peek inside an archive package during a capture or merge you'll often see temporary "_scribble" files appear). New data is appended to the primary data file. If anything goes wrong (power loss, OS crash, ...) the partially modified files are summarily discarded and the primary data file is truncated at the point before the action began. The result is an instant rewind to a valid archive state. You'll see "auto-repair" in the log when this happens.

[quote]Don't get me wrong...I think your product has some great features...and I do appreciate your thoughts and guidance.[/quote]
I hope some of this technical information will help explain the extraordinary efforts that QRecall takes to preserve your data, and detect when that data has been lost or damaged.]]> https://forums.qrecall.com/posts/preList/252/1226.page https://forums.qrecall.com/posts/preList/252/1226.page GMT
Thanks for the info...possibly, you could assist me in better understanding the available Repair options...it seemed to me that after executing the Repair operation...previously verified layers in the archive were indeed compromised by this subsequent re-Capture operation...which is very much contrary to what you have stated...possibly (very likely) a user error on my part when running the Repair.

As you recall...I ran the Repair operation against the archive after the verify failed...I ran it using only the first default option..."Use auto-repair information"...you further stated...from examining the log files that I attached...that the Repair was successful. However, after the Repair operation completed...I opened the archive...and saw 3 of the 4 layers now showing "Damaged Files"...which turned-out to be the large virtual machine package...(the most important reason for running the backup in the first place, by the way).

Thus it appeared to me that the VM package in layer 2 and 1...taken 3 and 4 weeks ago respectively...had been compromised...and thus my assumption that previously verified backup layers had now been corrupted. Should I have run the Repair with different/additional options selected? Would this have preserved my 1st and 2nd layers?

Thanks...

GKG]]> https://forums.qrecall.com/posts/preList/252/1227.page https://forums.qrecall.com/posts/preList/252/1227.page GMT
[quote=Gary K. Griffey]Thanks for the info...possibly, you could assist me in better understanding the available Repair options...it seemed to me that after executing the Repair operation...previously verified layers in the archive were indeed compromised by this subsequent re-Capture operation...which is very much contrary to what you have stated...possibly (very likely) a user error on my part when running the Repair.[/quote]
None of the above; the previous verified data simply stopped verifying. A capture action only adds to an archive, it doesn't rewrite portions of the archive that have already been captured. If a previously captured and verified data record later fails its verification, then it's because some external cause (magnetic media failure, a glitch in the drive controller, OS bug, whatever) either lost, changed, or overwrote that data. The last thing to happen to an archive isn't necessary the cause. ;)

The various repair options (which I'll explain in a moment) aren't to blame, nor can they pull valid data out of thin air.

[quote]As you recall...I ran the Repair operation against the archive after the verify failed...[/quote]
That's absolutely the correct thing to do.

[quote]I ran it using only the first default option..."Use auto-repair information"...you further stated...from examining the log files that I attached...that the Repair was successful. However, after the Repair operation completed...I opened the archive...and saw 3 of the 4 layers now showing "Damaged Files"...which turned-out to be the large virtual machine package...(the most important reason for running the backup in the first place, by the way).[/quote]
This is also correct. The archive is now "repaired" in that it is valid and internally consistent. However, data was damaged. Lost data can't be magically reinvented. QRecall examined the records and concluded that the data block beloning to two versions of your VM file were lost. So the two file records that contained the damaged data blocks were expunged from the archive, and the folders that contained those files was marked as "-Damaged-" indicating where the data loss occurred.

[quote]Thus it appeared to me that the VM package in layer 2 and 1...taken 3 and 4 weeks ago respectively...had been compromised...and thus my assumption that previously verified backup layers had now been corrupted.[/quote]
That's correct. The data you captured a few weeks ago became damaged at some point. The verify alerted you to the issue, and the repair recovered the files and folders that weren't damaged.

Looking at the log, only a single data record was corrupted in your archive. Most likely, this impacted a single data block belonging to different versions of the file in the two earliest layers. That data didn't belong to later versions of the file, so the subsequent layers were unscathed.

[quote]Should I have run the Repair with different/additional options selected?[/quote]
Not really, unless you're desperate.

The repair options are:

[list]Copy recovered content to new archive: Use this only if you do not want to touch the damaged archive in any way. It's useful for testing repair settings (since it doesn't change the original archive) or repairing an archive on read-only media.[/list]
[list]Recover lost files: If directory records in the archive are destroyed, it may leave "orphaned" file records. That is, file records that aren't contained in any folder. This option scrapes the archive and assembles all orphaned files together in a group of special "recovered" folders. Note that this may resurrect files previously deleted by a merge action.[/list]
[list]Recover incomplete files: If a data block belonging to a file is lost, the file is deleted. With this option turned on, the file is kept, marked as "damaged" and all of the remaining (valid) data block are assembled into a file. The file is still incomplete—the lost data is still lost—but the remaining data is recovered. The file probably isn't usable, but might contain usable data.[/list]
This last option is probably the one you're most interested in, but it still can't recover the entire file. It can only recover the portion of the file data that wasn't lost.

[quote]Would this have preserved my 1st and 2nd layers?[/quote]
No. Lost data is still lost data. You can't get it back once it's gone. Using the last option, you can get everything else in the file that wasn't damaged back, but that's usually of limited value.
]]> https://forums.qrecall.com/posts/preList/252/1228.page https://forums.qrecall.com/posts/preList/252/1228.page GMT
So...just to summarize...(I promise :lol: )...previously verified layers in the archive were indeed corrupted...but [b]not[/b] via the last Capture operation...through some other, as of yet, unrecognized "event"...that is my final "takeaway" from your comments...correct?

If so..this makes me feel completely confident in your product once again going forward...expect several $40 licenses fees from my clients in the near future...you deserve it...just for listening to me... :lol:

Thanks again...

GKG]]> https://forums.qrecall.com/posts/preList/252/1229.page https://forums.qrecall.com/posts/preList/252/1229.page GMT Correct. And should have let you write the reply; that was so much more succinct. ;)

[quote]If so..this makes me feel completely confident in your product once again going forward...expect several $40 licenses fees from my clients in the near future...[/quote]
Always good news.]]> https://forums.qrecall.com/posts/preList/252/1230.page https://forums.qrecall.com/posts/preList/252/1230.page GMT
I am getting a QRecall application crash in beta versions 1.2v6 and now in the just released 1.2v8. It occurs when the Re-Index operation is performed.

I have attached the crash log. Here is what I see.

If you select the File ==> ReIndex option....the Open File dialogue is displayed...you then select an archive...click on Open...and the form disappears completely...and nothing appears....if you then walk through the same steps again...this time, the archive browser does appear and the Re-index operation continues...but you then receive the crash when you close the archive browser after the re-index completes.

The re-index does seem to work...just the UI appears to crash afterwards.

Thanks...

GKG]]> https://forums.qrecall.com/posts/preList/252/1233.page https://forums.qrecall.com/posts/preList/252/1233.page GMT Thanks, Gary.

This is a known bug. It occurs with the Repair command too. And sometimes the first time you choose either of these commands nothing happens, but the second time it works. There's also a related bug that can cause the QRecall application to crash when closing an archive window.

These are caused by a change in OS X that happened around version 10.6.2 which changed the order of events that occur when opening and closing a window. While arguably an improvement, it trips QRecall up.

I've been ignoring this issue because the QReacall user interface is being largely rewritten as I write this. The new code should replace the buggy code and (hopefully) won't have any of the same problems.]]> https://forums.qrecall.com/posts/preList/252/1234.page https://forums.qrecall.com/posts/preList/252/1234.page GMT
Thanks...

GKG]]> https://forums.qrecall.com/posts/preList/252/1235.page https://forums.qrecall.com/posts/preList/252/1235.page GMT
Thanks
Chris]]> https://forums.qrecall.com/posts/preList/252/1529.page https://forums.qrecall.com/posts/preList/252/1529.page GMT What would you like a QRecall menu extra would do?]]> https://forums.qrecall.com/posts/preList/252/1530.page https://forums.qrecall.com/posts/preList/252/1530.page GMT https://forums.qrecall.com/posts/preList/252/1531.page https://forums.qrecall.com/posts/preList/252/1531.page GMT
Just a smaller activity display than the monitor window? A way of starting and stopping actions, suspending the schedule, that sort of thing?]]> https://forums.qrecall.com/posts/preList/252/1532.page https://forums.qrecall.com/posts/preList/252/1532.page GMT Chris]]> https://forums.qrecall.com/posts/preList/252/1533.page https://forums.qrecall.com/posts/preList/252/1533.page GMT https://forums.qrecall.com/posts/preList/252/1534.page https://forums.qrecall.com/posts/preList/252/1534.page GMT