备份与恢复

MySQL

一、前言

1. 备份文件类型与相关工具

MySQL 的备份按文件类型主要分为 逻辑备份（SQL 语句）和 物理备份（文件拷贝）。

逻辑备份适合数据量级小于 10G 的数据，相关工具有 mysqldump、mydumper（多线程，更快）。
物理备份适合数据量级非常大的数据，相关工具主要是 xtraBackup。

2. 备份方式与备份内容

而 MySQL 的备份方式主要是 全量备份+增量备份+二进制日志 共同实现。

全量备份就是将整个数据库完全备份下来
增量备份是在全量备份的基础上，做累加
二进制在生产环境中必须开启，用于记录全量或增量备份以后变化的数据，用于“基于时间点”的增量恢复。

除了数据，还需备份配置文件（通常位于 /etc/my.cnf 或 /etc/mysql/my.cnf）。

2.1 备份方式最佳实践

全量备份：每周一次（XtraBackup）。
增量备份：每日一次（XtraBackup --incremental）。
实时增量：开启 Binlog 并实时同步/备份到远程存储。这样在极端情况下，可以先通过物理备份快速“回血”，再通过 Binlog 精确恢复到故障前的最后一秒。

3. 关于数据恢复

数据恢复流程应为：

全量备份 –> 增量备份（增量一 -> 增量二 -> 增量N… ） –> 二进制日志（恢复全量或增量备份以后变化的数据）

二、注意事项

版本问题：

MySQL 5.7 与 8.0 差异巨大，在跨版本恢复（如从 5.7 到 8.0）时使用 XtraBackup 不适合，需要使用 mysqldump 或 mydumper 逻辑备份。
使用不同的工具进行备份/恢复时，要注意版本兼容性，可通过以下命令验证版本：
- mysqldump -V
- mydumper -V
- xtrabackup -v
- 通常大版本号相同就行，例如5.7与8.0

不要备份系统库：

GitLab

一、前言

GitLab 的完全备份实际上包含两部分：数据备份（由 GitLab 提供的工具完成）和 配置文件备份（必须手动完成）。

如果 GitLab 通过 apt/yum 安装，可根据下面的方式进行备份。

二、注意事项

版本必须一致：

恢复备份时，新服务器上的 GitLab 版本必须与创建备份时的版本完全一致。

密钥文件至关重要：

/etc/gitlab/gitlab-secrets.json 包含数据库加密密钥。如果丢失此文件，即使有数据备份，你也无法恢复（数据将无法解密）。

三、手动备份

一个完整的备份包含两个步骤：命令备份数据 + 手动备份配置。

1. 备份数据

GitLab 提供了一个内置命令来打包所有数据。

# 运行备份命令
sudo gitlab-backup create

# 如果用的是 Docker 部署
# docker exec -t <container_name> gitlab-backup create

默认存放路径： /var/opt/gitlab/backups/
生成文件： 类似 1768201492_2026_01_12_15.9.2_gitlab_backup.tar。文件名包含了时间戳和 GitLab 版本号。

2. 备份配置文件

GitLab 的备份命令不会备份配置文件。需要手动保存 /etc/gitlab 目录下的关键文件。

/etc/gitlab/gitlab.rb (主配置文件)
/etc/gitlab/gitlab-secrets.json (绝对核心文件，丢失无法恢复数据)
/etc/gitlab/ssl/ (如配置了 HTTPS 证书)
/etc/gitlab/ssh_host_keys/ (可选，防止用户端 SSH 报错)

四、自动化备份并存放至远程 MinIO

生产环境中，手动备份容易遗忘，因此需要通过定时任务定时备份。

Kubernetes

一、前言

在 Kubernetes 生产环境中，仅备份 etcd 并不足以实现应用级的快速恢复。本文档详细整理了基于 Velero 的集群备份与恢复方案。

Velero 是一个云原生灾备工具，支持 K8s 资源对象（YAML）和持久化卷数据（PV）的统一备份：

方案一：Restic/Kopia（文件系统级备份）

原理：通过在每个节点运行 Pod 访问本地挂载卷，直接读取文件并上传至对象存储。
适用场景：任何支持挂载的存储（NFS, Ceph, HostPath 等）、跨云平台迁移、无快照能力的存储。
特点：通用性强，但对于海量小文件备份速度较慢。

方案二：Volume Snapshot（存储快照级备份）

原理：调用云厂商或存储侧的 CSI 快照接口进行物理备份。
适用场景：公有云环境（EBS, OSS, Azure Disk）、支持 CSI 快照的私有化存储（Ceph, NetApp）。
特点：备份/恢复速度极快，性能损耗小，但依赖底层存储硬件能力。

