Verify failed after 7 minutes. I've sent another report and have started a repair action.

Edit: After just a couple of minutes the repair action quit with an error message that it had lost contact with process, no entry in the log. I've restarted the repair and it looks like it's running normally.

I should have mentioned that I've sent a report. I'll move the archive to the MBP (USB3( and start the verify now.

This problem is still with us, apparently. I ran a scheduled backup of my MBP over wifi to a backup drive attached to my iMac last night, and the log shows this morning that the archive failed with a "problem closing file," as it did on 11/16. The archive shows what looks like a complete layer from last night's backup, though, so apparently it was written before the problem occurred. I tried this morning to rerun the backup manually, and it failed again

Action 2015-12-06 09:23:24 Failure Program exception
Action 2015-12-06 09:23:24 invalid position added to bucket
Action 2015-12-06 09:23:24 Failure Command failed
Action 2015-12-06 09:23:24 An internal program error occurred. Please report this problem to the developer.

Since we dealt with this problem in November I've been running this backup manually during the day with no problems. This was the first time I've run it as a scheduled backup overnight. This is not the drive that had the problem earlier but the one that had been offsite, and I just swapped back in on Friday. The problem occurred on the third backup run after the swap.

I guess I'll have to run another repair on this archive, but I'll wait to hear from you before I start it.

As I read this,another difference between these two encryption methods occurs to me. With qrecall doing the encryption, the archive volume wouldn't need to be mounted on a Mac that could decrypt it -- specifically, the archive volume could be mounted on an Airport Extreme.

When I started using Qrecall I used a single unencrypted archive drive mounted on the Airport Extreme that served my LAN, to back up both my iMac and MBP. When I decided to add a second drive and keep one offsite I encrypted both drives (using FileVault). I found that the Airport Extreme could no longer mount these drives because it couldn't decrypt them, so I had to keep the active backup mounted on the iMac. I don't know if similar considerations would apply to other forms of NAS or not.

So I'm also wondering about switching over to Qrecall encryption. On the plus side I could shut down the iMac at night, or when it isn't used for several days. On the negative, it would probably take several days to decrypt and reencrypt each 1TB+ archive. Neither choice looks clearly dominant to me right now.

I was referring the period of time at the end of a backup when the Monitor is reporting "archive closing -- the interval between the log entries for "Captured xxx items. . ." and "Capture finished." Going back and look at a series of log entries, it's pretty clear that it is related to error correction, as the following entries show. Error correction was installed on the 17th and 18th, then removed on the 21st and the time interval drops significantly. Then it goes back up after I inflated the archive again on the 21st (except for the backup on the 22nd, which was exceptionally short overall).

Action 2015-11-17 11:08:33 Captured 2591 items, 2.26 GB (8% duplicate)
Action 2015-11-17 11:09:30 ------- Capture finished (20:42)

Action 2015-11-18 12:27:25 Captured 7949 items, 1.5 GB (19% duplicate)
Action 2015-11-18 12:45:45 ------- Capture finished (34:03)

21-Nov-15 ? removed error correction

Action 2015-11-22 08:44:15 Captured 12494 items, 1.72 GB (29% duplicate)
Action 2015-11-22 08:44:24 ------- Capture finished (1:24:21)

Action 2015-11-22 13:31:27 ------- Inflate 2nd backup.quanta

Action 2015-11-22 17:00:44 Captured 720 items, 547.4 MB (56% duplicate)
Action 2015-11-22 17:00:49 ------- Capture finished (01:50)

Action 2015-11-23 10:39:31 Captured 912 items, 480.9 MB (83% duplicate)
Action 2015-11-23 10:45:13 ------- Capture finished (10:16)

Action 2015-11-24 07:55:11 Captured 1797 items, 876.2 MB (46% duplicate)
Action 2015-11-24 08:04:39 ------- Capture finished (19:57)

This is not a problem you need to do anything about, just an observation -- something I might not have even noticed normally, except for the fact that I was troubleshooting during this period so paying closer attention to what was happening, and that make a ten minute interval seem long when I'm watching for it to get over.

Yes, the b23 version seems to take care of the Monitor problem, so all is fine again. I do notice that closing the archive seems to be taking longer, whichh I assume is related the error correction?

I ran another backup using v2.0.0a22 alpha to see what would happen with the Monitor. When I started the backup the window flashed briefly showing the backup starting, then shifted immediately to "Idle" and stayed there. The only indication of the running backup was the "Archive busy" window when I tried to open the archive. I came back later and and a crash window was showing, indicating that Qrecall had quit, but the app was still running and the log indicates that the backup completed normally. I filled in that crash report window and also sent another report from the app, so you should have both.

Both of these last two backups were run with the drive mounted on the MBP. Next I'm going to more the drive to the iMac and run backups of both machines that way. The iMac is running the previous beta version.

I've now repaired my archive and it completed successfully, though the log still shows Data Problems -- Invalid data at the same two locations that have been showing up. Is this now a permanent feature of this archive?

After the repair completed I ran a Merge Layers action followed by a backup, which seems to have run fine with one minor glitch. I clicked on the backup while the Merge was in process, figuring it would run after the Merge completed, which it did. But the Monitor window only showed the running Merge and did not show the waiting backup, as it has done in the past. When I came back to the computer after the backup had started, the Monitor window showed "Idle" and the only indication I could find that the the backup was actually running was the "Archive busy" window that came up when I tried to open the archive.

I've now repaired my archive with Qrecall v2.0.0a22 alpha and sent you that report, removed the repository companion files, and started the archive repair again to get the archive back. I'll let you know in the morning how it works out.

The repair that I just did had one probably insignificant glitch you should know about. I shut the lid about 1/3 of the way through, then opened it again about an hour later and it seemed to pick up OK. I'm in the habit of shutting the lid when I'm done working, and it's hard to remember not to do that when a long process I haven't been paying any attention to is running in the background.

I use power management on the iMac for a scheduled 1am backup and it works fine. I somehow never thought of that on the MBP. One question that occurs to me there, though, is that backing up the MBP involves 2 computers, not one. I'm running the backup from the MBP, but the drive is mounted to the iMac. Does that cause any problems? Also, if I command the MBP backup to wake the computer before the backup but not to sleep it after the backup will it then go to sleep according to the Energy Saver inactivity settings? I ask that because I'm hesitant to tell Qrecall to sleep the computer when I might sometimes run that backup command during the day when I'm working on other things. I'll probably keep running the MBP backups as I've been doing, but it will be nice to have a clearer understanding of my options.

Thanks again for the stellar support you provide.

Thanks for the quick response and explanation. It all makes sense. I think I had power nap turned off in Yosemite and previously, but I guess El Cap turned it on as a default. I've traced a couple of other problems to El Cap's changing default settings, I think.

If the fix is coming along quickly, I'll wait, but if stripping the error codes is relatively simple and it would be fit your schedule better not to be diverted to that fix right now, please send me the instructions for stripping them,

I ran the drive through Disk Utility, Diskwarrior, and TechTool Pro (full surface scan) and everything looked fine. I realize this doesn't totally clear the disk, but looking more carefully at when it happens suggests that the problem a byproduct of a scheduled backup trying to run when both computers involved are normally asleep.

I normally leave my backup drive connected to an iMac (USB2) and backup my MBP over wifi, though I do sometimes move the backup drive to the MBP for time-intensive operations like verify and repair, to take advantage of the greater speed provided by USB3. I have a scheduled backup on the MBP for 3am, and the MBP is usually asleep with the lid closed at that time. Until I upgraded to El Cap that backup usually didn't run and I would just start a manual backup when I turned the computer on in the morning. More recently, though, that scheduled backup is trying to run, and that's when my "problem closing archive" occurs. See the backup failures at 2015-11-16 03:04:33 and 2015-11-19 03:37:19.

In both cases, the backup seem to run for a while, but not actually complete, and then fail about 4 hours later. Backups run manually during the day seem to complete properly. After running the above utilities to check the drive I was able to successfully back up the MBP at both 2015-11-17 10:48:14 and 2015-11-18 12:10:41 and to backup the iMac at 11/17 19:04 (not shown on the report because that backup was run from the iMac).

Since yesterday?s failure I don?t seem to be able to repair the archive. Two consecutive Repair cycles both show ?Invalid data? at the same locations, and the archive will not open because the index is incorrect. Is this archive totally lost, or is there a way of getting rid of the invalid data and repairing the rest of the archive? When I get it up and running again I?ll delete the 3am backup for the MBP and just run daily backups manually, and with luck that will take care of the problem.

BTW, the missing filter references that show up in each backup log are due to excluded files on the other machine.

I've thought from time to time that it would sometimes be convenient to be able to attach notes to layers, to keep track of significant events attached to the layer -- major system upgrades, perhaps, or a significant reshuffling of my filling system. I'm feeling stupid now for not suggesting this much earlier in the v2.0 development cycle, but I guess it's been out of mind until now, and just popped back up so I decided to mention it.

My scheduled backup last night looks from the log like it completed the backup then quit with a "problem closing archive." When I tried to rerun it, the archive needed repair. After the repair the archive includes last night's layer, showing the same number of files and size the log for last night showed, so apparently the backup had completed and then something screwed up as it was closing. The repair log showed two locations of invalid data.

When I woke the computer up this morning it showed an alert that "logout had failed because some app refused to quit. I don't remember if it was qrecall or not. I've been having these logout failures at night sometimes since updating to El Cap, and discovered to that was because the update apparently turned on an option to log out after an hour of inactivity, which had not been previously set. I don't know if that caused any problem with qrecall, or not.

I'm sending a report.

I'm seeing log entries for both recaptured files and capture issues attributed to "file length changed during capture" for various log files. Is this normal? Should I just exclude these logs from the capture?

I also see that my qrecall logs for September and October are both under 2MB, while the November log is already over 2.6GB. Has the amount of stuff being logged shot way up for some reason, should it be set back to a lessor level?

I'll send a report

The exclusions will work fine, I think, now that I understand the way it works. It was just a shock to see them looking like they were pointing at the wrong disk, and not understanding why.

I'm still having trouble deleting items from the archive to clean it out. I first thought it might be because I didn't have enough headroom, but I took a second archive off the drive and now have 400+gb free space and still get "waiting for archive" when I attempt to delete an item. I'm thinking about start a repair as my next step. Is there anything simpler I should check first?