Backupninja 1.2.2 介绍与选型指南

目标：说清 Backupninja 是什么、解决什么问题——它是一个配置驱动的「备份调度框架」（meta-backup system），通过向 /etc/backup.d/ 丢配置文件来统一调度 rdiff-backup、duplicity、rsync、tar、borgbackup、restic、mysqldump 等各类备份后端，并提供邮件报告与 ninjahelper TUI 向导；本文为认知与选型篇，版本、依赖、后端清单等全部数据均于 2026-10-24 从官方与 Debian 权威来源联网溯源取得，安装实测见本专栏安装实测篇，CLI 与 TUI 详解见命令详解篇。

一、环境信息

本文是认知与选型篇，不依赖特定服务器环境；文中全部版本、依赖与功能数据均来自下列权威来源，查询日期统一为 2026-10-24：

💡 技术拓展：查询版本时容易混淆「上游版本」与「发行版仓包版本」。Backupninja 的上游发布以 GitLab 标签（如 1.2.1 于 2021-01-26 打标）和 Debian 导入记录为准；Debian stable（trixie）、oldstable（bookworm）当前均为 1.2.2-1，oldoldstable（bullseye）为 1.2.1-1。即截至 2026-10-24，官方最新稳定版就是 1.2.2，Debian 仓包与上游同步、并无滞后；但该项目上游发版节奏慢（最近三年无新上游版本），选型时应接受「功能稳定、更新低频」的现状，并以 Debian 仓库的打包版本为实际安装来源。

二、软件概述

2.1 定位：配置驱动的备份调度框架

Backupninja 的官方自我描述是「lightweight, extensible meta-backup system（轻量、可扩展的元备份系统）」：你在 /etc/backup.d/ 目录下放置若干 ini 风格的配置文件，backupninja 主脚本每小时被 cron 拉起一次，按文件名顺序与 when 调度规则逐个执行这些配置——每个配置文件按后缀名（.rdiff、.dup、.mysql、.tar、.rsync、.sys、.sh 等）交给对应的 handler 脚本去完成真正的备份动作。

它与「备份引擎」类工具（BorgBackup、restic、rdiff-backup 自身）有本质区别：Backupninja 本身不做备份存储、不管理快照格式、不提供去重或加密，它只负责「何时、以什么配置、调用哪个后端、跑完之后如何汇总报告」这一层编排。打个比方：Borg/restic 是发动机，Backupninja 是把多个发动机装进同一辆车并按时发车的调度台。

💡 技术拓展：Linux 备份工具按「能力层次」可分为三类，选型前先分清你要的是哪一层——

类型	代表工具	职责	特点
备份调度框架（本篇主角）	Backupninja、rsnapshot（偏 cron+rsync 封装）	统一配置入口、定时调度、多后端编排、运行报告	自身不定义存储格式，后端可替换
备份引擎（单机/拉推式）	BorgBackup、restic、rdiff-backup、duplicity	定义快照/增量格式，去重、压缩、加密	能力强但各自配置语法独立，多机多后端时运维碎片化
备份服务器（C/S 架构）	UrBackup、Bareos、Proxmox Backup Server、burp	服务端集中管理多客户端、Web 控制台、集中存储	适合多机集中管控，部署与资源开销最大

Backupninja 适合「单机或少量服务器、希望用一套统一配置文件把多种备份任务管起来、不需要集中式备份服务器」的场景。

2.2 发展沿革与版本节奏

Backupninja 由 riseup.net 集体（美国非营利激进技术组织）开发并长期在其自有服务器上使用，随 Debian/Ubuntu 仓库广泛分发。根据 Debian changelog（tracker.debian.org，查询日期 2026-10-24），主要版本节奏如下：

关键解读：版本节奏约为「数年一版」，1.2.2 距今（2026-10）已三年多没有新上游版本。这不是弃坑信号——它随 Debian trixie（2025 年发布的 stable）正常迁移并保持 1.2.2-1，且该工具定位就是「稳定、极简、无守护进程」；但对追新特性的人来说，这里明显不如引擎型工具活跃。

2.3 软件性质

• 实现语言：纯 POSIX/bash shell（Debtags 标注 implemented-in::shell），主脚本 /usr/sbin/backupninja 约 730 行，无守护进程、无数据库、无运行时依赖。
• 许可：GPL-2.0+（Debian copyright 文件），自由软件。
• 体量：deb 包 89.9 kB，安装后约 360 kB，含主脚本、ninjahelper 向导、13 类 handler、9 个 TUI helper 与手册页。
• 运行方式：无常驻进程；/etc/cron.d/backupninja 每小时整点拉起 backupninja，由其内部 when 规则决定本次是否真正执行各配置。

三、核心架构

3.1 三层结构

Backupninja 的架构可以概括为「一个调度器 + 一组 handler + 一个配置目录」：

