G够VPS

自建集中备份服务器：一台便宜 VPS 收拢所有备份

手里 VPS 一多，备份散落在各处，丢了都不知道。小够教你用一台大硬盘便宜 VPS 做集中备份节点：专用用户、目录规划、自动拉取、保留策略，一套架构管住所有备份。

我是小够。VPS 一多，备份就乱了：A 机器的备份在 A 机器上，B 机器的 cron 半年前就挂了没人知道。集中备份服务器就是解决这个的：用一台便宜的大硬盘 VPS，专门收各台机器的备份，备份状态一眼看全。

思路

[VPS-A] --rsync over ssh--> \\
[VPS-B] --rsync over ssh-->  [备份服务器：大硬盘]
[VPS-C] --rsync over ssh--> /

备份服务器不跑业务，只存备份。选型就一个要求：硬盘大、便宜、稳定。各家都有存储型套餐，硬盘给得多，CPU 弱点无所谓，反正只存文件。

第一步：备份服务器初始化

# 建专用用户，别用 root 收备份
sudo useradd -m backupuser
sudo mkdir -p /data/backups
sudo chown backupuser:backupuser /data/backups

备份数据单独放 /data，和系统盘分开（最好是独立的数据盘），以后扩容直接加盘。

第二步：SSH 密钥打通

每台业务机器生成密钥，把公钥放到备份服务器的 backupuser 账号下。为了安全，给这个密钥加上限制——只能跑 rsync，不能登录 shell。编辑备份服务器上的 ~/.ssh/authorized_keys，在公钥前面加：

command="rrsync -ro /data/backups/",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...

这样即使某台业务机器被黑，攻击者也只能往备份目录写东西，拿不到备份服务器的 shell。rrsync 是 rsync 自带的受限封装，多数发行版都有。

第三步：业务机器推送备份

每台业务机器的备份脚本，最后加一行推送：

# 备份完成后推送到备份服务器
rsync -az --delete /backup/ backupuser@backup-server:/data/backups/vps-a/

注意 --delete 会删除目标端多余文件，备份场景小够建议不要加，宁可多占点空间，也别让一次误操作连备份一起删了。

用 systemd timer 或 cron 定在业务备份完成后半小时，错峰推送，别几台机器同时传把带宽打满。

第四步：目录规划

/data/backups/
├── vps-a/          # 每台机器一个目录
│   ├── daily/
│   ├── weekly/
│   └── monthly/
├── vps-b/
└── vps-c/

目录名用机器的用途命名（blog、shop、git），别用 IP——IP 会变，用途不变。

第五步：保留策略与校验

备份服务器上跑保留策略（GFS 轮换那套），每个机器目录独立执行。更重要的是校验：

# 每周抽查：随机挑一个备份包，解压测试
tar -tzf /data/backups/vps-a/daily/site-2025-08-10.tar.gz > /dev/null && echo "OK"

备份包打不开，等于没备份。这个检查一定要自动化，加到定时任务里，失败了发告警。

第六步：备份服务器自己也要备份

别笑，这是真事：有人把所有备份集中到一台机器，结果这台机器硬盘挂了，全没了。备份服务器的核心数据（至少是最重要的那几个包）再同步一份到对象存储。rclone 之前讲过，配一次就行。另外元数据也要留档：维护一份 README.md，记录每台机器的备份内容、频率、保留策略，跟着备份一起同步到对象存储——机器可以重建，文档丢了，备份就成了一堆不知道是谁的 tar 包。

常见问题

Q：一台备份服务器够吗？要不要两台？ A：对个人和小团队，一台 + 对象存储冷备足够了。等业务大到丢不起，再考虑双备份节点。先跑起来，别过度设计。

Q：rsync 和 rclone 哪个适合传备份？ A：机器之间用 rsync（增量快）；传到对象存储用 rclone。两个工具不冲突，各干各的活。

Q：备份服务器被黑了怎么办？ A：这就是为什么用受限密钥（rrsync）：攻击者只能写备份目录，拿不到 shell。另外备份包本身 gpg 加密了，即使被拖走也解不开。三层防护：受限密钥、加密备份、对象存储冷备。

Q：旧备份占满了磁盘怎么办？ A：先检查保留策略是不是在跑（find -mtime +N -delete 那套）。应急可以手动删最旧的，但事后一定要把自动化修好，手动删不是长久之计。

网络：安全组只开 SSH

备份服务器越简单越安全：

  • 只开 22 端口（SSH），且只允许业务机的 IP 访问
  • 其他端口全关，它不跑业务，不需要
  • SSH 只允许密钥登录，禁密码（前面讲过）

攻击面越小越好，备份服务器是"保险柜"，不是"展厅"。

监控脚本完整示例

核心就盯三件事：备份按时到达、磁盘用量、机器存活（异地心跳检测，机器失联要知道）。下面是检查脚本：

