企业官网建设流程全解析

• 教程

SRE 的核心职责是保障服务持续可用，而服务背后每台服务器都会产生海量数据——访问日志、数据库记录、各类元数据。如何高效地压缩、归档、轮转并备份这些数据，既是数据安全的基本保障，也是避免磁盘空间耗尽的关键。本篇指南基于 School of SRE（LinkedIn 内部 SRE 入门课程）的 Linux 中级课程 中 Archiving and Backup 章节，系统讲解 gzip 压缩、tar 归档、rsync 网络同步备份及增量/差异/云备份的核心概念，并给出可直接落地的命令与脚本，帮助你构建一套完整的日志与数据保护方案。

上图为 gzip 压缩的典型实操：一个 248984 字节的messages日志文件经gzip压缩后生成messages.gz，大小缩减至 46793 字节，约为原文件的五分之一，随后又通过gunzip恢复了原始文件。

为什么 SRE 需要掌握归档与备份

在 SRE 的日常工作中，"服务不掉线（至少 99.99% 可用）"只是表象，真正需要持续管理的是服务背后产生的大量数据。这些数据包括：

• 日志文件：应用日志、系统日志（如/var/log/messages）、审计日志，用于排障与合规审计；
• 数据库中的用户数据：任何业务的核心资产，丢失即灾难；
• 各类元数据与配置：支撑系统运行状态的描述性信息。

这些数据的特点是只增不减，若不加以控制，磁盘很快会被写满，导致服务因空间不足而异常。因此 SRE 需要一套组合拳：压缩（compress）、归档（archive）、轮转（rotate）、备份（backup），在保障数据安全的同时，避免"跑满磁盘"的运维事故。

一个值得注意的区分是：

• 压缩（Compression）：用算法减小数据体积，如 gzip；
• 归档（Archiving）：把多个文件/目录合并为单个文件便于管理与传输，如 tar；
• 轮转（Rotation）：按时间/大小切分日志，保留最近 N 份，如 logrotate；
• 备份（Backup）：复制数据到独立介质/位置，用于灾难恢复。

本篇聚焦归档与备份两大环节，这也是 本课程 中与存储（Storage Media）并列的 SRE 核心技能。

归档（Archiving）：为合规与空间管理而压缩存储

归档通常针对不再频繁使用、但出于合规（compliance）目的必须保留的数据。通过压缩格式存储，可以大幅节省磁盘空间。归档不是删除，而是把"冷数据"以更紧凑的方式保存下来，随时可以恢复。

下面的章节介绍两类最核心的归档工具：gzip（单文件压缩）与tar（多文件/目录打包）。

gzip：单文件压缩与解压

gzip是 Linux 下最常用的压缩程序，用于压缩一个或多个文件。它的一个关键行为是：压缩后会用压缩版本替换原始文件。

# 查看原始文件大小 ls -l # -rw-r--r-- 1 root root 248984 ... messages # 压缩 gzip messages # 再次查看：原始 messages 已被 messages.gz 替换 ls -l # -rw-r--r-- 1 root root 46793 ... messages.gz

从输出可以看到，248984 字节的messages日志被压缩为 46793 字节的messages.gz，体积缩减到原来的约五分之一，这就是日志文件为何普遍采用 gzip 轮转存储的原因。

解压使用gunzip命令，它会将.gz文件还原为原始文件：

gunzip messages.gz

提示：gzip只处理单个文件。如果需要"压缩整个目录"，应先用tar打包，再压缩（或直接使用tar的-z选项一步完成，见下文）。

tar：把多个文件与目录打包成单个归档

tar（Tape Archive，磁带归档）程序用于把文件和目录归档为单个文件，通常称为 tarball。它在 SRE 工作中的典型用途是：在数据转移到长期备份服务器之前，先打包成归档文件。与gzip不同，tar不会替换现有文件与目录，而是创建一个新的.tar后缀文件。

tar提供了大量旗标（flags），下表是 SRE 最常用的一组：

用文件与文件夹创建归档

创建归档使用-c（create）旗标，-f后紧跟归档文件名：

# 将 file1、file2、messages 三个文件打包为 archive.tar tar cf archive.tar file1 file2 messages # 验证：归档已生成，且原文件仍然保留 ls # archive.tar file1 file2 messages

如上图所示，执行tar cf archive.tar file1 file2 messages后，目录中多出了archive.tar，而原文件file1、file2、messages依然存在——这正是归档与压缩（gzip）在行为上的重要区别。

列出归档中的文件

使用-t旗标可以查看归档内容而不解压：

tar tf archive.tar

tar tvf archive.tar # 加上 -v 可以看到每个文件的权限、属主与大小详情

从归档中提取文件

使用-x旗标解包归档：

tar xf archive.tar

