Burp 3.2.0 介绍与选型指南

目标：介绍开源网络备份恢复工具 Burp（grke/burp）的定位、核心架构、功能特性与版本现状，并给出与同类备份组件的量化选型对比，帮助读者判断它是否适合自己的备份场景。本文全部数据来自官方渠道（GitHub grke/burp 仓库、burp.grke.org 官网、SourceForge），实查日期为 2026-10-24。

一、环境信息

本篇为认知与选型篇，所有信息均为联网溯源取证，不涉及本地安装实测；安装、配置与命令实测见本专栏后续篇章。

• 组件名称：Burp（全称 BackUp and Restore Program，仓库地址 grke/burp）
• 官方网站：https://burp.grke.org/
• 源码仓库：https://github.com/grke/burp
• 开源许可：AGPLv3（自由软件，作者 Graham Keeling）
• 开发语言：C 语言（依赖 librsync、OpenSSL、zlib、uthash 等库）
• 数据来源与查询日期：GitHub Releases / 仓库页 / shields.io 徽章 / burp.grke.org 官网，查询日期 2026-10-24

⚠️ 同名异物防混淆（务必先读）：本文介绍的 Burp 是 grke/burp——一款 C/S 架构的网络备份恢复工具（BackUp and Restore Program 的缩写）。它 不是 PortSwigger 公司的 Burp Suite——后者是用于 Web 应用渗透测试的安全测试平台（抓包代理、漏洞扫描器）。两者只是名字相同，功能领域完全无关。搜索引擎里大量结果指向 Burp Suite，检索 burp 备份工具时请以 grke/burp、burp backup 为关键词，避免混淆。

二、软件概述

2.1 Burp 是什么

Burp 官网对它的一句话定义是："Burp is a network backup and restore program. It attempts to reduce network traffic and the amount of space that is used by each backup."（Burp 是一个网络备份与恢复程序，尽力降低网络流量与每次备份占用的存储空间，来源：burp.grke.org 首页，查询日期 2026-10-24）。当备份对象是 Windows 计算机时，Burp 使用 VSS（Volume Shadow Copy Service，卷影复制服务）做快照以保证文件一致性。

它的核心设计目标是"网络备份"：多台客户端机器把数据备份到一台中心备份服务器，靠三项机制同时压低网络流量与存储占用：

1. librsync 流式差量：文件第二次备份时，客户端只传输文件变化部分（delta），而不是整个文件；
2. 服务端 zlib 压缩：数据落盘前按 zlib9（默认级别 9）压缩，可用 compression = zlib0 关闭；
3. 保留策略自动清理：服务端按 keep 规则自动删除过期备份，存储占用可控。

2.2 发展沿革与维护方

Burp 由英国开发者 Graham Keeling 个人主导开发，GitHub 仓库创建于 2011 年 3 月 28 日，至今持续维护。官网 "Last updated: May 2026"，与 2026-05-30 发布的 3.3.0 版本相呼应，属于典型的"个人长期维护、更新节奏缓慢但稳定"的开源项目。官网明示它是开源自由软件（AGPLv3），作者以业余时间维护并接受捐赠。

2.3 版本线现状（查询日期 2026-10-24）

官方采用"三轨版本"策略：Latest（最新版，含新特性但可能不稳定）、Stable（官方推荐的生产稳定版）、Old stable（旧稳定版）。从 GitHub Releases 页面与官网下载页（burp.grke.org/download.html）实查到的版本矩阵如下：

关键差异解读：3.1.0 起移除了 protocol 2（旧协议），3.1.2 起因 OpenSSL 弃用 Blowfish，新文件加密改用 AES-CBC-256（仍可解密历史 Blowfish 加密文件）；因此跨大版本升级前应先确认客户端与服务端版本匹配策略（服务端有 version_warn 选项提醒版本不一致）。从 2.4.0 升级到 3.x 前建议阅读官方 Release Notes 的"Things to watch out for"清单。

仓库整体活跃度量化数据（来源：GitHub 仓库页 HTML 与 shields.io 徽章，查询日期 2026-10-24）：

