先确定备份目标，再决定保留周期

Linux服务器磁盘空间不足时，备份不应默认写回同一块已告警的磁盘。先确认哪些数据丢失后无法重建、业务最多能接受丢失多久，以及备份应恢复到什么状态；再将必要数据备份到独立存储或其他服务器，并验证恢复结果。保留周期则根据恢复点目标（RPO）、恢复时间目标（RTO）、备份容量和合规要求共同确定，不能只看本机剩余空间。

通常应优先保护业务数据、数据库、必要的系统与应用配置、证书和任务定义；缓存、临时文件、可重新生成的构建产物通常不必按同等周期保留。备份频率按数据变化速度和可接受的数据损失量安排；数据库与文件应采用能保证一致性的方式备份。至少定期在隔离环境中实际恢复，确认数据可用、服务能启动，而不只是确认备份文件存在。

先判断空间压力和备份边界

在开始复制前，确认空间不足发生在哪个文件系统，并检查是否有备份任务正在占用空间。以下命令适用于常见 Linux 发行版，只读取信息，不会修改文件：

df -hT
df -ih
du -xhd1 /var /home /srv 2>/dev/null | sort -h

df -hT查看各挂载点的容量和文件系统类型，df -ih检查 inode 是否耗尽；如果磁盘容量尚有余量但 inode 用尽，大量小文件也可能导致写入失败。du用于粗略定位目录占用，-x限制在当前文件系统内。根据实际目录选择检查路径，权限不足会导致部分目录统计不完整。

备份前应区分以下内容：

不要仅凭目录名称排除数据。例如，名为 cache 的目录可能被应用用于保存尚未入库的内容；反过来，日志文件也可能包含排障或审计所需信息。排除前应核实其用途、重建方式和保留要求。

同时确认备份目标不是同一文件系统上的另一个目录。把文件从 /var 复制到同一块盘的 /backup，可以用于整理目录，却不能抵御磁盘故障，也会进一步消耗本机空间。目标为网络挂载时，还要先确认挂载确实有效；若挂载意外失效，写入可能落到本机挂载点目录，造成空间继续下降。

按恢复需求确定范围和频率

备份范围的判断标准不是“整机复制越多越好”，而是能否在故障后重建业务。建议先列出服务依赖：数据文件位于何处、数据库采用什么方式存储、服务配置在哪里、启动依赖哪些账户和证书，以及恢复时需要哪些版本信息。对重要路径逐项标记“必须备份”“可重新生成”或“需进一步确认”，并由应用负责人核实。

频率应以可接受的数据丢失量为依据：

• 数据变化频繁、丢失影响大的业务，应缩短备份间隔；若无法承受一个间隔内的数据损失，仅靠定时文件备份可能不够，需要评估数据库自身的日志归档或其他持续保护机制。
• 变化较少的配置、静态内容，可以降低增量备份频率，但应在变更后及时触发备份。
• 数据库和文件若存在关联，例如文件记录由数据库索引，恢复时应选取相互匹配的时间点，避免出现记录存在但附件缺失，或附件存在但记录不存在。
• 备份间隔不是唯一指标。还要计算备份所需时间、传输中断后的补传能力，以及恢复时能否在业务允许的时间内完成。

可把每类数据登记为一行，至少记录数据位置、责任人、备份方式、频率、保留周期、加密与访问要求、恢复步骤和最近一次恢复验证时间。没有明确恢复责任人或恢复步骤的备份，发生故障时往往难以快速使用。

保证备份内容一致

普通文件复制适用于已经静止或允许短暂不一致的数据。应用持续写文件时，复制过程可能跨越多次修改，得到的目录并不对应某个完整时点。对这类数据，可在业务允许的维护窗口暂停写入或停止相关服务，完成复制后再恢复服务；如果不能停机，应使用应用支持的一致性导出机制，或经过验证的文件系统快照流程。仅仅使用 rsync、压缩归档或云端存储，并不会自动保证应用一致性。

数据库应优先采用对应数据库的备份工具。以常见命令为例，下面是逻辑导出思路，实际参数、认证方式和一致性语义应按数据库类型及版本核对：

# MySQL / MariaDB：按实际数据库、账号和认证配置调整
mysqldump --single-transaction --databases appdb > /mnt/backup/appdb.sql

# PostgreSQL：按实际数据库账号和认证配置调整
pg_dump -Fc -d appdb -f /mnt/backup/appdb.dump

命令中的 /mnt/backup 必须是已确认可用的独立备份目标，不能假设它一定是远端存储。导出文件可能含有敏感业务数据，应限制目录和文件访问权限，避免写入网页目录或对外共享位置。数据库类型、存储引擎、版本、事务特性和认证方式都会影响备份方法；执行前查阅对应版本文档，并验证命令退出状态与文件完整性。导出成功也不代表恢复必然成功，仍需进行实际导入测试。