扩展机制：要教 backupninja 一个新后端，只需把一个以新后缀命名的 bash 脚本丢进 /usr/share/backupninja/（官方手册 backup.d(5) 原文：Support for additional configuration types can be added by dropping bash scripts with the name of the suffix into /usr/share/backupninja）。.sh 后缀最特殊——它不调用任何备份工具，而是把整个配置文件当 shell 脚本直接执行，用于自定义任务（如备份前导出应用配置、备份后清理）。

3.2 执行链路与报告

一次完整运行的链路（依据 backupninja(1) 手册与 /etc/cron.d/backupninja 包内文件）：

1. cron 每小时整点执行 /usr/sbin/backupninja（包内置条目 0 * * * * root if [ -x /usr/sbin/backupninja ]; then /usr/sbin/backupninja; fi）；
2. 主脚本校验 /etc/backup.d/ 及每个配置文件的权限（必须 root 所有、组/其他不可读写，否则拒绝执行）；
3. 按文件名字母序遍历配置，与 when 调度规则匹配（默认 when = everyday at 01:00）；
4. 命中者以 /var/lock/backupninja/ 下的锁文件互斥执行对应 handler；
5. 全部结束后按 loglevel 写 /var/log/backupninja.log（logrotate 月轮转 6 份），并向 reportemail（默认 root）发送汇总邮件；可选将日志 rsync 到 reporthost 聚合为 ninjareport，或输出 prometheus node-exporter 文本文件指标（reportprom）。

这一「调度 + 权限校验 + 锁互斥 + 日志 + 邮件报告」的链路，正是它作为「框架」的核心价值：后端随便换，这层治理不变。

四、功能特性

4.1 备份后端（handler）全量清单

以下清单来自 Debian 包官方描述（packages.debian.org/trixie/backupninja，查询日期 2026-10-24）与包内文件列表（/usr/share/backupninja/）：

关键解读：handler 覆盖「文件系统 + 主流数据库 + 代码仓库 + 系统信息」四类对象，且数据库导出类 handler 被设计为先执行、文件系统增量类后执行（官方 backup.d(5) 手册建议数据库 dump 用小编号在前、.rdiff 用大编号在后，使 dump 产物被纳入文件系统备份）。

4.2 ninjahelper 交互式向导

/usr/sbin/ninjahelper 是基于 dialog 的终端菜单向导：主菜单列出已有动作配置（可查看/编辑/启停/改名/立即运行/试运行/删除），「create a new backup action」进入各 handler 的分步问答（调度时间、目标目录、包含/排除路径、压缩算法等），最终自动生成命名规范、权限 600 的配置文件。对不想手写 ini 的运维非常友好。九类带 .helper 的后端（borg、dup、makecd、mysql、pgsql、rdiff、restic、sys、tar）都有独立向导。

4.3 报告与可观测

• 邮件报告：每次运行结束向 reportemail 发送汇总（成功/致命/错误/警告计数与各动作状态），reportsuccess/reportinfo/reportwarning/reportspace 控制报告粒度；本地投递由 MTA（Debian 默认推荐装 exim4）完成。
• 日志：/var/log/backupninja.log，loglevel 1–5 可调，logrotate 每月轮转保留 6 份。
• Prometheus 指标（1.2.2 新增）：reportprom = yes 时把备份状态写入 prometheus-node-exporter 的文本文件目录，接入 Prometheus 告警体系。
• 集中报表：reporthost/reportuser/reportdirectory 可把各机日志 rsync 到一台报表机聚合为 ninjareport。

4.4 调度能力（when 语法）

when 支持「星期/日 + 时刻」组合与 hourly、manual 特殊值，多 when 行并存即多计划。合法示例（backup.d(5) 原文）：

when = sundays at 02:00
when = 30th at 22
when = 30 at 22:00
when = everyday at 01
when = Tuesday at 05:00
when = hourly
when = manual

注意 at 后必须是 2 位小时（可带 :分钟），when = everyday at 5:00、tuesday at 2am 这类写法不合法；when = manual 的配置不参与定时、只能用 backupninja --run 文件 或 ninjahelper 手动执行。

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

以下最小流程整理自官方手册 backupninja(1) 与 backup.d(5)（来源：Debian trixie 随包手册页，查询日期 2026-10-24）；每条命令的完整实测回显见本专栏安装实测篇与命令详解篇，此处仅给认知篇所需的最小命令形态：

# 1. 在 Debian/Ubuntu 上安装（自动带上 dialog、gawk 等基础依赖）
apt-get install backupninja

# 2. 安装后即有每小时整点的 cron 触发；先放一个最简单的动作配置
#    （.sh 后缀 = 直接执行的 shell 脚本，适合第一次验证链路）
cat > /etc/backup.d/40-dpkg.sh <<'EOF'
when = manual
dpkg --get-selections > /var/backups/dpkg-selections.txt
EOF
chmod 600 /etc/backup.d/40-dpkg.sh

# 3. 试运行（--test 只做连通性/配置检查，不真正执行动作）
backupninja --test --run /etc/backup.d/40-dpkg.sh

