4、文件系统备份：rsync同步、tar归档、对象存储(S3/MinIO)备份方案

文件系统备份，说白了就是把你服务器上的文件和目录，安全地复制到别处去。这是最基础、也是最常用的备份手段。我做了这么多年运维，遇到过各种奇葩的数据丢失场景——误删、硬盘坏道、勒索病毒……每次都是靠文件系统备份救回来的。

今天咱们就聊聊三种主流的文件系统备份方案：rsync同步、tar归档、对象存储(S3/MinIO)备份。这三种方案各有千秋，适用场景也不同。我个人习惯是组合使用，取长补短。

4.1 rsync同步：增量备份的利器

rsync 是我最常用的工具之一。它的核心优势是增量传输——只同步变化的部分，而不是每次都全量复制。这在带宽有限、数据量大的场景下，简直是救命稻草。

我记得有一次，一个客户的日志服务器每天产生几十GB的日志文件。如果用全量备份，带宽根本扛不住。后来我用 rsync 做增量同步，每天只传几MB的差异数据，问题就解决了。

4.1.1 基本用法

# 本地同步
rsync -avz /source/dir/ /destination/dir/

# 远程同步（推送到远程）
rsync -avz /source/dir/ user@remote:/destination/dir/

# 远程同步（从远程拉取）
rsync -avz user@remote:/source/dir/ /destination/dir/

参数说明：

  • -a：归档模式，保留权限、时间戳、符号链接等属性
  • -v：显示详细信息
  • -z：传输时压缩，节省带宽
  • --delete：删除目标端多余的文件，保持两端完全一致
⚠️ 注意： 源目录末尾的斜杠 / 很关键。有斜杠表示同步目录内的内容，没有斜杠表示同步目录本身。我曾经因为这个细节，把整个目录结构搞乱了，折腾了半天才恢复。

4.1.2 增量备份脚本

实际项目中，我通常会写一个脚本，配合 cron 定时执行：

#!/bin/bash
# 每日增量备份脚本
SOURCE="/data/app"
BACKUP_DIR="/backup/app"
DATE=$(date +%Y%m%d)

# 创建当天的备份目录
mkdir -p $BACKUP_DIR/$DATE

# 使用 --link-dest 实现增量备份
rsync -avz --delete --link-dest=$BACKUP_DIR/latest $SOURCE $BACKUP_DIR/$DATE

# 更新 latest 软链接
rm -f $BACKUP_DIR/latest
ln -s $BACKUP_DIR/$DATE $BACKUP_DIR/latest

这个脚本的精髓在于 --link-dest 参数。它利用硬链接技术，让每天的备份看起来像全量备份，但实际上只存储变化的部分。你想想看，既保留了全量备份的便利性，又节省了存储空间，多划算。

4.2 tar归档：打包压缩，便于存储

tar 是 Linux 下最经典的归档工具。它的强项是把一堆文件打包成一个文件，再配合压缩算法，能大幅减小体积。我一般用 tar 做全量备份，然后存到冷存储或者对象存储里。

为什么会这样？因为 tar 打包后的文件是单一的，便于管理、传输和加密。而且 tar 支持管道操作，可以跟其他工具无缝配合。

4.2.1 常用命令

# 创建 tar 归档并压缩
tar -czf backup.tar.gz /data/app

# 创建 tar 归档并压缩（使用 bzip2，压缩率更高）
tar -cjf backup.tar.bz2 /data/app

# 解压
tar -xzf backup.tar.gz -C /restore/dir

# 查看归档内容
tar -tzf backup.tar.gz

参数说明：

  • -c：创建归档
  • -x：解压归档
  • -z：通过 gzip 压缩
  • -j：通过 bzip2 压缩
  • -f：指定归档文件名
💡 小技巧： 如果文件数量特别多（比如几十万个），tar 的打包过程可能会很慢。我建议先用 find 命令筛选出需要备份的文件，再通过管道传给 tar，这样能提高效率。

