Message |
|
James, Thanks for the clarification...I would have sworn that in previous versions, if a new archive is created...and the setting is changed to the highest compression before any capture is performed...that after that initial capture completes the Compact option was already disabled..but I guess I am wrong on that one. Thanks, again... GKG
|
|
|
James, I am running the latest beta... 1.2(029) and am observing an innocuous, yet odd anomaly. I created a new archive...changed its settings for maximum capture compression...however, after I perform the initial capture...the Compact option is available on the UI. Executing the Compact operation on this archive obviously yields no additional gains... I know that on previous betas...if you captured at maximum compression...the Compact option was not available. No big deal...I just thought you would like to know... Thanks, GKG
|
|
|
James, I re-ran the same restore using my 2nd favorite backup utility, , Super Duper....and the log clearly indicates that they do indeed fire-off the forced cache update command at the end of their restore routine...I have attached the excerpt from the SD log indicating this activity. Therefore, the restored system did not, obviously, exhibit the same errors after the SD restore completed...so...I guess incorporating this forced boot cache update in a QRecall restoration, as you referred to before, may be in order...if possible. Thanks, GKG
|
|
|
James, Today I performed a full System volume restore of OSX 10.6.6 using the most recent beta version of QRecall. The restore completed OK....however, after the restore was complete...several applications, like 1Password, begin to experience automatic backup failures with the following error: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache After researching the error a bit...it seems the following Terminal command will correct this issue: sudo update_dyld_shared_cache -force So...all seems well now...however, this error is something I have not seen before after a QRecall restore. I thought you may like to know... Thanks, GKG
|
|
|
James, Just a quick update on this issue. After comparing results of the current V19 beta vs. previous beta's..the performance appears to be roughly the same...i.e., much faster than the current 1.1.4 "gold" code....even on 10.6.5... Sorry for raising a red flag on this...all seems to be working well in V19... Thanks, GKG
|
|
|
James, Thanks for the response...I like your plan...I will let v19 run for a week or so on my machines as it did before...and then go back and compare with previous beta timings.. Thanks, GKG
|
|
|
James, I have installed the latest beta v19 release. I have not encountered any issues with this latest release..but I am seeing a definite capture performance degradation when compared to earlier betas. You mentioned that the v19 beta release had some debugging code removed...were there other changes as well? The performance I am seeing, at least thus far, seems to be about what I was seeing in the latest production release. When I started using the beta I observed huge capture performance gains...this appears to be reduced in V19. Thanks, GKG
|
|
|
|
|
|
Ok...thanks for the details on the Shift+Command+G within the capture dialog. One other clarification...is there any way that hidden files/folders can be viewed in an archive? When you open an archive...these folders/files are obviously not visible. Thanks, GKG
|
|
|
Greetings James, One of my recent full OSX drive backups failed verification and indicated that a repair of the archive was required. After executing the repair...a single Samba log file, residing under the OSX hidden folder "Private" was flagged as being corrupted in 3 of the 11 layers. In the past, you have indicated that simply re-capturing the file/folder flagged as corrupted should basically return the archive to a healthy condition. The issue here is...how can one direct QRecall to overtly re-capture a file residing in an OSX hidden folder or file? In the normal archive Capture dialog...hidden folders/files are not enumerated....even if you change Finder preferences to reveal hidden files. Thanks... GKG
|
|
|
James, Thanks for the explanation...makes sense... So far...the 2 separate capture actions seem to be doing the job well... Thanks again for all your help on this issue. Thanks, GKG
|
|
|
James, I believe that I may have stumbled across the reason for my VM's not being backed-up using FSEventsd...possibly, you have already deduced this from the sent reports, etc....but I thought it may be worth recapping. It seems that the directory that contains the VM package files is not being updated when a virtual machine inside of it has been updated (i.e., started and stopped). This can be easily observed directly in Finder...normally, when you update, say an individual text document inside of the Documents folder...both the Documents folder and the specific text document reflect the new updated timestamp. This is not true when it comes to VMWare virtual machines...when a virtual machine is started and stopped...the virtual machine's specific package folder does reflect the updated time stamp as seen in Finder...but the enclosing folder does not. For example, right now I have a virtual machine in a folder...the virtual machine's package has a Finder time stamp of 13:37 today...however, its enclosing folder has a time stamp of 13:15...meaning the enclosing folder did not get notified that one of its component objects has been updated. And obviously, when you create a QRecall action that points directly at the enclosing folder...the VM package(s) are backed up...if they have been updated. So...it looks like, as you so stated...the virtual machine process is somehow updating the individual package folder but not updating the enclosing folder...how VMWare Fusion is accomplishing this is not at all clear to me. I would think the OS should not allow this at all. Any comments? Thanks, GKG
|
|
|
James, Thanks for the update... I will setup the two actions per your instructions and give it a try. I am also a bit puzzled by the lack of "noise" from Time Machine users. I certainly know that Time Machine is an "ugly" way of backing-up virtual machines...since their virtual disks are very large and change constantly if the VM is running...still, many of my clients use Windows VM's...and, they use Time Machine to back them up. I have, however, confirmed, that as you would expect...if you perform the same test plan that we used with QRecall...i.e., Start/Stop the VM...shutdown system...upon system restart...Time Machine does NOT capture the VM either... Thanks, GKG
|
|
|
James, Ok...I have sent the report from the test laptop. I guess as far as running incremental captures with QRAuditFileSystemHistoryDays = 0.0 is concerned...my concern is that there could be other folders/files that are also being inadvertently "missed" by FSEventsd...it just seems odd to me that a virtual machine folder is the only one that could experience this issue...although I have no proof, of course, that other folders are not being backed-up... Certainly, the overhead for performing the full deep system scan each time can be huge...no doubt...possibly, if you believe this to be isolated to virtual machine folders only...I will take your advice and split this into 2 backup actions...one for the entire volume that specifically excludes the single VM directory...and another that only includes the VM directory...since you stated that the named target directory itself is always "deep scanned"...and only sub-directories employ the FSEventsd logic. Thanks...If you need any more info or testing...please let me know... Gary
|
|
|
James, Ok...I entered your Terminal commands to rename the .fseventsd folder... I then cycled the VM...rebooted....and ran a Capture. The Capture used the "deep traversal"...even though QRAuditFileSystemHistoryDays was set to the default value....I guess because .fsevenetsd was recreated? I then, however, cycled the VM again...restarted the computer...and ran another capture...this one missed the VM...so it still does not work correctly. I am attaching the .fseventsd-suspect folder as a single zip file. I hope this provides the info you need to supply Apple with a bug report. I guess for now...I will have to run all my captures using QRAuditFileSystemHistoryDays = 0.0...just to be sure everything is backed-up. Thanks, Let me know if you need any more info... Gary
|
|
|