Carl Wilhelm Soderstrom <chrome AT real-time DOT com> wrote on 09/10/2009
12:42:33 PM:
> On 09/10 11:02 , Les Mikesell wrote:
> > You'll almost certainly end up with an unusable copy if you let the VM
> > run while copying
>
>
> To test this, some years ago I actually tried archiving and restoring a
> vmware disk image while it was in use. Turns out it worked just fine.
> That said, the vmware session was not in active use at the time and I
> certainly wouldn't trust this to not give thoroughly corrupt data.
>
> You may be able to get away with it occasionally; but on any system in
> production the amount of disk activity will likely corrupt your backup.
You are right: it comes completely down to a lot of uncontrollable items
For example, if the *guest* OS has cached certain items in RAM, how will
you know? If the guest has left the filesystem in an unrecoverable state,
how will you know? Or if the *host* operating system is playing games
with something, how will you know?
Of course, the bigger problem is that the disk is basically *guaranteed*
to be inconsistent, as you copy the file(s) and the guest continues to
make changes behind you... After all, if the system wasn't doing anything
during the copy, you could have simply shut it down! :)
It's even worse than pulling the plug on a physical machine and hoping
that it comes up. At least with real hardwrae, you've got an
internally-consistent (assuming journalling) image of the file system. 99%
of the time, it will be OK. 1% of the time, it won't. I don't want to
find out that I've hit that 1% when I'm trying to recover a production
file server! :)
There are other issues that one should test as well. For example, have
you tried restoring a guest to a *different* host? One with a different
CPU? Depending on the combination of CPU features (such as NX, 32/64-bit,
virtualization support, etc.), it may not be possible to restore a running
guest to a different host without crashing it. It's always a good idea to
test for these things! (Even with the for-pay vMotion tools, there are
limits on what hosts you can switch between without problems.)
Or do what we do: shut down the guest before copying it somewhere. We
only do this on occasion (usually quarterly), so the couple of minutes of
downtime is manageable. We don't consider this as backup, but disaster
recovery. We can restore a, say, month-old copy of the server, then use
BackupPC to restore the data from within the guest. Still *way* faster
than actual bare-metal restores, for no additional cost.
Tim Massey
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