如果使用文件级复制，可将源数据复制到已挂载的独立目标。以下示例适用于常见 Linux 环境，目录需替换为实际路径：

rsync -aHAX --numeric-ids /srv/app-data/ /mnt/backup/server01/app-data/

该命令不会删除目标端多余文件，但也不会自动生成不可变历史版本；重复执行可能覆盖目标中同名文件，因此目标目录不应同时作为多个备份批次的唯一副本。文件复制期间源数据仍在变化时，结果不保证一致。执行前确认目标挂载、容量、权限及剩余空间，并先在小规模非关键目录验证路径是否符合预期。

备份脚本还应检查命令退出码、日志和目标容量。不能只看脚本是否运行过；需确认本次备份包含预期文件，数据库导出不是空文件或不完整文件，并在必要时进行校验。对重要备份，可记录文件清单、时间戳和校验值，便于发现传输或存储异常。

设计保留周期，避免备份挤占业务盘

保留周期要同时满足恢复需求和容量约束。可以采用“近期备份较密、较早备份较疏”的分层思路：例如保留一段时间的日备份，再保留更长时间的周备份和月备份。日、周、月的具体数量应由业务变更频率、审计要求、存储预算和恢复需求决定；示例周期不能直接视为适用于所有业务的标准。

估算容量时，不要只看单次备份大小。至少核算初始全量、后续增量、数据库导出增长、文件变化比例、并行任务临时空间，以及保留期内的历史版本。若使用压缩或去重，节省比例取决于数据内容，不能假设固定压缩率。备份目标还应留出增长余量；一旦目标接近容量上限，应调整保留策略或扩展独立存储，而不是让本机业务盘和备份盘同时耗尽。

清理旧备份前先确认保留规则、目标路径和最近一次可用恢复点。避免将不加核验的自动删除命令直接用于生产备份目录；路径变量为空、挂载失效或目录写错，都可能导致误删。建议先列出拟删除清单，由脚本或人工核对后再执行，并确保删除后仍满足最低保留要求。对于重要数据，可设置只读或受限删除权限，并将备份副本与生产账号分开管理，降低误操作或账号失陷造成的同时损失。

Linux服务器磁盘空间不足时，若备份已经占用业务盘，应先确认哪些文件属于可清理的临时数据、历史日志或重复副本，再按既定策略迁移或清理。不要为腾空间直接删除唯一一份数据库导出、近期备份或应用数据。若磁盘已满并影响服务写入，优先停止会继续产生临时文件的备份任务，确认备份是否完整，再选择安全的清理路径；任何清理动作都应先检查文件归属、用途和保留要求。

用恢复演练验证备份是否可用

恢复演练应在隔离环境或独立测试目录进行，避免覆盖线上数据。先选取一个实际备份点，核对备份时间、范围、校验结果和对应配置，再按正式故障处置顺序恢复。文件恢复要检查文件数量、关键文件内容、所有者与权限；数据库恢复要确认导入完成、表和关键记录可查询，并验证应用是否能读取对应数据。

一次有效演练至少包括：

1. 从备份介质读取数据，确认目标可访问、文件可解包或数据库导出可解析。
2. 按恢复文档还原配置、文件和数据库，记录每一步耗时与报错。
3. 启动必要服务并执行业务层检查，例如读取关键记录、打开代表性附件、检查任务配置。
4. 核对恢复点是否符合预期的数据时间，确认数据库与文件之间没有明显时间错位。
5. 清理测试环境中的敏感数据，并更新恢复步骤、责任人和问题清单。

若文件无法读取、数据库导入报错、权限不匹配或服务不能启动，应先查明是备份不完整、版本依赖缺失、密钥未备份，还是恢复步骤过时。修正后重新生成备份并再次演练，不能把“文件已复制到另一台机器”当作演练通过。恢复时间也应记录下来，与业务可接受的恢复时间比较；超出范围时，需要减少恢复步骤、改善数据组织方式或调整备份方案。

适用边界与可执行判断

文件级备份适合可独立复制、恢复关系较简单的数据；持续写入的数据库、消息队列或依赖多个目录共同工作的应用，必须使用经过验证的一致性方案。快照有助于获得某个时点的文件系统视图，但若快照仍位于同一物理存储，不能替代异地或独立副本；快照本身也不一定保证应用和数据库处于一致状态。

安排方案时，可用以下标准逐项判断：

• 备份目标是否与生产数据处于不同故障域，且确认挂载和容量正常？
• 每类关键数据是否明确了范围、负责人、备份频率和可接受的数据丢失量？
• 数据库与文件是否采用适合其写入特性的备份方法？
• 保留周期是否满足恢复与审计要求，同时不会挤占业务盘？
• 是否定期在隔离环境完成恢复，并验证数据、权限、服务和耗时？

只要其中一项无法确认，就应先补足对应环节，再把该备份视为可依赖的恢复手段。