版本节奏解读：2.x 时代（2014—2021）发布密集，3.1.x 系列后节奏放缓至"一至两年一个稳定版"（3.1.4 → 3.2.0 间隔约三年，3.2.0 → 3.3.0 间隔约五个月）。对使用者的含义是：功能迭代慢、接口稳定，适合当"装好就不动"的备份基础设施，但新特性（如 3.3.0 的 force_update_encryption）落地需要耐心。

三、核心架构

3.1 C/S 推送式备份模型

Burp 采用经典的 C/S（Client/Server）架构：备份服务器常驻监听 TCP 4971 端口，各客户端主动把数据"推送"到服务器。一台服务器可同时服务大量客户端，每个客户端连接由服务端 fork 一个子进程处理，子进程会重新读取服务端主配置与该客户端的专属配置，因此几乎所有配置修改都不需要重启服务端（来源：burp.grke.org "Server basics" 文档）。

💡 技术拓展：备份系统的数据流向不止"客户端推送"一种。常见模型对比——

模型	工作方式	代表组件	适用场景
客户端推送（push）	客户端主动连服务器上传	Burp、UrBackup、Bacula	客户端在内网、服务器集中存放
服务器拉取（pull）	服务器主动连客户端抓取	rdiff-backup（可反向）、Amanda	服务器对客户端有网络可达性、集中管控
本地快照 + 异地同步	本地先生成快照仓库再复制	BorgBackup、Restic	单机为主、需端到端加密

Burp 实际采用"客户端推送"模型：客户端即使位于 NAT 后也可正常备份，服务端无需持有客户端的凭据，权限边界清晰。

3.2 传输安全：TLS 双向证书认证

客户端与服务端之间全程使用 SSL/TLS 加密通信。首次接入时走"证书自动签发"流程：客户端用内置的 burp_ca 工具生成私钥与 CSR（证书签名请求），发给服务端；服务端作为 CA（证书颁发机构）验证客户端的 password 共享口令后签署证书并回传。此后双方基于证书互相认证，通信链路加密（实测环境中协商的是 TLS 1.3 的 TLS_AES_256_GCM_SHA384 套件）。安全模型上 Burp 还提供了两个方向的防御选项（来源：burp.grke.org "Security models" 文档）：

• 不信任服务端（客户端视角）：启用 encryption_password 做客户端侧 AES-CBC-256 加密（注意：路径名不加密，且开启后无法再做网络差量传输）、server_can_restore=0 禁止服务端发起恢复、server_can_override_includes=0 禁止服务端改写备份范围；
• 不信任客户端用户（服务端管理员视角）：用 client_can_delete/client_can_diff/client_can_force_backup/client_can_list/client_can_monitor/client_can_restore/client_can_verify 逐项收紧客户端能力。

3.3 定时备份模型：客户端轮询 + 服务端 timer 裁决

Burp 的定时备份不是服务端直接调度客户端，而是"客户端定时来问、服务端说了算"：客户端用 cron（默认示例为每 20 分钟）执行 burp -a t，服务端运行 timer 脚本，依据 timer_arg 定义的"最小间隔 + 时间带"（如 20h、Mon,Tue,...,00,01,...,23）判断当前是否允许备份，允许则当场执行，不允许则本轮跳过。这个模型天然把各客户端的备份时机打散，避免备份风暴。

3.4 服务端存储与保留

每次成功备份在服务端生成一个带编号与时间戳的备份目录（如 0000001），最新备份由 current 符号链接指向。Burp 3.x 的存储安排是：最新备份保存完整数据（data 目录），历史备份保存反向增量（deltas.reverse），新备份完成后服务端会自动"整理"备份链，保证恢复最新备份时无需逐层回放差量。保留策略由 keep 配置驱动，支持多级 keep 值实现"越久远的备份越稀疏"的指数衰减保留；hardlinked_archive=1 可让边界备份用硬链接方式固化全量。备份完成后服务端还会把备份内容做 zlib 压缩落盘。

3.5 状态监控与生态

