Minarca 介绍与选型指南

目标：面向初次接触 Minarca 的系统管理员与运维团队，讲清 Minarca 的产品定位、双端架构、与底层 rdiff-backup 引擎的关系、功能边界，并与同类开源备份方案做量化对比，帮助完成「是否选用 Minarca」的选型决策。本文为认知与选型篇，全部信息联网溯源自官方公开来源（标注来源与查询日期 2026-10-22），部署实操与命令实测见《Ubuntu 22.04 安装 Minarca 指南（服务端与客户端）》。

一、环境信息（资料溯源说明）

本篇是认知篇，不包含本地实测内容，全部结论溯源自下列官方公开来源。为保证可复核，逐条列出来源、用途与查询日期：

版本实查结果（查询日期 2026-10-22）：

💡 说明：Minarca 的服务端与客户端版本线并不同步（服务端 6.x、客户端 7.x），这是官方刻意的设计——客户端 7.x 是用 Python 重写后的新一代 agent，与服务端 6.2.x 通过协议兼容。选型和安装时不要误以为「两端版本必须一致」，Ubuntu 22.04（jammy）官方仓库内最新组合即 server 6.2.5 + client 7.2.0-1。

二、软件概述

2.1 身份定位

Minarca 是一款开源、自托管（Self-Hosted）的集中式数据备份解决方案，由加拿大 IKUS Software inc.（创始人 Patrik Dufresne）开发维护。官网对其定位的原文是「Your open-source, user-friendly data backup solution」——开源、易用、无许可费，支持 Linux、macOS 与 Windows 客户端。

产品由两端构成：

• Minarca Client（代理/Agent）：安装在被备份的计算机上，提供图形界面与命令行两种形态，负责按计划执行备份、与服务器通信、上报状态；
• Minarca Server（中央服务器）：集中管理所有客户端与备份仓库，提供 Web 管理界面（仪表盘、账户、配额、告警），并提供基于 Web 的数据浏览与恢复。

来源：Minarca 官网主页（minarca.org/en_CA，2026-10-22 查询）。

2.2 维护方与许可证

AGPLv3 对使用者的含义：自托管部署、内部使用、修改均免费且无须开源自有业务代码；但若对 Minarca 本身做了修改并以网络服务形式对外提供，需要按 AGPLv3 开放修改部分的源码。企业若需要商业授权与服务保障，可购买 IKUS Soft 的支持服务。

2.3 技术栈与版本线

GitLab 仓库 README 明确了三个组件关系：

• Minarca Server：基于 rdiffweb（IKUS Soft 的另一开源项目，rdiff-backup 仓库的 Web 管理界面）二次开发，Python 编写，AGPLv3；
• 备份引擎：调用 rdiff-backup 完成实际的备份与恢复数据流；
• Minarca Client：Python 编写（7.x 为重写后的新一代 agent），支持 Windows、macOS、Linux，提供 GUI 与 CLI 两种形态。

官方 APT 仓库（jammy）中同时发布 rdiff-backup-1.2、rdiff-backup-2.0、rdiff-backup-2.2 三个引擎兼容包（2026-10-22 实查 Packages 索引），说明服务端会按客户端版本调用不同主版本的 rdiff-backup 引擎以保证前向兼容——老客户端用什么引擎版本创建的仓库，服务端就用对应引擎版本维护，避免跨引擎大版本的仓库格式风险。

三、核心架构

3.1 双端结构与组件分工

┌────────────────────────┐         ┌──────────────────────────────────┐
│  Minarca Client（多台）  │         │        Minarca Server            │
│  ┌──────────────────┐  │         │  ┌────────────────────────────┐  │
│  │ 调度器（计划任务） │  │  HTTPS/ │  │ Web 管理界面（rdiffweb 衍生）│  │
│  │ GUI / CLI         │──┼── SSH ──┼─▶│ 账户/配额/报表/告警          │  │
│  │ rdiff-backup 引擎 │  │  :8080  │  ├────────────────────────────┤  │
│  └──────────────────┘  │  :22    │  │ 备份仓库（默认 /backups）    │  │
│  被保护数据（本地磁盘）  │         │  │ rdiff-backup 仓库格式        │  │
└────────────────────────┘         │  └────────────────────────────┘  │
                                   └──────────────────────────────────┘

分工要点（依据官方安装文档与 README，2026-10-22）：

