From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEc7t-00050S-PD for qemu-devel@nongnu.org; Fri, 23 Jan 2015 06:10:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEc7o-0005tm-UW for qemu-devel@nongnu.org; Fri, 23 Jan 2015 06:10:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEc7o-0005sk-NH for qemu-devel@nongnu.org; Fri, 23 Jan 2015 06:10:04 -0500 Date: Fri, 23 Jan 2015 12:09:58 +0100 From: Kashyap Chamarthy Message-ID: <20150123110958.GA14654@tesla.redhat.com> References: <201501211832330964659@sangfor.com.cn> <54BF81F0.9070908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BF81F0.9070908@redhat.com> Subject: Re: [Qemu-devel] [question] incremental backup a running vm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , Zhang Haoyu , Fam Zheng , qemu-devel , kvm On Wed, Jan 21, 2015 at 11:39:44AM +0100, Paolo Bonzini wrote: > > > On 21/01/2015 11:32, Zhang Haoyu wrote: > > Hi, > > > > Does drive_mirror support incremental backup a running vm? > > Or other mechanism does? > > > > incremental backup a running vm requirements: > > First time backup, all of the allocated data will be mirrored to destination, > > then a copied bitmap will be saved to a file, then the bitmap file will log dirty for > > the changed data. > > Next time backup, only the dirty data will be mirrored to destination. > > Even the VM shutdown and start after several days, > > the bitmap will be loaded while starting vm. > > Any ideas? > > Drive-mirror is for storage migration. For backup there is another job, > drive-backup. drive-backup copies a point-in-time snapshot of one or > more disks corresponding to when the backup was started. Zhang, I've been testing the `drive-backup` command via QMP for a little while, and it works reasonably well. If you'd like to test it you can quickly try as below, once you have a QEMU instance runing with QMP (I invoke my QEMU instances with '-qmp tcp:localhost:4444,server'). The below script invokes the 'drive-backup' QMP command (Ensure you're using the correct disk, your disk ID might be 'drive-virtio-disk1' :-) ) ----------------- #!/bin/bash set -x exec 3<>/dev/tcp/localhost/4444 echo -e "{ 'execute': 'qmp_capabilities' }" >&3 read response <&3 echo $response echo -e "{ 'execute': 'drive-backup', 'arguments': { 'device': 'drive-virtio-disk0', 'sync': 'full', 'target': '/export/backup-of-vm1.qcow2', 'mode': 'absolute-paths', 'format': 'qcow2' } }" >&3 read response <&3 echo $response ----------------- Once the above is invoked succesfully, you can see the success of the command on the shell where your QMP server is running: ----------------- [. . .] char device redirected to /dev/pts/8 (label charserial0) QEMU waiting for connection on: disconnected:tcp:localhost:4444,server Formatting '/export/backup-of-vm1.qcow2', fmt=qcow2 size=53687091200 encryption=off cluster_size=65536 lazy_refcounts=off ----------------- > > Incremental backup is being worked on. You can see patches on the list. > > Paolo > -- /kashyap