服务端可另开一个状态端口（默认 4972），以 SSL+JSON 提供各客户端的备份状态。三种内置查看方式：burp -a s（ncurses 交互式监控台）、burp -a S（快照输出，适合脚本/cron 巡检）、burp -a m（原始 JSON 接口）；第三方生态有 burp-ui（Web 界面）与 ansible 自动化部署角色（来源：burp.grke.org "Status monitor" 文档与 GitHub wiki）。

四、功能特性

综合官方文档（burp.grke.org FEATURES/DOCS 页）与 Release Notes，Burp 的主要功能如下：

功能边界（官方明示或设计使然）：Burp 是文件级备份工具，不做整盘镜像/裸机恢复（对比 UrBackup 的镜像备份）；数据库等应用一致性需要配合 pre/post 脚本自行处理（客户端配置支持 backup_script_pre/post 钩子）；没有内置 Web 管理界面（ burp-ui 为第三方项目）。

五、快速开始（最小可用示例）

以下为官方 Quick Start 文档（burp.grke.org/docs.html → quickstart）给出的最小流程，供理解使用模型；逐命令实测版见《Burp 3.2.0 安装与运行实测指南》（发布于本专栏）。流程为"编译安装 → 启动服务端 → 客户端接入 → 备份/恢复"：

# 1. 安装编译依赖（Debian/Ubuntu）
apt-get install make pkg-config check g++ \
        librsync-dev libz-dev libssl-dev uthash-dev

# 2. 编译安装（在 burp 源码目录内）
./configure --prefix=/usr --sysconfdir=/etc/burp --localstatedir=/var
make
make install
make install-configs

# 3. 启动服务端（首次启动自动生成 CA 与 SSL 证书）
burp -c /etc/burp/burp-server.conf

# 4. 客户端强制发起一次备份（默认备份 /home）
burp -a b

# 5. 列出可用备份
burp -a l

客户端定时接入的官方推荐 cron 配置（来源：官方 quickstart 文档，让客户端每 20 分钟询问一次服务端是否该备份）：

MAILTO=
7,27,47 * * * * root    /usr/sbin/burp -a t

要点解读：burp 一个二进制同时承担服务端与客户端两种角色，由配置文件中的 mode = server/client 决定；make install-configs 安装的示例配置即带一套可跑通的默认值（服务端监听 4971、客户端名 testclient、默认备份 /home）。

六、适用场景与限制

6.1 适用场景

1. 中小规模机房的多机文件备份：几十台以内的 Linux/Windows 服务器或办公机，把数据集中备份到一台备份服务器，用 keep 保留策略控制存储增长；
2. 对网络流量敏感的链路：分支机构经 WAN 备份到中心机房，librsync 差量显著降低二次备份流量；
3. 需要集中式证书管理的备份体系：服务端自带 CA，客户端接入零人工签发，证书吊销（CRL）闭环，适合纳入统一安全基线；
4. 要求备份行为可审计、可脚本化：备份范围、时间带、保留策略全部落在服务端配置文件里，配合 -a S 快照与 summary_script 做巡检报表；
5. 无管理界面的无人值守环境：纯文本配置 + cron + 状态端口 JSON，适合纳入 Ansible 等自动化体系（官方 wiki 提供现成 role）。

6.2 限制与注意

1. 无 Web UI：日常管理靠 CLI 与配置文件，图形化诉求需第三方 burp-ui 或改用 UrBackup；
2. 个人维护的开源项目：star 数百级、版本节奏一至两年，遇到关键 bug 修复周期取决于作者业余时间，生产使用需自担验证责任（AGPLv3、无质保）；
3. 文件级备份：不做块级镜像与裸机恢复；虚拟机整盘备份场景更适合 Proxmox Backup Server；
4. 客户端加密牺牲差量：启用 encryption_password 后文件任何改动都要整文件重传，不信任服务端又带宽紧张时需要取舍；
5. 跨版本升级需谨慎：3.x 已移除 protocol 2、加密算法由 Blowfish 换为 AES-CBC-256，新旧版本混跑前先核对 Release Notes；
6. 恢复演练仍不可省：任何备份工具都一样，未验证过恢复的备份等于没有备份。

