灾备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 demux是 bup 备份系统基于 git packfile 格式、支持快速增量保存与全局去重中的一个内部命令它的任务是从标准输入读取 bup 特有的“复用multiplexed”字节流将其中的数据流与错误流精确还原到自身的标准输出与标准错误。本文以官方手册页 Documentation/bup-demux.1.md 为骨架结合仓库源码demux.py、helpers.py、on.py与配套手册 bup-mux.1.md、bup-on.1.md完整讲解该命令的用法、复用流线的包格式、底层实现细节及其在远程备份bup on链路中的核心作用。读完后你将能理解 bup 如何在单条连接上同时承载数据与诊断输出并掌握复用流协议的可复现格式。命令概览名称、语法与定位根据手册页的 NAME 与 SYNOPSIS 部分bup-demux - demultiplexes data and error streams from standard input bup demux即bup demux将标准输入上携带的 bup“复用流”拆解还原为数据stdout与错误stderr两部分。该命令不接受任何参数或选项其声明式用法就是单独一行bup demux。从源码看demux.py 中通过options.Options(optspec)解析参数若传入多余参数会直接调用o.fatal(...)报错退出bup demux # internal command (may be removed or changed at any time) --需要特别强调手册页中的一条重要提示这是一个内部命令随时可能被移除或改变行为原文为 Note: this is an internal command, and may be removed or changed at any time.。因此它不适合被外部脚本直接依赖读者应将其视为理解 bup 客户端-服务器通信机制的技术窗口而不是稳定的对外接口。设计动机为什么需要“多路分离”bup 的远程备份采用客户端-服务器架构。当bup on通过 ssh 在远端主机执行index、save、split、restore等子命令时远端进程既会产生业务数据如备份内容的 stdout 输出也会产生调试信息、进度提示与错误信息stderr。如果让两者各自走独立的 ssh 通道连接管理会变得复杂且不可靠更常见的情况是只有一条可用通道例如 bup-mux.1.md 提到的 inetd 服务器场景。bup 的解决方案是“复用mux— 分离demux”配对发送端使用bup mux把子进程的 stdout 与 stderr 交织编码成单条字节流即“复用流”接收端使用bup demux把这条流按帧拆回 stdout 与 stderr再分别写到本地的标准输出与标准错误。手册页明确写道bup demux的首要用途是支撑bup on(1)原文 Its primary purpose is to supportbup-on(1).。这一句话点明了该命令在整个 bup 远程备份链路中的枢纽地位。复用流协议BUPMUX 同步串与包帧格式要理解bup demux的行为必须先弄清它解析的流格式。该格式的编码端实现在 helpers.py 的mux(outfd, outr, errr)函数中整个协议只有四类元素同步串magic连接建立后发送端首先写入 6 字节的bBUPMUX作为“后续内容均为复用帧”的分界标记。数据包stdout从 stdout 管道读取最多MAX_PACKET定义为128 * 1024即 128 KiB字节后以os.writev写出一个头部加负载头部为 5 字节struct.pack(!IB, len(buf), 1)——大端序 4 字节长度 1 字节的流标识符1。错误包stderr从 stderr 管道读取最多 1024 字节后同样写出 5 字节头部但流标识符为2。结束帧terminator当两个管道都读到 EOF 后发送端最后写入struct.pack(!IB, 0, 3)——长度 0、标识符3表示“复用会话到此终止”。mux()的注释明确要求无论发生什么在返回前都必须写入该结束帧从而保证复用会话有确定的边界。发送端通过select.select([outr, errr], [], [])轮询两个管道谁可读就先读谁从而在单条输出流上交错传输两类数据。对应的常量与读帧逻辑均位于 helpers.pyMAX_PACKET 128 * 1024定义了单帧数据量的上限。实现机制DemuxConn 如何逐帧还原双流bup demux的解码逻辑完全封装在 helpers.py 的DemuxConn类中该类是 bup 客户端-服务器协议所用BaseConn位于同一文件 helpers.py 附近的一个具体子类。其工作过程可分为三个阶段初始化阶段寻找 BUPMUX 边界DemuxConn.__init__逐字节读取输入直到凑齐完整的bBUPMUX同步串为止。在此之前的任何内容都被视为“mux 初始化之前产生的调试/日志输出”代码注释原文 Anything that comes through before the sync string was not multiplexed and can be assumed to be debug/log before mux init.会被直接转发到本进程的 stderr。若在凑齐同步串之前遇到 EOF则抛出IOError(demux: unexpected EOF during initialization)并把已读到的残余尾部写入 stderr 后退出——这保证了异常场景下调试信息也不会丢失。主循环阶段按 5 字节头部拆帧_next_packet(timeout)是核心拆帧逻辑先用select等待输入可读支持超时再用checked_reader(self.infd, 5)精确读取 5 字节头部解析n, fdw struct.unpack(!IB, ns)得到负载长度与流标识符若n MAX_PACKET说明连接已被破坏代码注释 assume that something went wrong会先读取 1024 字节打印到 stderr 并抛出Connection broken异常fdw 1本次为 stdout 数据self.reader被设为checked_reader(self.infd, n)即按 n 字节精确读取负载供上层以 readline/read 的方式消费fdw 2本次为 stderr 数据逐块读出后直接写入本进程的 stderrfdw 3会话结束帧将自身标记为closed然后继续读取输入中剩余的所有内容并全部写入 stderr——因为这些可能包括bup.cmd.mux中mux()调用之后产生的调试消息、异常回溯等源码注释明确说明了这一点。数据消费阶段按行还原 stdoutDemuxConn继承的readline()/read()通过_read_parts与_load_buf完成“按需拆帧”每次请求数据时若当前帧耗尽就拉取下一帧直到遇到fdw 3结束帧为止。这样上层代码可以用完全透明的文件式接口读取数据而无须关心帧边界。demux.py 的main()正是这样组织的sys.stdout.flush() sys.stderr.flush() out byte_stream(sys.stdout) try: with DemuxConn(sys.stdin.fileno(), open(os.devnull, wb)) as dmc: for line in iter(dmc.readline, b): out.write(line) finally: # just in case out.flush() sys.stderr.flush()注意两个细节其一DemuxConn的输出通道参数被设置为os.devnull空设备因为demux自身只负责“读流并分发”不需要通过连接回写任何协议应答其二主循环用iter(dmc.readline, b)逐行读取把 stdout 数据流原样写回本进程的 stdout直到结束帧或 EOF。在bup on远程备份链路中的位置bup demux的实战价值完全体现在bup on的调用链中。打开 on.py可以读到一段完整的 ASCII 拓扑图直观展示了它的位置本地bup onserver 进程通过 ssh 与远端on--server执行 index/save 等通信远端的 stdout 与 stderr 先在 ssh 的 stderr 通道上被复用编码mux out/err本地再启动bup demux接收该通道并还原成本地 stdout 与 stderr。对应代码位于 on.pysys.stdout.flush() sys.stderr.flush() with ssh.connect(dest, port, bon--server, stderrPIPE) as on_srv: argvs b\0.join([bbup] argv) on_srv.stdin.write(struct.pack(!I, len(argvs)) argvs) on_srv.stdin.flush() # write on--servers stdout/stderr to our stdout/stderr via demux with stopped(Popen((bup.path.exe(), bdemux), stdinon_srv.stderr), timeout1) as demux: if srv_config: run_server(on_srv, srv_config) demux.wait() # finish the output return on_srv.returncode整个流程可以概括为本地bup on通过ssh.connect建立到远端的连接远端运行on--server远端把自身的 stdout/stderr 复用编码后经 ssh stderr 通道传回本地用Popen((bup.path.exe(), bdemux), stdinon_srv.stderr)启动一个bup demux子进程其标准输入正是该复用通道本地自己的服务器逻辑run_server通过 ssh stdout 通道与远端进行协议交互demux.wait()确保远端全部输出都被还原完毕bup on最终以远端的返回码退出。也就是说远端备份过程中打印的进度如 bup-on.1.md 示例中的Saving: 100.00% (241/241k, 648/648 files), done.、服务器状态消息bup server: reading from stdin.与可能的错误回溯都是经由这条“mux → ssh → demux”管道最终呈现到用户终端的。bup on的“反向模式”由备份服务器主动 ssh 到被备份机数据保存到本地仓库适用于被备份机无法访问备份服务器或后者藏于单向防火墙之后也因此能获得干净、完整的终端输出体验。与bup mux的配对关系及典型用法bup demux与bup mux是同一协议的收发两端手册页 bup-mux.1.md 对此有直接说明bup mux在 bup 客户端-服务器协议中用于“在单条连接流上同时发送数据与调试/错误输出”其语法为bup mux command [options...]。发送端 mux.py 的实现与demux形成镜像它先把子命令的 stdin 换成/dev/null独占 stdin 给子命令用os.pipe()创建两对管道分别承接子进程的 stdout 与 stderr然后调用mux(out.fileno(), outr, errr)完成帧编码最后以子命令的退出码作为自身的退出码。mux.py 的 optspec 中提示了它的一种经典部署形态——bup mux bup server可被用于 inetd 服务器场景由 inetd 提供单条连接mux包装bup server把服务器的数据与诊断输出复用成一条流发给客户端客户端再用bup demux还原。这解释了为何协议要如此强调“结束帧必须写、同步串必须找”——在单条长连接上双方都必须能精确判断“会话从哪里开始、到哪里结束”。使用要点与注意事项基于手册页与源码实现使用bup demux时有几点值得注意无需参数直接bup demux即可多余参数会导致解析失败并报错退出输入必须是合法复用流标准输入必须是bBUPMUX同步串开头、后续为!IB帧格式的数据否则会以unexpected EOF during initialization或Connection broken异常终止内部接口行为可能变动手册页明确警告其可能被移除或更改不应在外部脚本中作为稳定依赖退出行为bup demux本身只负责还原输出远端命令的最终退出码由bup on基于远端返回码决定而非由 demux 决定与之配套的命令发送端见bup mux完整用法示例与场景见bup on。总结bup demux虽是一个仅十几行主逻辑的内部命令却是 bup 远程备份架构中不可替代的一环。它与 helpers.py 中的mux()/DemuxConn共同定义了“BUPMUX 同步串 5 字节!IB帧头 1/2/3 三种流标识 128 KiB 单帧上限”的复用流协议使得 bup 能够在 ssh、inetd 等单条通道上同时、有序、无损地传输数据流与错误流。理解这条协议链路也就理解了bup on反向备份模式下终端输出从远端进程一路抵达本地终端的完整旅程——这正是 bup-demux.1.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 迁移 rsnapshot 备份存档bup import-rsnapshot 命令用法与源码级原理解析bup 迁移 rsnapshot 备份存档 bup import rsnapshot 命令用法与源码级原理解析 本篇技术指南围绕 bup 仓库中 bup im灾备CLI存储bup help 命令完全指南内置文档查阅机制与实现原理bup help 命令完全指南内置文档查阅机制与实现原理 本篇技术指南以 bup 项目的手册页 Documentation/bup help.1.md htt灾备CLI存储bup midx 多索引.midx文件深入解析原理、命令行操作与自动维护机制bup midx 多索引.midx文件深入解析原理、命令行操作与自动维护机制 bup 是基于 git packfile 格式的高效备份系统当仓库中积累了灾备CLI存储上一篇Qwen终极指南如何利用阿里巴巴智能大模型快速构建AI应用下一篇GitHub VS Code 主题完全配置指南打造个性化开发环境创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考