mcpField
D
database-backup

database-backup

github.com/seb1n数据与数据库232113 次安装11 周前更新
代码仓库

关于 database-backup

供 AI Agent 规划数据库备份策略，并为 PostgreSQL、MySQL 和 MongoDB 制定脚本、计划、保留策略及验证步骤。技能会考虑恢复需求，并对具有破坏性的恢复操作提供安全注意事项。

主要功能

  1. 01支持 PostgreSQL、MySQL 和 MongoDB
  2. 02全量、增量、差异及时间点备份
  3. 03生成压缩及可选加密脚本
  4. 04规划调度与保留策略
  5. 05完整性检查和恢复测试
  6. 06恢复安全与凭据保护注意事项

适用场景

  1. 01根据 RPO 和 RTO 规划备份
  2. 02生成定时数据库备份脚本
  3. 03设置保留期限与过期备份清理
  4. 04编写并测试数据库恢复流程

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/seb1n/awesome-ai-agent-skills --skill database-backup

安装后在 Claude Code 中输入/database-backup确认已加载。

详细介绍

数据库备份

此技能可帮助 AI Agent 针对 PostgreSQL、MySQL 和 MongoDB 规划并执行数据库备份策略。Agent 会选择合适的备份类型（完整、增量、差异或时间点），生成带压缩和加密功能的备份脚本，通过 cron 或类似工具配置自动调度，定义保留策略，并通过恢复测试验证备份完整性。

工作流

  1. 评估备份需求： 确定数据库类型、大小、可接受的数据丢失时间窗口（恢复点目标）以及可接受的停机时间（恢复时间目标）。确认备份是否必须保持一致性（使用应用层锁或快照），以及数据库是否能承受备份期间的短暂锁定。

  2. 选择备份策略： 根据需求选择合适的备份类型。完整备份会捕获整个数据库，恢复最简单，但创建速度最慢。增量备份只捕获自上次备份以来的更改，可节省时间和存储空间。差异备份会捕获自上次完整备份以来的更改，提供折中方案。时间点恢复（PITR）使用预写日志或 oplog 恢复到任意时刻，可提供最低的 RPO。

  3. 生成备份脚本： 生成调用目标数据库对应备份工具的 shell 脚本。脚本应包含压缩（gzip、lz4 或 zstd）、可选加密（GPG 或 OpenSSL）、带时间戳的文件名，以及带退出代码的错误处理。脚本还应记录输出，以便监控。

  4. 配置调度和保留策略： 使用 cron、systemd 定时器或任务调度程序设置自动执行。定义保留策略（例如，保留 7 份每日备份、4 份每周备份和 12 份每月备份），并清理过期备份以控制存储用量。

  5. 验证备份完整性： 每次备份后，确认文件非空且校验和有效。定期在预发布环境中执行测试恢复，以确认备份确实可恢复。验证失败时发出警报。

  6. 记录并监控： 记录备份计划、保留策略、存储位置和恢复流程。使用 Prometheus、Datadog 等工具或简单的电子邮件通知，为备份遗漏或失败设置监控警报。

支持的技术

  • PostgreSQL： pg_dump、pg_basebackup、用于 PITR 的 WAL 归档
  • MySQL： mysqldump、mysqlpump、Percona XtraBackup、用于 PITR 的 binlog
  • MongoDB： mongodump、mongorestore、文件系统快照、用于 PITR 的 oplog
  • 压缩： gzip、lz4、zstd、pigz
  • 加密： GPG、OpenSSL AES-256
  • 存储： 本地磁盘、AWS S3、Google Cloud Storage、Azure Blob Storage

用法

向 Agent 提供数据库类型、名称和连接详情。说明你的 RPO/RTO 要求、首选存储目标，以及是否需要加密。Agent 将生成完整的备份方案，包括脚本、调度、保留策略和验证步骤。

示例

示例 1：使用 Cron 计划执行 PostgreSQL 完整备份

请求： 设置 PostgreSQL 数据库的每夜完整备份，保留 30 天，压缩后上传到本地备份目录。

#!/usr/bin/env bash
# pg_backup.sh — Nightly PostgreSQL full backup
set -euo pipefail

DB_NAME="production"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/postgresql"
RETENTION_DAYS=30
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${TIMESTAMP}.sql.gz"

mkdir -p "$BACKUP_DIR"

echo "[$(date)] Starting backup of database '${DB_NAME}'..."
pg_dump -U "$DB_USER" -h localhost -Fc "$DB_NAME" | gzip > "$BACKUP_FILE"

# Verify the backup file is non-empty
if [ ! -s "$BACKUP_FILE" ]; then
    echo "[$(date)] ERROR: Backup file is empty. Aborting." >&2
    exit 1
fi

FILE_SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
echo "[$(date)] Backup complete: ${BACKUP_FILE} (${FILE_SIZE})"

# Clean up backups older than retention period
find "$BACKUP_DIR" -name "${DB_NAME}_*.sql.gz" -mtime +${RETENTION_DAYS} -delete
echo "[$(date)] Expired backups removed (older than ${RETENTION_DAYS} days)."

Cron 条目（每天凌晨 2:00 运行）：