4.2.2 分卷压缩与加密

有时候备份文件太大，单个文件不好传输。这时候可以用分卷压缩：

# 分卷压缩，每卷 1GB
tar -czf - /data/app | split -b 1G - backup.tar.gz.part

# 合并并解压
cat backup.tar.gz.part* | tar -xzf - -C /restore/dir

如果备份的是敏感数据，我建议加上加密：

# 使用 openssl 加密
tar -czf - /data/app | openssl enc -aes-256-cbc -salt -out backup.tar.gz.enc

# 解密并解压
openssl enc -d -aes-256-cbc -in backup.tar.gz.enc | tar -xzf - -C /restore/dir

嗯，这里要注意：加密的密码一定要妥善保管。我曾经见过有人把密码写在脚本里，结果脚本泄露了，整个备份形同虚设。

4.3 对象存储(S3/MinIO)备份方案

对象存储是云原生时代的标配。S3 是 AWS 的对象存储服务，MinIO 是开源的兼容 S3 的解决方案。它们的优势是高可用、可扩展、按需付费。

我个人习惯把 tar 归档后的文件，或者 rsync 同步后的目录，定期上传到对象存储。这样既利用了对象存储的可靠性，又保留了本地备份的灵活性。

4.3.1 使用 AWS CLI 上传到 S3

# 上传单个文件
aws s3 cp backup.tar.gz s3://my-bucket/backups/

# 同步目录到 S3
aws s3 sync /backup/dir s3://my-bucket/backups/

# 从 S3 下载
aws s3 sync s3://my-bucket/backups/ /restore/dir

aws s3 sync 命令跟 rsync 类似，也是增量同步。它会自动对比本地和远程的文件，只上传变化的部分。

4.3.2 使用 MinIO 客户端

MinIO 的客户端叫 mc，用法跟 AWS CLI 几乎一样：

# 配置 MinIO 服务
mc alias set myminio http://minio.example.com:9000 access_key secret_key

# 上传文件
mc cp backup.tar.gz myminio/my-bucket/backups/

# 同步目录
mc mirror /backup/dir myminio/my-bucket/backups/

# 下载
mc mirror myminio/my-bucket/backups/ /restore/dir
🔑 关键点： 对象存储的备份策略，我建议采用「生命周期管理」。比如：最近7天的备份保留在标准存储，7-30天的备份自动转为低频存储，30天以上的备份转为归档存储。这样能大幅降低成本。

4.3.3 备份策略对比

方案 适用场景 优点 缺点
rsync 本地或远程增量同步 增量传输、速度快、节省带宽 依赖网络、需要目标端存储
tar 全量打包、归档存储 单一文件、便于管理、支持加密 全量备份、耗时较长
对象存储 云端备份、异地容灾 高可用、可扩展、按需付费 依赖网络、有存储成本

4.4 实战建议：组合使用

在实际项目中，我很少只用一种方案。通常的做法是：

  1. 日常增量备份：用 rsync 每小时或每天同步到本地备份服务器
  2. 每周全量归档：用 tar 打包全量数据，压缩后存到本地
  3. 异地容灾：将 tar 归档文件上传到 S3 或 MinIO，实现异地备份

我曾经遇到过一个案例：客户的本地备份服务器被勒索病毒加密了，幸好我们还有一份备份在 MinIO 上，直接从对象存储恢复，避免了数据丢失。从那以后，我坚持「本地+异地」的双重备份策略。

⚠️ 避坑指南： 我曾经因为忘记测试恢复流程，导致备份文件损坏了半年都没发现。所以，定期做恢复演练非常重要。建议每个月至少做一次完整的恢复测试，确保备份文件是可用的。

好了，文件系统备份的三种方案就聊到这里。rsync 适合增量同步，tar 适合全量归档，对象存储适合异地容灾。你想想看，如果能把这三种方案组合起来，基本上就能覆盖大部分的数据保护需求了。

← 上一章 📖 返回目录 下一章 →