Linux 实用工具实战指南：压缩、网络传输与系统排查

在日常服务器维护和团队协作里，我见过不少人不是不会敲命令，而是遇到实际任务时不知道把哪些命令串起来用。最典型的一幕是：要给一台远程服务器传一个大目录，有人会在笔记本上下载下来再上传，中间还要经过 Windows 图形界面，结果几十 GB 数据传了整整一天。而这件事在 Linux 下本来几行命令就能完成。另一幕则是“磁盘满了就删文件，删了半天 df 一看还是 100%”，最后才发现问题根本不在文件大小上，而是一个被进程占用、已经标记删除的文件还没释放空间。

这篇Linux指南把三个高频场景拆开讲：压缩、网络传输、系统工具。不是罗列命令大全，而是重点说明每个工具解决什么问题、为什么这么选、实战里有哪些坑。无论你是刚接触服务器的新手，还是想补全 Linux 操作拼图的开发或运维，这篇文章都能给你一套可落地的操作思路。

1. 先说清楚三个方向到底在解决什么问题

1.1 很多人不缺命令，缺的是组合思维

Linux 的设计哲学是小工具做大事情。tar、gzip、scp、rsync、df、free、lsof，每个命令单独看都不复杂，但真实工作里几乎没有哪件事是单个命令独立完成的。

举一个最常见的场景：你想把 /var/www 下的站点备份到另一台机器上。听起来简单，但实际要考虑的事情包括：目录里有没有需要排除的日志文件、用什么压缩算法能在时间和体积之间取得平衡、传输过程中断网怎么办、传完之后如何确认两边文件一致。这一串问题分别由 tar、gzip/zstd、rsync、sha256sum 来解决，而不是靠某一个“万能命令”。

再比如排查“磁盘满了”。正确顺序通常是先 df -h 确认哪个分区满，再 du -sh 找出哪里占用最多，找到大文件后还要确认它是否正被进程占用。如果你跳过判断直接删文件，很容易删了个寂寞。工具还是那些工具，关键是判断动作的顺序不能反。

1.2 你的使用阶段决定你该关注什么

这篇文章的内容是按使用程度分层设计的。

• 如果你刚开始接触 Linux，先掌握 tar、gzip、scp、df、free 的基础用法，能够完成“打包、传输、看资源”的基本闭环。
• 如果你日常需要维护服务器，rsync 的增量同步、zstd 压缩算法、systemd 日志查询、lsof 排查占用是必须补上的能力。
• 如果你经常折腾虚拟机或大数据量备份，那 qcow2 镜像压缩、断点续传、双端校验这些进阶技巧会直接帮你节省大量时间和磁盘。

并不存在一个必须全部学会的清单，按你现在最常遇到的场景去取用就行。

2. 压缩：选型取决于“解压后能否完整还原”

2.1 tar 的核心价值是归档，不是压缩率

很多从 Windows 转过来的朋友会把 tar 理解成“压缩工具”，这其实是个常见的误读。tar 最初叫做 Tape Archive，它做的事情是把一堆文件和目录打包成单一数据流，同时保留文件权限、属主、时间戳、符号链接这些信息。真正的压缩发生在 gzip、xz、zstd 这些外部工具介入之后。

所以在 Linux 里你会看到各种组合后缀：.tar.gz、.tar.xz、.tar.zst。其中 .tar 代表归档，后段代表压缩算法。如果你想真正完整备份一个应用目录，而不是只求能解压出内容，用 tar 是正确选择。相比之下，zip 在 Linux 下虽然也能解，但它处理符号链接和权限的方式非常别扭，经常导致恢复出来的环境跟原来不一致。

打个包看看：

bash复制# 归档并压缩 /opt/app 到当前目录
tar -czvf app.tar.gz /opt/app

# 查看包里有什么，先预览再解压
tar -tzvf app.tar.gz | head -20

# 解压到指定目录
tar -xzvf app.tar.gz -C /opt/restore

几个选项说明一下。-c 创建归档，-x 解压，-t 列表查看，-v 显示详细过程，-z 使用 gzip 压缩，-f 指定文件名。注意 -f 必须放在选项组最后，因为它的下一个参数被视为档案文件名；如果写成 tar -cfzv，tar 会把 z 误认为是档案文件名，报错是一定的。

