Carl Wilhelm Soderstrom <chr...@real-time.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
