Message |
|
James, I can now confirm...it is the system restart which causes the event to be dropped. If you start/stop the VM...and then run the Capture without a system restart...it captures the VM as expected every time. If you do perform the restart...even waiting 3 or 4 minutes after closing down the VM...the VM is not captured. So it seems there is no event persistence through a system restart...I will try your Terminal commands and see if that makes a difference. Gary
|
|
|
Whoops I forgot... The VM Directory is: USERS/Gary/Documents/Virtual Machines GKG
|
|
|
James, Ok...will do... I will retry the VM start/stop, then recapture without the system restart...but I know that this worked before...so, I believe that the issue is related to persisting the events through a restart...but I will retest just to make sure... I will also give the Terminal commands a shot and let you know... Thanks, Gary
|
|
|
James, I have just repeated the same steps on another macBook Pro laptop that I have...using a VM, etc...same exact result....i.e., on the second Capture...after the VM Startup/Shutdown and the system shutdown/restart...the virtual machine directory is not flagged as being updated even though Finder clearly indicates that it has been updated. So...QRecall bypasses the VM... So...I do not believe that this is an issue on a specific laptop...like the hidden FSEevents file is corrupted, etc...this seems to be easy to recreate on any system... Very scary...for QRecall, Time Machine,etc... I just don't see how Finder could "know" about the directory update but evidently not FSEventsd...could the VMWare Fusion application somehow be suppressing this from FSEventsd? Sounds odd... Gary
|
|
|
James, Ok...followed your list and here is what happened: 1) Capture performed at 06:04...virtual machine was captured as expected. 2) Opened VM...closed VM...to update VM disk file, etc. 3) Shutdown/Restarted laptop 3) Ran second capture at 06:15...this attempt did NOT capture VM...even though the VM package directory has an update time of 06:13... 4) Your new logging clearly indicates that the ~/Documents/Virtual Machine directory was not flagged as updated for the second capture attempt..and, therefore, QRecall did not back it up. I also sent the report as well. So...it appears that OSX and FSEvenetsd are at fault here...your thoughts? Also, any suggestions or thoughts as to why FSEventsd is not working? It seems that if this was a common issue there would be a lot of "long faces" out there come restore time. Thanks again for the special version. GKG
|
|
|
Thanks James... I will install it and follow the steps you have outlined... Thanks... GKG
|
|
|
Understood... I will not make any changes or delete the fseventsd hidden file... Thanks...
|
|
|
James, Thanks for the update...I wonder what the time delay is between fseventsd receiving an event and actually performing the write to the hidden file... I can also certainly try your suggestion of simply deleting the fseventsd hidden file on the laptop's volume and allowing it to be re-created from scratch...I don't think that would hurt anything... If you do have time to work-up a special version that would log exactly what QRecall "sees" in that hidden file it would be great...I would just love to get to the bottom of this... Thanks again... GKG
|
|
|
James, I am using the FSEventer utility program that you mentioned...and certainly seeing the entire virtual machine package and the VM disk file get a "Content Modified" event fired...whenever the VM is started or shutdown...and, therefore, I would think that it would always be included in an incremental backup if it was started/stopped after the previous backup....so, I am still not sure what is happening. One other question...if I open a Finder "Smart Folder" window...and mask on "Last Modified Date"...the VM package folders are correctly flagged as being updated...now I realize that a Smart Folder uses Spotlight...but isn't Spotlight "fed" by the same FSEvent daemon as QRecall? And, therefore, shouldn't the results be the same, i.e., if it shows up in a Smart Folder "Last Modified" mask shouldn't it be captured with QRecall? Thanks, GKG
|
|
|
Ok...I will give it a try....
|
|
|
James, Just a quick update...I see no errors for FSEvents daemon on the laptop... One interesting observation...the VM has been running on the laptop since about 07:20 this morning (about 4 hours)...and...although the VM package file (aka...folder) has a Date Modified of 09/09/2010 07:21....inside the package...the virtual machine's disk file (.VMDK) has a date modified of the current time...which is what you would expect...as the disk is being updated constantly... I just wonder if QRecall is actually looking "inside" the VM package when it does its timestamp compare on an incremental..because it would seem that if it simply used the package's timestamp....it would bypass backing it up... GKG
|
|
|
James, Thanks for your thoughts... Just for clarification...I am using VMWare Fusion...and not Bootcamp...so I would certainly think that FSEvents should catching changes to the VM package file... I will look at the system logs and see if I see any errors...and also take a look at FSEventer... Thanks again... Gary
|
|
|
James, After some further testing...I am still experiencing issues capturing my virtual machine package file. I don't believe the issue is with QRecall itself...but, rather the file system events. Here is my very simple process that evidently will not work. 1) QRecall incremental backup taken of laptop drive yesterday AM...the backup include the large VM package file as it should have...the backup was executed from the laptop itself to a target network share on my mac Pro desktop. No issues. 2) I used the virtual machine all day yesterday and this morning. 3) I shutdown the VM...and rebooted the laptop. 4) I repeated the exact same QRecall action....i.e., running the incremental backup from the laptop to the same network share...a small number of files were re-captured...but not the VM...which again, is my main goal. The laptop is running with no special QRAuditFileSystemHistoryDays value...so it is using the 6.9 default. So...it would appear that the 10.6 File System events did not advise QRecall to backup the Vm package..even though it most certainly had been updated. From your previous notes...I do not see any reason the file system events on the laptop's drive should have been deleted or otherwise compromised. What am I doing wrong? You mentioned that these file system events are located in a hidden file on the drive itself...obviously, you are using an API or equivalent to read these values...it there any way that I could actually peer into this hidden file to see if the VM package file is being flagged as changed? I just wonder what other user/system related files are being skipped in my incremental backups...makes you question the value of any backup system using these events..like Time Machine, etc. Thanks, GKG
|
|
|
Ok...I have deleted the negative index file...and the Compact is now running... Thanks, GKG
|
|
|
|
|
|