-C 指定解压目标目录这一点非常关键。tar 解压默认去当前目录找目标位置，如果你在一个乱七八糟的目录里直接解压，包内文件全都会散到当前目录下，后续清理起来很麻烦。我习惯是解压前至少先看一眼 tar -tzvf 的输出确认包内有没有顶层目录，再决定是否加 -C。

2.2 gzip、xz、zstd 到底怎么选

同一份数据，用不同压缩算法得到的结果差别很大。我拿一个真实的应用目录测过，原始大小 2.1GB，里面主要是文本配置文件和日志。gzip 压缩后约 410MB，耗时 38 秒；xz 压缩后约 330MB，但耗时将近 5 分钟；zstd 默认等级压缩后约 380MB，耗时只有 9 秒。

实际操作时不需要记那么多参数，tar 支持根据后缀自动选择算法：

bash复制# 生成 .tar.xz 归档
tar -caf app.tar.xz /opt/app

# 生成 .tar.zst 归档（需要系统装了 zstd）
tar -caf app.tar.zst /opt/app

-a 选项会按文件后缀自动匹配压缩算法，省去记 -J、--zstd 这些额外参数的精力。

针对实时传输的场景，我个人强烈推荐 zstd。它兼顾压缩速度和压缩率，CPU 开销不像 xz 那么夸张；而且解压速度非常快，接收方能快速恢复数据。gzip 的优势是无处不在，几乎任何精简系统都自带，适合制作需要广泛兼容的发布包。xz 则适合那种“压一次、存很久”的冷数据，你愿意花几分钟压缩换取 10% 左右的体积节省。

如果你不确定目标机器是否安装 zstd，可以先跑一下 zstd --version。没有的话，Debian/Ubuntu 用 apt install zstd，RHEL/CentOS 系用 dnf install zstd，一条命令的事。

2.3 磁盘镜像与 qcow2 压缩：不要用 zip 思路处理镜像文件

热词里“qcow2压缩”搜索量很高，这通常出现在 KVM/QEMU 虚拟机的维护场景中。qcow2 的特点是写时分配，也就是说，虚拟机内部创建文件时，宿主机上的镜像文件才会真正占用空间。但当你在虚拟机里删除大量文件后，qcow2 镜像文件并不会自动收缩，宿主机看到的镜像体积仍然很大，甚至接近上限。

如果你直接对这个 qcow2 文件跑 gzip 或 zip，会得到一个依然臃肿的压缩包，压缩过程慢不说，对恢复也没有太大帮助。正确的做法是用 qemu-img convert 重新整理镜像，它能把未分配的空间识别出来并直接丢弃，同时 -c 参数可以启用压缩写入。

大致过程如下：

1. 启动虚拟机，删除不需要的大文件，这一步是为了释放虚拟磁盘内部的空间。
2. 现代的 guest 文件系统支持 discard/trim，可以直接执行 fstrim -v / 通知底层释放未使用块。传统做法是用 dd if=/dev/zero of=/tmp/zero bs=1M 把磁盘填满再删除该文件，这种方式对虚拟机磁盘类型支持更广泛，但会短暂占满磁盘，务必注意剩余空间。
3. 关闭虚拟机。
4. 在宿主机执行镜像压缩转换：

bash复制qemu-img convert -p -c -O qcow2 vm-old.qcow2 vm-new.qcow2

-p 显示进度，-c 启用压缩，-O qcow2 指定输出格式。转换完成后先确认新镜像能正常启动，再删除旧镜像。别急着删，我就见过有人转换完立刻删除旧文件，结果新镜像启动报错，最后只能靠备份恢复。完整流程应该是：确认新镜像可用 → 把旧镜像 mv 到备份位置 → 再跑一段时间 → 确认无误后清掉。

我自己处理过的案例是一台 Ubuntu 虚拟机，内部实际数据约 30GB，qcow2 镜像却膨胀到 68GB。执行 fstrim 后用上面那条命令转换，新镜像直接回到 31GB。不仅宿主机磁盘得到释放，后续备份这套镜像的速度也快了一倍。

2.4 打包前和解压后的检查习惯不能省

从事 Linux 工作越久，越会觉得“压缩/解压”这类操作其实自带风险。打包后不检查，解压后不验证，出了问题往往要花更多时间补救。

打包完成后，至少做两件事：

bash复制# 查看包内结构
tar -tzf app.tar.gz | head -30

# 生成校验值，便于传输后核对
sha256sum app.tar.gz > app.tar.gz.sha256

这能在早期发现目录结构不对、关键文件没包进去的问题，不用等传到远程才发现。