• 客户端负责发起备份：按配置的计划调度，本地调用 rdiff-backup 引擎，把增量数据推送到服务端；
• 服务端负责集中存储与管理：接收各客户端推来的备份，按账户隔离存储在 /backups（默认路径），Web 界面完成账户、配额、计划、告警与恢复；
• 管理员通过 Web 界面浏览与恢复任意客户端、任意时间点的文件——恢复动作在服务端 Web 上即可完成，也可以由客户端在本地发起。

3.2 备份机制：反向增量

Minarca 的备份能力来自 rdiff-backup 引擎，采用**反向增量（reverse incremental）**模型：每次备份时，最新状态始终是镜像副本（可直接浏览的完整目录树），旧版本以增量差异数据的形式存放在子目录中，恢复旧版本时由引擎按需重组。

💡 技术拓展：备份系统的版本累积机制不止「反向增量」一种，主流方案对比——

机制	原理	优点	缺点	代表
完全备份	每次全量复制	恢复最快	存储与带宽开销最大	tar 全量脚本
传统增量	只备份自上次备份后的变化	省空间	恢复需逐层叠加	Bacula/Bareos 增量级
差异增量	只备份自上次全量后的变化	恢复只需两份	随时间增量变大	Bareos Differential
反向增量	最新=完整镜像，历史=反向差异	最新版可直接访问，恢复直观	老旧版本恢复需重组	rdiff-backup / Minarca
去重快照	块级去重+全局快照池	空间效率最高	需要专门仓库格式	BorgBackup / Restic

Minarca（rdiff-backup 引擎）实际采用「反向增量」，取舍是最新版本零成本直接可读、历史版本按需重组，与 Web 界面「浏览并下载任意版本文件」的产品定位吻合。

3.3 与 rdiff-backup 的关系：封装发行版 vs 底层引擎

这是选型 Minarca 时最需要分辨的一点。两者是「发行版与内核」的关系：

三个实用结论：

1. 用了 Minarca 仍然等于用了 rdiff-backup：仓库格式就是 rdiff-backup 格式，极端情况下（Minarca 服务不可用）可以用 rdiff-backup 命令行直接读取仓库恢复数据。官网原话是「you're guaranteed to be able to recover it safely, with or without Minarca」（无论有没有 Minarca，都能安全恢复）。
2. 只想用引擎、不需要集中管理：直接用 rdiff-backup 更轻；需要 Web 恢复、账户、配额、多客户端集中管理，Minarca 是官方给出的完整答案。
3. 引擎版本由 Minarca 统一管理：不需要（也不应该）在服务器上单独升级引擎主版本，Minarca 通过 rdiff-backup-1.2/2.0/2.2 兼容包自行匹配客户端仓库格式。

3.4 集中管理与多租户模型

Minarca 面向服务提供商（MSP）的定位体现在其多租户设计上（官网原文，2026-10-22）：每个客户拥有独立账户、专属存储空间与独立配额（quota），管理员可以在一个集中仪表盘里纵览所有备份状态，配合告警系统在故障发生时及时介入。这套「账户 → 配额 → 客户端 → 备份仓库」的层级，是它与 rsync 脚本类方案（Rsnapshot）最本质的差异。

四、功能特性

依据官网主页、下载页与 README 汇总（2026-10-22）：

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

以下命令取自官方安装文档《Quick Installation Steps (Debian Linux)》（https://minarca.org/en_CA/doc/installation，2026-10-22 查询），在 Ubuntu 22.04 / Debian 上从零到可用服务端的最小路径。逐条命令的实测回显、systemd 托管细节与排障过程见《Ubuntu 22.04 安装 Minarca 指南（服务端与客户端）》。

5.1 服务端五步安装（官方步骤）

# 1. 准备系统
apt update
apt upgrade
apt install ca-certificates curl lsb-release gpg

# 2. 添加 Minarca 仓库签名密钥
curl -L -o /etc/apt/keyrings/minarca-keyring.asc https://www.ikus-soft.com/archive/public.asc

# 3. 添加 Minarca APT 仓库
cat <<EOF > /etc/apt/sources.list.d/minarca.sources
Types: deb
URIs: https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/
Suites: $(lsb_release -sc)
Components: main
Architectures: amd64
Signed-By: /etc/apt/keyrings/minarca-keyring.asc
EOF

# 4. 安装 Minarca 服务端
apt update
apt install minarca-server

# 5. 访问 Web 管理界面（默认 http://127.0.0.1:8080，默认账号 admin / admin123）

官方文档要点：安装后服务即通过 systemd 托管（service minarca-server start/stop 管理）；Web 界面监听 8080 端口、默认监听所有网卡；生产环境官方强烈建议前置 Nginx/Apache 反向代理并配置 SSL。

