My backup drive is normally attached to my wife's iMac, and my MBP gets backed up to that drive over the network. As you know, I've had occasional problems with scheduled MBP backups not completing properly, then completing fine when I rerun the backup. I attribute this to network flakiness and it's not a big problem.

This week, though, I'm having more consistent problems. I've had several backup failures on both machines, have repaired the archive three time, and am being told that it needs to be reindexed again. The problems appear primarily associated with the MBP, but after two apparently successful iMac backups the Status window showed backup problems eve though the log showed nothing. At one point yesterday all my layers after Nov 2013 disappeared, but repairing the archive brought them back.

I'm sending reports from both computers. If you need a more detailed description of my experience let me know.

Ralph

Ralph,

I don?t have much in the way of an explanation for why your layers disappeared on you, other than to suggest that you make sure you?re viewing the current owner and volume. If you have the Hide Unrelated Layers view option selected, and you inadvertently select an older owner or volume in the archive, QRecall will ?conveniently? hide all of the layers since that volume was last captured.

Reviewing the logs for your iMac, you?re consistently getting capture failures, but they?re rather minor. In fact, going back almost a month, the only consist problem you?ve encountered is capturing the tmSync.plist file in your iPhoto database folder. It would appear that some process is constantly replacing this file. When QRecall goes to capture it, it reads the directory, but by the time it gets around to reading the file, it?s been deleted and replaced. QRecall logs this and continues. It doesn?t, however, have any impact on the integrity of the archive.

(If you find this annoying, I might suggest that you add the tmSync.plist file to either the capture's ?exclude? or ?ignore changes? list.)

The MacBook Pro is another story. As you mentioned, it consistently fails (about once or twice a week) with I/O errors while reading or writing to the archive over the network. I/O errors are a deal breaker and terminate the capture, leaving the archive in a state that requires repair. Typically, the auto-repair is sufficient to get it back in service. But you also occasionally experience permission errors. I can?t tell if this is a file server issue, a virus scanner, or genuine permission problem. Permission or other access failures can leave the archive is a state that requires a full-blown repair or reindex to get things back into shape.

Which brings us to the repair actions. On the few occasions that you?ve perform a repair, the repair logged nothing out of the ordinary. This implies that the I/O and permission errors you?re encountering on the MBP are due to transient network transmission errors and are not a result of any damaged data in the archive or issues with the physical media.

If you?re ever concerned that your archive might have been compromised, run the Verify command/action.

One thing I will mention: I see that a Repair action was run from the MPB to an archive that (I assume) was accessed over the network. This is asking for trouble. If your network connection is causing spurious I/O errors, the Repair command will interpret that as damaged data and will delete that data from the archive. So if the I/O error was caused by the network, this will result in perfectly good archive data being erased?probably not what you want. If you must repair an archive remotely, start with the ?Reindex only? option. A reindex does not overwrite or attempt to repair the primary archive data file, so it won?t do any damage if the network causes problems.

James Bucanek wrote:
I don?t have much in the way of an explanation for why your layers disappeared on you, other than to suggest that you make sure you?re viewing the current owner and volume. If you have the Hide Unrelated Layers view option selected, and you inadvertently select an older owner or volume in the archive, QRecall will ?conveniently? hide all of the layers since that volume was last captured.

That probably was the cause of my disappearing archive. The archive I was left with was from my previous MBP, which I retired in December. I had never noticed that hide command but must have triggered it inadvertently. I'm feeling a little stupid right now for panicking when the archive seemed to disappear, instead of investigating it a bit more carefully.

Reviewing the logs for your iMac, you?re consistently getting capture failures, but they?re rather minor. In fact, going back almost a month, the only consist problem you?ve encountered is capturing the tmSync.plist file in your iPhoto database folder. It would appear that some process is constantly replacing this file. When QRecall goes to capture it, it reads the directory, but by the time it gets around to reading the file, it?s been deleted and replaced. QRecall logs this and continues. It doesn?t, however, have any impact on the integrity of the archive.

(If you find this annoying, I might suggest that you add the tmSync.plist file to either the capture's ?exclude? or ?ignore changes? list.)

I haven't noticed problems with the iMac backups, except for the occasional problem notice in the status window when nothing showed up in the log. The iPhoto Library is a package rather than a folder, and there doesn't seem to be any way to drill into it to exclude the plist file, so I guess I'll just leave that as is.

The MacBook Pro is another story. As you mentioned, it consistently fails (about once or twice a week) with I/O errors while reading or writing to the archive over the network. I/O errors are a deal breaker and terminate the capture, leaving the archive in a state that requires repair. Typically, the auto-repair is sufficient to get it back in service. But you also occasionally experience permission errors. I can?t tell if this is a file server issue, a virus scanner, or genuine permission problem. Permission or other access failures can leave the archive is a state that requires a full-blown repair or reindex to get things back into shape.

Which brings us to the repair actions. On the few occasions that you?ve perform a repair, the repair logged nothing out of the ordinary. This implies that the I/O and permission errors you?re encountering on the MBP are due to transient network transmission errors and are not a result of any damaged data in the archive or issues with the physical media.

If you?re ever concerned that your archive might have been compromised, run the Verify command/action.

The problems MBP have been minor but manageable, and usually resolvable by simply rerunning the backup. The failures in the last couple of weeks have required reindexing, which is new. I've been repairing rather than just reindexing because of past experiences when that was required, but it sounds like reindexing would have taken care of it in these cases. I generally Merge layers and Verify the archive every couple of weeks, when I swap in my off-site backup drive.

One thing I will mention: I see that a Repair action was run from the MPB to an archive that (I assume) was accessed over the network. This is asking for trouble.

Both my MBP and that backup drive have USB 3 while the iMac is USB 2, so I sometimes physically mount that drive to the MBP for long operations like a repair, to take advantage of the higher speed.

Thanks again for the prompt and useful support, which you always provide.

Ralph

Ralph Strauch wrote:The iPhoto Library is a package rather than a folder, and there doesn't seem to be any way to drill into it to exclude the plist file, so I guess I'll just leave that as is.

When adding any item to a list in QRecall (capture items, exclude items, ignore items, and so on), there are two ways of adding hidden items:

When clicking the + button to add an item, holding down the Option key will let you pick invisible items and holding down the Shift key will let you pick items inside packages.

Select the package in the Finder and use the contextual menu command Show Package Contents. Locate the item inside the package and drag it into the item list.

Otherwise, it sounds like you have things well in hand.

OK, thanks. I tried the control key inside the Qrecall list and didn't think about the other possibilities. I'll exclude the plist.