二、注意事项

Namespace 映射：

在将备份恢复到新集群时，可以实现 Namespace 的重新命名映射。

存储类（StorageClass）兼容性：

如果原集群和目标集群的 StorageClass 名称不一致，需在恢复时配置 configmap 进行映射转换。

备份 Hooks：

对于有状态应用（如 MySQL/ES），备份前应通过 Pre-backup Hook 执行 flush tables with read lock，确保数据一致性。

插件版本一致性：

Velero 客户端版本、服务端版本以及对应的插件（如 AWS/MinIO 插件）版本需严格匹配。

三、环境部署

1. 安装 Velero 客户端

# 下载二进制包
wget https://github.com/vmware-tanzu/velero/releases/download/v1.12.0/velero-v1.12.0-linux-amd64.tar.gz
tar -xvf velero-v1.12.0-linux-amd64.tar.gz
mv velero /usr/local/bin/ && velero version --client

2. 初始化 Velero 服务端（以 MinIO 为例）

install_velero.sh

# 准备 MinIO 凭证
cat > credentials-velero <<EOF
[default]
aws_access_key_id = minioadmin
aws_secret_access_key = minioadmin
EOF

# 执行安装
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.7.0 \
  --bucket k8s-backup \
  --secret-file ./credentials-velero \
  --use-node-agent \
  --use-volume-snapshots=false \
  --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio-service.storage.svc:9000

四、备份操作

1. 手动执行备份

1.1 备份整个 Namespace

# 备份 production 命名空间，并保留 72 小时
velero backup create backup-prod-$(date +%Y%m%d) \
  --include-namespaces production \
  --ttl 72h0m0s

1.2 带有选择器的特定资源备份

velero backup create app-backup \
  --selector app=nginx \
  --include-resources deployments,configmaps

2. 自动化定时备份 (Schedule)

类似于 ES 的 SLM 策略，Velero 通过 Schedule 对象实现周期性备份。

Elasticsearch

一、前言

Elasticsearch 的数据安全至关重要。本文档详细整理了两种主流的生产级备份与恢复方案，分别适用于不同的业务场景和数据规模：

方案一：Elasticdump（轻量级迁移/备份）

原理：通过 API 抓取数据并导出为 JSON 文件。
适用场景：数据量较小（GB 级以下）、单索引迁移、跨版本/跨集群迁移、无需复杂环境配置的场景。
特点：部署简单，但备份和恢复速度较慢。

方案二：Snapshot 快照（生产级灾备）

原理：基于文件系统的物理增量备份（官方推荐）。
适用场景：海量数据（TB/PB 级）、集群全量备份、定时自动化灾备。
特点：备份/恢复速度极快（直接复制底层文件），支持增量，但需要配置共享存储（如 NFS、S3）。

三、注意事项

跨版本恢复：

快照只能恢复到相同版本或更高版本的 ES 中；
在将低版本数据恢复到高版本 ES 时（例如 ES 7.10 的快照 -> 恢复到 ES 8.x）通常可以，但跨大版本还是需查阅官方迁移指南。

索引别名：

如果索引有别名，恢复后需要手动添加别名。

索引副本数：

如果新旧集群架构不同（例如：旧集群是 5 个节点，新集群只有 1 个节点），直接恢复可能会导致索引变成红色（Red），因为副本数（Replicas）无法满足。可以在恢复时动态修改索引设置：

# 示例：恢复时强制将副本数设为 0（适合单节点新集群）
curl -X POST "New_ES_IP:9200/_snapshot/nfs_backup/outer/_restore?pretty" -H 'Content-Type: application/json' -d'
{
  "indices": "mtproxy,chat,user...",
  "include_global_state": false,
  "index_settings": {
    "index.number_of_replicas": 0
  }
}
'

三、使用 elasticdump

1. 安装 elasticdump

在能连通 ES 集群的机器安装

# 1. 安装 npm
apt-get install -y nodejs npm

# 2. 全局安装 elasticdump
npm install elasticdump -g

# 3. 验证安装
elasticdump --version

2. 备份数据

2.1 准备备份脚本

backup_es.sh

#!/bin/bash

# --- 0. 默认配置 ---
DEFAULT_ES_URL="http://172.16.30.111:9200"
DEFAULT_ROOT_DIR="/root/es_backup"

# --- 1. 交互式输入 ES 地址 ---
echo "----------------------------------------"
read -p "请输入 ES 地址 [默认: ${DEFAULT_ES_URL}]: " USER_ES_URL
ES_URL=${USER_ES_URL:-$DEFAULT_ES_URL}