0 2 * * * /usr/local/bin/pg_backup.sh >> /var/log/pg_backup.log 2>&1
示例 2：MongoDB 备份和恢复流程

请求： 备份 MongoDB 副本集并记录恢复流程。

备份脚本：

#!/usr/bin/env bash
# mongo_backup.sh — MongoDB replica set backup
set -euo pipefail

: "${MONGO_URI:?Set MONGO_URI through the secret manager or environment}"
BACKUP_DIR="/var/backups/mongodb"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DUMP_DIR="${BACKUP_DIR}/dump_${TIMESTAMP}"

mkdir -p "$BACKUP_DIR"

echo "[$(date)] Starting mongodump..."
mongodump --uri="$MONGO_URI" --oplog --out="$DUMP_DIR"

# Compress the dump directory
tar -czf "${DUMP_DIR}.tar.gz" -C "$BACKUP_DIR" "dump_${TIMESTAMP}"
tar -tzf "${DUMP_DIR}.tar.gz" >/dev/null

# Refuse cleanup unless the resolved path is the expected timestamped child.
case "$DUMP_DIR" in
  "$BACKUP_DIR"/dump_[0-9]*) rm -rf -- "$DUMP_DIR" ;;
  *) echo "Refusing unsafe cleanup path: $DUMP_DIR" >&2; exit 1 ;;
esac

echo "[$(date)] Backup complete: ${DUMP_DIR}.tar.gz"

# Retain only the last 14 backups
ls -t ${BACKUP_DIR}/dump_*.tar.gz | tail -n +15 | xargs -r rm --

恢复流程：

# 1. Extract the backup archive
tar -xzf /var/backups/mongodb/dump_20250115_020000.tar.gz -C /tmp/

# 2. Restore to the target MongoDB instance
: "${RESTORE_MONGO_URI:?Set RESTORE_MONGO_URI through the secret manager or environment}"
: "${RESTORE_TARGET_CONFIRMED:?Set RESTORE_TARGET_CONFIRMED=yes only after verifying the target is the authorized restore environment}"
[ "$RESTORE_TARGET_CONFIRMED" = "yes" ] || { echo "Restore target is not confirmed" >&2; exit 1; }
mongorestore --uri="$RESTORE_MONGO_URI" \
  --oplogReplay --drop /tmp/dump_20250115_020000/

# 3. Verify collections and document counts
mongosh --eval "db.adminCommand({listDatabases: 1})"

最佳实践

  • 定期测试恢复——从未恢复过的备份不值得信任。安排每月在预发布环境中进行恢复演练。
  • 使用 GPG 或 AES-256 加密静态和传输中的备份，尤其是在异地或云存储中保存备份时。切勿将加密密钥与备份存放在一起。
  • **使用 --oplog 标志（MongoDB）或 WAL 归档（PostgreSQL）**启用时间点恢复，从而大幅减少潜在数据丢失。
  • 将备份存储在独立的故障域中——例如另一台服务器、可用区或云区域——这样单次基础设施故障就不会同时摧毁数据库和备份。
  • 通过告警监控备份作业——没有消息不代表成功。针对缺失的备份、零字节文件或校验和不匹配的情况设置告警。
  • 记录完整的恢复流程，包括确切命令、预期耗时和负责人，这样即使压力之下也能在不猜测的情况下完成恢复。

安全与权限

  • 从检查配置和制定恢复计划开始。未经对指定环境的明确授权，不要安装计划任务、删除过期备份、上传数据或启动恢复。
  • 将 --drop 等恢复命令视为破坏性操作。确定并独立验证目标位置，确认其为预期的隔离恢复目标；在适用时，先创建恢复前的恢复点；如果目标身份不明确，则停止操作。
  • 勿将凭据写入脚本、命令输出、日志或生成的示例中。优先使用密钥管理器注入，或采用受保护的客户端配置，并为备份和恢复身份遵循最小权限原则。
  • 在恢复演练期间保留源备份及其校验和。切勿仅凭归档内容列表或校验和验证就声称数据可恢复；应验证有代表性的恢复结果和应用层不变量。

边缘情况

  • 数据库过大，超出磁盘空间： 对于大于本地可用存储空间的数据库，请将备份直接流式传输到对象存储（例如，pg_dump | gzip | aws s3 cp - s3://bucket/backup.gz），以避免本地磁盘耗尽。
  • 备份期间有活动写入流量： 使用 pg_dump 的 --snapshot 或 MongoDB 的 --oplog，即使写入仍在继续，也能获取一致的时间点备份。对于 MySQL，使用 Percona XtraBackup 对 InnoDB 进行热备份，无需加锁。
  • 加密数据库的备份： 如果启用了透明数据加密（TDE），请确保单独备份加密密钥，并确保备份过程以可恢复的格式捕获加密数据。
  • 跨区域复制延迟： 从副本备份时，请在开始备份前确认复制延迟为零或接近零，以避免捕获过期数据。
  • 备份凭据轮换： 将凭据存储在密钥管理器（Vault、AWS Secrets Manager）中，而不是硬编码到脚本里；并确保备份脚本能够处理凭据轮换，无需手动更新。

评论

支持 Markdown