解压到目标目录之后，不要只看命令是否执行成功，而是实际确认关键服务能否启动、关键文件是否存在。比如备份的是 Nginx 配置，解压后可能还要执行 nginx -t 验证语法；如果备份的是应用目录，检查一下可执行文件的权限位是否与原来一致。

再提醒一个从 Windows 环境转来的高频坑：不要用 Windows 的右键压缩功能直接打包 Linux 项目里的代码目录，再传到服务器解压。 在 Windows 下打包会把符号链接当作普通文本或直接损坏，文件权限默认变成 755，隐藏文件的处理也很容易出问题。凡是准备部署到 Linux 的目录，都建议在 Linux 环境内用 tar 完成打包，再去传输。

3. 网络传输：scp 只是入门，rsync 才算真正入行

3.1 scp 的方便与局限

scp 的语法非常直观，适合临时传几个小文件：

bash复制# 上传单个文件
scp /tmp/test.txt user@192.168.1.100:/data/

# 指定端口，注意 scp 用大写 P
scp -P 2222 /tmp/test.txt user@192.168.1.100:/data/

有一个细节总有人搞混：ssh 指定端口用的是小写 -p，而 scp 因为历史原因用的是大写 -P。如果你写 scp -p 2222，scp 会把 -p 解释为“保留文件修改时间”，端口参数彻底失效，紧接着就报连接失败或使用默认端口。

scp 适合日常小文件快速传输。但它的缺点也很明显：没有断点续传的能力，传输中断就要从头再来；而且它总是全量复制，不会比较两端文件的新旧或差异；对包含大量软链接、权限信息复杂的目录结构，scp 的处理也不够细致。

当一个目录已经达到 GB 级以上，或者你需要反复同步，再用 scp 就是给自己找麻烦。而 rsync 正是为此而生的工具。

3.2 rsync 为什么会成为运维主力

rsync 最核心的价值是“增量同步”。它会在传输前对比源端和目标端的文件，只传输有差异的部分，而不是把整个目录重新复制一遍。对于多次备份同一个目录的场景，后续每次运行 rsync 的速度都会快得惊人。

常用命令长这样：

bash复制rsync -avz --progress --partial -e "ssh -p 2222" /opt/app/ user@192.168.1.100:/backup/app/

各参数的作用：-a 是 archive 模式，等价于 -rlptgoD，递归同步并保留符号链接、权限、时间戳、属主这些关键属性；-v 详细输出；-z 传输时压缩；--progress 显示进度；--partial 表示保留传输中断产生的部分文件，下次可以继续；-e 指定远程 shell 及端口。

这里有一个新手必踩的坑：源路径末尾的斜杠很重要。 /opt/app/ 表示把 app 目录下的内容同步过去，目标端得到的是 /backup/app/ 下直接是目录内容；而 /opt/app 不带尾斜杠，则表示同步整个 app 目录本身，目标端会出现 /backup/app/app。很多事故都源于对这个细节的误解。

--delete 也是一个高频误用点。它表示删除目标端那些源端已经不存在的文件，让目标完全镜像源。听起来合理，但如果你手误写反了同步方向，数据在几分钟内就会被清空。所以我的习惯是：第一次执行 rsync 永远加 --dry-run，先看它打算删掉哪些文件，确认无误后再去掉该参数正式执行。

bash复制rsync -av --delete --dry-run /opt/app/ user@host:/backup/app/

如果要在业务高峰期跨网络同步大目录，可以限制带宽，避免挤占业务流量：

bash复制rsync -av --bwlimit=20000 --progress /opt/app/ user@host:/backup/app/

--bwlimit 单位是 KB/s，上面示例限速约 20MB/s，具体数值按实际带宽调整即可。

从同步原理上说，rsync 所做的不止“比较修改时间”这么简单，它会对文件内容做滚动校验，能感知到文件中间某一段是否变化，然后只传输变化的分块。这也是它能做到断点续传和高效增量的底层原因。

3.3 下载、共享与校验：curl、wget 和临时 HTTP 服务

和远程服务器之间传文件，除了 scp 和 rsync，还会遇到从公网拉取软件包、在局域网内做临时共享的情况。

下载单个文件，wget 和 curl 都是常用工具。断点续传时，wget 用 -c，curl 用 -C -：

bash复制wget -c https://example.com/big-file.tar.gz
curl -C - -O https://example.com/big-file.tar.gz

如果在同一局域网内，你想把当前目录共享给别人下载，最简单的办法是临时起一个 HTTP 服务：

