云服务器配置指南（十）：运维与维护——让服务器长治久安

发表于 2025-12-06 更新于 2025-12-12 分类于技术，云服务器配置指南本文字数： 1.8k 6 mins

这是《云服务器配置指南》系列的最后一篇。如果说前面的九篇是在教你如何“生”出一个功能强大的服务器，那么这一篇就是教你如何“养”好它。

很多新手（包括当年的我）都有一个误区：服务部署好了，能跑了，就万事大吉了。直到某天半夜，磁盘被日志塞满，或者数据库文件损坏且没有备份，才痛心疾首。

运维（Operations）不是只有大公司才需要的，个人服务器同样需要精心呵护。今天我们不谈高大上的DevOps理念，只谈最接地气的：怎么让你的服务器不挂，挂了能救，救不回来能跑路。

一、日志：你的“黑匣子”

当服务器出现异常时，日志是你唯一的线索。学会看日志，是运维的第一课。

1. 系统级日志：journalctl

现在的 Linux 发行版大多使用 systemd，journalctl 是查看系统日志的神器。

# 实时查看系统发生了什么（类似 tail -f）
journalctl -f

# 查看某个服务为什么启动失败（比如 sshd）
journalctl -u ssh -n 50 --no-pager

# 查看红色的报错信息（只看 error 级别）
journalctl -p err -b

经验之谈：如果你的 SSH 突然连不上了，或者某个服务莫名其妙挂了，先看 journalctl -xe，通常答案就在最后几行。

2. 容器日志：docker logs

对于 Docker 部署的服务，日志管理相对简单。

# 实时查看容器日志
docker logs -f <container_name>

# 只看最近的 100 行（日志太长时很有用）
docker logs --tail 100 <container_name>

坑点预警：Docker 默认的日志驱动是 json-file，如果不加限制，它会无限增长，直到吃光你的磁盘空间。我在第一篇里提到的 Docker 配置中已经加了 max-size 限制，如果你没加，赶紧去补上。

3. 关键应用日志：Nginx

Nginx 是流量的入口，它的日志价值极高。

Access Log (access.log)：谁访问了你？访问了什么？状态码是多少？
Error Log (error.log)：Nginx 为什么报错？配置哪里写错了？

# 看看谁在疯狂扫描你的服务器
tail -f ~/nginx/logs/access.log

# 统计一下访问最多的 IP（简单的流量分析）
awk '{print $1}' ~/nginx/logs/access.log | sort | uniq -c | sort -rn | head -10

二、备份：运维的底线

没有备份的数据，就是垃圾。 这句话虽然难听，但是真理。不要相信云服务商的“99.99% 可靠性”，数据掌握在自己手里才最安全。

1. 备份什么？

配置文件：docker-compose.yml，Nginx 配置，.env 文件。这些丢了，你得重新配一遍，很痛苦。
持久化数据：数据库文件（MySQL/PostgreSQL 的 data 目录），应用上传的文件（如 WordPress 的 uploads）。这些丢了，就是真的丢了。

2. 怎么备份？（自动化脚本）

手动备份是不靠谱的，人总会懒惰。我们需要一个脚本，配合 crontab 自动执行。

这是一个我常用的简单备份脚本 backup.sh：

#!/bin/bash

# 定义备份目录和时间
BACKUP_ROOT=~/backups
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR=$BACKUP_ROOT/$DATE
RETENTION_DAYS=7  # 保留最近7天的备份

mkdir -p $BACKUP_DIR

echo "[$(date)] 开始备份..."

# 1. 备份 Nginx 配置
tar -czf $BACKUP_DIR/nginx_conf.tar.gz -C ~ nginx/

# 2. 备份关键应用数据 (以 uptime-kuma 为例)
# 注意：对于数据库，最好先 dump 出来再备份文件，或者在低峰期停机备份
tar -czf $BACKUP_DIR/uptime-kuma.tar.gz -C ~ uptime-kuma/

