WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] A simple backup

To: Nick Anderson <nick@xxxxxxxxxxxx>
Subject: Re: [Xen-users] A simple backup
From: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
Date: Sat, 10 May 2008 08:22:53 +0100
Cc: Steve Spencer <sspencer@xxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx, Tiago Cruz <tiagocruz@xxxxxxxxxxxx>
Delivery-date: Sat, 10 May 2008 00:16:20 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=bmYb/A8Okk+Uod74t9iNgNxfuuZfkjDEFCTAwqlM9pU=; b=aVASD+OASJdDHoMVwuOnnOyKA9OxqZMU97hgJcOnHEPxe2Jr66M6H7mTBN7Y5BR9IVkqIrg3IfKN9Px45DXcP7Ng+REVj04szL9cDBmvSmxFGtVa11e0tjTn43zIfWjVmNlnzXIhGlj8psn+DuPw1V3b0i5mfL3/bhFbcEtDSg4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S0kZYWHCj6BGPfphgWRwjRkfLRThZSY5CDtXruyqhRY52zOH/CO7UYpq+sdtE+Tpq5WN59VbpN8TbEyjjDcu/zcWJBPadKgTHwX6h5b8/7dWYHGaanonGYW9yshI9ceg2OmuBiffV/6oHnwn0QVlxLwcB5aWAW1Q8QHhjJ9zq5Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <48239ADA.5070706@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <48221AEF.50009@xxxxxxxx> <48222125.4030405@xxxxxxxxxxxx> <200805082005.47735.mark.williamson@xxxxxxxxxxxx> <48237545.2000808@xxxxxxxxxxxx> <48239ADA.5070706@xxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)
Nick Anderson wrote:
Nick Anderson wrote:
Mark Williamson wrote:
This is not really ideal, since it's not always desirable to have to save a domain's memory state. It would be nicer if you could somehow guarantee a consistent filesystem state on your disk snapshot. I've been looking into how to do this and I believe it's quite possible to modify the code to support this properly.

Mark, thanks for the reply.
My thought is this. If I xm save it saves the memory state and pauses the VM. While the vm is paused I can then snapshot the block device from dom0 of the guest vm. Since the domain is paused there is no disk activity during the snapshot, and anything that was possibly half-written is in the memory state. So I should be able to reliably dd the snapshot since when I try to restore I could try restoring the block device state, and use xm restore on the checkpoint to restore the memory at the same time. Is this not essentially what xm migrate does? Can we not be assured that since we have memory state and block state at that point in time that the data will be consistent?

.... When I say assured I mean just as assured as any other backup. There is always the possibility of flipped bits, I am just thinking that having memory state and block state when attempting a restore would be very very close if not the same as having turned the domain off and copied the block device then turn it back on.

hope that makes sense and there wasnt too much rambling.

Does that sound right? I guess I am really interested how lvm snapshots are thought of as not safe when a domain is paused and you have the memory state.
Any operation that has not paged disk operations out to the disk image have their changes stashed in RAM: this makes databases It's bad enough when it's a text file in the middle of being edited, but when it's a database like Oracle or MySQL or even db4, you're vulnerable to some real trouble because their 'atomic operations' won't be.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>