tar xvf archive.tar # -v 显示解包过程的每个文件

一步完成"打包 + 压缩"

日常运维中最常见的组合是-czf：创建归档的同时用 gzip 压缩，得到体积更小的.tar.gz文件：

tar czf backup.tar.gz /var/log/ tar tzf backup.tar.gz # 查看 .tar.gz 内容 tar xzf backup.tar.gz # 解压并解包

如需更强的压缩率，可改用 bzip2（-j，生成.tar.bz2）或 xz（-J，生成.tar.xz），代价是压缩耗时更长。

用 tar 实现增量备份

tar不仅用于静态打包，还内置了增量归档能力，是后续自动化备份脚本的基础。核心参数是--listed-incremental，它配合一个元数据文件（通常以.snar结尾）记录"上次归档后哪些文件发生了变化"：

# 第一次：全量归档，同时生成元文件 snapshot.snar tar --create --listed-incremental=snapshot.snar --file=backup-$(date +%F).tar /var/log/ # 第二次：基于元文件，只归档自上次以来的变更 tar --create --listed-incremental=snapshot.snar --file=backup-$(date +%F).tar /var/log/

第一次执行时归档全部内容，之后每次执行只追加变更过的文件，这与下文"增量备份"的理念完全一致。

备份（Backup）：数据丢失前的最后防线

备份是复制/拷贝现有数据的过程，目的是在数据丢失时能够恢复数据集。当某些数据虽然不在日常工作中使用，但需要作为未来合规依据与"真相来源（source of truth）"时，备份就显得尤为关键。

根据策略不同，备份可分为以下几种类型：

增量备份（Incremental Backup）

增量备份是自上次备份以来新增或变更数据的备份。它的优点是大幅减少数据冗余、提高存储效率：因为每次只备份变化量，而非全部数据。

• 优点：备份数据量小、耗时短、占用存储少；
• 缺点：恢复时需要"首次全量 + 所有增量"按顺序重放，恢复链路较长。

差异备份（Differential Backup）

当数据持续修改、更新时，我们通常针对自上次备份以来发生的变更进行备份，这类备份称为差异备份。

• 与增量备份的区别：差异备份基于上次全量备份计算差异，而不是基于上一次任意类型的备份；
• 优点：恢复只需"上次全量 + 最后一次差异"，比增量备份的恢复更简单；
• 缺点：随着时间推移，每次差异备份的数据量会逐渐增大，存储开销高于增量备份。

网络备份（Network Backup）

网络备份是指通过客户端-服务器模型，把数据从源端发送到远端备份目的地。备份目的地可以是集中式（centralized），也可以是去中心化（decentralized）。其中去中心化备份对灾难恢复（disaster recovery）场景尤其有价值——当某个数据中心整体不可用时，其他站点仍持有数据副本。

rsync：跨服务器同步的利器

rsync是 Linux 下用于将文件从一台服务器同步到目标服务器的经典命令，也是网络备份最常用的工具之一。

rsync [options] <source> <destination>

如上图所示，一条典型的远程备份命令：

rsync -av archive.tar azureuser@backup_server:

• -a（archive mode）：归档模式，递归同步并保留权限、时间戳、属主等元数据；
• -v（verbose）：显示同步过程的详细信息；
• azureuser@backup_server:：目标地址。冒号（:）后没有指定路径时，文件会被放到该用户的主目录（home directory）下，本例中即/home/azureuser。

rsync 的增量特性体现在输出中的sending incremental file list：它只传输发生变化的部分，并给出发送/接收字节数、传输速率、文件总大小与加速比等信息，非常适合日志与归档文件的定期同步。

日常高频使用的 rsync 选项包括：

查看rsync全部可用选项，随时使用：

man rsync

云备份（Cloud Backup）

除了本地与网络备份，还可以把备份数据托管到第三方云服务。相比本地机器或未配置 RAID 的服务器上的存储，云备份通常更可靠，因为云厂商负责数据冗余（redundancy）管理、数据恢复（recovery）与数据安全（security）。即使本地磁盘全部损坏、机房整体故障，云端副本依然可以恢复业务。

课程中提到的两个广泛使用的云备份方案是：

• Azure Backup（微软）：面向 Azure 生态的托管备份服务，支持虚拟机、数据库与文件级备份；
• Amazon Glacier（AWS）：面向长期归档的低成本冷存储服务，适合合规留存类数据。

需要说明的是：云备份虽然可靠性更高，但引入网络带宽成本与恢复时间（RTO）考量；实践中常按"本地快速恢复 + 云端长期留存"的分层策略组合使用。

综合实战：用 Bash 脚本自动化日志备份

