Correct, that is what we often call in virtualization... a crash consistent state. This is usually what a VM backup is really, is a crash consistent backup. Snapshots on active VMs vary according to the Virtualization Platform design, and unless you 'qualify' the file system state against memory state, which is transitionally costly, you have a true gap. Thus, transactional IO is lost, that is in memory, true that for database systems this can be especially painful. But most of the time, real-time systems not-withstanding, a crash consistent state, today, is sufficient.
Schorschi -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Christian Grassi Sent: Tuesday, 12 April, 2011 09:20 To: Frédéric Grelot Cc: virt-tools-list Subject: Re: [virt-tools-list] Best way to backup my VMs Actually you create a doubt in my mind... If you have a VM with lots of memory, if you just suspend the machine, and back it up without saving the ram, in teory, as no fsync succeded you could lose a lot of stuff which is in the filesystem cache and not synced. Am I wrong ? Regards Chris On Tue, 2011-04-12 at 17:50 +0200, Frédéric Grelot wrote: > > 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 _______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. _______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
