更新备份大小，当备份被创建¶

https://blueprints.launchpad.net/cinder/+spec/report-size-when-backup-created

此蓝图建议在备份创建时，使用备份后端报告的大小来更新备份信息。

问题描述¶

大多数云提供商为最终用户提供了一种便捷的方式来保护他们的数据，即为他们的卷创建备份。用户可以随时创建任何备份副本，云提供商会根据备份总大小向他们收费。作为基本的卷服务，Cinder 支持创建、恢复和删除备份以及备份配额，但我们当前的备份大小不正确，备份的大小始终等于原始卷的大小，即使增量备份不包含任何内容也是如此。

用例¶

备份的大小属性将反映后端实际大小，配额和收费将更加准确。

提议的变更¶

此规范建议备份驱动程序在创建备份时报告后端保存的实际大小。因此，当用户请求为 10G 卷创建备份时，Cinder 仍然会生成一个包含 10G 的记录，并为配额预留 10G，但当报告实际大小时，我们将更新对象和配额。

注意：这里的实际大小是指后端最终的大小，这意味着如果我们为仅包含 200mb 数据的 1G 卷创建备份，并且压缩后磁盘上仅使用 100mb，则实际大小为 100mb，而不是 200mb 或 1G。

由于 Cinder 对每个资源都使用统一的单位 G，因此该大小也应四舍五入到 G，例如，如果创建的增量备份在后端实际大小仅为 12mb，驱动程序仍然应向 Cinder 服务报告 1 G

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
        }
    """
    return

Cinder 的备份服务将使用此 size 来更新备份模型，以及提交一部分预留（为了涵盖这种情况，Cinder 不会直接提交预留记录，而是在后台实际创建备份后更新预留并提交更新的记录）。

为了报告备份保存的实际大小，驱动程序需要记录或计算对象大小。以我们的 chunkeddriver 为例，总大小是通过对象的大小累积得出的

size = object1_size + object2_size....

如果启用了压缩功能，对象的大小应该是

size = compressed_object1_size + compressed_object2_size...

现在 Cinder 具有 size 属性用于备份对象，该属性仅反映创建时的卷大小。为了支持更新备份的实际大小，我们将添加另一个属性。

1. volume_size：这用于记录原始卷的大小，并且可以在恢复时用于创建新卷，我们不能直接链接到原始卷的大小，因为我们可以在备份卷后调整卷的大小。

2. size：这将用于存储驱动程序报告的值，而不是原始卷的大小。当备份首次创建时，此值将等于 volume_size，并在后端创建备份时更新。

备选方案¶

继续使用卷的大小来生成备份的大小以及数据库中的配额使用记录。

数据模型影响¶

无

REST API 影响¶

无

Cinder 客户端影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

在提交配额预留时，性能会略有下降。

其他部署者影响¶

无

开发人员影响¶

开发人员应在添加新的备份驱动程序时，在 backup 方法中报告备份的大小。

实现¶

负责人¶

主要负责人: tommylikehu(tommylikehu@gmail.com)

工作项¶

更新 cinder 以支持更新备份大小。
更新现有驱动程序以报告备份的实际大小。
添加相关的单元测试用例。

依赖项¶

无

测试¶

添加单元测试以涵盖此更改。

文档影响¶

更新基础备份驱动程序的接口。
更新开发人员文档以宣传此更改。

参考资料¶

无

更新备份大小，当备份被创建