七、同类选型对比

7.1 对比对象与维度说明

选取本站已收录的同类开源备份组件做量化对比：快照式工具 BorgBackup、Restic，图形化 C/S 备份服务器 UrBackup，配置调度框架 Backupninja，librsync 系单向备份 rdiff-backup，以及虚拟化生态的 Proxmox Backup Server。社区数据实查日期均为 2026-10-24（Burp 数据取自 GitHub 仓库页/shields.io，其余组件取自各自仓库页；不同组件仓库规模口径一致）。

7.2 定位与架构对比

对比解读：Burp 与 UrBackup 同属"中心备份服务器"流派，差别在管理界面与镜像能力；Borg/Restic 是"快照仓库"流派，没有常驻服务端；Backupninja 是"调度壳"，不解决存储本身；rdiff-backup 是"可浏览镜像"流派；PBS 深度绑定 Proxmox 虚拟化场景。

7.3 社区活跃度量化对比

活跃度解读：Burp 的社区规模在备份类组件中最小、迭代最慢，这是"个人业余项目"的固有属性；它的优势不在社区体量，而在"轻、稳、专"——单个 C 二进制、依赖少、十几年稳定演进。若把社区生态与商业支持放首位，Borg/Restic/UrBackup/PBS 都比 Burp 保险。

7.4 功能能力对比

功能解读：Burp 的差异化能力集中在"中心化 C/S + 自带 CA 证书体系 + 内建定时裁决 + 多级保留"，这四件套开箱即用；缺镜像备份与 Web UI 是它与 UrBackup/PBS 的主要差距。

7.5 选型建议

• 选 Burp：要一台"装完就不管"的轻量中心备份服务器、客户端数量几十以内、只要文件级备份、接受 CLI 管理与缓慢版本节奏，且重视自带证书签发/吊销这种闭环安全链；
• 选 UrBackup：同样的 C/S 场景但需要 Web 界面、整盘镜像与裸机恢复（参见《UrBackup 2.5.38 介绍与选型指南》）；
• 选 BorgBackup / Restic：没有常驻服务端诉求、要端到端加密与内容去重、单机或少量机器推到对象存储/SSH 仓库（参见《BorgBackup 1.4 介绍与选型指南》与《Restic 0.19 介绍与选型指南》）；
• 选 Backupninja：机器上已有 rdiff-backup/duplicity 等后端，只想要一套统一的配置化调度与通知壳子，它不与 Burp 构成竞争关系；
• 选 rdiff-backup：想要"恢复端可直接浏览的镜像 + 简单增量"，且偏好 SSH 通道而非自建 CA（参见《rdiff-backup 介绍与选型指南》）；
• 选 Proxmox Backup Server：备份对象是 PVE 虚拟机/容器，要块级去重与内置 Web UI（参见《Proxmox Backup Server 4.2 介绍与选型指南》）。

⚠️ 再次提醒：以上对比与本文全部内容针对 grke/burp 备份工具；若你要找的是 Web 安全测试工具，那是 PortSwigger 的 Burp Suite，与本篇及本专栏无关。

八、参考链接

1. Burp 官网（含 FEATURES/DOCS/FAQ）：https://burp.grke.org/
2. GitHub 仓库 grke/burp（Releases/CHANGELOG）：https://github.com/grke/burp
3. 官方 Quick Start 文档：https://burp.grke.org/docs.html
4. 官方下载页（版本轨道说明）：https://burp.grke.org/download.html
5. 官方安全模型文档：https://burp.grke.org/docs/security-models.html
6. 官方保留策略文档：https://burp.grke.org/docs/retention.html
7. 本站实测篇：《Burp 3.2.0 安装与运行实测指南》（本专栏）
8. 本站同类组件：《UrBackup 2.5.38 介绍与选型指南》、《BorgBackup 1.4 介绍与选型指南》、《Restic 0.19 介绍与选型指南》、《rdiff-backup 介绍与选型指南》、《Proxmox Backup Server 4.2 介绍与选型指南》