bash复制cd /data/share
python3 -m http.server 8000 --bind 0.0.0.0

对方在浏览器输入 http://你的IP:8000 就能看到目录并下载。这个方式适合临时共享，传完后记得 Ctrl+C 关掉，不然相当于给内网开了个匿名文件入口。生产环境要长期共享文件，还是应该交给 Nginx 或正经文件服务去做鉴权和访问控制。

还有一种不太占磁盘的管道式传输思路，适合没有足够空间生成完整归档的场景：

bash复制tar czf - /opt/app | ssh user@192.168.1.100 "cat > /data/app-backup.tar.gz"

tar 把内容输出到标准输出，通过 SSH 管道在远程机器上落盘。中间不产生临时文件，对源端磁盘很友好。但要注意，这种方式的可靠性和断点恢复能力都不如 rsync，只适合临时应急。

3.4 跨机器传输后容易被忽略的双端校验

大文件传完了，很多人就默认任务结束，直到用的时候才发现文件损坏。尤其是跨机房的公网传输，数据经过多跳网络，出现损坏的概率并不为零。

常用校验方法是先记录源端文件的哈希值，传输完成后再在目标端计算一次：

bash复制# 源端
sha256sum app.tar.gz

# 目标端，核对输出是否一致
sha256sum app.tar.gz

如果文件数量很多，一条条算哈希不太现实，可以先对比文件总数和总大小，再做抽检：

bash复制# 统计文件数量和总大小
find /opt/app -type f | wc -l
du -sb /opt/app

# 传输完成后在目标端同样执行两边命令

如果希望自动化，将源端生成的哈希列表传到目标端后再用 sha256sum -c 检查，会更可靠些。整体来说，校验这一步花不了多少时间，但它能把“传输失败”“文件不完整”这类问题从偶发事故变成可感知的异常，值得作为固定习惯。

SSH 公钥配置在这类频繁传输场景里也很有用，能省去每次输入密码的麻烦：

bash复制# 在本机生成密钥对
ssh-keygen -t ed25519

# 复制公钥到远程主机
ssh-copy-id -p 2222 user@192.168.1.100

之后再执行 scp 或 rsync 就不会反复要密码了。远程主机上的 .ssh 目录权限建议设为 700，authorized_keys 文件权限设为 600。权限放太宽时 sshd 会拒绝登录，日志里常见 “Authentication refused: bad ownership or modes”，很多人就是被这个坑卡了半天。

4. 系统工具：核心是“先判断，再操作”，顺序不能反

4.1 磁盘：df 与 du 显示不一致，到底该信谁

系统工具这一块最容易出问题的点在于：你用一种工具的视角去解释另一个工具的输出。

df -hT 报告的是文件系统层面的空间占用，它直接看分区上块设备的使用情况。du -sh /opt 则是从根目录往下遍历文件，把所有文件大小累加。两者不是一回事，所以显示数据不一致是正常的，没必要惊讶。

bash复制df -hT
du -h --max-depth=1 / | sort -hr | head -20

但有一种情况需要警惕：df 显示分区仍然满了，而你用 du 扫描后发现可删除的大文件已经删掉，空间却一点没释放。这时候基本可以确定，有进程仍然持有那个已被删除文件的文件句柄。

排查命令：

bash复制lsof +L1 | grep deleted

+L1 的含义是列出 link count 为 0 但仍被进程打开的文件。看到结果后，确认是哪个进程在占用，再决定是重启服务，还是用 fuser -k 结束占用进程。直接暴力删目录往往是无效的。

在生产环境处理这种情况，我通常先尝试清空而不是删除：

bash复制# 如果日志文件被进程占用，直接删除无法释放空间
rm /var/log/nginx/access.log

# 更安全的方式是把文件清空，进程还能继续写
truncate -s 0 /var/log/nginx/access.log

truncate 不会删除文件，也不影响进程已打开的文件描述符，空间能立刻释放，服务也不需要重启，是处理已删除占用和日志轮转的常用技巧。

4.2 内存问题别只看 used，available 才是真实答案

在 Linux 上执行 free -h，很多人一看到 used 占了 90% 以上就慌了，以为内存不够。实际上这是对 Linux 内存管理机制的误解。

text复制              total        used        free      shared  buff/cache   available
Mem:            31Gi        22Gi       1.2Gi       213Mi       8.2Gi       8.5Gi

