For two straight weeks my system partition archive needed repair when verified. In both times disk verification showed no error and the repair was successful, but 6 out of the last 7 daily layers are now "incomplete", while 4 from the previous week were incomplete. (Note that I removed those incomplete layers and compacted the archive after the first repair.)

As can be seen from the screenshot below, the repair log indicates there are 4 "unreachable" folders under my system partition "carlosys", including one under my user profile directory tree. The 4 folder serial numbers are the same for each day. Unfortunately I can't tell which folders they are referring to so I can't investigate further.

I'm still on Yosemite (10.10.5), if that matters.

edit: forgot to say, a diag report was sent.

Did a manual capture just now, followed by verification, and sure enough, the verification failed again for the same reason. It's repairing. I'll send another diag. report when it's done.

I have seen this with another archive.

Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

James Bucanek wrote:Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.

Something just came to mind, though I don't know if it bears any significance to the issue.

I have a SSD partition dedicated for my documents, which is mounted at boot as the "Documents" folder under my user profile. As a result, while sys.quanta (the archive at issue) is set up to capture only the system (root) partition, it doesn't backup the contents of the ~/Documents folder, which is backed up separately.

Sys.quanta, however, does show two "volumes" when opened in QRecall: "carlosys" (the name of my system partition) and "Documents", as shown in the attached screenshot below. Note that the size for the "Documents" volume is zero. It really is an empty volume.

Ming-Li Wang wrote:The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.

This seems to be the problem. I've identified several issues with archives that were originally created with 1.2 and later updated to 2.0.

I'm still investigating, but this problem seems to be related to how volumes are identified in 2.0 vs. 1.x. This disagreement causes newly captured items to migrate into a new directory hierarchy that, in turn, trips a number of internal consistency checks. In your case, a delta directory record (a database record that records changes in a previously captured folder) can only refer to a another directory record that is both (a) in an earlier layer and (b) at the exact same location in the volume/folder hierarchy. The shifting volume identifiers cause the second test to fail, making the inherited directory record "unreachable."

The verify may also report "layer catalog tree" errors, which basically means the folder structure in the index and the folder structure the verify thinks the archive should have aren't identical.

The verification failed again today with "layer catalog tree" error as you mentioned. It's fine now after reindexing with the newest layer (created last night) intact. I'm going to seal the archive and start a new one for the time being. The old archive would be kept for a while so it would be available for testing if you find a solution.

I keep old system archives to satisfy my occasional curiosity when I want to see how something was done/set back then, and for the rare cases where I want to check an old plist or the like when investigating an issue. Nothing critical. To resuscitate the system, a recent archive suffices.

What worries me are my other archives, which hold my actual "data" and were all created by QR v.1.2.x. Weekly verifications have all checked out just fine so far, but do you advise starting anew with those as well?

My advice would be to wait until I fix this bug

I'm pretty confident that there's no data loss, just migration pains.

Strange! I sealed the old sys.quanta and created a new one, which had its first capture last night (at 3am this morning), and then immediately failed the verification less than 2 hours later. It's repairing; a diag report will be sent when done.

edit: the repair job checked the partition hosting the archive: no problem. I also verified my system partition with Disk Utility: no problem either.