QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Gary K. Griffey
Forum Index » Profile for Gary K. Griffey » Messages posted by Gary K. Griffey
Author Message
James,

I am getting this error on one of my archives. The archive verifies OK...but when I try to Compress it...I get the error.

"cannot open negative hash map"
"A network or disk error was encountered"

I checked the disk with disk utility and it shows clean...

Thanks,

GKG
Understood thanks...

I will continue testing...just to clarify...I am no longer restarting the laptop and using target disk mode for Capture per your advice...I am executing QRecall right from the laptop itself...so...I am hoping the file system events work as expected.

Thanks,

GKG
Ok...this only seems to work for file changes made before a system restart.

So...if you run the virtual machine....shut it down...then reboot your mac...then, run a QRecall Capture...it misses the virtual machine...until the virtual machine is started and stopped again...

So...it would appear that file system changes, at least for certain files, are not "surviving" through a system restart...that sure seems odd to me...

James,

An interesting observation was noted this morning...I would like to solicit your comments.

After running the virtual machine on my laptop for an hour or so...I shut it down...then attempted to perform a QRecall incremental capture. As I have seen many times before...the virtual machine package file was not included in the capture...even though its Date Modified was well after the previous capture.

Normally, I simply modify the QRAuditFileSystemHistoryDays setting to force the virtual machine to be included...this morning, however, I decided to enable the QRLogCaptureDecisions switch instead. This appears to have solved the issue...in other words...unlike setting the QRAuditFileSystemHistoryDays to say, 0.0...which forces the "deep traversal"...simply enabling QRLogCaptureDecisions correctly included the virtual machine package in the capture...but did not perform the "deep traversal".



Any thoughts as to why?

Gary
James,

Thanks for all the info and direction. Here is what my simple test plan will include:

Prior to executing a normal incremental Capture of the laptop which will always include the large VM image:

1) Run verify on existing archive.
2) Run Disk Utility on the target disk drive...just to make sure everything is normal.
3) Create Archive dump using the options that you have detailed.

Then...

4) Execute incremental Capture process with a QRAuditFileSystemHistoryDays set to a somewhat reduced value.
5) Execute Verify action on newly created archive.
6) If Verify action fails...create another archive dump.

I will also make every effort to keep other variables to a minimum...like using the exact same target drive...namely an internal SATA drive on my Mac Pro...and keeping the connection method the same...a FireWire cable.

I will let you know my results after I have performed a few Captures..

Thanks, again...

Gary
James,

I have basically ruled-out your supposition of a bad target disk drive/controller...as I have attempted this exact backup scenario to 4 different disk drives...both internal and external...using 3 different computers. Each of the 4 tests began with a new QRecall archive....the initial backup always Verified OK...but a subsequent incremental always fails...usually the third or forth...but this varies. I always Verify the archive prior to running the next incremental.

One experiment I tried this morning...I deleted the 6th "damaged" layer in the archive that was created yesterday...compacted and verified the now 5 layer archive....and it verified successfully. Then, I re-ran the exact same incremental capture again...but this time I used the advanced setting "defaults write com.qrecall.client QRAuditFileSystemHistoryDays -float 0.0"...and this time the 6th layer was not only captured but also verified successfully. This is by no means proof...I realize...as the issue is intermittent...but I have "bumped my head" on this setting before using QRecall...and I am wondering if it is somehow playing a role here.

Certainly, during a capture...you display the virtual machine package file in the status window...this appeared in both captures....the first bad one and the second good one...but there is no display of the individual package components that are being captured...my assumption was that if a package was flagged for capture...then all components were captured...is it possible that a component of the package was not captured in my first incremental yesterday but was captured in the second incremental because if the "QRAuditFileSystemHistoryDays" setting? And could this omission be causing the bad data?

Thanks,

Gary
Greetings James,

Possibly, you could provide me with some troubleshooting guidance. I am continuing to have issues successfully capturing a virtual machine disk file with QRecall beta 1.2v8.

The capture is being performed on a macBook Pro...the laptop is always freshly rebooted just prior to running the captures...thus, the virtual machine is not running...in fact, nothing is running except the capture...the capture is targeting the entire laptop's system volume...which includes this 32 GB virtual machine disk.

The initial capture seems to run fine...however, on subsequent captures...usually the 4th or 5th incremental...an error inevitably pops-up...the error is always identified by a Verify operation...the capture completes normally...and the subsequent Repair operation always identifies the exact same file as being Damaged...namely the VMWare Fusion virtual disk file (.VMDK).

I know that you mentioned in our prior discussion that "stuff happens" and that files do get corrupted. These errors, however, only seem to happen on this particular capture process...and it is always the virtual machine disk file that is damaged...which seems a bit odd to me.

Is there any troubleshooting options that I have? To be honest...the main reason I run QRecall on this laptop is to efficiently backup this virtual machine image on a weekly basis...so...I am really looking to try and resolve this issue. Could this be some type of capacity / threshold being reached by the 4th or 5th incremental? I know you said that archives up to 6 TB could be created with beta 1.2v8...this archive is only around 43 GB...the funny thing is...the capture always appears to finish just fine...but the Verify catches the error. I would think that if the disk drive in the laptop was getting "flakey" the capture might flag read errors, etc. I have experienced the errors writing with the target archive on a Firewire drive and the same errors with the archive on an AFP network share...so I doubt the target media is to blame.

Any help would be appreciated.

Thanks,

GKG

Understood...

Thanks...

GKG
James,

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
James...thanks so much for your time...I know this thread got ridiculously long...I just think the technology/methodology that you have built into your product is really superior...and my only goal is to continue using QRecall as a valuable tool in my backup "arsenal"...

So...just to summarize...(I promise )...previously verified layers in the archive were indeed corrupted...but not 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...

Thanks again...

GKG
James,

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
Ok...I will investigate the log message content further and see if this multiple indexing is actually taking place.

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

James,

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...
Greetings James,

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.
James,

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


 
Forum Index » Profile for Gary K. Griffey » Messages posted by Gary K. Griffey
Go to:   
Powered by JForum 2.1.8 © JForum Team