Linux 内核会把空闲内存尽可能用来做缓存（buff/cache），加速磁盘和文件访问。这部分内存在应用需要时可以被内核自动释放，因此真正需要关注的是 available 这一列，它才表示当前可分配给新进程的内存估算值。

如果你怀疑内存确实不够用，可以用这两条命令找出内存消耗最高的进程：

bash复制ps aux --sort=-%mem | head -15
top -o %MEM

如果系统开始频繁使用交换分区，说明物理内存压力已经很大。可以用 vmstat 1 观察 si（swap in）和 so（swap out）。这两列持续非零，大概率是内存真的不够了，需要考虑扩容，而不是简单清理缓存。

顺带解释一个常见疑惑：热搜里“linux查看cache版本”大概想问的是“free 输出里的 cache 是什么”。free -h 中的 buff/cache 表示内核用于缓冲区与页缓存的内存，不是某个软件缓存目录，也不是 CPU 缓存。如果你想了解 CPU 的 L1/L2/L3 缓存，应该用 lscpu | grep -i cache。

4.3 端口、文件、进程：lsof 是排查绕不开的工具

服务器上最常见的报错场景是端口被占用。这时随手执行 lsof -i:8080，就能看到是哪个进程在监听：

bash复制lsof -i:8080
ss -lntp | grep 8080

ss 是现代 Linux 上更推荐的网络状态工具，-l 只显示监听端口，-n 不做反向域名解析，-t 只看 TCP，-p 显示进程信息。它在性能和输出格式上都比老的 netstat 更好。

如果想看某个文件正被谁打开，尤其当你想删除它又提示“device or resource busy”时，可以这样：

bash复制lsof /var/log/syslog

做出杀进程的决策前，务必先确认进程是什么、是否由 systemd 管理。不要一看到端口被占就 kill -9，这往往会把问题扩大。 如果这个进程是由 systemd 管理的服务，正确做法是 systemctl restart 服务名，让服务自己平滑重来。如果它是一个孤儿进程或僵尸进程，再去考虑 kill。

4.4 systemd 时代：查服务状态优先看 journal

如果说老一代管理员习惯 ps aux | grep xxx 找进程，那 systemd 时代更高效的方式是让系统告诉你服务当前是什么状态、为什么失败。

基础命令：

bash复制# 查看服务状态和最近日志
systemctl status nginx

# 只查看当前失败的服务
systemctl list-units --type=service --state=failed

# 查看 nginx 最近 100 行日志
journalctl -u nginx -n 100 --no-pager

# 如果遇到错误，输出扩展信息
journalctl -xe

systemctl status 的重要价值在于你不仅能看到进程是否在跑，还能看到服务启动是否成功、启动了多少次、有没有触发自动重启。如果服务反复崩溃，systemd 默认的重启策略和失败状态会在输出里体现得很清楚。

自定义服务文件是另一个高频踩坑点。修改 /etc/systemd/system/xxx.service 后，必须执行：

bash复制systemctl daemon-reload

如果不执行，systemd 可能还在按旧配置运行，你以为改好了，实际服务用的还是老参数。这个细节排除了无数莫名其妙的“我配置明明改了，为什么没生效”。

4.5 新建用户与权限边界：实战中最容易出错的环节

热搜词里“linux新建用户”出现频率很高，很多教程只告诉你 useradd 加 passwd，却没说清楚发行版差异和 SSH 登录的权限要求。

创建一个新用户：

bash复制sudo useradd -m -s /bin/bash alice
sudo passwd alice

-m 创建家目录，-s /bin/bash 指定登录 shell。如果少了 -m，用户没有家目录，很多程序会运行异常；如果默认 shell 是 nologin，用户无法正常登录执行命令。

能否用 sudo 取决于用户组。Debian/Ubuntu 系把用户加入 sudo 组，RHEL/CentOS/Rocky 系加入 wheel 组：

bash复制# Debian/Ubuntu
sudo usermod -aG sudo alice

# RHEL/CentOS/Rocky
sudo usermod -aG wheel alice

很多教程会顺手写一句“修改 /etc/sudoers”，但正确做法是用 visudo 去改，防止语法错误把自己锁在外面。

当你希望用户通过 SSH 密钥登录时，需要手动创建 .ssh 目录并写入公钥：

bash复制sudo mkdir -p /home/alice/.ssh
sudo tee /home/alice/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAA... 你的公钥内容
EOF

