> Actually, this isn't right. Think about the case where you lose > power to > your computer; you don't get corrupted disks, you get > "crash-consistent" disks > (this is what journaling filesystems are for). So if you know what > you are > doing, it is sufficient just to pause the guest (virsh suspend > <guest>), take > the backup, and then resume the guest (virsh resume <guest>). True, > you > won't get all of the data that might have been in-flight in memory, > but it > should be a valid state of the disk.
I tend to agree with that, it already happened to me for a zimbra server, and I lost nothing. > > That all being said, installing backup software in the guest is the > best > course of action. An other method to profit from virtualization-enabled server would be to take the following actions : -inside guest : turn of server application -inside guest : unmount data disk -host : pause guest (necessary?) -host : lvm (or qcow/qed) snapshot of disk -host : resume guest -inside guest : remount and restart server application Provided there is no side-effect of unmounting with regard to guest cache (to be confirmed), I think this would reduce downtime, and permits backup of specific parts of the server application without stopping it as a whole. A (maybe safest) other option would be to gracefully shutdown the server, LVM/qcow/qed snapshot its disk and restart the server immediately : the data duplication itself won't account for the downtime, since it can be done later. Frederic. > > -- > Chris Lalancette > > _______________________________________________ > virt-tools-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/virt-tools-list > _______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