# 4. 真正执行单条动作并输出调试日志
backupninja --run /etc/backup.d/40-dpkg.sh

# 5. 查看运行日志
tail /var/log/backupninja.log

要点：配置文件必须 chmod 600 且属主 root，否则主脚本会因权限校验失败拒绝执行；when = manual 让它不参与定时，验证通过后再改成实际调度（如 when = everyday at 02:00）。更省事的方式是直接运行 ninjahelper，用 TUI 向导生成同样的配置。

六、适用场景与限制

6.1 适合的场景

1. 单机多后端统一纳管：一台服务器上同时要「/etc 归档 tar + /var 镜像 rsync + MySQL 每日 dump + 系统信息收集」，用 backupninja 四个配置文件统一调度、统一日志、统一邮件报告，避免四套 cron 与四种日志各自为政。
2. Debian/Ubuntu 运维基线：apt 一条命令装好、无常驻服务、纯配置文件可纳入 etckeeper/Ansible 管理，很适合作为发行版运维基线组件。
3. 推送到备份服务器/对象存储的编排层：rdiff/dup/borg/restic handler 均支持 remote 目标（ssh），可作为「引擎型工具的统一调度壳」——引擎负责存储格式，backupninja 负责时间、配置与报告。
4. 低成本合规留痕：sys handler 自动收集 debconf 应答、包清单、分区表、硬件信息，为灾备重建提供系统画像。

6.2 限制与短板

1. 无集中控制台：没有 Web UI，多机管理靠各自配置 + 可选的 ninjareport 日志聚合；需要集中管控请看备份服务器类（UrBackup、Bareos、Proxmox Backup Server、burp）。
2. 上游发版低频：1.2.2 之后三年无新上游版本（截至 2026-10-24），新后端特性（如官方 kopia 支持）指望不上；好在 handler 机制本身可自行扩展。
3. 秒级 RPO 做不到：调度粒度受 cron 与 when 语法限制（最小粒度小时级命中 + 小时内整点分钟），不适合高频增量场景。
4. 权限纪律严格：/etc/backup.d/ 下文件必须 root:root 0600，权限多一点也不执行——这是安全设计，也是新手最常见的报错来源。
5. 官方 release 与 Debian 仓包版本可能滞后的提示：本项目当前表现相反——上游与 Debian 同步在 1.2.2；但 RHEL 系发行版（EPEL/Fedora rawhide 曾长期停留在 1.1.0）包版本明显滞后，跨发行版选型时以各发行版仓实查为准。

七、同类选型对比（含量化维度）

7.1 量化对比表

下表对比数据均于 2026-10-24 联网溯源：Backupninja 数据来自 Debian 包元数据与 changelog；对比工具列其官方定位（来源为各自官方文档/仓库与本站已有专栏），版本号一律以各官方 Release 页实时为准，此处不硬编码竞品版本。

关键解读：Backupninja 的不可替代点在「一个配置目录管全部后端 + 统一报告」；如果你的诉求只是单机文件快照，直接用引擎更简单；如果机器多到需要控制台，直接上备份服务器。

7.2 选型建议（如果…则…）

• 如果你的服务器是 Debian/Ubuntu、备份对象多样（文件 + MySQL/PostgreSQL + 系统信息）、想用一套配置文件与日志统一管理 → Backupninja（搭配 rdiff-backup/duplicity/borg 任选为存储后端）。
• 如果只需要本机文件快照、追求简单直接 → 《rdiff-backup 介绍与选型指南》或 《rsnapshot 介绍与选型指南》，二者也都可以反过来被 Backupninja 调度（.rdiff 后缀）。
• 如果要加密增量推送到不可信存储 → duplicity（Backupninja .dup 后端）或 restic/borg 引擎；duplicity 的选型细节见 《Duplicity 介绍与选型指南》。
• 如果是多台客户端需要集中备份、恢复与控制台 → 《UrBackup 2.5.38 介绍与选型指南》、《Bareos 介绍与选型指南》或面向 Proxmox 生态的 《Proxmox Backup Server 4.2 介绍与选型指南》。
• 如果要「调度框架 + 引擎」组合使用，典型组合是 Backupninja 调度 rdiff-backup，二者关系与实践见 《rdiff-backup 介绍与选型指南》与本站 rdiff-backup 专栏的命令详解篇。

八、参考链接

1. Debian 包页（版本/依赖/handler 描述）：https://packages.debian.org/stable/backupninja （查询日期 2026-10-24）
2. Debian Package Tracker（版本迁移/changelog）：https://tracker.debian.org/pkg/backupninja （查询日期 2026-10-24）
3. 上游代码仓库（GitLab）：https://0xacab.org/liberate/backupninja （查询日期 2026-10-24）
4. 上游文档站（riseup.net 集体）：https://riseup.net/backupninja （查询日期 2026-10-24）
5. 随包手册页：backupninja(1)、ninjahelper(1)、backup.d(5)、backupninja.conf(5)（Debian trixie，backupninja 1.2.2-1）