Update backup’s size when backup is created


This blueprint proposes to update backup with the size reported by backup backend when backup is created.

Problem description

Most clouds provide end user a convenient way to protect their data by creating a backup for their volume. Users can create any backup copy at anytime, and the cloud providers charge them by the backup size in total. As the basic volume service, Cinder supports creating, restoring and deleting backups plus the backup quotas, but our backup size isn’t correct at present, the backup’s size always equals to the original volume’s size even if the incremental backup doesn’t have any content in it.

Use Cases

Backup’s size attribute will reflect the actual size on the backend, the quota and charge would be more accurate.

Proposed change

This spec proposes that the backup driver should report the actual size that object holds at the backend when backup is created. So, when user requests to create a backup for a volume with 10G, Cinder will still generate the record with 10G as well as consume 10G for quota reservation, but when the actual size is reported, we will update both the object and the quotas.

Note: The actual size here stands for the final size at the backend, that means if we create backup for a 1G volume which only has 200mb data and after compression only 100mb is used at disk, the actual size is 100mb, not 200mb or 1G.

As Cinder has the unified unit G for every resource, that size should be rounded up to G too, for example, if we create an incremental backup whose actual size is only 12mb at backend, driver should still report 1 G to Cinder service:

def backup(self, backup, volume_file, backup_metadata=False):
    """Start a backup of a specified volume.

    Driver should return the size that the backup object holds
    in the backend, with the unit of G. For instance:

    .. code-block:: python

            'size': 2

Cinder’s backup service would use this size to update backup model as well as commit portion of the reservation (Instead of commit the reservation record, Cinder will update the reservation and then commit the updated record after backup is actually created in the background to cover this case ).

In order to report the actual size that backup holds, drivers need to record or calculate the object size. Take our chunkeddriver for instance, the total size is accumulated by the objects’ size:

size = object1_size + object2_size....

If compression feature is enabled, the object’s size should be:

size = compressed_object1_size + compressed_object2_size...

Now Cinder has the attribute size for backup object which only reflects the volume’s size when created. In order to support updating the actual size of the backup, we will add one more attribute here.

1. volume_size: This is used to record the original volume’s size and can be used to create new volume when restoring, we can not directly link to the original volume size here because we could resize the volume after the volume is backed up.

2. size: This will be used to store the reported value from driver rather the original volume size. And when backup is first created, this value would be equal to the volume_size and will be updated when backup is created at backend.


Keep using volume’s size to generate the backup’s size as well as quota usage record in database.

Data model impact


REST API impact


Cinder-client impact


Security impact


Notifications impact


Other end user impact


Performance Impact

There would be a slight performance impact when committing quota reservations.

Other deployer impact


Developer impact

Developer should report backup’s size in backup method when adding new backup driver.



Primary assignee:


Work Items

  • Update cinder to support update the backup size.

  • Update existing driver to report backup’s actual size.

  • Add related unit testcases.




  • Add unit tests to cover this change.

Documentation Impact

  • Update the base backup driver’s interface.

  • Update developer’s documentation to advertise this change.