# 3. 备份 Docker Compose 文件
tar -czf $BACKUP_DIR/compose_files.tar.gz -C ~ --exclude='*/data' --include='*/docker-compose.yml' .

# 4. 删除旧备份
find $BACKUP_ROOT -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} +

echo "[$(date)] 备份完成：$BACKUP_DIR"

然后设置定时任务（crontab -e），每天凌晨 3 点执行：

1	0 3 * * * /bin/bash /root/backup.sh >> /root/backup.log 2>&1

3. 异地备份（3-2-1 原则）

备份放在本地硬盘上是不够的。万一服务器硬盘坏了，或者被黑客勒索了，本地备份也一起完蛋。

最简单的异地备份：使用 rclone 同步到 Google Drive、OneDrive 或阿里云 OSS。

# 安装 rclone
curl https://rclone.org/install.sh | sudo bash

# 配置（按提示操作）
rclone config

# 在备份脚本最后加上这一行
rclone sync $BACKUP_ROOT remote:myserver-backups

三、监控：给服务器装上仪表盘

你不能总是等到网站打不开了才发现服务器挂了。你需要一双眼睛，替你盯着服务器。

1. 轻量级命令行工具

htop：比 top 好看且好用。一眼就能看出是哪个进程在吃 CPU。
btop：比 htop 更炫酷，界面极具极客感，信息量巨大。强烈推荐安装体验一下。
ncdu：磁盘空间分析神器。当磁盘满了，用它能迅速找出是哪个文件夹在占用空间。

1
2
3

apt install htop ncdu -y
# btop 可能需要手动安装或通过 snap 安装
snap install btop

2. 可视化监控面板

我们在第七篇中部署的 Uptime Kuma 是外部监控（从外面看网站活没活）。

如果你想监控服务器内部状态（CPU、内存、网速），推荐 Netdata 或 Beszel（最近很火的轻量级监控）。

这里推荐一个极简方案：Glances。它既可以在终端跑，也可以起一个 Web 服务。

# 临时查看
glances

# 启动 Web 模式
glances -w
# 然后访问 http://ip:61208

四、常见故障排查手册

1. 磁盘满了 (No space left on device)

这是最常见的问题。

定位大文件：运行 ncdu /，通常是 /var/lib/docker (Docker 镜像/容器) 或 /var/log (日志) 占了大头。

清理 Docker：

1 2	# 慎用！这会删除所有未使用的镜像、容器和网络 docker system prune -a

清理日志：

1 2	# 清理 systemd 日志，只保留最近 100M journalctl --vacuum-size=100M

2. 内存爆了 (OOM Killer)

如果你的 MySQL 或 Java 应用突然挂了，日志里也没报错，很可能是被 Linux 的 OOM (Out of Memory) Killer 杀掉了。

查看证据：dmesg | grep -i "out of memory"
解决办法：
- 增加 Swap 分区（我们在第一篇里做过）。
- 限制容器内存：在 docker-compose.yml 中添加 mem_limit。
- 升级服务器配置（加钱）。

3. CPU 100%

找出元凶：运行 htop，按 P 按 CPU 使用率排序。
分析原因：
- 如果是 kswapd0 占用高，说明内存不足，系统在疯狂交换内存。
- 如果是某个应用进程，查看其日志。
- 如果是莫名其妙的进程（如 xmrig），恭喜你，你被挖矿了。赶紧断网、杀进程、查 Crontab、查 SSH 密钥，或者直接重装系统。

结语：服务器的生命周期

至此，我们的《云服务器配置指南》系列就完结了。

从购买服务器、配置 SSH 安全、搭建 Docker 环境，到部署 Nginx、博客、AI 服务，最后到今天的运维监控。你已经掌握了从零打造一个现代化个人服务器的全套技能。

这台服务器，现在是你的代码游乐场，是你的数据保险箱，也是你探索数字世界的基地。

技术在变，工具在变，但折腾的心不变。希望这台服务器能陪你走得很远。

Happy Hacking!

一、 日志：你的“黑匣子”