restic version
任何。
添加一个额外的列来列出备份的大小(以字节为单位)可能非常有用。
只需检查它们的大小,它就会帮助区分不同的备份。
$ restic snapshots
ID Date Host Tags Directory Size
--------------------------------------------------------------------------
5b969a0e 2016-12-09 15:10:32 localhost myfile 390865
$ restic snapshots
ID Date Host Tags Directory
----------------------------------------------------------------------
5b969a0e 2016-12-09 15:10:32 localhost myfile
谢谢你的建议。 您希望尺寸是多少? 由于所有数据都进行了重复数据删除,因此特定快照的“大小”并不容易确定。 那是该快照中引用的所有数据的大小吗? 或者拍摄快照时尚未存储在 repo 中的数据(新数据)?
这是一个非常好的提议。 右边的数字应该是添加到 repo 的 blob 的累积大小。 它是任何备份运行中最有趣的定量参数。
今晚我的增量浪费了多少空间? 哎呀,比昨晚多了 10 倍,我在这儿留下了一些垃圾(或者忘了放一些排除项),我最好把它清理干净。 ;)
+1 @zcalusic建议
随着时间的推移,“新”blob(由该特定快照添加)的大小问题变得不那么重要,因为这些 blob 将被以后的快照引用。 此外,当删除较早的快照时,特定快照引用的 blob 数量将增加。
我认为备份完成后立即打印此信息很有价值,我们也可以将其记录在repo中的快照数据结构中。 我计划为特定快照添加某种“详细信息”视图,我认为在那里显示新 blob 的数量和大小是个好主意,但在概述中(命令snapshots
)它不够相关。 在那里,我认为 restic 应该显示特定快照的整个大小(如果你要恢复它,你会得到什么),因为这不会改变。
我立即想起了 rdiff-backup 的统计标志(参见 https://www.systutorials.com/docs/linux/man/1-rdiff-backup-statistics/)。 有时很高兴看到 2 个快照之间的某种差异。
确实,但那是另一回事:它是实时计算的并比较两个快照。 我们可能会添加类似的东西,但是为snapshots
概览列表这样做太昂贵了(至少我们现在在数据结构中可用的信息)。
了解快照的“唯一”数据大小与快照的总大小(包括重复数据删除的数据)可能会很有用。
IMO 了解新快照使用了多少额外空间将非常有用。 这甚至可能只是在备份期间计算并存储在快照元数据中的物理存储空间。 如果删除了某个快照,则该元数据应在所有未来快照中失效。
我想即使在这个方向上没有做任何其他事情,我也会欣赏这样的功能。 但是,在删除一些以前的备份后重新计算这个“额外大小”的选项也很好。 我认为这就是BackupLoupe在 Mac OS 上为 Time Machine 所做的。 (Time Machine 中的重复数据删除是非常基础的,但是定义“快照大小”的问题是一样的)。
我想立即了解的最基本的事情是,如果我恢复快照 X 的内容,它会在目标磁盘上消耗多少磁盘空间。
最好我也能够仅获取文件子集的此信息,例如,如果size
命令采用与restore
命令相同类型的包含/排除选项。 或者,如果restore
命令有一个选项,让它只报告这样的统计信息而不是实际恢复。
感谢@rawtaz向我指出这个问题。
我将备份存储在计量存储 (Backblaze B2) 中。 我想知道每次运行备份时我创建了多少新数据。 在备份过程中,这似乎应该很容易计算; 如果 restic 只是将其记录为结束备份的一部分,我会很高兴……但似乎将其存储为快照的属性也可能很有用(以便将来查询)。
我对需要对存储库进行大量重新扫描的任何内容都不感兴趣,因为这只会产生额外的费用。
任何新闻?
你好
我想支持这个建议。 除了针对任何现有快照的“如果我恢复该快照有多大”以及创建快照时“此快照添加了多少”之外,我还有第三个建议:
能够回答以下问题也将有所帮助:“如果我删除以下快照,我的存储库大小会减少多少?” 在决定是否删除快照时,这在restic forget --prune --dry-run
很有用。 例如,我最近在一个 repo 中删除了 40 个快照中的 20 个,并将大小从 1.1GB 减少到 1.0GB。 如果我知道这只会节省 100MB,我可能会保留较旧的快照。
@mholt制作了 #1729 来显示一些统计数据。 也许他可以插嘴说一下这个公关的进展。
@dimejo已经完成了——只是在等待它被审查/合并。 :)
在这里跳到一个非常老的问题,但对我来说,在考虑快照时有 2 个重要的大小字段
例如
$ restic snapshots
ID Date Host Tags Directory Snapshot Size Restore Size
--------------------------------------------------------------------------------------------------
5b969a0e 2016-12-09 15:10:32 localhost myfile 10 MB 57 GB
至少那时我可以知道单个快照正在使用多少空间以及我需要多少空间来执行还原。
正如@fd0已经指出的那样,在每次调用restic snapshots
打印大小将是一个非常昂贵的命令。 但是您可以使用restic stats来打印单个快照或整个存储库的大小。
我认为备份完成后立即打印此信息很有价值,我们也可以将其记录在repo中的快照数据结构中。 我计划为特定快照添加某种“详细信息”视图,我认为在那里显示新 blob 的数量和大小是个好主意,但在概述中(命令
snapshots
)它不够相关。 在那里,我认为 restic 应该显示特定快照的整个大小(如果你要恢复它,你会得到什么),因为这不会改变。好点子! 队列中是否有此增强功能? 存储库中去重数据的总大小也将有助于此类概要。
此功能有任何更新吗? 这是非常有用的,能够看到每个快照规模和恢复大小。
+1
不是在这一点上。 如果有任何更新,它将显示在本期中。
最有用的评论
随着时间的推移,“新”blob(由该特定快照添加)的大小问题变得不那么重要,因为这些 blob 将被以后的快照引用。 此外,当删除较早的快照时,特定快照引用的 blob 数量将增加。
我认为备份完成后立即打印此信息很有价值,我们也可以将其记录在repo中的快照数据结构中。 我计划为特定快照添加某种“详细信息”视图,我认为在那里显示新 blob 的数量和大小是个好主意,但在概述中(命令
snapshots
)它不够相关。 在那里,我认为 restic 应该显示特定快照的整个大小(如果你要恢复它,你会得到什么),因为这不会改变。