Open Stack

On 30/06, int32bit wrote:
> Currently the size in backup is src volume size rather than backup
> file/object size, it's used to record original volume size that avoid
> damaging target in restore operation if the volume has been resized.
>
> But it may be more useful for end user to tell them backup files/objects
> size(object count really make no sense for user). It's also useful for
> cloud provider to compute their bill.
>
> I think It's not very hard to implement it if we use or extend
> `chunkeddriver`.  Firstly we need add `get_backup_size` new interface in
> driver API and let's update backup size in `_finalize_backup`. The backend
> driver should implement this interface if possible. If the backend driver
> is not possible to implement like `CephBackupDriver`, we raise
> NotImplementedError. And then we need add a new field(named volume_size) in
> backup object as well as db model associated to backup, and store
> files/objects size in original size field. At last, we add this new
> field volume_size to backup ViewBuilder in API.

Hi,

I think this is a good idea, just a couple of comments.

We should not change the meaning of the size field in the backup model,
size should remain the original volume's size, and the new field should
refer to the allocated/consumed size.

Besides adding the size of the hash table to the size of the chunks when
calculating the consumed size of the backups, maybe we should also
include a mechanism for drivers to account for the overhead of having
additional objects.

Last I would like to thank you for being thorough and considering the
Ceph backup driver case as well, although it won't need to be an
exception, as it could also report the real size of the backup with one
of these 2 mechanisms:

- Piping the output from export-diff and processing the metadata in
  there to calculate the size.

- Once the backup has completed using the diff command to get the list
  of byte extents and calculate the real size of the image from the
  parent backup.

Cheers,
Gorka.