把保留天数换成可回答的恢复问题
保留策略不是随便填一个版本数。先问自己：误删多久后可能发现，能接受丢失多长时间内的新增资料，恢复时最多能等多久。前者影响历史覆盖窗口，后两者分别帮助确定备份频率与恢复目标。照片归档和每天变化的个人笔记，需求可能不同；一个任务覆盖所有文件看似省事，却容易使高变化资料挤占真正需要长期保存的历史。
先给数据分组并记录源范围、排除项和可重新生成的内容，再测量现有规模。Mac 的目录占用仅用于初步预算，不能预测去重压缩后的仓库大小，也不能替代 DSM 的统计。本文以个人资料为例，不涉及公司文件。所有数字都应写成计划或实际观察结果，不能把估算包装成已经验证能保留多少个月。
du -sk ./personal-sample-s 汇总，-k 以 1024 字节单位估计分配空间；用于容量预算，不代表逻辑大小或压缩后备份大小。 示意：10240 ./personal-sample，约 10 MiB 分配空间。 权限拒绝、占位云文件会使估算不完整；大目录查询会读元数据，不能只按此数值承诺保留天数。
快照、RAID 与异机备份承担不同任务
RAID 提供的是部分磁盘故障场景下的冗余，不能恢复所有误删和加密破坏。位于同一 NAS 的快照便于快速找回历史，但整机损坏、存储池故障或设备丢失时可能一起不可用；所以快照不等于异机备份。复制到另一设备也还要考虑账号权限和位置是否独立，避免同一组凭据能同时毁掉源与所有备份。
Snapshot Replication 的共享文件夹快照依赖受支持机型与 Btrfs 卷，不能把 ext4 卷直接当成支持；LUN 等对象要另外查对应功能前提。Hyper Backup 的支持范围不同，应按任务向导与机型文档核对，不用“有 Btrfs”推导所有功能都可用。容量查询仅帮助交叉核对，具体快照、仓库和配额占用应看各自管理界面。
df -h /Volumes/BackupCheck只读查询已确认挂载路径；-h 易读显示共享端返回的容量信息。 示意：Capacity 70%；它可能反映服务端卷或用户配额视图。 共享未挂载时先回 Finder 确认，不能在同名本地目录继续备份；以 DSM 任务与配额界面交叉核对。
修改轮换设置就是接受历史版本可能被删除
在 Hyper Backup 选择目标任务，进入任务设置中的轮换或版本保留页面，先查看当前模式、版本列表和最早可恢复时间，再评估要改什么。按最早版本淘汰、Smart Recycle 与自定义保留规则有不同选择逻辑，不能只根据名称猜行为。界面位置因版本而异，找不到时使用该版本帮助入口，不改内部数据库或配置文件。
降低版本上限、缩短保留窗口或手动删除版本，都可能不可逆地移除恢复点。删除完成后不能通过再调大上限把历史变回来。修改前应记录旧策略，确认关键里程碑是否已有独立导出并恢复验收；锁定版本是否适用也要在当前任务界面核对。本文不提供一键清理动作，审核策略的重点是哪些日期会失去恢复能力，而不只是预计腾出多少空间。
mktemp -d ./restore-check.XXXXXX-d 新建唯一目录；用输出路径作为 Hyper Backup Explorer 导出目的地，避免覆盖现有文件。 示意：./restore-check.A1b2C3；实际名称随机生成，需在后续步骤使用实际路径。 创建失败检查当前目录写权限和空间；不要改到系统目录或沿用已含资料的恢复目录。
用变化率试算，再由实际统计修正
一个可讨论的个人示例是：每天备份，近期保留较密版本，较远日期按周或月保留；它只是设计目标，不是要求照填的精确规则。比如希望发现三周前的误删时仍能找回，就不能只保存最近七天。实际任务若连续失败，版本数还可能看起来很多，却已经缺少最近数据；需要同时关注最后成功时间和历史跨度。
容量预算至少考虑初始数据、持续变化的数据块、版本数量和恢复临时空间。每日变化量受大文件反复改写、重命名、压缩方式影响，不能简单用源大小乘版本数。先观察一段代表性使用周期，在 Hyper Backup 的统计与版本列表核对增长，再修正计划。客户端 dry-run 只能比较普通样本目录，不用于估算 .hbk 内部空间或替代官方统计。
rsync -rnic -- ./personal-sample/ ./restore-check/-r 递归、-n dry-run、-i 显示变化、-c 依据内容校验比较；尾斜杠比较源的内容，不写目标。 示意：>f 表示源文件相对目标需要更新；无输出仅说明源侧选中文件无需更新。 没有 --delete，因此不报告目标多出的文件；-c 会完整读取内容。不得对运行中的备份仓库做目录级比较。
完整性检查与恢复演练都要安排
Hyper Backup 的完整性检查用于发现仓库相关问题，应通过任务界面安排在负载可接受的时间，并确认检查结果与覆盖情况。若出现 restore-only 或异常状态，先保存错误、保护现有仓库并按官方恢复路径处理，不在备份目标内部手工删除文件。任务显示成功、仓库检查通过和某个历史版本可实际恢复，是三个需要分别记录的结论。
恢复演练挑选近期与较早版本各一组样本，导出到新目录后比较内容，再核对必要的元数据。Mac 上看到的 UID 与权限不等价于 DSM 原生还原后的权限，所以面向 NAS 应用的恢复还需要独立环境检查。保留策略的价值只有在用户真的能选择需要的时间点并读出文件时才得到验证，不能只靠版本列表截图完成验收。
stat -f '%N | bytes=%z | mode=%Sp | uid=%u gid=%g' ./restore-check/notes.txt-f 为 BSD/macOS 格式，显示名称、字节数、权限、数字身份；便于与恢复前私人记录对照。 示意：bytes=128 | mode=-rw-------；仅展示格式，不是已测结果。 不能使用 GNU 的 -c；不同机器 UID 可不同，Mac 导出元数据也不能代替 DSM 原生权限恢复验收。
建立短小但能发现失效的复查周期
日常关注任务是否按期成功、失败通知是否到达以及目标是否在线；定期查看最早与最新恢复点是否仍满足目标。通知本身也可能配置失败，应通过受支持界面做一次验证。更换目标盘、调整配额、升级套件或改变保留策略后，重新做抽样恢复，而不是沿用几个月前的成功记录。记录应明确日期、任务、版本、样本和结果，避免泛泛写“正常”。
空间吃紧时先找增长原因与可替代内容，再讨论策略调整。应优先增加经过核对的目标容量或拆分不同需求，而不是急着删除最早版本。如果确实决定清理，先完成关键历史资料的独立恢复验收，并把将失去的时间范围写清楚。摘要只支持样本内容一致，不承诺整个仓库无误；最终策略要同时满足恢复窗口和可持续维护的工作量。
shasum -a 256 ./personal-sample/photo.jpg ./restore-check/photo.jpg-a 256 指定 SHA-256，比较两个本地样本的摘要；无需 NAS 管理权限。 示意：两行 64 位摘要相同，表示所读内容一致。 找不到文件检查导出位置；不能证明整库、权限或未来介质可靠。请只用个人无敏感样本。
把恢复需求写成三条可检验承诺
从一个个人资料场景开始：笔记每天修改，照片每月集中归档，大型临时视频随时可以重新生成。假设希望笔记最多丢失一天修改，误删在三周后发现仍可找回，某个年度归档节点需要额外长期保存。这是三个不同要求，分别对应执行频率、近期历史跨度和里程碑副本。单独填写三十个版本，并不能自动满足三项要求。
先准备当前任务范围、最近一段成功记录、目标可用容量与真实版本列表。再把每项需求翻译成验收问题：昨天的笔记在不在，三周前的笔记能否选到，年度节点是否有独立保存说明。计划尚未运行时，只能写“目标如此”，不能填“已覆盖”。如果错误通常在两个月后才被发现，应改变历史要求，而不是用三周样本成功替代它。
恢复时间也要留在策略表中。文件级恢复允许等半天，与希望一小时内继续使用，会影响是否需要本地快速恢复点和预先可用的恢复工具。长期备份可以保护内容，却不必然满足很短的恢复时间。把等待凭据、取回离线介质和下载时间计入预期，才能比较两种方案是否真正服务于同一个需求。
区间,恢复点数,每点新保留GB,小计GB
初始数据基线,不另计恢复点,300,300
近期日版,28,2,56
随后周版,8,6,48
更早月版,10,15,150
元数据与波动,1,40,40
合计预算,,,594
目标预算,,,800完整填写模板；数字与代号均为示意，未实机验证。阅读不改变系统；另存并填写记录属于 write。请将待填写项替换为自己的实际结果。
算清一份示意策略的版本与空间
考虑一种人为规划：最近二十八天每天一个，随后八周每周一个，再往前十个月每月一个。为了便于计算，这里把三个区间定义为互不重叠，总计四十六个计划恢复点。它是一张需求草图，不是声称某个软件只需填四十六就会产生完全相同的日期。执行缺口、时间边界与轮换选择都会影响最后留下的版本，必须以实际日期列表验收。
假设首次仓库占用三百GB，后续每个日区间需保留二GB新内容，周区间六GB，月区间十五GB，另为元数据及波动预留四十GB。保守相加为三百加五十六加四十八加一百五十加四十，得到五百九十四GB。若目标预算八百GB，理论余量二百零六GB。所有变化量都是示意假设，尚未测量压缩、去重或大文件改写效果。
这张算式比“源乘版本数”更能说明变量，但也不能准确预测仓库。一次重新编码一百GB视频，可能显著改变新数据量；同时，多版本共享数据可能使部分求和重复计入。因此先运行代表性的观察周期，按任务统计重新填入变化量，再看预算是否仍成立。恢复到本地另需四十GB空间时，那是恢复设备的预算，不能把它误当仓库内已经可用的空闲容量。
将纸面策略映射到软件并验证轮换
进入Hyper Backup，选择任务后打开设置中的轮换页面，先记录当前模式和上限。官方设置说明区分按最早版本删除、智能回收和自定义策略；智能回收按小时、日、周选择代表版本，不能把它描述成自动保存任意月度里程碑。若需要上述月度目标，先核对当前自定义规则的可表达范围，并在版本图或实际日期列表上验证。
提交配置会改变运行行为，是写操作；缩短历史并触发旧版本清理，则具有删除恢复点的后果，按danger看待。修改前挑选一个即将落入淘汰范围的样本，确认是否还有业务之外的个人长期保存需要；有的话先独立导出并验收。恢复旧设置只能恢复以后如何轮换，已经删除的历史不会重新出现。
可以用一个专门的小样本任务验证轮换理解。每天在说明里追加一条不同标记，按计划产生若干版本，再对照期望日期表。样本任务的结果用于验证规则解释，不能等比例推算整个资料库的空间。出现多个日期挤在一起时，先查是否都来自同一天的重复运行；目标是覆盖发现错误的窗口，而不是让版本数字看上去很多。
任务代号：RET-A（示意）
实际检查日期／时区：待填写
旧模式与上限：待读取
拟新模式与上限：待确认
最早／最近可恢复点：待读取
关键里程碑独立导出：待执行
抽样版本甲／内容标记／打开结果：待填写
抽样版本乙／内容标记／打开结果：待填写
预计淘汰区间：待确认
实际轮换后日期差异：待观察
失败分支与下一步：待填写完整填写模板；数字与代号均为示意，未实机验证。阅读不改变系统；另存并填写记录属于 write。请将待填写项替换为自己的实际结果。
区分增长异常、任务失败与历史缺失
症状是空间增长超过预算，原因可能是源新加入了大型媒体、重编码文件频繁变化，或当前尚未触发轮换。下一步查看任务范围、增长统计与版本数，先修正假设，再决定扩容或拆分资料组。不要在还不知道变化来自哪里时立即缩短所有历史。拆分任务也需要确认各自范围，避免两边都以为对方备份了某个目录。
症状是版本很多却没有昨天的数据，首先查最后成功时间和失败日志；历史数量不能补足最近缺口。症状是三周前版本消失，查上限、规则区间和任务建立时间；从未生成过的版本无法通过加大上限补回。症状是版本可见却无法导出，进入仓库读取或恢复路径排查，并保留现有仓库，不把它归类为单纯的保留设置问题。
每次复查应写出实际最早恢复点、最近成功点、被抽查的两个版本以及下一步。容量告警可以作为提前介入条件，但不能取代日期核对。结束本轮修改后，保留旧策略说明和变更原因，等新任务与恢复抽样都通过才关闭记录。如果尚未等到一个完整轮换周期，就明确标为等待观察，让下次检查继续这项工作。
性质：模拟范例，非真实执行结果
任务RET-A；目标28个日点+随后8个周点+更早10个月点
容量300+56+48+150+40=594GB；目标800GB，余206GB
输出restore-check/recent/和restore-check/older/
模拟结果：近期绿色封面，三周前蓝色封面，文本可打开
模拟故障：旧版很多却没有昨天版本→查最近失败→修复运行条件
回退边界：改回旧策略不能找回已删除历史
实际日期／完成版本／工具版本／耗时／结果：____完整模拟填写范例，用于说明结果和故障分支。复制后以真实信息替换，另存记录属于write。