Re: [libvirt] [PATCH 1/8] snapshots: Avoid term 'checkpoint' for full system snapshot

On Wed, Jun 13, 2018 at 7:42 PM Eric Blake <eblake(a)redhat.com&gt; wrote: I want to refer only to the new concept of checkpoint, compared with snapshot. I think checkpoint should refer to the current snapshot. When you perform a backup, you should get the changed blocks in the current snapshot. When you restore, you want to the restore several complete snapshots, and one partial snapshot, based on the backups of that snapshot. Lets try to see an example: T1 - user create new vm marked for incremental backup - system create base volume (S1) - system create new dirty bitmap (B1) T2 - user create a snapshot - dirty bitmap in original snapshot deactivated (B1) - system create new snapshot (S2) - system starts new dirty bitmap in the new snapshot (B2) T3 - user create new checkpoint - system deactivate current dirty bitmap (B2) - system create new dirty bitmap (B3) - user backups data in snapshot S2 using dirty bitmap B2 - user backups data in snapshot S1 using dirty bitmap B1 T4 - user create new checkpoint - system deactivate current dirty bitmap (B3) - system create new dirty bitmap (B4) - user backups data in snapshot S2 using dirty bitmap B3 Lets say use want to restore to state as it was in T3 This is the data kept by the backup application: - snapshots - S1 - checkpoints - B1 - S2 - checkpoints - B2 - B3 T5 - user start restore to state in time T3 - user create new disk - user create empty snapshot S1 - user upload snapshot S1 data to stoage - user create empty snaphost disk S2 - user upload snapshot S1 data to stoage John, are dirty bitmaps implemented in this way in qemu? Nir