1 From e9d7fc0567eb5bef368a950a4813d6eb5867572b Mon Sep 17 00:00:00 2001
2 From: Dietmar Maurer <dietmar@proxmox.com>
3 Date: Tue, 13 Nov 2012 09:24:50 +0100
4 Subject: [PATCH v3 1/6] RFC: Efficient VM backup for qemu
6 This series provides a way to efficiently backup VMs.
8 * Backup to a single archive file
9 * Backup contain all data to restore VM (full backup)
10 * Do not depend on storage type or image format
11 * Avoid use of temporary storage
12 * store sparse images efficiently
14 The file docs/backup-rfc.txt contains more details.
19 * move BackupInfo from BDS to BackupBlockJob
20 * introduce BackupDriver to allow more than one backup format
21 * vma: add suport to store vmstate (size is not known in advance)
22 * add ability to store VM state
26 * BackupDriver: remove cancel_cb
27 * use enum for BackupFormat
28 * vma: use bdrv_open instead of bdrv_file_open
29 * vma: fix aio, use O_DIRECT
30 * backup one drive after another (try to avoid high load)
32 Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
34 docs/backup-rfc.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++
35 1 files changed, 119 insertions(+), 0 deletions(-)
36 create mode 100644 docs/backup-rfc.txt
38 diff --git a/docs/backup-rfc.txt b/docs/backup-rfc.txt
40 index 0000000..5b4b3df
42 +++ b/docs/backup-rfc.txt
44 +RFC: Efficient VM backup for qemu
48 +* Backup to a single archive file
49 +* Backup needs to contain all data to restore VM (full backup)
50 +* Do not depend on storage type or image format
51 +* Avoid use of temporary storage
52 +* store sparse images efficiently
56 +Most VM backup solutions use some kind of snapshot to get a consistent
57 +VM view at a specific point in time. For example, we previously used
58 +LVM to create a snapshot of all used VM images, which are then copied
61 +That basically means that any data written during backup involve
62 +considerable overhead. For LVM we get the following steps:
64 +1.) read original data (VM write)
65 +2.) write original data into snapshot (VM write)
66 +3.) write new data (VM write)
67 +4.) read data from snapshot (backup)
68 +5.) write data from snapshot into tar file (backup)
70 +Another approach to backup VM images is to create a new qcow2 image
71 +which use the old image as base. During backup, writes are redirected
72 +to the new image, so the old image represents a 'snapshot'. After
73 +backup, data need to be copied back from new image into the old
74 +one (commit). So a simple write during backup triggers the following
77 +1.) write new data to new image (VM write)
78 +2.) read data from old image (backup)
79 +3.) write data from old image into tar file (backup)
81 +4.) read data from new image (commit)
82 +5.) write data to old image (commit)
84 +This is in fact the same overhead as before. Other tools like qemu
85 +livebackup produces similar overhead (2 reads, 3 writes).
87 +Some storage types/formats supports internal snapshots using some kind
88 +of reference counting (rados, sheepdog, dm-thin, qcow2). It would be possible
89 +to use that for backups, but for now we want to be storage-independent.
91 +Note: It turned out that taking a qcow2 snapshot can take a very long
92 +time on larger files.
94 +=Make it more efficient=
96 +The be more efficient, we simply need to avoid unnecessary steps. The
97 +following steps are always required:
99 +1.) read old data before it gets overwritten
100 +2.) write that data into the backup archive
101 +3.) write new data (VM write)
103 +As you can see, this involves only one read, an two writes.
105 +To make that work, our backup archive need to be able to store image
106 +data 'out of order'. It is important to notice that this will not work
107 +with traditional archive formats like tar.
109 +During backup we simply intercept writes, then read existing data and
110 +store that directly into the archive. After that we can continue the
115 +* very good performance (1 read, 2 writes)
116 +* works on any storage type and image format.
117 +* avoid usage of temporary storage
118 +* we can define a new and simple archive format, which is able to
119 + store sparse files efficiently.
121 +Note: Storing sparse files is a mess with existing archive
122 +formats. For example, tar requires information about holes at the
123 +beginning of the archive.
127 +* we need to define a new archive format
129 +Note: Most existing archive formats are optimized to store small files
130 +including file attributes. We simply do not need that for VM archives.
132 +* archive contains data 'out of order'
134 +If you want to access image data in sequential order, you need to
135 +re-order archive data. It would be possible to to that on the fly,
136 +using temporary files.
138 +Fortunately, a normal restore/extract works perfectly with 'out of
139 +order' data, because the target files are seekable.
141 +* slow backup storage can slow down VM during backup
143 +It is important to note that we only do sequential writes to the
144 +backup storage. Furthermore one can compress the backup stream. IMHO,
145 +it is better to slow down the VM a bit. All other solutions creates
146 +large amounts of temporary data during backup.
148 +=Archive format requirements=
150 +The basic requirement for such new format is that we can store image
151 +date 'out of order'. It is also very likely that we have less than 256
152 +drives/images per VM, and we want to be able to store VM configuration
155 +We have defined a very simply format with those properties, see:
157 +docs/specs/vma_spec.txt
159 +Please let us know if you know an existing format which provides the