灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载bup 是一款基于 git packfile 格式的高效备份系统依靠全局去重将每个数据块只存储一次因此任何一个数据块的损坏都可能同时影响所有备份集。bup fsck正是针对这一风险提供的仓库底层完整性校验与修复工具它检查.pack数据文件及其索引的完整性、定位文件损坏并借助par2生成与使用恢复块recovery blocks自动修复被损坏的数据。读完本文你将掌握bup fsck的完整命令用法、par2恢复机制的底层原理、与bup validate-refs等高层校验工具的分工以及如何用bup damage模拟磁盘损坏来验证备份系统的自愈能力。命令概览SYNOPSISbup fsck的完整调用形式为bup fsck [-r] [-g] [-v] [--quick] [-j jobs] [--par2-ok] [--disable-par2] [packfile...]当指定了packfile参数必须以.pack结尾时pack 相关的操作只针对这些文件不指定任何 packfile 时则检查当前仓库$BUP_DIR默认~/.bup中objects/pack/目录下的所有packfile。它检查什么数据损坏corruption而非连通性connectivitybup fsck的职责边界非常明确。它当前只校验仓库中数据层面的完整性——即objects/pack/下的数据 packfile 及其对应的.idx索引是否与写入时一致、是否发生了位翻转或扇区错误等损坏。它不检查更高层的连通性问题例如某个 save 引用的对象是否真的存在于仓库中。对于这类缺对象问题官方文档明确指向另外两个工具bup validate-refs见 Documentation/bup-validate-refs.1.md检查分支备份集可达范围内的 commit/tree 是否引用缺失对象以及 bupm 元数据文件是否损坏bup validate-object-links进一步校验对象之间的链接完整性。这一分工背后有明确的工程考量bup fsck处理的文件损坏通常由磁盘硬件故障坏扇区、位翻转引起发生概率较高但可通过冗余数据修复而连通性缺失更可能是希望是少见的软件 bug 导致属于另一类问题。两者都是备份可靠性保障的一部分但工具不同、修复手段也不同。校验的两种模式git verify-pack 与 --quick当检查 packfile 和索引时bup fsck默认依赖git verify-packgit 自带的 pack 校验命令做完整校验。若指定--quick则跳过完整的git verify-pack改为由 bup 自己直接校验 packfile 与.idx文件末尾的 SHA-1 校验和。从源码 lib/bup/cmd/fsck.py 的git_verify()实现可以看到两种路径完整模式执行git verify-pack -- stem失败即记录git verify-pack failed并返回失败quick 模式对stem.idx和stem.pack两个文件读取文件末尾 20 字节的 SHA-1trailing再对文件剩余部分重新计算 SHA-1actual两者不一致即判定损坏。相关逻辑见trailing_and_actual_checksum()lib/bup/cmd/fsck.py。--quick能带来显著的速度提升而可靠性几乎不受影响因此非常适合日常巡检但如果你比较多疑也可以坚持用完整模式。注意对于已经带恢复信息par2 恢复块的 pack--quick不生效见下文验证优先于恢复数据。为什么去重备份系统必须校验一损俱损的块在普通备份系统中损坏的块影响有限——因为备份集之间有大量重复数据一个备份集损坏通常无伤大雅。但在 bup 这样的去重备份系统中同一个块即使被每一次备份使用也只会被存储一次这正是全局去重的意义包括对虚拟机镜像等内部重复数据的去重。如果该块损坏且不可恢复那么所有备份集会同时受损。因此bup fsck的意义不仅是发现问题更是提供一条在磁盘错误发生后恢复备份数据的路径。当然官方文档也给出了明确警告bup fsck显然无法从完整的磁盘故障整个盘报废中恢复数据。如果备份重要必须认真考虑冗余方案——例如用 RAID 实现多盘冗余或做异地备份off-site backups实现站点级冗余。基于 par2 的恢复机制原理与源码实现要让 fsck 具备修复能力需要两个条件系统安装了par2命令行工具par2cmdline通过--generate为 packfile 预先生成 par2 恢复块。恢复块允许从损坏中恢复最多5%的.pack文件内容。其数学原理是 Reed-Solomon 类纠删码在生成时额外保存冗余数据校验时用这些冗余数据重建被破坏的原始字节。运行时探测 par2par2_setup每次运行 fsck 时程序都会先探测系统上是否存在可用的par2lib/bup/cmd/fsck.py执行par2 --help若命令不存在或返回码非 0则输出警告并禁用所有恢复功能--disable-par2选项则强制模拟未安装 par2的场景忽略所有已存在的恢复块。生成恢复块par2_generatebup fsck -g会为每个缺少恢复块的 pack 调用 par2 的create动作。源码 lib/bup/cmd/fsck.py 揭示了几个值得注意的实现细节par2 在中断如 Ctrl-C时可能留下空文件因此 bup 会在 pack 所在目录的临时子目录中生成恢复块成功后再rename回原目录避免生成过程被打断时产生损坏的残留文件生成时使用-c200参数即最多允许 200 个损坏块实际块大小由 par2 根据输入动态计算生成后目录中应出现两个文件pack-HASH.par2索引与pack-HASH.vol000200.par2恢复块卷文件任何意外产物都会被记录并上报Unexpected par2 file (please report)。校验恢复文件状态par2_recovery_file_statusfsck 会检查恢复文件是否完整、非空lib/bup/cmd/fsck.py若pack-HASH.par2或pack-HASH.vol000200.par2缺失或为空文件则判定该 pack 的恢复数据不可用并输出error: empty par2 file - .../error: missing par2 file - ...。这正是 test/ext/test-fsck 中 fsck rejects empty par2 index files / vol files 测试所覆盖的场景——故意把恢复文件清空确认 fsck 会拒绝并报错。修复流程attempt_repair当--repair被请求时attempt_repair()lib/bup/cmd/fsck.py的执行顺序是先用git_verify受--quick影响确认 pack 是否真的损坏若完好则直接报ok损坏且没有恢复数据 → 输出has no recovery data失败有恢复数据 → 调用par2 repair尝试修复修复成功后重新校验.idx索引如果索引的末尾校验和不匹配直接删除该.idx文件并执行git index-pack从已修复的.pack重新生成索引。最后一步非常关键既然.idx完全可以从.pack重新生成bup 就不再为.idx生成恢复信息把所有恢复块都用在保护 packfile 本身上这一行为变更记录在 note/main.md。注释也说明历史上 bup 曾把.idx纳入恢复信息当前实现特意保持了向后兼容性。验证优先于恢复数据do_pack 的逻辑在 verify 模式下bup fsck不带-r/-g逻辑是git 校验必须通过且若存在恢复数据par2 校验也必须通过lib/bup/cmd/fsck.py。换句话说par2 verify只证明 pack 自生成恢复块以来没有变化——如果 pack 在生成恢复块之前就已损坏par2 校验会失败。这就是文档所说--quick对已带恢复信息的 pack 无效的原因对这类 packfsck 总会额外跑 par2 校验以确保恢复数据本身与原始数据一致。并行校验--jobs-j/--jobsnumjobs控制同时运行的 pack 校验数量。从源码看lib/bup/cmd/fsck.py多任务通过os.fork()实现每个子进程处理一个 pack父进程用os.wait()收割并合并各进程退出码。文档特别提醒并行数不是越大越好——如果同时读太多 pack磁盘会因在文件间反复寻道而饱和性能反而下降即使numjobs小于 CPU 核心数也是如此。建议结合实际磁盘吞吐量实验确定最优值。完整参数说明OPTIONS参数说明-r, --repair使用已存在的恢复块尝试修复损坏的 pack。需要par2。-g, --generate为没有恢复块的 pack 生成恢复块。需要par2。-v, --verbose增加输出详细程度可多次使用-vv、-vvv等。--quick不跑完整的git verify-pack仅检查 pack 与.idx末尾的最终校验和显著提速。对已有恢复信息的 pack 无效果。-j, --jobsnumjobs同时运行的 pack 校验任务数上限。过多会导致磁盘寻道饱和性能下降。--par2-ok仅探测 par2 是否安装且可用可用返回 0不可用返回 1。不做任何实际检查且与其它选项互斥lib/bup/cmd/fsck.py 中其它选项会直接fatal。--disable-par2强制忽略已安装的 par2 和所有恢复块。packfile...可选指定要处理的.pack文件必须以此结尾见 lib/bup/cmd/fsck.py。省略时处理仓库内全部 pack。两个细节值得强调传入的 packfile 参数必须以.pack结尾否则 fsck 会直接报错退出--par2-ok的行为类似grep/test用退出码 1 表达预期中的否定结果因此适合直接用在脚本的条件判断里。退出状态EXIT STATUS与脚本编写bup fsck的退出码约定参考 lib/bup/helpers.py 的常量定义1当且仅当--repair被请求、确实需要修复、修复成功、且没有其它错误时返回 10没有任何错误其它非零值发生了错误如EXIT_FAILURE 2。这个设计刻意让修复成功与grep 找到匹配一样用状态 1 表达一种预期中可能出现的结果源码注释对此有明确说明。note/main.md 也确认--repair承诺只要需要修复、修复成功且无其它错误就以状态 1 退出。因此脚本逻辑可以写作bup fsck -r rc$? if [ $rc -eq 1 ]; then echo fsck 完成了修复 elif [ $rc -eq 0 ]; then echo 仓库一切正常 else echo fsck 遇到错误例如 par2 修复失败 fi这一约定在 test/ext/test-fsck 中被严格验证测试先人为损坏 pack 再运行bup fsck --quick -rvv -j9断言退出码为 1WVPASSEQ 1 $?。实战示例EXAMPLES为所有 pack 生成恢复块bup fsck -g为特定 pack 生成恢复块bup fsck -g ~/.bup/objects/pack/153a1420cb1c8*.pack检查所有 pack 的正确性可能非常慢bup fsck日常巡检建议搭配--quick加速bup fsck --quick检查并修复所有损坏的 packbup fsck -r检查并修复特定 packbup fsck -r ~/.bup/objects/pack/153a1420cb1c8*.pack在脚本中探测 par2 是否可用if bup fsck --par2-ok; then echo par2 is ok fi模拟损坏与验证自愈bup damage bup fsck 的测试闭环如何确认 fsck 的修复能力真的有效bup 提供了配套工具bup damage见 Documentation/bup-damage.1.md用于故意随机破坏.pack或.idx文件中的块模拟真实磁盘损坏。文档对它的警告同样醒目THIS PROGRAM IS EXTREMELY DANGEROUS AND WILL DESTROY YOUR DATA——它只应在测试仓库上使用。典型的自愈演练流程来自 bup-damage 文档的示例# 1. 先备份 pack防止演练搞砸一切 cp -pPR ~/.bup/objects/pack ~/bup-packs.bak # 2. 为所有 pack 生成恢复块 bup fsck -g # 3. 故意损坏 pack 和 idx-n 10 个块、每块 1 字节、固定随机种子 bup damage -n 10 -s 1 -S 0 ~/.bup/objects/pack/*.{pack,idx} # 4. 检查应发现损坏此时预期失败 bup fsck --quick # 5. 用恢复块修复 bup fsck -rbup damage的关键参数详见其文档-n, --numnumblocks每个文件损坏的块数默认 10-s, --sizemaxblocksize每个损坏块的最大字节数默认 1除非指定--percent。多字节块可能横跨两个恢复块边界小文件中单块还可能大于恢复块因此默认的 1 字节最安全--percentmaxblockpercent损坏块最大尺寸占原文件百分比与--size同时给出时取两者较小值-S, --seedrandomseed固定随机种子保证测试可复现--equal在文件中等距分布损坏块从偏移 0 开始配合合适块大小可保证每块只损坏一个恢复块。需要留意bup damage的当前行为是概率性的——给定字节有 1/256 的概率实际未被改变且多个损坏段可能落入同一恢复块因此--equal或-s 1更利于精确控制。仓库自带的端到端测试 test/ext/test-fsck 完整复现了这一闭环可作为可复现的验证参考它bup init一个临时仓库、多次bup save生成数据然后依次验证无损坏时bup fsck/bup fsck --quick均通过bup damage破坏.idx后bup fsck --quick失败WVFAIL有 par2 时bup fsck -r修复索引并返回 1WVEXPRC 1 bup fsck -r破坏.pack后bup fsck --quick失败bup fsck --quick -rvv -j9修复成功且退出码为 1空 par2 文件会被拒绝fsck rejects empty par2 index files / vol files损坏过重600 个等距字节超出-c200的恢复能力时bup fsck -r返回非 0/1 的其他错误码WVEXPRC [!01]——这印证了文档中最多恢复 5%的限制检测孤儿 pack 相关文件见下节。孤儿 pack 相关文件报告stray pack-related files当不带参数检查整个仓库时bup fsck会额外报告一类问题看起来与某个 pack 相关、但对应.pack已不存在的残留文件。产生原因在文档中说明得很直接旧版本的bup gc删除 pack 时不会删除所有关联文件从而留下遗留物。现在bup gc已修正为删除pack-HASH.*的所有相关文件note/main.md同时bup fsck会在全仓库扫描时报告此类残留。源码 lib/bup/cmd/fsck.py 的实现逻辑是先用正则pack-([a-f0-9]{40})\.pack$收集现存 pack 的 SHA-1 集合再扫描objects/pack/pack-*下所有文件凡是以pack-40HEX开头、但 SHA-1 不在现存集合中的输出No pack file for 文件名。测试 test/ext/test-fsck 的 fsck detects orphaned pack-related files 一节用touch伪造了pack_stem、pack_stem.、pack_stem.lingering三个残留文件验证bup fsck会逐一报告它们。与高层校验工具的分工与配合bup fsck与bup validate-refs的关系值得再次强调bup fsck关注物理层的数据完整性与文件损坏检测/修复是位坏了能救回来的手段bup validate-refsDocumentation/bup-validate-refs.1.md关注逻辑层的引用完整性检查 ref分支/保存点可达范围内是否存在指向缺失对象的 commit/tree以及 bupm 元数据文件是否有缺失的路径条目可能是 bup 0.25 至 0.30.1 之间某些版本造成的问题。其--links检查比完整restore/join快得多发现的问题可配合bup get --repair处理。一个完整的仓库健康检查流程因此是分层的# 1. 物理层检查并修复数据损坏 bup fsck -r # 2. 逻辑层检查引用完整性与元数据 bup validate-refs从当前 bup 版本起参考 note/main.mdfsck 还引入了若干行为约定--repair以退出码 1 表示修复成功--quick现在同时检查 packfile 与索引此前只检查 packfile--generate/--repair在没有合适 par2 时立即报错退出此前--generate只是打印 skipped且 fsck 只接受*.pack参数、不再为.idx生成恢复信息。总结与最佳实践围绕bup fsck形成一套可靠的备份自愈流程核心要点如下首次启用执行bup fsck -g为所有 pack 生成 par2 恢复块需安装 par2cmdline此后新产生的 pack 也需定期-g补齐定期巡检用bup fsck --quick做快速完整性检查怀疑异常时再用不带--quick的完整模式或bup validate-refs深入排查发现损坏用bup fsck -r修复并以退出码区分正常0/ 已修复1/ 出错其它非零演练验证在测试仓库上用bup damage -n 10 -s 1 -S 0bup fsck -r验证自愈能力参考 test/ext/test-fsck 的完整流程牢记边界par2 恢复上限约为 pack 文件 5% 的损坏量对应-c200的恢复块配置完整磁盘故障必须靠 RAID、异地备份等冗余方案兜底。参考文档Documentation/bup-fsck.1.md本文核心依据的官方手册页Documentation/bup-damage.1.mdbup damage损坏模拟工具手册Documentation/bup-validate-refs.1.md高层引用完整性校验手册lib/bup/cmd/fsck.pyfsck 的核心实现par2 集成、quick 校验、修复流程、并行调度test/ext/test-fsckfsck 的端到端集成测试损坏模拟 修复验证 残留文件检测note/main.md当前版本中 fsck 相关行为变更说明。赞分享灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载相关推荐CPM.cmake快速入门指南10分钟学会现代化C依赖管理CPM.cmake快速入门指南10分钟学会现代化C依赖管理 CPM.cmake是一个跨平台的CMake脚本为CMake添加了强大的依赖管理功能。它作为CCitra 3DS模拟器终极指南如何在电脑上免费畅玩任天堂3DS游戏Citra 3DS模拟器终极指南如何在电脑上免费畅玩任天堂3DS游戏 想要在电脑上重温《精灵宝可梦》系列、《塞尔达传说》等经典任天堂3DS游戏吗Citra模终极指南Audiobookshelf音频文件修复与恢复完整解决方案终极指南Audiobookshelf音频文件修复与恢复完整解决方案 Audiobookshelf作为一款强大的自托管音频书和播客服务器让用户能够轻松管理和享后端音视频前端上一篇kkFileView前端状态管理Redux Toolkit实践指南下一篇OrcaSlicer自定义填充全攻略SVG导入到G代码一键生成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考