理解了tar与备份类型之后，可以把它们串成一个可投入使用的备份脚本。在 Bash Scripting 章节中，课程给出了一个将备份流程自动化的backup.sh脚本，它把"增量备份"与"全量备份"统一到一个命令入口，并用到函数、参数校验、字符串比较与逻辑运算符等 bash 特性：

#!/bin/bash # Scripts to take incremental and full backup backup_dir="/mnt/backup/" time_stamp="`date +%d-%m-%Y-%Hh-%Mm-%Ss`" log_backup(){ if [ $# -lt 2 ]; then echo "Usage: ./backup.sh [backup_type] [log_path]" exit 1; fi if [ $1 == "incremental" ]; then if [ $# -ne 3 ]; then echo "Usage: ./backup.sh [backup_type] [log_path] [meta_file]" exit 3; fi tar --create --listed-incremental=$3 --verbose --verbose --file="${backup_dir}incremental-${time_stamp}.tar" $2 if [ $? -eq 0 ]; then echo "Incremental backup succesful at '${backup_dir}incremental-${time_stamp}.tar'" else echo "Incremental Backup Failure" fi elif [ $1 == "full" ];then tar cf "${backup_dir}fullbackup-${time_stamp}.tar" $2 if [ $? -eq 0 ];then echo "Full backup successful at '${backup_dir}fullbackup-${time_stamp}.tar'" else echo "Full Backup Failure" fi else echo "Unknown parameter passed" echo "Usage: ./backup.sh [incremental|full] [log_path]" exit 2; fi } if [ $# -lt 2 ] || [ $# -gt 3 ];then echo "Usage: ./backup.sh [incremental|full] [log_path]" exit 1 elif [ $# -eq 2 ];then log_backup $1 $2 elif [ $# -eq 3 ];then log_backup $1 $2 $3 fi exit 0

这个脚本的核心设计值得逐点拆解：

1. 参数约定：第一个参数指定备份类型（incremental或full），第二个参数是要备份的日志路径；只有增量备份需要第三个参数——元数据文件（.snar），用于记录上次备份状态；
2. 时间戳命名：date +%d-%m-%Y-%Hh-%Mm-%Ss为每次归档生成唯一文件名，避免覆盖历史备份；
3. 增量备份实现：核心命令是tar --create --listed-incremental=$3 --verbose --verbose --file=... $2，其中--listed-incremental即上文提到的增量归档机制，--verbose --verbose（双-v）会输出更详细的文件级信息；
4. 全量备份实现：tar cf "${backup_dir}fullbackup-${time_stamp}.tar" $2，每次对目录做完整归档；
5. 失败处理：通过$?检查每条tar命令的退出码，成功或失败分别输出明确提示；
6. 退出码约定：参数个数不足返回1，未知备份类型返回2，增量备份缺少元文件参数返回3，正常结束返回0——非零退出码与错误类型一一对应，便于被监控系统捕获。

运行方式：

# 全量备份 /var/log ./backup.sh full /var/log # 增量备份 /var/log，并使用 snapshot.snar 作为元文件 ./backup.sh incremental /var/log snapshot.snar

将上述脚本加入cron（例如每天凌晨执行一次增量备份、每周一次全量备份），再配合 rsync 将归档传输到远端备份服务器，就构成了一套完整的"本地压缩归档 → 定期增量备份 → 远程异地同步"的数据保护链路。该脚本与 bash 基础（变量、参数、退出状态）紧密结合，是练习 SRE 自动化能力的好起点。

最佳实践小结

结合本课程内容（Storage Media 中 RAID 冗余与文件系统管理、本篇的归档备份），SRE 在数据保护上的实践要点可归纳为：

1. 先归档后压缩：目录用tar打包，再以-z/-j压缩，兼顾管理与体积；
2. 日志必须轮转：配合 gzip 按日/周切分，只保留 N 份，防止磁盘被日志写满；
3. 分层备份策略：本地增量备份满足快速恢复，云备份（如 Azure Backup、Amazon Glacier）满足异地容灾与长期合规留存；
4. 网络备份走 rsync：利用增量传输与 SSH 加密，高效、安全地同步到备份服务器；
5. 自动化 + 监控：用 bash 脚本 + cron 把备份变成例行任务，并用退出码接入监控告警，确保"备份失败"能第一时间被发现；
6. 定期验证恢复：备份的价值在于可恢复，应周期性演练从归档中tar xf还原数据，确认链路可用。

进一步学习

• 本课程整体路线与实验环境（RHEL 8 Docker 容器）见 Linux 中级课程介绍；
• 深入理解磁盘、文件系统、RAID 冗余与 LVM，见 Storage Media；
• 巩固变量、函数、条件判断等 bash 基础，见 Bash Scripting；
• 如需了解文件系统损坏检查与修复（fsck）及其错误码，可参考 Storage Media 的"Checking and Repairing FS"一节。

• 教程