#!/bin/bash
# check-backups.sh：检查每台机器的备份是否按时到达
ALERT_EMAIL="[email protected]"
for dir in /data/backups/*/; do
    name=$(basename $dir)
    # 找最新的备份文件，看修改时间
    latest=$(find $dir -type f -name "*.tar.gz" -o -name "*.dump" | xargs ls -t 2>/dev/null | head -1)
    if [ -z "$latest" ]; then
        echo "$name: 从未收到备份！" | mail -s "备份告警" $ALERT_EMAIL
        continue
    fi
    age=$(( $(date +%s) - $(stat -c %Y "$latest") ))
    if [ $age -gt 93600 ]; then  # 26 小时
        echo "$name: 备份已 $((age/3600)) 小时未更新！" | mail -s "备份告警" $ALERT_EMAIL
    fi
done
# 顺手检查磁盘
df -h /data | awk 'NR==2 && int($5) > 80 {print "磁盘已用 "$5}'

每天跑一次，有异常就发邮件。没人看的监控等于没监控，告警一定要能触达到人。

恢复流程：写下来贴墙上

真到恢复那天，别现场想步骤。提前写好：

  1. 从备份服务器找到对应机器、对应日期的包
  2. 传到新机器（scp 或 rclone）
  3. 按备份时的文档恢复（数据库导入、文件解压、配置还原）
  4. 验证业务正常

每一步的命令都写进文档，恢复时复制粘贴。紧张的时候人是会犯低级错误的，文档是镇定剂。

成本测算

  • 存储型 VPS 一台：硬盘 1T 左右的套餐，月付通常十几到几十块
  • 对象存储冷备：几个 GB，一个月几块钱
  • 总计：一顿饭钱，换来所有机器的备份有家可归

小够的账：备份的钱不能省，但也不用多花。存储型 VPS + 对象存储，这个组合够用到业务很大的规模。

多台机器的密钥管理

业务机器一多，每台一个密钥，备份服务器的 authorized_keys 越来越长。管理建议：

  • 密钥注释写清楚是哪台机器：ssh-keygen -C "vps-blog-2025"
  • 机器下线了，立刻删掉它的公钥，别留着
  • 定期审计：authorized_keys 里每一行都对得上现役机器

密钥和员工账号一个道理：入职要加，离职要删。机器"离职"了（销毁、换商家），密钥必须同步删。

带宽规划

  • 业务机→备份服务器：走的是备份服务器的下行
  • 估算：5 台 × 每天 2GB = 10GB，错峰到凌晨 4 小时，百兆口绰绰有余
  • 真不够就再错峰：按机器分时段，01:00、02:00、03:00 排开

备份服务器的系统加固

备份服务器存着所有家当，安全级别要最高：

  1. SSH 只密钥登录，禁密码，改默认端口（前面讲过，别只依赖改端口）
  2. fail2ban 防爆破
  3. 自动安全更新开起来
  4. 除了 SSH 和必要的监控端口，防火墙全关
  5. 定期看登录日志：last、journalctl -u ssh

备份服务器被黑 = 所有备份泄露，它的安全投入产出比是最高的。

灾难场景推演

提前想好最坏的情况：

场景一：某台业务机硬盘挂了 → 从备份服务器拉对应包恢复到新机器，RTO 取决于传包速度。

场景二：备份服务器硬盘挂了 → 对象存储里有冷备，拉回来重建，平时就要确认冷备在更新。

场景三：业务机和备份服务器同时挂（机房级故障） → 所以备份服务器必须和业务机不在同一个机房，对象存储冷备是最后的救命稻草。

场景四：人为误删 → 保留策略里的历史版本顶上。--delete 没加的话，误删的文件在备份里还躺着。

每个场景每年想一遍，方案有没有短板一目了然。

从一台机器起步

别觉得"我就一台 VPS，不用搞这些"。集中备份的思想，一台机器也适用：

  • 备份服务器可以先用对象存储顶着（rclone 那套）
  • 等机器多了，再起一台存储型 VPS 做集中节点
  • 脚本和目录规范从第一天就定好，迁移时零成本

先跑起来，再迭代。

备份服务器选购要点

选型逻辑和业务机反过来：硬盘第一、配置随缘（只跑 rsync/sshd，1 核 1G 都够，1T 硬盘起步比较从容）。各家的存储型套餐就是为这个生的：硬盘给得多，其他配置寒酸，价格还便宜。

  1. 硬盘类型：备份是顺序读写为主，HDD 都够用，不用追求 NVMe。省钱
  2. 流量：备份是下行（收数据），看商家的下行流量/带宽。每天几十 GB 的量，1T 月流量起步
  3. 地区：和业务机不同机房、最好不同国家。同机房的"异地"是假异地——业务机在美国，备份机就选欧洲或亚洲；业务机在香港，备份机选美国或欧洲。原则：自然灾害、网络故障、政策风险不重叠。差一个大洲就够了，慢点没关系，半夜传完就行
  4. 商家：和业务机不同商家更好。商家整体故障时，鸡蛋不在一个篮子里

不用四个全满足，“不同机房"最重要，其他是加分项。

备份服务器的日常巡检

每周花 5 分钟：

# 1. 磁盘用了多少
df -h /data
# 2. 每台机器的最新备份是什么时候
for d in /data/backups/*/; do echo "== $d"; ls -t $d/daily 2>/dev/null | head -3; done
# 3. 服务状态
systemctl status sshd
# 4. 最近有没有异常登录
last | head -20

做成脚本+定时，比人肉靠谱。但人肉每周看一眼也有价值——机器看不懂"这个备份包怎么比平时小一半”。

备份包异常变小的告警

# 备份包突然变小，可能是源出问题了（比如数据库没导出来）
size=$(stat -c%s /data/backups/vps-a/daily/site-$(date +%F).tar.gz)
[ $size -lt 1048576 ] && echo "备份包异常小：$size bytes" | mail -s "告警" [email protected]

阈值按业务定：备份"有"不等于"对"，大小是最简单的完整性信号。

小够的总结

集中备份服务器这套架构，核心就四句话：一台大硬盘机器收拢、受限密钥保安全、保留策略自动转、监控告警盯着看。搭起来一下午，受益是长期的。机器越多，这套架构的价值越大。

备份服务器退役：数据怎么办

备份服务器也要换的时候（比如找到更便宜的）：

  1. 新机器搭好，同样的目录结构
  2. rsync -a 全量同步过去
  3. 业务机器的推送目标改成新机器
  4. 并行跑一周，确认新机器收包正常
  5. 老机器的数据保留 30 天再删

铁律：新链路跑顺之前，老链路别断。