sudo chown -R alice:alice /home/alice/.ssh
sudo chmod 700 /home/alice/.ssh
sudo chmod 600 /home/alice/.ssh/authorized_keys

注意目标用户家目录本身也不能让其他用户可写，否则 sshd 同样会拒绝公钥登录。这类权限问题在日志里往往不会直接写“权限过高”，而是含糊地提示认证失败，排错成本不低。

5. 把这些工具串成一个可落地的新机初始化流程

5.1 一台裸机到手后的完整操作顺序

工具单独讲一百遍，不如完整走一遍流程。下面我用一台 Ubuntu 22.04 服务器为例，演示从拿到机器到完成基础配置的全过程。脚本可以直接复制执行，但建议一行行跑，边跑边理解。

bash复制# 1. 更新软件源
sudo apt update && sudo apt upgrade -y

# 2. 创建日常运维用户，避免直接使用 root
sudo useradd -m -s /bin/bash deploy
sudo passwd deploy

# 3. 给用户 sudo 权限
sudo usermod -aG sudo deploy

# 4. 配置 SSH 公钥登录（把本地公钥内容粘贴到下面）
sudo mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... yourkey" | sudo tee /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

# 5. 安装基础工具
sudo apt install -y curl wget vim htop lsof tree p7zip-full zstd rsync tmux

# 6. 开启防火墙，仅放行 SSH
sudo ufw allow OpenSSH
sudo ufw enable

如果是 RHEL 系的 Rocky/AlmaLinux，包管理器和防火墙命令不同：

bash复制# 替代第 1 步和第 5 步
sudo dnf update -y
sudo dnf install -y curl wget vim htop lsof p7zip zstd rsync tmux

# 替代第 6 步
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

注意在 CentOS 系默认不允许密码登录 root？实际上系统配置各异，但通用建议是：/etc/ssh/sshd_config 中把 PermitRootLogin 设为 prohibit-password，只允许密钥登录 root，普通用户则用密码或密钥均可。修改后执行 sudo systemctl reload sshd。

这一步为什么不直接用 root 操作？我见过太多人长期用 root 跑日常命令，某次手滑 rm -rf 的路径少写一个字母，整台机器直接报废。普通用户加 sudo 的机制能在关键操作前多一层确认，也能避免脚本里的错误命令以 root 身份直接执行。

5.2 初始化和部署中高频出现的两件事：Python 与 Nginx

很多新人在拿到服务器后，第一反应是“我要装 Python 环境”和“我要装 Nginx”。但这两件事踩坑率非常高，值得单独提一下。

Python 方面，Ubuntu 22.04 自带 Python 3.10，CentOS 系某些版本可能没有安装或版本偏低。如果你用 python3 --version 发现版本不够，最安全的途径是用官方包管理或 pyenv，而不是直接修改系统内置的 python 软链接。

举个例子，在 CentOS 7 上把 /usr/bin/python 从 2.7 改成指向 Python 3，会导致 yum 直接崩溃，因为 yum 还依赖 2.7。这类问题在网上一搜一大把，修复起来又麻烦。正确思路是：如果只是某个项目需要新版本 Python，就用虚拟环境：

bash复制# 创建虚拟环境
python3 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activate

# 之后安装的依赖都隔离在这个环境里
pip install flask

Nginx 在很多服务器上承担反向代理和静态文件服务。装好后注意几个关键点：

bash复制# 启动并设置开机自启
sudo systemctl enable --now nginx

# 修改配置后先校验语法，再平滑重载
sudo nginx -t
sudo systemctl reload nginx

如果修改过 Nginx 配置后 systemctl reload nginx 没有任何提示，但页面没有变化，很可能是配置校验没过但你现在执行了 reload 吗？其实 nginx 的 reload 会先检查配置，如果语法有误就不会应用新配置。因此修改配置后第一步永远是 nginx -t，确认输出 syntax is ok 再看业务。

配置站点的思路也很简单：在 /etc/nginx/conf.d/example.conf 里写一个 server 块，例如：

nginx复制server {
    listen 80;
    server_name example.com;
    root /var/www/example;
    index index.html;
}

然后执行 nginx -t 和 systemctl reload nginx。如果出现 “bind() to 0.0.0.0:80 failed”，基本可以断定 80 端口已被别的 Web 服务占用，用 ss -lntp | grep :80 检查是谁在监听，再做下一步决定。

5.3 初始化之后的备份思路：cron 与 rsync 的组合

新机器搭建完成后，最不应该省略的一步是建立备份机制。