灾备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 格式的高效备份系统本篇文章以官方note/0.30-from-0.29.3.md发布说明为核心骨架逐一解析 bup 0.30 相较于 0.29.3 的行为变更、新命令bup get、远程restore/ls、VFS 重写、Bug 修复与构建系统调整并结合仓库源码与手册佐证底层实现。读完本文你将掌握 bup 0.30 新增的跨仓库数据搬运与重写能力、时间戳同名的零填充命名规则、prune-older保留策略反转等关键行为以及升级前需要注意的兼容性事项。升级前须知May require attentionbup 0.30 引入了若干可能影响既有工作流的行为变更升级后需要留意。最低 git 版本提升至 1.5.60.30 起bup 运行时要求的最低git版本为 1.5.6。这意味着较旧的 git 将不再被支持升级 bup 前应确认系统中 git 版本满足要求。prune-older 保留策略反转从保留最旧改为保留最新此前bup prune-older在每个时间段分组day、week、month 等内保留最旧的一次保存0.30 改为保留每个分组内最新的一次保存。对应源码实现位于 lib/bup/cmd/prune_older.py其中retain_newest_in_region与“keep the newest save”的语义相吻合同时新增的keep-dailies-for、keep-monthlies-for、keep-yearlies-for等选项也都明确描述为“retain thenewestsave per day/month/year”。该策略反转意味着使用bup prune-older定期清理旧保存时每个时间窗口内保留的是最近一次快照更符合“随时可回滚到最近状态”的直觉依赖旧行为保留窗口内最旧保存的脚本需要重新评估清理结果。同名时间戳保存零填充后缀与反向序号bup现在会对时间戳相同的保存名添加零填充后缀例如1970-01-01-214640-07以避免重名。序号目前表示该保存在默认git rev-list顺序中的反向位置因此给定/foo/1970-01-01-214640-09 /foo/1970-01-01-214640-10在正常情况下-10是紧随-09之后创建的保存且-09是-10的唯一父提交。换句话说序号越大通常对应创建时间越晚。该命名规则影响所有依赖bup ls输出或按保存名定位数据的脚本例如bup restore branch/1970-01-01-214640-07/...时需要精确使用带后缀的名字。Python 版本限制拒绝 Python 3bup 0.30 尚不兼容 Python 3若检测到 Python 主版本不是 2将拒绝运行除非设置环境变量BUP_ALLOW_UNEXPECTED_PYTHON_VERSIONtrue该变量在 note/0.30-from-0.29.3.md 中有说明主要用于开发与测试场景。在 Python 3 已成为主流的今天这一限制值得特别注意——生产环境应继续使用 Python 2 运行 bup 0.30或等待后续支持 Python 3 的版本例如仓库 note/main.md 中已提到后续版本将最低 Python 版本提升至 3.8。bup ls -s 输出树哈希bup ls -s现在为提交报告树tree哈希除非同时指定--commit-hash。这改变了ls -s输出列的含义依赖哈希输出的脚本需要相应调整。新命令与远程能力General0.30 是远程操作能力大幅增强的版本新增了bup get命令并让restore、ls直接支持远程仓库。bup get跨仓库传输与重写实验性务必谨慎bup get是 0.30 新增的命令用于在本地或远程仓库之间传输或重写数据。它可以把远程保存追加到本地分支由此天然支持仓库合并merge repositories以--rewrite方式按目标仓库配置如bup.split.files、bup.split.trees重新切分数据以--repair方式在传输过程中检测并修复已知问题如用合成的 “repair files” 替换内容缺失的路径。官方手册 Documentation/man1/bup-get.1.md 给出了完整的方法列表--ff、--append、--pick、--force-pick、--new-tag、--replace、--unnamed各方法均支持带冒号的METHOD: ref dest变体以指定目标引用。典型用法# 将 src-repo 的 archives 分支快进到本地仓库 $ bup get -s src-repo --ff archives # 把 archives 的某个特定保存追加为 pruned-archives 分支的新提交 $ bup get -s src-repo --pick: archives/2013-01-01-030405 pruned-archives # 从远程主机拉取 $ bup on remotehost get --ff archives # 推送本地分支到远程 $ bup get -r remotehost: --ff archives # 用远程仓库的 bup.split.* 配置重写重新切分archives 分支 $ git --git-dir $BUP_DIR config bup.split.trees true $ git --git-dir $BUP_DIR config bup.split.files legacy:16 $ bup get --rewrite --append: archives archives-resplit # 修复单个保存 $ bup get --repair --pick archives/latest fixed重要警告bup get是极少数能“有意地”以破坏性方式修改数据的命令之一危险性远高于大多数 bup 命令。手册中特别提醒如果重写/修复后你仍关心的数据可以成功 join 或 restore那才是有说服力的成功信号仓库内的 dev/compare-trees 可用于对比操作前后结果。建议在验证无误之前不要删除原始数据。restore 与 ls 支持远程仓库bup restore -r host:path ...可直接从远程仓库恢复数据详见 Documentation/man1/bup-restore.1.md。在 lib/bup/cmd/restore.py 的命令行规范中可以看到-r, remote remote repository path选项的定义。bup ls -r host:path ...可报告远程仓库信息详见 Documentation/man1/bup-ls.1.md。VFS 重写更易支持远程、降低内存占用支撑restore、ls、fuse等命令的 VFS虚拟文件系统在 0.30 中被重写目标是让远程仓库访问更简单在某些场景例如 bup fuse降低内存占用为将来实现更有选择性的缓存打下基础。目前数据达到阈值后只是被随机驱逐evict。从 lib/bup/vfs.py 的resolve实现可以看出当仓库为远程时repo.is_remote()路径解析会重定向到更高效的远程版本repo.resolve(...)印证了 VFS 重写对远程访问的直接支撑。其他常规改进bup现在会尊重 git 的pack.packSizeLimit设置来写 packfile当前仅当该选项直接设置在远程仓库时才会影响远程仓库。bup save为所有链接和普通文件存储 size 信息对新格式保存的目录获取大文件大小会更便宜可能改善bup ls -l、find /some/fuse/dir -ls等命令的性能。bup split新增--noop --blobs|--tree选项打印结果 id 但不把数据存入仓库。在 lib/bup/cmd/split.py 中可以看到noop与--copy被归为同一类“不需要仓库写入”的操作writing not (opt.noop or opt.copy)并且--noop/--copy与-c、-n互斥。Bug 修复Bugs0.30 修复了一批影响稳定性、可移植性与兼容性的问题子进程输出处理bup对子进程诊断、进度等输出的处理方式已调整降低主进程退出例如按 C-c / SIGINT后 bup 仍继续运行的可能性。远程仓库压缩级别现在向远程仓库写入时会正确遵循指定的压缩级别。FIFO 创建方式bup restore改用mkfifo而不是mknod创建 FIFO更可移植此前至少在部分 NetBSD 版本上有问题。mergetag 头遇到带mergetag头的提交不再崩溃目前只是忽略当bup通过rm、prune-older、get重写提交时这些头会被丢弃。bloom 进度输出进度消息改为以\r而非\n结尾避免退出时留下多余输出行。split --bench 输出补上了缺失的空格。Python 兼容性修复了多种 Python 版本兼容问题包括 Python 3 引入的部分不兼容点。平台问题修复了 WSL 上的 mincore 问题以及一些 Android 构建不兼容问题。构建系统与测试改进Build system测试与构建系统在 0.30 也有一轮清理测试不再假设pwd位于/bin。测试对 locale 的敏感度降低。test-meta不再尝试对文件执行chattr TT仅对目录有效较新的 Linux 内核会拒绝该操作至少自 4.12 起可能 4.10 起。test-rm在较新 git 自动创建 packed-refs 时不再失败。test-sparse-files在容器内运行时更不易失败。test-index-check-device与test-xdev改为使用各自独立的 loopback 挂载文件此前两者挂载同一镜像两次可能产生相同的设备号。致谢与升级建议0.30 版本感谢了 Alexander Barton、Artem Leshchev、Ben Kelly、Fabian xx4h Melters、Greg Troxel、Jamie Wyrick、Julien Goodwin、Mateusz Konieczny、Nathaniel Filardo、Patrick Rouleau、Paul Kronenwetter、Rob Browning、Robert Evans、Tim Riemenschneider 与 bedhanger 等贡献者。综合来看升级到 0.30 前建议完成以下核查确认git 1.5.6确认 Python 运行环境为 Python 2或为测试目的设置BUP_ALLOW_UNEXPECTED_PYTHON_VERSIONtrue复核依赖保存名解析与prune-older保留策略的自动化脚本如使用ls -s输出哈希注意其语义变为树哈希。若计划尝试bup get务必先在小仓库中演练--ff/--append/--rewrite并利用 dev/compare-trees 对比前后数据确认无误后再作用于正式备份。延伸阅读官方发布说明原文note/0.30-from-0.29.3.mdbup get完整手册方法、选项、REPAIRS、示例Documentation/man1/bup-get.1.mdbup restore手册Documentation/man1/bup-restore.1.mdbup ls手册Documentation/man1/bup-ls.1.mdbup split实现lib/bup/cmd/split.pybup prune-older实现lib/bup/cmd/prune_older.pyVFS 实现lib/bup/vfs.py后续版本变更含 Python 3 支持路线note/main.md赞分享灾备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 0.33.4 版本要点解析fsck 恢复数据可靠性加固、bup on 远程标准输入修复与配置系统变更bup 0.33.4 版本要点解析fsck 恢复数据可靠性加固、bup on 远程标准输入修复与配置系统变更 本篇技术指南聚焦 bup基于 git pack灾备CLI存储bup get 全指南仓库间引用传输、重写rewrite与修复repair实战详解bup get 全指南仓库间引用传输、重写rewrite与修复repair实战详解 导读本文以 bup 仓库中的官方手册 Documentation灾备CLI存储使用 Go 泛型从 map 中按值反查键深入解析 lo.FindKey 与 FindKeyBy使用 Go 泛型从 map 中按值反查键深入解析 lo.FindKey 与 FindKeyBy 导读 在基于 Go 1.18 泛型实现的 Lodash 风格灾备CLI存储上一篇猫抓cat-catch资源嗅探扩展从安装到M3U8合并下载的4个任务下一篇dhtcrawler2 vs dhtcrawler为什么选择这个革命性的P2P爬虫升级版创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考