尧图网页设计 
灾备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 格式的高效备份系统支持快速增量保存与全局去重。与 git 一致bup 的全部运行参数都通过git config体系存放在仓库的config文件中本文围绕 bup-config(5) 手册页逐项讲解bup.repo.id、bup.server.deduplicate-writes、bup.split.files、bup.split.trees、压缩级别与 pack 大小限制等核心配置并延伸说明BUP_DIR、XDG_CACHE_HOME等环境变量与缓存文件。读完本文你将能正确地初始化、迁移、调优 bup 仓库并理解每个配置项背后的源码实现。配置机制一切皆在 git config 中bup 不维护自己的配置语法而是直接复用 git 的配置体系。所有配置项都写在仓库的config文件中通过git config命令读写。手册给出的标准写法是git --git-dir$BUP_DIR config bup.split.trees true即先通过--git-dir显式指向 bup 仓库目录默认由BUP_DIR环境变量决定未设置时默认~/.bup再用config子命令设置具体选项。读取配置则不带参数执行git --git-dir$BUP_DIR config 选项。从源码结构看bup 在运行时通过各处的config_get()统一读取这些选项。例如 lib/bup/hashsplit.py 中configuration()函数负责把bup.split.trees布尔型和bup.split.files字符串型解析成分块参数表并把该表作为仓库元数据在协议层传递见 lib/bup/protocol.py 中列出的受支持配置键。这保证了客户端与服务端在分块、压缩等行为上严格一致。bup.repo.id仓库的唯一标识符作用与取值约束bup.repo.id是为仓库设置的一个跨仓库唯一标识符。由于它当前会被用作文件系统路径的一部分因此只能包含以下字符0123456789_ ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz同时两个仓库的 id 不能只存在大小写差异如something与SOMETHING除非所有相关文件系统都区分大小写否则会引发路径冲突。自动生成与刷新手册明确指出bup init在创建新仓库、或刷新一个尚无bup.repo.id的既有仓库时会自动写入一个随机标识。因此对旧仓库重新执行一次bup init即可补齐该配置。如果你希望自行指定 id建议包含随机内容以保证唯一性。源码印证了这一行为在 lib/bup/git.py 的init_repo()中当以刷新方式打开已存在的仓库refresh为真时仅当get_config(bbup.repo.id)返回None才写入新 id而全新初始化refresh为假时则无条件写入。随机 id 由 lib/bup/helpers.py 的make_repo_id()生成它用SystemRandom从 36 个字符小写字母加数字中随机抽取 31 位组成形如a1b2c3...的标识。客户端侧lib/bup/client.py 会通过config_get(bbup.repo.id)读取该值用于远程仓库缓存数据的定位与区分。复制仓库后必须更换 id手册给出了一条重要运维准则凡是复制出来的仓库本地cp或跨主机rsync都必须更换bup.repo.id。重复的标识至少会引发显著的性能问题。更换方法很简单git --git-dir$BUP_DIR config bup.repo.id 新的唯一随机串bup.server.deduplicate-writes服务器端写前去重默认值true。两种工作模式true默认bup-server对每个传入对象先查询本地索引若对象已存在服务器会建议客户端下载该对象所在的*.idx文件从而避免重复发送数据。false服务器不在写入前查询本地索引而是在会话开始时就让客户端一次性下载其全部*.idx文件由客户端自行避免重复写入。该模式适用于资源受限的服务器硬件如路由器、慢速 NAS。与 dumb-server-mode 标记文件的联动手册规定若bup.server.deduplicate-writes未被设置且存在$BUP_DIR/dumb-server-mode文件则 bup 视同该配置为false。从源码实现看lib/bup/repo/local.py 在读取该选项时会检查仓库目录下的bup-dumb-server标记文件若该文件存在且配置显式为true直接抛出ConfigError两者互相矛盾若标记文件存在而配置未设置或为false则按false处理。源码级行为差异在 lib/bup/repo/local.py 中当服务器端读取到该选项为false时会强制run_midxFalse不生成 midx 索引合并文件且_deduplicate_writesFalse而选项为true或未设置时则默认生成 midx 并在allow_duplicates未显式开启时执行写前去重。协议层 lib/bup/protocol.py 同样通过repo.config_get()读取该布尔选项来决定会话交互策略。配置变更示例git --git-dir$BUP_DIR config bup.server.deduplicate-writes false # 低配服务器 git --git-dir$BUP_DIR config bup.server.deduplicate-writes true # 恢复默认bup.split.files去重分块粒度默认值legacy:13。取值规则该选项决定bup save、bup split等命令对数据进行分块的方式并直接控制去重的粒度。值必须是形如legacy:N的字符串其中整数N必须大于 12 且小于 22。源码 lib/bup/hashsplit.py 用正则legacy:(13|14|15|16|17|18|19|20|21)做严格校验非法值会触发ConfigError见 lib/bup/hashsplit.py。N 的含义与权衡N是哈希分块算法中用于产生块边界的固定位数这些位全部为 1 时即产生一个块边界因此它直接决定了去重对象的平均大小期望的平均块大小为2^N即1 N字节最大块大小为平均值的 4 倍文件中足够小的一处改动最多只会带来大约2^N字节的新数据外加树元数据。这是一个经典权衡位数越少去重粒度越细、去重效率越高位数越多对象越少磁盘上的元数据占用与仓库操作期间的 RAM 消耗越低。手册指出对许多现有仓库而言legacy:13可能偏小每提升 1 位大致能将许多操作的 RAM 需求减半但也会因暴露更少的去重潜力而使仓库体积有所增加——具体效果取决于仓库中数据的文件大小与去重率。若时间和空间允许可以用bup get --rewrite将同一份数据以不同配置重写到新仓库实测对比后再定值相关回归测试可参考 test/ext/test-get-repair-bupm 与 test/ext/test-get-rewrite-missing。两条必须注意的警告已有数据的仓库不要随意改值更改该值会改变分块边界导致后续保存无法对已有数据去重数据会被再次完整存储一遍。不同配置的仓库不要共用同一索引与下面bup.split.trees同理索引中的哈希优化将失效未修改的文件也会被bup save完全重读代价高昂。bup.split.trees目录树的拆分保存bup.split.trees是一个布尔选项默认未设置即关闭。设为true后bup 在写入仓库时会尝试对树目录进行拆分例如在bup save、bup gc等操作中。这对大型目录发生局部变化的场景如体量庞大且持续活跃的 Maildir 邮件目录能显著减小新写入仓库的数据量。更多原理见仓库根目录的 DESIGN.md 中 Handling large directories 一节。为什么目录哈希会受其影响目录树的哈希允许 bup 在索引显示目录未变、且对应树对象已存在于目标仓库时跳过整棵目录的遍历。由于该选项的取值会改变可拆分目录树的哈希值索引中记录的哈希在上次保存时bup.split.trees取值不同的仓库中无法命中因此凡是受树拆分影响的通常很大的目录都必须重新读取并重算相关哈希。换言之用同一份索引向取值不同的仓库保存会降低性能。配置示例git --git-dir$BUP_DIR config bup.split.trees true压缩与打包core.compression、pack.compression、pack.packSizeLimit这三个选项继承自 git 的打包体系共同控制 pack 文件的压缩级别与体积上限。配置项默认行为说明core.compression若未设置bup 取 1注意git 的默认是 -1pack 文件的默认压缩级别命令行显式给出的压缩级别优先于它pack.compression未设置时回退到core.compression更细粒度的 pack 压缩级别pack.packSizeLimit1e9 字节约 0.93 GiB写入 pack 时的最大尺寸限制如bup save相关设置应在目标仓库可能为远端中进行源码实现印证了上述回退链在 lib/bup/repo/base.py 的_make_base()中压缩级别依次尝试pack.compression→core.compression→ 交由底层默认 1max_pack_size则读取pack.packSizeLimitopttypeint。手册还指出即使把pack.packSizeLimit设成如2g2 GiBpack 内所有对象仍可被 31 位偏移寻址idx 文件中无需大偏移记录。环境变量与缓存位置BUP_DIR设置后即成为默认仓库位置命令行bup -d 目录可临时覆盖它。从源码看lib/bup/path.py 的defaultrepo()优先返回BUP_DIR否则回退到~/.buplib/bup/main.py 会把-d指定的目录转成绝对路径并写入环境变量确保后续子进程不受chdir影响。例如BUP_DIR/srv/backup/bup bup init bup -d /srv/backup/bup index /homeXDG_CACHE_HOME/bup 与 index-cache$XDG_CACHE_HOME/bup/remote是首选缓存位置未设XDG_CACHE_HOME时回退到~/.cache/bup/remote而$BUP_DIR/index-cache是带优先级的备用位置。远程仓库的数据在bup save -r等操作期间存放在这些位置。查找逻辑lib/bup/path.py是按$XDG_CACHE_HOME/bup/remote、~/.cache/bup/remote、$BUP_DIR/index-cache的顺序查找既有数据若目标仓库的数据在任一位置均不存在则当$XDG_CACHE_HOME已设置时使用前者否则使用后者。配置实践小结初始化与迁移新仓库由bup init自动写入bup.repo.id复制仓库后务必手动更换该 id避免重复标识引发的性能问题。低配服务器在受限硬件上运行bup-server时可设bup.server.deduplicate-writes false或直接放置dumb-server-mode标记文件达到同等效果。大仓库调优结合数据实测谨慎提升bup.split.files的位数以降低 RAM 与元数据开销对含大型活跃目录的数据开启bup.split.trees。压缩与打包按需通过pack.compression/core.compression调整压缩级别用pack.packSizeLimit控制 pack 上限命令行参数优先级最高。改动前先评估bup.split.files与bup.split.trees的改变会影响既有数据的去重与索引哈希务必先在测试仓库中用bup get --rewrite验证。完整的配置项语义、环境变量与缓存文件说明可查阅 bup-config(5) 手册原文相关命令手册位于 Documentation 目录如 bup-server(1)、bup-save(1)。bup 是本项目所属的 Very efficient backup system基于 git packfile 格式的高效备份系统更多设计背景参见 DESIGN.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备份系统基于Git格式的高效增量备份解决方案Bup备份系统基于Git格式的高效增量备份解决方案 Bup是一个基于Git包文件格式的创新备份系统通过滚动校验和算法实现智能数据分块和全局去重解决了传统备灾备CLI存储BUP - 分布式备份系统BUP 分布式备份系统 BUP是一个基于git的分布式备份系统它可以帮助您轻松地保护您的数据安全并允许您在任何时候恢复您的文件。 什么是BUP BUP是基灾备CLI存储Mac Mouse Fix 用 3 类手势让普通鼠标达到触控板级体验Mac Mouse Fix 用 3 类手势让普通鼠标达到触控板级体验 在 Blender 里环绕视角、在浏览器里前后翻页普通鼠标在 macOS 上做不到这些。灾备CLI存储创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 bup-config：Bup 备份系统的 Git 风格配置指南（仓库标识、分块粒度与服务器去重）
灾备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 格式的高效备份系统支持快速增量保存与全局去重。与 git 一致bup 的全部运行参数都通过git config体系存放在仓库的config文件中本文围绕 bup-config(5) 手册页逐项讲解bup.repo.id、bup.server.deduplicate-writes、bup.split.files、bup.split.trees、压缩级别与 pack 大小限制等核心配置并延伸说明BUP_DIR、XDG_CACHE_HOME等环境变量与缓存文件。读完本文你将能正确地初始化、迁移、调优 bup 仓库并理解每个配置项背后的源码实现。配置机制一切皆在 git config 中bup 不维护自己的配置语法而是直接复用 git 的配置体系。所有配置项都写在仓库的config文件中通过git config命令读写。手册给出的标准写法是git --git-dir$BUP_DIR config bup.split.trees true即先通过--git-dir显式指向 bup 仓库目录默认由BUP_DIR环境变量决定未设置时默认~/.bup再用config子命令设置具体选项。读取配置则不带参数执行git --git-dir$BUP_DIR config 选项。从源码结构看bup 在运行时通过各处的config_get()统一读取这些选项。例如 lib/bup/hashsplit.py 中configuration()函数负责把bup.split.trees布尔型和bup.split.files字符串型解析成分块参数表并把该表作为仓库元数据在协议层传递见 lib/bup/protocol.py 中列出的受支持配置键。这保证了客户端与服务端在分块、压缩等行为上严格一致。bup.repo.id仓库的唯一标识符作用与取值约束bup.repo.id是为仓库设置的一个跨仓库唯一标识符。由于它当前会被用作文件系统路径的一部分因此只能包含以下字符0123456789_ ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz同时两个仓库的 id 不能只存在大小写差异如something与SOMETHING除非所有相关文件系统都区分大小写否则会引发路径冲突。自动生成与刷新手册明确指出bup init在创建新仓库、或刷新一个尚无bup.repo.id的既有仓库时会自动写入一个随机标识。因此对旧仓库重新执行一次bup init即可补齐该配置。如果你希望自行指定 id建议包含随机内容以保证唯一性。源码印证了这一行为在 lib/bup/git.py 的init_repo()中当以刷新方式打开已存在的仓库refresh为真时仅当get_config(bbup.repo.id)返回None才写入新 id而全新初始化refresh为假时则无条件写入。随机 id 由 lib/bup/helpers.py 的make_repo_id()生成它用SystemRandom从 36 个字符小写字母加数字中随机抽取 31 位组成形如a1b2c3...的标识。客户端侧lib/bup/client.py 会通过config_get(bbup.repo.id)读取该值用于远程仓库缓存数据的定位与区分。复制仓库后必须更换 id手册给出了一条重要运维准则凡是复制出来的仓库本地cp或跨主机rsync都必须更换bup.repo.id。重复的标识至少会引发显著的性能问题。更换方法很简单git --git-dir$BUP_DIR config bup.repo.id 新的唯一随机串bup.server.deduplicate-writes服务器端写前去重默认值true。两种工作模式true默认bup-server对每个传入对象先查询本地索引若对象已存在服务器会建议客户端下载该对象所在的*.idx文件从而避免重复发送数据。false服务器不在写入前查询本地索引而是在会话开始时就让客户端一次性下载其全部*.idx文件由客户端自行避免重复写入。该模式适用于资源受限的服务器硬件如路由器、慢速 NAS。与 dumb-server-mode 标记文件的联动手册规定若bup.server.deduplicate-writes未被设置且存在$BUP_DIR/dumb-server-mode文件则 bup 视同该配置为false。从源码实现看lib/bup/repo/local.py 在读取该选项时会检查仓库目录下的bup-dumb-server标记文件若该文件存在且配置显式为true直接抛出ConfigError两者互相矛盾若标记文件存在而配置未设置或为false则按false处理。源码级行为差异在 lib/bup/repo/local.py 中当服务器端读取到该选项为false时会强制run_midxFalse不生成 midx 索引合并文件且_deduplicate_writesFalse而选项为true或未设置时则默认生成 midx 并在allow_duplicates未显式开启时执行写前去重。协议层 lib/bup/protocol.py 同样通过repo.config_get()读取该布尔选项来决定会话交互策略。配置变更示例git --git-dir$BUP_DIR config bup.server.deduplicate-writes false # 低配服务器 git --git-dir$BUP_DIR config bup.server.deduplicate-writes true # 恢复默认bup.split.files去重分块粒度默认值legacy:13。取值规则该选项决定bup save、bup split等命令对数据进行分块的方式并直接控制去重的粒度。值必须是形如legacy:N的字符串其中整数N必须大于 12 且小于 22。源码 lib/bup/hashsplit.py 用正则legacy:(13|14|15|16|17|18|19|20|21)做严格校验非法值会触发ConfigError见 lib/bup/hashsplit.py。N 的含义与权衡N是哈希分块算法中用于产生块边界的固定位数这些位全部为 1 时即产生一个块边界因此它直接决定了去重对象的平均大小期望的平均块大小为2^N即1 N字节最大块大小为平均值的 4 倍文件中足够小的一处改动最多只会带来大约2^N字节的新数据外加树元数据。这是一个经典权衡位数越少去重粒度越细、去重效率越高位数越多对象越少磁盘上的元数据占用与仓库操作期间的 RAM 消耗越低。手册指出对许多现有仓库而言legacy:13可能偏小每提升 1 位大致能将许多操作的 RAM 需求减半但也会因暴露更少的去重潜力而使仓库体积有所增加——具体效果取决于仓库中数据的文件大小与去重率。若时间和空间允许可以用bup get --rewrite将同一份数据以不同配置重写到新仓库实测对比后再定值相关回归测试可参考 test/ext/test-get-repair-bupm 与 test/ext/test-get-rewrite-missing。两条必须注意的警告已有数据的仓库不要随意改值更改该值会改变分块边界导致后续保存无法对已有数据去重数据会被再次完整存储一遍。不同配置的仓库不要共用同一索引与下面bup.split.trees同理索引中的哈希优化将失效未修改的文件也会被bup save完全重读代价高昂。bup.split.trees目录树的拆分保存bup.split.trees是一个布尔选项默认未设置即关闭。设为true后bup 在写入仓库时会尝试对树目录进行拆分例如在bup save、bup gc等操作中。这对大型目录发生局部变化的场景如体量庞大且持续活跃的 Maildir 邮件目录能显著减小新写入仓库的数据量。更多原理见仓库根目录的 DESIGN.md 中 Handling large directories 一节。为什么目录哈希会受其影响目录树的哈希允许 bup 在索引显示目录未变、且对应树对象已存在于目标仓库时跳过整棵目录的遍历。由于该选项的取值会改变可拆分目录树的哈希值索引中记录的哈希在上次保存时bup.split.trees取值不同的仓库中无法命中因此凡是受树拆分影响的通常很大的目录都必须重新读取并重算相关哈希。换言之用同一份索引向取值不同的仓库保存会降低性能。配置示例git --git-dir$BUP_DIR config bup.split.trees true压缩与打包core.compression、pack.compression、pack.packSizeLimit这三个选项继承自 git 的打包体系共同控制 pack 文件的压缩级别与体积上限。配置项默认行为说明core.compression若未设置bup 取 1注意git 的默认是 -1pack 文件的默认压缩级别命令行显式给出的压缩级别优先于它pack.compression未设置时回退到core.compression更细粒度的 pack 压缩级别pack.packSizeLimit1e9 字节约 0.93 GiB写入 pack 时的最大尺寸限制如bup save相关设置应在目标仓库可能为远端中进行源码实现印证了上述回退链在 lib/bup/repo/base.py 的_make_base()中压缩级别依次尝试pack.compression→core.compression→ 交由底层默认 1max_pack_size则读取pack.packSizeLimitopttypeint。手册还指出即使把pack.packSizeLimit设成如2g2 GiBpack 内所有对象仍可被 31 位偏移寻址idx 文件中无需大偏移记录。环境变量与缓存位置BUP_DIR设置后即成为默认仓库位置命令行bup -d 目录可临时覆盖它。从源码看lib/bup/path.py 的defaultrepo()优先返回BUP_DIR否则回退到~/.buplib/bup/main.py 会把-d指定的目录转成绝对路径并写入环境变量确保后续子进程不受chdir影响。例如BUP_DIR/srv/backup/bup bup init bup -d /srv/backup/bup index /homeXDG_CACHE_HOME/bup 与 index-cache$XDG_CACHE_HOME/bup/remote是首选缓存位置未设XDG_CACHE_HOME时回退到~/.cache/bup/remote而$BUP_DIR/index-cache是带优先级的备用位置。远程仓库的数据在bup save -r等操作期间存放在这些位置。查找逻辑lib/bup/path.py是按$XDG_CACHE_HOME/bup/remote、~/.cache/bup/remote、$BUP_DIR/index-cache的顺序查找既有数据若目标仓库的数据在任一位置均不存在则当$XDG_CACHE_HOME已设置时使用前者否则使用后者。配置实践小结初始化与迁移新仓库由bup init自动写入bup.repo.id复制仓库后务必手动更换该 id避免重复标识引发的性能问题。低配服务器在受限硬件上运行bup-server时可设bup.server.deduplicate-writes false或直接放置dumb-server-mode标记文件达到同等效果。大仓库调优结合数据实测谨慎提升bup.split.files的位数以降低 RAM 与元数据开销对含大型活跃目录的数据开启bup.split.trees。压缩与打包按需通过pack.compression/core.compression调整压缩级别用pack.packSizeLimit控制 pack 上限命令行参数优先级最高。改动前先评估bup.split.files与bup.split.trees的改变会影响既有数据的去重与索引哈希务必先在测试仓库中用bup get --rewrite验证。完整的配置项语义、环境变量与缓存文件说明可查阅 bup-config(5) 手册原文相关命令手册位于 Documentation 目录如 bup-server(1)、bup-save(1)。bup 是本项目所属的 Very efficient backup system基于 git packfile 格式的高效备份系统更多设计背景参见 DESIGN.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备份系统基于Git格式的高效增量备份解决方案Bup备份系统基于Git格式的高效增量备份解决方案 Bup是一个基于Git包文件格式的创新备份系统通过滚动校验和算法实现智能数据分块和全局去重解决了传统备灾备CLI存储BUP - 分布式备份系统BUP 分布式备份系统 BUP是一个基于git的分布式备份系统它可以帮助您轻松地保护您的数据安全并允许您在任何时候恢复您的文件。 什么是BUP BUP是基灾备CLI存储Mac Mouse Fix 用 3 类手势让普通鼠标达到触控板级体验Mac Mouse Fix 用 3 类手势让普通鼠标达到触控板级体验 在 Blender 里环绕视角、在浏览器里前后翻页普通鼠标在 macOS 上做不到这些。灾备CLI存储创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考