On Mon, Sep 28, 2015 at 8:24 AM, Edward Ned Harvey (blu) <b...@nedharvey.com> wrote: >> From: Bill Bogstad [mailto:bogs...@pobox.com] >> >> > 2- Use a snapshotting filesystem like btrfs or zfs in the host, so the >> > host can >> replicate the guest storage to another location seamlessly. >> >> I don't see how this can work in a way that would be useful. >> Filesystem snapshots of your emulated disk images by the host OS may >> give you a single point in time copy, but they don't guarantee that >> the copy is in any way consistent. > > This is one of my favorite modes of operation. I run a ZFS host, and have > guest VM's residing in zvol's, which get snapshotted and replicated > periodically to additional attached storage, and offsite and offline. > > If something happens, like the whole machine explodes or whatever, then I > restore the guest snapshot, and power it on. The behavior of the guest > machine is exactly as if the guest machine had been running and then suddenly > the guest power was yanked or kernel panic or something. The guest storage > device is a precise snapshot of what the guest storage would have looked like > at the instant that the storage snapshot occurred.
Well, we are on the same page on that anyway. It is exactly like pulling the plug on a running system. > If you're running an OS or some daemon that can't survive a power > interruption, time to find a new OS or switch to a different daemon. While some OSes/filesystems handle power interruption well at this point, it seems to me that there are lots of apps/servers which do not and which people still need to use. Particularly in a VM environment where you might be running legacy OS/app combinations because you can't replace them, it seems to me that suggesting this method as a generic way to backup VMs is not really appropriate. Sure we should all replace our old software systems with ones that use transactions to protect against this kind of failure, but I don't think we are there yet. Bill Bogstad _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
