Author |
Message |
8 years ago
|
#1
|
Alexandre Takacs
Joined: Jul 5, 2014
Messages: 22
Offline
|
I am using Vmware fusion and part of my Qrecall Backup the various VMs I have on my system. As you probably know the virtual machines are stored within HFS "bundles", which includes all the individual files comprising a specific VM. I recently had to recover a VM and unfortunately I was greeted with this error: I understand (but I might be wrong) that the issue was that the VM was running during the backup and that the some of the underlying files where modified during the backup, thus making the "bundle" inconsistent. I guess that this backup is pretty much toast but I would very much hear your advices about avoiding such an issue in the future. My first inclination would be to script a VM "suspend" as a "before capture" script ? Any further info / pointer much appreciated.
|
|
|
8 years ago
|
#2
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1572
Offline
|
Alexandre, You are absolutely correct. Making a backup (with any software) of a virtual machine image while that VM is running is probably going to result in an incomplete/corrupt copy. This is a general problem with software that doesn't immediately write all of its data to disk and affects databases, video editing software, and so on. QRecall 2.0 has a new set of action events specifically designed to address this. You can start a capture action when an application quits, and you can ignore or stop a capture action if an application is running. This encourages the capture to run only when the application that might be modifying those files is dormant. If you run captures regularly and your VMWare usage is infrequent, you might consider just skipping backups that occur when that app is running by adding a new condition to your capture action: - Stop If Application [ VMWare Fusion ] Is Open If you run VMWare regularly, and want to capture complete, and stable, copies of your VM images, run the capture using an Event Schedule: - Event: Run when [ VMWare Fusion Quits ] My solution was to split off my (Parallels) VM images into their own archive.
My primary archive, which captures my startup volume, excludes the Parallels folder from all captures (set up in Archive > Settings...)
I have a second archive the just captures the Parallels folder.
The capture action for the second archive runs 1 minute after Parallels Desktop quits
The action also stops capturing if the application starts again Using this scheme, QRecall captures my VM images immediately after I quit, and never while it's running. I always get a "clean" copy of the VM images. If you want to make occasional copies during the day, just suspend your VMs and quit the app when you take a break (I do it before going to get coffee). By the time you get back, QRecall will have captured your VMs. Another important note: QRecall depends on File System Change Events (a macOS service that tracks changes made to your filesystem) to quickly determine what items have changed and need to be considered for re-capturing. A few software applications, most notably VM apps, make changes in a way that eludes File System Change Events. This means that QRecall won't notice that certain files within your VM package have changed, possibly for weeks. The capture action has a new "Deep Scan" option that ignores File System Change Events and exhaustively examines every file for changes. As you can imagine, this is much slower. Another advantage of splitting off your VM captures into a separate archive and action is that you can perform a "Deep Scan" on your VM captures (which is fairly shallow) and continue to use File System Change Events for your regular captures.
|
- QRecall Development - |
|
|
8 years ago
|
#3
|
Alexandre Takacs
Joined: Jul 5, 2014
Messages: 22
Offline
|
Thanks for you detailed answer. My problem is that my system - and those VM - run pretty much 24/7. I might consider suspending them for capture but I'd really like to avoid actually shutting down (if at all possible). FWIW I managed to recover a Time Machine backup of the VM that was taken pretty much at the same time as the corrupt QR one - but I think it is just a matter of luck...
|
|
|
8 years ago
|
#4
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1572
Offline
|
Alexandre Takacs wrote:My problem is that my system - and those VM - run pretty much 24/7. I might consider suspending them for capture but I'd really like to avoid actually shutting down (if at all possible).
The big question is does "suspending" a VM flush all of its data to disk? If it does, then you could take a manual approach: create a capture action for just your VM folder, occasionally suspend your VMs, start the capture, and then resume them when the capture is finished. (I have a much better solution for this kind of problem in the next major release of QRecall...)
|
- QRecall Development - |
|
|
8 years ago
|
#5
|
Alexandre Takacs
Joined: Jul 5, 2014
Messages: 22
Offline
|
I have a much better solution for this kind of problem in the next major release of QRecall...)
Aha.. now you got me interested Something we can discuss here ? If you have something "in the pipeline" I guess I will not invest time / resources in tuning by backup routine ...
|
|
|
8 years ago
|
#6
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1572
Offline
|
On deck for QRecall 2.1 is the ability to run a script (or any POSIX executable) before, and again after, an action runs. A script could, potentially, take steps to prepare either the archive (such as mounting a NAS device) or the items (like backing up a database server or shutting down a VM) for capture. Once the action finishes, a second script can perform any desired cleanup or post-processing (disconnect a NA, resume a VM, ...). Your situation would require some tools (shell commands, AppleScript, etc.) that could control the running VMs.
|
- QRecall Development - |
|
|
8 years ago
|
#7
|
Alexandre Takacs
Joined: Jul 5, 2014
Messages: 22
Offline
|
Oh ok - I thought it was already possible using the "before" and "after" actions. But looking closer I understand you can't actually run a script - which would be neat...
|
|
|
|