5.2 客户端接入（Linux 示例）

客户端从官方下载页获取对应平台安装包（Debian/Ubuntu 用 deb 包，地址 https://www.ikus-soft.com/archive/minarca/minarca-client-latest-amd64.deb，2026-10-22 实查该 latest 软链当前指向 7.2.0-1 版本），安装后通过图形界面或命令行填入服务器地址与管理员分配的账户即可建立关联。CLI 用法详见《Minarca 7.2 常用 CLI 命令与工具详解》。

5.3 体验环境

不部署也能体验：官方提供在线演示环境 https://test.minarca.net/ （登录账号 admin / admin123，2026-10-22 官网标注），可在浏览器里直观了解服务端管理界面与恢复流程。

六、适用场景与限制

6.1 硬件与系统要求（官方安装文档，2026-10-22）

补充要求：需另备 ≥8 GiB 临时存储（建议 tmpfs，恢复时使用，靠近 Web 应用部署）；备份存储建议与系统盘分离；物理机推荐 ZFS（RAID 控制器配 JBOD 模式），虚拟机推荐 ext4；操作系统盘不要用 ZFS。

内核前置：Minarca 依赖**无特权用户命名空间（unprivileged user namespaces）**隔离 SSH 连接与备份进程。官方给出验证命令 unshare --user --net bash；Ubuntu 23.10+ 等带 AppArmor 限制的系统需按官方文档写入 sysctl 配置（kernel.unprivileged_userns_clone=1、kernel.apparmor_restrict_unprivileged_userns=0）。Ubuntu 22.04 默认不受 AppArmor 限制，通常无需额外配置。

6.2 适用场景

• MSP / 服务提供商托管备份：多租户账户+配额+集中仪表盘是原生能力，为每个客户划出独立备份空间；
• 中小企业统一备份：一台服务器集中收编 Windows/macOS/Linux 办公机与服务器，Web 界面降低日常运维与恢复门槛；
• 数据自主可控：自托管、无许可费、仓库格式开放（rdiff-backup 格式可脱离产品恢复），适合对数据主权敏感的团队；
• 已有 rdiff-backup 脚本体系的升级：保留 rdiff-backup 仓库资产，叠加集中管理界面平滑过渡。

6.3 限制与注意

七、同类选型对比

7.1 量化对比表

下表把 Minarca 与常见开源备份方案放在同一维度下比较。Minarca 行数据为本文实查（2026-10-22），其余项目行为其官方公开资料的通行事实（各项目官网/文档长期声明），供选型参考：

7.2 关键差异与选型建议

• 要「备份产品」而非「备份工具」：Minarca 与 Bareos、BackupPC 同属集中式产品形态。Bareos 企业级能力（磁带、目录数据库、精细调度）最强但配置复杂；BackupPC 部署简单但 Web 界面老旧、按主机管理；Minarca 以现代 Web 界面 + 多租户配额取胜，学习成本最低。
• 要「加密优先、脚本集成」：Borg 或 Restic。两者内建仓库加密与去重，空间效率远高于反向增量，但都没有原生集中管理产品形态，恢复主要靠命令行。
• 要「极致简单、rsync 老手」：Rsnapshot。纯 rsync+硬链接，没有服务端概念，几十台机器以内、愿意自维护脚本的场景仍然好用。
• 已有 rdiff-backup 资产：直接在原仓库上叠加 Minarca Server，即可获得 Web 恢复与集中管理，不必迁移数据格式。
• 一句话选型：把「谁在用」放在第一位——给非备份专家用（MSP 客户、行政办公终端），Minarca 的 Web 恢复与多租户是决定性优势；给专业运维做脚本化基础设施，Borg/Restic/Rsnapshot 的加密与去重更值钱。

八、参考链接

• Minarca 官网：https://minarca.org/
• 官方下载页：https://minarca.org/en_CA/download
• 官方安装文档：https://minarca.org/en_CA/doc/installation
• GitLab 源码仓库：https://gitlab.com/ikus-soft/minarca
• GitHub 镜像仓库：https://github.com/ikus060/minarca
• rdiff-backup 引擎官网：https://rdiff-backup.net/
• rdiffweb（服务端 Web 界面上游项目）：https://rdiffweb.org/
• 在线演示环境：https://test.minarca.net/
• 相关篇目：《Ubuntu 22.04 安装 Minarca 指南（服务端与客户端）》、《Minarca Server 6.2 配置参数详解》、《Minarca 7.2 常用 CLI 命令与工具详解》