This is very interesting, but no matter what I do I still see all layers. Am I missing something?

Thanks James, I can rest easier now.

Isn't it amazing that despite using QRecall for some time I have never noticed the tool tips. Old age is definitely setting in

It's just a warning I think - a little blue exclamation mark rather than a slightly more scary triangular yellow exclamation mark.

I didn't think it was a serious issue but I thought it was worth just running it past you.

Hi James

I have a small issue I can't seem to resolve. Every time I verify one of my archives I get the error "negative hash map does not agree with contrusted map". I follow the instructions and reindex the archive but the error persists upon re-verify. I have also tried repairing the archive.

Any ideas on why this is happening so much and what to do about it.

Thanks
Adrian

James

Thanks again, I now see the flaw in my methodology. Why are these things so damned obvious in hindsight

James

Thanks for yet another in depth explanation of what is going on. I suppose my first question is do I have anything to worry about in terms of my schedules and exclusions? The only thing I ignore changes in is my Virtual machines folder which I archive once per day as the last activity. As I don't use my VMs much would it be better to not bother ignoring them?

As you can probably see from the logs, my System is on it's own drive, in fact now an SSD, and the users are on a Softraid RAID 1 array. The system volume and Users directory are saved to separate archives, which I thought to be a good way of doing things, i.e. keeping archives specific to volumes.


Adrian

Diagnostic report sent.

Thanks.

QRecall is definitely not performing regular exhaustive scans, at best it is once per month and in May it didn't do it at all.

I have checked the defaults with the "defaults read" command in terminal and I get:

QRAuditFileSystemHistoryDays = "6.9";

I should add that I have had cause to perform repairs a few times so would this reset the count down for FileSystemHistoryDays?

Adrian

James

I have a feeling that QRecall isn't performing an exhaustive scan as often as it should. What am I looking for in the logs which will confirm it is doing this approximately once a week with the default setting of 6.9 days? Also is it possible to force an exhaustive scan?

Oops, I somehow missed that you had already reselected the archive. I really must do something about these darned spectacles.

Have you checked that the action is still pointing to the correct archive? I had an instance where for reasons unknown an action ended up pointing to some obscure file.

Adrian

James

Just a quick follow up. I have found no other data corruption in any files on my Drobo and I have started a new Users directory archive.

The only other thing that springs to mind is that I deleted a lot of content from the archive that subsequently became corrupted which resulted in my weekly verify/merge/compact actions started a big compact. Because this was taking so long I set it to run each night and stop at 0800. The corruption issue started after I embarked on this series of actions.

I'm not suggesting that QRecall is at fault per ce, but I wonder if there is a connection somewhere.

Adrian

It seems this is not applicable to the Drobo-FS, James. The Drobo-FS only has an ethernet port and it is supposed to do its own file system check upon booting.

I did a firmware update on it recently and I am beginning to wonder if that is the root of the problem.

I am currently running a QRecall verify on my other archives to make sure they are OK. So far I haven't discovered any other file corruption.

Well, that certainly explains the problem. Unfortunately the Drobo-FS has its own internal file system and from what little I know, the method of checking can be destructive of data! Great!

Sometimes I think these systems are too damned clever for their own good.

Thanks anyway James

James

I capture my Users directory to an archive hosted on a Drobo-FS and this has performed well for some time. I also capture my System volume and other Macs to their own archives on the Drobo.

My Users archive has recently suffered some serious, and it would seem unrepairable problems, such that I now have an archive with 157 layers of which 89 are showing as damaged. For my most recent attempt at a repair I manually deleted all the index files in the archive and the repair ran through but reported a number of errors in the archive. I then ran my Users archive action which seems to have run without incident but the progress bar in the activity window is only about 40% of the way across when the archive is being closed and the closing process seems to take an inordinately long time. However, the capture seems to have completed without any other issues.

I am very reluctant to write off this archive but right now I don't see what else I can do. I have submitted a report.