服务器挂了、数据丢了，网站就没了——这就是大家常说的“跑路风险”。服务器数据备份策略不是拿张纸记下来，而是真刀真枪地写脚本、配定时任务，确保哪天出事能立刻恢复。

这篇文章用最直接的方式，带你把备份流程彻底跑通，所有命令和设备路径都写进去了，照着做就行。

前置准备

在动手之前，先把下面这些东西确认好，否则后面容易卡壳。

• 一台 Linux 服务器（本文以 CentOS 7+ / Ubuntu 20.04+ 为例）


• SSH 登录权限，能执行 sudo 命令


• 目标存储空间：本地另一个硬盘分区（比如 /data/backup）或远程服务器（通过 SSH 密钥免密登录）


• 宝塔面板用户：从宝塔后台“计划任务”添加备份任务也可以，但建议同时了解命令操作，方便排查


• 基础命令常识：知道 ls、cd、mkdir 即可，本文会给出完整命令片段

重点注意：备份文件不要放在系统盘，否则一旦系统盘损坏，连备份一起带走。

分步操作

第一步：创建备份目录并设置权限

在非系统盘（比如数据盘 /data）下建个备份文件夹：

sudo mkdir -p /data/backup

sudo chmod 700 /data/backup

chmod 700 表示只有 root 能读写执行，安全性更高。

第二步：编写备份脚本（全量 + 增量）

创建一个脚本文件 backup.sh，内容如下（注意替换你自己的路径）：

#!/bin/bash

服务器数据备份策略核心脚本：全量+增量
SOURCE_DIR="/var/www/html"   # 要备份的网站或数据目录

BACKUP_DIR="/data/backup"    # 备份存储目录

DATE=$(date +%F_%H%M)

LOG="/var/log/backup.log"
全量备份（每周日执行，文件名带全量标记）
if [ "$(date +%u)" -eq 7 ]; then

tar -czf "${BACKUP_DIR}/full_${DATE}.tar.gz" "$SOURCE_DIR" 2>>$LOG

echo "[$(date)] 全量备份完成: full_${DATE}.tar.gz" >> $LOG

else
增量备份：使用 rsync 同步变化文件，保留完整目录结构
rsync -av --delete "${SOURCE_DIR}/" "${BACKUP_DIR}/incremental/" >> $LOG 2>&1

echo "[$(date)] 增量备份完成" >> $LOG

fi
删除7天前的备份文件（保留足够恢复点）
find "$BACKUP_DIR" -name "full_*.tar.gz" -mtime +7 -exec rm {} \;

解释：

• tar -czf 制作全量压缩包，每周日运行一次。


• 其他日子用 rsync 做增量同步，只复制修改过的文件，速度快。


• --delete 保证目标目录与源完全一致，删除源已删的文件（避免垃圾堆积）


• 自动删除7天以上的全量包，节省空间

第三步：设置定时任务（cron）

sudo chmod +x /root/backup.sh

sudo crontab -e

在打开的编辑器中添加以下行，代表每天凌晨3点执行：

0 3 * * * /root/backup.sh

保存退出。

如果想查看是否生效，可以运行：

crontab -l

宝塔面板用户的操作路径（免命令版）

如果你用的是宝塔面板，同样能实现服务器数据备份策略：

1. 登录宝塔后台 → 左侧“计划任务”


2. 点击“添加任务”

• 任务类型：Shell脚本


• 执行周期：每天（可以选0点或3点）


• 脚本内容：直接粘贴上面的 backup.sh 脚本内容（记得修改路径）

1. 点击“添加”后，可以手动“执行”一次测试

重要：宝塔的计划任务默认以 www 用户执行，如果备份目录需要 root 权限，请把脚本放在 root 用户下，或用 sudo。

避坑指南

| 常见错误 | 原因 | 解决办法 |

|----------|------|----------|

| tar: 无法打开 /var/www/html: 权限不允许 | 脚本运行用户权限不足 | 用 sudo 执行脚本，或把脚本所有者改为 root |

| rsync: connection refused | 远程备份时 SSH 端口不对或服务未启动 | 检查目标机器 SSH 是否运行，端口是否22，或改用 -e 'ssh -p 2222' 指定端口 |

| 备份文件越来越大，磁盘空间报警 | 增量备份未清理历史版本 | 脚本中增加 find 清理逻辑（已写在上面）或使用 -b 选项保留有限份数 |

| crontab 任务未执行 | cron 服务未启动或脚本路径错误 | 执行 systemctl status crond（CentOS）或 systemctl status cron（Ubuntu）检查服务状态 |

一句话避坑： 先手动执行一遍脚本，确认没有任何报错，再添加 crontab。

高频问题解答

Q1：有没必要备份数据库？怎么一起备份？

A：当然需要。可以在同一个脚本里追加 MySQL 或 MariaDB 的导出命令，例如：

mysqldump -u root -p'密码' --all-databases > "${BACKUP_DIR}/db_${DATE}.sql"

建议数据库导出后也压缩，并进入备份文件统一管理。

Q2：能不能只做增量不做全量？

A：虽然可以，但不推荐。全量备份是灾难恢复的基石，增量备份依赖于上一次全量或增量链。如果你连续增量几个月，一旦中间一个增量文件损坏，后面全废。建议每周一次全量，每天一次增量。

Q3：备份到远程服务器需要怎么配置？

A：将脚本中的目标路径改为 user@remote_ip:/backup/，并提前配置 SSH 密钥免密登录。具体命令：

ssh-keygen -t rsa -b 4096

ssh-copy-id user@remote_ip

注意rsync命令要改成：

rsync -avz --delete -e ssh "$SOURCE_DIR/" "user@remote_ip:/backup/incremental/"

Q4：怎样确认备份文件是可用的？

A：定期（比如每月一次）解压一个全量备份到临时目录，对比文件数量、MD5 校验。建议在脚本最后加入：

# 校验最近一次全量备份的完整性

echo "$(date) 校验全量包: "; tar -tzf "${BACKUP_DIR}/full_$(date +%F).tar.gz" | head -5

如果解压失败，立即发告警邮件或钉钉通知。

效果验证

完成配置后，不要直接走人，做以下检查：

1. 手动执行一次脚本

   sudo /root/backup.sh

查看 /var/log/backup.log 中是否有“备份完成”字样。

1. 检查备份文件是否存在

   ls -lh /data/backup/

应该能看到 full_ 开头的压缩包或 incremental/ 目录。

1. 模拟恢复测试（重要）

   # 将全量备份解压到一个测试目录

sudo tar -xzf /data/backup/full_20250315_0300.tar.gz -C /tmp/test_restore/

du -sh /tmp/test_restore/

如果大小和源目录一致，说明备份可靠。

1. 查看 crontab 是否生效

   tail -f /var/log/cron  # CentOS

或 Ubuntu:
tail -f /var/log/syslog | grep CRON

看到类似 (root) CMD (/root/backup.sh) 的输出就对了。

最后的建议： 服务器数据备份策略一旦设定好，要定期（比如每月一次）拔出备份硬盘或远程下载一个备份文件到本地验证。

不要等出事了才发现备份文件是坏的。

如果你在配置中遇到任何报错，优先回看避坑部分，再对照高频问题解决。

坚持执行这套方法，你的服务器数据就有了真正的“保险”。