数据库备份工具真正困难的部分，往往不是执行一次 mysqldump，而是持续解决定时运行、结果追踪、失败发现和部署维护。OpsDump v0.1.0 将这些能力收进一个基于 GoFrame v2 的单进程平台：使用单二进制交付，以 SQLite 保存平台数据，并通过 Web 页面完成管理，同时兼顾数据库备份和通用任务调度。
当前版本已经实现并跑通，适合用于验证轻量运维平台的部署方式与备份流程。不过，v0.1 仍应按早期版本对待，上生产前需要补齐恢复演练、告警和平台自身备份等环节。
单二进制与 SQLite 解决了什么
对于规模不大的团队，运维平台本身如果还依赖数据库、消息队列和多个服务，维护成本很容易超过它带来的收益。OpsDump 采用单进程、单二进制和 SQLite 的组合，主要降低了三类门槛：
- 部署简单：复制可执行文件和必要配置即可启动，不需要额外搭建平台数据库。
- 迁移直接：仓库根目录
ops-dump/是独立 Go 模块，模块名为ops-dump，便于单独构建和迁移。 - 管理集中：备份任务与通用调度任务可以通过 Web 页面统一管理，减少散落在多台机器上的 cron 配置。
SQLite 很适合单实例工具，但边界也很明确：它不是天然的多节点协调数据库。不要在没有验证锁、共享存储和故障切换行为的情况下，同时启动多个 OpsDump 实例并让它们读写同一个 SQLite 文件。
从源码构建与服务化运行
下面给出一套可以改造的部署流程。具体入口目录、配置参数和监听地址应以项目实际版本为准；示例假设仓库根模块可以通过 go build ./... 编译，并最终产出一个名为 ops-dump 的程序。
cd ops-dump
go mod download
go test ./...
# 如果 main 包位于仓库根目录，可以直接执行：
go build -trimpath -ldflags="-s -w" -o ./dist/ops-dump .
./dist/ops-dump --help
若项目的 main 包位于 cmd/ops-dump，则把构建命令调整为：
go build -trimpath -ldflags="-s -w" -o ./dist/ops-dump ./cmd/ops-dump
Linux 主机上可以使用 systemd 托管进程。以下文件中的启动参数属于部署示例，运行前需要根据 ./ops-dump --help 和项目配置方式进行修改：
# /etc/systemd/system/ops-dump.service
[Unit]
Description=OpsDump backup and task scheduler
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=opsdump
Group=opsdump
WorkingDirectory=/opt/ops-dump
ExecStart=/opt/ops-dump/ops-dump
Restart=on-failure
RestartSec=5
UMask=0077
[Install]
WantedBy=multi-user.target
sudo install -d -o opsdump -g opsdump -m 0750 /opt/ops-dump
sudo install -o opsdump -g opsdump -m 0750 ./dist/ops-dump /opt/ops-dump/ops-dump
sudo systemctl daemon-reload
sudo systemctl enable --now ops-dump
sudo systemctl status ops-dump
UMask=0077 可以减少备份配置、日志或数据库文件被其他本地用户读取的风险。生产环境还应确认 SQLite 文件、备份目录和配置文件都由专用账号管理。
把备份命令做成可验证的任务
如果当前版本支持执行通用命令任务，可以将数据库原生导出工具包装成脚本，再交给调度器调用。由于来源摘要没有给出 OpsDump 的任务配置格式，下面示例只展示可被调度的任务脚本，不假设具体 API 或页面字段。
运行前需要安装 mysqldump 和 gzip，并设置数据库连接环境变量：
#!/usr/bin/env bash
set -Eeuo pipefail
: "${MYSQL_HOST:?MYSQL_HOST is required}"
: "${MYSQL_USER:?MYSQL_USER is required}"
: "${MYSQL_PASSWORD:?MYSQL_PASSWORD is required}"
: "${MYSQL_DATABASE:?MYSQL_DATABASE is required}"
BACKUP_DIR="${BACKUP_DIR:-/var/backups/mysql}"
RETENTION_DAYS="${RETENTION_DAYS:-14}"
TIMESTAMP="$(date -u +%Y%m%dT%H%M%SZ)"
TARGET="${BACKUP_DIR}/${MYSQL_DATABASE}-${TIMESTAMP}.sql.gz"
TEMP_FILE="${TARGET}.tmp"
install -d -m 0700 "$BACKUP_DIR"
trap 'rm -f "$TEMP_FILE"' EXIT
MYSQL_PWD="$MYSQL_PASSWORD" mysqldump \
--host="$MYSQL_HOST" \
--user="$MYSQL_USER" \
--single-transaction \
--routines \
--events \
--databases "$MYSQL_DATABASE" \
| gzip -9 > "$TEMP_FILE"
gzip -t "$TEMP_FILE"
mv "$TEMP_FILE" "$TARGET"
sha256sum "$TARGET" > "${TARGET}.sha256"
find "$BACKUP_DIR" -type f \
\( -name '*.sql.gz' -o -name '*.sql.gz.sha256' \) \
-mtime "+$RETENTION_DAYS" -delete
printf 'backup_created=%s\n' "$TARGET"
这个脚本具备几个适合调度系统识别的特征：发生错误时返回非零退出码，成功时输出明确的文件路径，临时文件不会冒充完整备份，并在落盘前通过 gzip -t 做基础校验。
密码不应直接写进任务命令或提交到仓库。可以从权限受控的环境文件、宿主机密钥服务或部署平台注入。对于 PostgreSQL，也可以用同样结构包装 pg_dump，保留临时文件、完整性检查和退出码处理。
可靠备份不能只看“任务成功”
调度器显示绿色状态，只能说明命令按预期退出，不能证明备份一定可恢复。采用 OpsDump 时，建议至少建立以下闭环：
- 定期在隔离环境中恢复备份，并执行表数量、关键记录和应用查询检查。
- 将备份复制到不同故障域，避免平台主机、SQLite 数据和备份文件同时丢失。
- 监控备份文件大小和持续时间；异常变小、突然变大或执行时间突变都值得告警。
- 明确任务超时、并发和重试策略，防止慢任务重叠执行并持续占用数据库资源。
- 对 Web 管理入口设置访问控制，不应直接暴露在公网。
- 单独备份 OpsDump 的 SQLite 数据及配置，并在复制前确认一致性处理方式。
v0.1 的采用建议
OpsDump v0.1.0 的价值在于用较低部署成本整合备份与调度，而不是替代所有企业级编排系统。它更适合单机或小规模环境、内部工具，以及希望逐步替换分散 cron 任务的团队。
落地时可以从一个非核心数据库开始：连续观察任务日志与资源消耗，完成至少一次真实恢复，再逐步迁移关键任务。对于需要多节点高可用、复杂依赖编排、严格审计或大规模并发的场景，则应先验证当前版本的能力边界，必要时继续保留成熟的外部调度和备份体系。