# --- 2. 交互式输入索引名 ---
read -p "请输入要备份的 Index 名称 (例如 message): " INDEX_NAME

# 如果输入为空，则退出
if [ -z "$INDEX_NAME" ]; then
    echo "❌ 错误: 索引名不能为空！"
    exit 1
fi

# --- 3. 交互式输入备份目录 ---
# 定义默认完整路径
DEFAULT_FULL_PATH="${DEFAULT_ROOT_DIR}/${INDEX_NAME}"

read -p "请输入保存目录 [默认: ${DEFAULT_FULL_PATH}]: " USER_DIR
BACKUP_DIR=${USER_DIR:-$DEFAULT_FULL_PATH}

# --- 4. 确认与准备 ---
LOG_FILE="${BACKUP_DIR}/backup_${INDEX_NAME}.log"

echo "----------------------------------------"
echo "🚀 任务概览:"
echo "   ES 地址:  ${ES_URL}"
echo "   目标索引: ${INDEX_NAME}"
echo "   保存路径: ${BACKUP_DIR}"
echo "   日志文件: ${LOG_FILE}"
echo "----------------------------------------"

# 创建目录
mkdir -p "$BACKUP_DIR"
if [ $? -ne 0 ]; then
    echo "❌ 错误: 无法创建目录 $BACKUP_DIR"
    exit 1
fi

# --- 5. 开始备份 Mapping (前台运行，很快) ---
echo "Step 1/2: 正在备份 Mapping..."
elasticdump \
  --input="${ES_URL}/${INDEX_NAME}" \
  --output="${BACKUP_DIR}/${INDEX_NAME}_mapping.json" \
  --type=mapping \
  --quiet

if [ $? -eq 0 ]; then
    echo "✅ Mapping 备份成功"
else
    echo "❌ Mapping 备份失败，停止后续任务。"
    exit 1
fi

# --- 6. 自动后台化 (Tmux Auto-Detach) ---
echo "Step 2/2: 准备备份 Data..."

if [ -n "$TMUX" ]; then
    echo "----------------------------------------"
    echo "✨ 检测到 Tmux 环境！"
    echo "👋 脚本将在 10秒后 自动将本会话挂起至后台 (Detach)。"
    echo "   备份任务将继续运行，你可以放心去处理别的事情。"
    echo "   如果想查看进度，请稍后执行: tmux attach"
    echo "   或者直接查看日志: tail -f ${LOG_FILE}"
    echo "----------------------------------------"
    sleep 10
    # 核心魔法：将当前客户端从 tmux 会话中断开，但保持会话运行
    tmux detach
else
    echo "⚠️ 未检测到 Tmux 环境，将继续在前台运行..."
    echo "   (如果你关闭这个窗口，备份可能会中断！)"
fi

# --- 7. 开始备份 Data (后台/隐身运行) ---
# 注意：我们把输出重定向到了日志文件，防止在这里输出没人看
echo "[$(date)] 开始备份 Data..." > "$LOG_FILE"

elasticdump \
  --input="${ES_URL}/${INDEX_NAME}" \
  --output="${BACKUP_DIR}/${INDEX_NAME}_data.json" \
  --type=data \
  --limit=1000 \
  --scrollTime=20m \
  --fileSize=1gb \
  --ignore-errors=true \
  --fsCompress=true  >> "$LOG_FILE" 2>&1

# 检测备份是否成功
if grep -q "dump complete" "$LOG_FILE"; then
    echo "" >> "$LOG_FILE"
    echo "========================================" >> "$LOG_FILE"
    echo "[$(date)] ✅ 检测到 'dump complete'，备份成功！" >> "$LOG_FILE"
    
    # 成功了才记录版本
    VERSION_FILE="${BACKUP_DIR}/version.txt"
    echo "Index: $INDEX_NAME" > "$VERSION_FILE"
    echo "Date: $(date)" >> "$VERSION_FILE"
    curl -s "$ES_URL" >> "$VERSION_FILE"
else
    echo "" >> "$LOG_FILE"
    echo "========================================" >> "$LOG_FILE"
    echo "[$(date)] ❌ 未检测到 'dump complete'，备份失败！" >> "$LOG_FILE"
    echo "请检查上方日志中的报错信息。" >> "$LOG_FILE"
fi

2.2 使用备份脚本

新建 Tmux 会话：

tmux new -s es_backup_message

运行脚本：

bash backup_es.sh

按提示输入：

ES 地址：(直接回车用默认)
索引名：message
备份目录：/root/es_backup/message