Re: [Qemu-block] dirty bitmap restore procedure

[John Snow]

On 11/29/2016 12:27 PM, Michael Ablassmeier wrote:
> hi John,
>
> On Tue, Nov 29, 2016 at 11:52:49AM -0500, John Snow wrote:
> > You need to create your snapshot and add (or reset) the bitmap using
> > a transaction.
>
> What i currently not get is the difference between:
>
>  1) create a snapshot and bitmap in an transaction OR

If you create a snapshot and a bitmap together in a transaction, the 
bitmap begins recording all new information from exactly that point 
forward. Although new writes won't go to the snapshot, they'll go to the 
new active layer, we need a bitmap present to record those writes for 
when you later issue your "commit" command to effectively re-merge the 
snapshot.

Here's a timeline:

[img]

Then, create an external snapshot:

[img]<--[top]

Next, some data happens to sneak into the top image:

[img]<--[top']

Then you copy "img" as "backup":

[img]<--[top']          ||     [backup]

Then you commit top' back down into img:

[img']                  ||     [backup]

Then maybe you create your bitmap:

[img':bitmap]           ||     [backup]

And now you perform some more writes:

[img'':bitmap]          ||     [backup]

But now when you create your incremental backup from this bitmap, it's 
only captured the newest write, because it wasn't present for that 
earlier write...

[img'':bitmap]          ||     [backup]<-/-[delta'']

You wind up missing necessary data in that backup.

By creating the snapshot AND the bitmap simultaneously, you can be 
assured that any new writes that apply WILL be accounted for in a new 
incremental backup.

The transaction allows us to guarantee these two actions happen exactly 
simultaneously.

>  2) create only a bitmap and then use the drive-backup
>     with sync=full to create a full backup, like shown in the
>     examples.

Nowhere in the documentation linked does it suggest you can create a 
bitmap first then use drive-backup sync=full -- without pausing the VM 
OR using a transaction. These are necessary steps.


When a bitmap is created, it starts out empty. As writes come in, the 
bitmap fills up. We can reset/clear the bitmap back to empty, or we can 
do an incremental backup to get it back to empty, too.

So we have several options for how we can start an incremental backup: 
The first here is what I documented in bitmaps.md.


"Live" method, (A):

- Create a bitmap
- Use a single transaction to:
    - Create a full backup using drive-backup sync=full
    - Reset the bitmap

The important point is just that the bitmap is empty/clear at the time 
of the backup. Any action you take to create a full backup, whether its 
via the external snapshot mechanism or the drive-backup mechanism must 
be "linked" in some way to the bitmap you hope to use for incremental 
backups. This linking mechanism is achieved generally two ways:

    (1) We used a transaction to batch the snapshot or backup mechanism
        alongside the bitmap add/clear to make sure they happen at the
        same exact moment in time, or
    (2) We paused the VM before we issued our commands to ensure that no
        writes occurred between the backup/snapshot operation and the
        bitmap creation operation.

Or a variation on the same method, (B):

- Use a transaction to:
    - Create a new bitmap
    - Create a full backup using drive-backup sync=full

Or the "paused" or non-live method, (C):

- Pause the VM
- Make a full backup
- Add or reset a bitmap
- Resume the VM

What it is *never* safe to do is (D):

- Do not pause the VM
- Make a full backup or external snapshot
- Create or reset a bitmap

The problem is that the VM gets to run between the second and third 
phases there, which means the bitmap and the snapshot/backup are no 
longer linked together anymore.

All safe methods are trying to achieve the same core purpose: making 
sure the bitmap is /empty/ at the exact same instant we take the 
snapshot/backup.

> using the snapshot i can be sure my disk is not changed during
> backup as the backing file of the snapshot gets written and
> changes get commited back as i remove the snapshot, or does

You can be sure no writes are going into your *BACKING FILE* but what 
about writes going to the active layer? The bitmap needs to know about 
those!

> drive-backup take care about this too? Does it even make

Indeed, when you issue drive-backup, any new writes to parts of the file 
that haven't been copied out yet are held back until those regions of 
the file can be copied. This allows new writes to go through while we 
back up the image, but you still get a real, proper backup.

It's also very easy to use with transactions and bitmaps, and I'm a lazy 
soul.

> sense to create a full backup using a snapshot or should
> i only use the bitmap and drive-backup feature?

Use whichever one is fastest, easiest, or makes the most sense to you. I 
prefer using the drive-backup method because I dislike the idea of 
having to create a snapshot and then commit it back later.

> As i understand based on wether i use 1) or 2) i get
> the different behavior regards backing files as you
> describe and must use different ways to recover.

Recovery is going to be fairly similar between the two approaches, they 
mostly differ in the creation of that initial backup. Both ways can be 
done safely.

> > As an exercise, I assume?
>
> yes, only testing here to get an understanding how it works.
>
> thank you,
>     - michael

I hope I have made this clearer instead of more confusing!

If you'd like to see examples of how we test the incremental backup 
features, take a look at iotest 124 in the QEMU source tree:

https://github.com/qemu/qemu/blob/master/tests/qemu-iotests/124


Good luck,
--js