大存储香港云服务器日志留存空间不足时，如何用df与du核对磁盘占用和清理依据

“香港云服务器可以搭建日志分析平台吗？”可以，但大存储机型的标称容量并不能直接证明日志留存一定够用。真正需要验收的是：日志所在文件系统还有多少可用空间、日志目录实际占用了多少、空间增长速度是多少，以及清理后能否满足既定留存周期。

核对时不要只执行一个命令。df回答“文件系统还剩多少空间”，du回答“指定目录下的可见文件占了多少空间”。先用df确认磁盘层面的压力，再用du定位目录和文件，最后解释两者差异，才能形成可靠的清理依据。

先确认日志路径和文件系统

以下示例以常见Linux系统为例，日志目录使用/var/log。如果日志分析平台将原始日志、索引或临时文件写入其他位置，应将示例路径替换为实际路径，例如/srv/logs、/data/logs或平台配置中的数据目录。

执行检查前需要满足三个条件：

• 已明确日志原文件、索引文件和临时文件的实际路径；
• 当前账号能够读取这些目录，必要时使用sudo；
• 已知业务要求的留存周期，例如保留多少天，是否需要归档或审计追溯。

先确认路径对应的挂载点、文件系统类型和挂载参数：

LOG_PATH=/var/log

sudo findmnt -T "$LOG_PATH" -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT "$LOG_PATH"
df -ih "$LOG_PATH"

重点查看以下输出：

• TARGET：实际挂载点。日志目录可能位于根分区，也可能是单独的数据分区；
• SOURCE：对应的块设备或逻辑卷；
• FSTYPE：文件系统类型；
• Size：文件系统总容量；
• Used：已经使用的容量；
• Avail：当前可用容量；
• Use%：容量使用率；
• IUse%：inode使用率。

df -hT /var/log只会返回包含/var/log的文件系统。如果/var/log是单独挂载的目录，它不会代表根分区的使用情况；如果日志平台还把索引写入/var/lib或/data，这些路径也必须单独检查。

df -ih用于排查“小文件很多但容量看起来还够”的情况。inode耗尽后，即使df -h显示仍有可用空间，也可能无法创建新文件。日志轮转产生大量小文件时，这个指标尤其重要。

用df判断文件系统是否真的接近上限

df是磁盘容量验收的第一层依据。它统计的是整个文件系统的使用情况，不仅包括日志目录，还包括同一挂载点下的程序文件、缓存、索引、临时文件、已删除但仍被进程打开的文件，以及文件系统自身的管理开销。

因此，以下判断比较可靠：

• Use%升高且Avail持续下降，说明文件系统整体确实在消耗空间；
• Avail已经不足以覆盖下一轮留存周期，说明当前容量规划不满足要求；
• IUse%接近上限，说明文件数量可能比文件总容量更早成为瓶颈；
• 只有查看日志目录的df，不能证明整个日志分析平台的数据目录都安全。

如果需要观察根文件系统下还有哪些一级目录占用空间，可以执行：

sudo du -x -h --max-depth=1 / | sort -h

这里的-x表示只统计当前文件系统，避免跨入单独挂载的目录。没有-x时，du /可能把其他分区、网络文件系统或独立数据盘一起算进来，结果会与df无法对应。

不同文件系统可能预留一部分空间供系统使用，因此df中的Avail不一定等于“总容量减去普通用户可见的已用容量”。验收时应以实际的Avail和增长趋势为准，而不是自行用总容量减去某个目录大小进行估算。

用du定位日志目录和大文件

确认挂载点后，再从目录层面定位占用来源：

sudo du -x -h --max-depth=1 /var/log | sort -h

如果要查看日志目录自身的总占用：

sudo du -x -s -h /var/log

如果需要列出较大的文件，可以使用GNU find提供的文件大小和修改时间字段：

sudo find /var/log -xdev -type f \
  -printf '%s\t%TY-%Tm-%Td %TH:%TM\t%p\n' |
  sort -n | tail -n 30

输出中：

• 第一列是字节数，适合排序；
• 第二列是文件的修改时间；
• 第三列是文件路径；
• -xdev确保不会跨越当前文件系统；
• tail -n 30只查看排序后最大的30个文件。

du统计的是当前能够遍历到的文件和目录。执行账号权限不足时，某些目录可能被跳过，结果会低估真实占用。因此，日志目录通常应使用sudo du进行核对。

同时要注意，du的结果不是整个文件系统的使用量。它不会自动包含以下内容：

• 同一文件系统中日志目录以外的其他目录；
• 已被删除但仍被进程打开的文件；
• 某些文件系统管理开销；
• 没有权限读取的目录；
• 被单独挂载的子文件系统，尤其是在使用-x时。

对照df与du解释空间差异

将两个命令的结果放在一起，可以按以下方式判断：

当df明显高于du时，应优先检查“已删除但仍被进程占用”的文件：

if command -v lsof >/dev/null 2>&1; then
  sudo lsof -nP +L1
else
  echo "lsof未安装，无法使用lsof检查已删除但仍打开的文件"
fi

如果输出的文件名带有(deleted)，说明目录项已经删除，但进程仍持有文件描述符。此时再次执行rm通常不会释放空间，只有进程关闭文件或重新打开日志后，空间才会真正回收。

这类问题不能直接通过删除进程文件解决。应先确认对应服务是否支持日志重新打开或平滑重启，再按照服务文档操作。重启或重新加载可能造成短暂日志中断，执行前应确认业务影响和回滚方式。完成后重新执行df，验证Avail是否增加。

如果df和du都显示空间很大，应继续检查整个挂载点，而不是只盯着/var/log：

MOUNT_PATH=$(df -P /var/log | awk 'NR==2 {print $6}')

sudo du -x -h --max-depth=1 "$MOUNT_PATH" | sort -h

这里的命令适合常见Linux环境。如果发行版使用精简版BusyBox，du的--max-depth或find的-printf可能不可用，应先执行以下核验：

du --help
find --help
df --help

不要在选项不兼容时直接修改命令并执行删除操作。

用增长速度判断留存是否够用

当前占用量只能说明“现在用了多少”，不能说明大存储机型能否满足未来留存需求。至少需要记录两个时间点，观察df和du的变化。

可以使用下面的只读命令进行短期采样：

LOG_PATH=/var/log

for i in 1 2 3; do
  date -Is

  df -B1P "$LOG_PATH" |
    awk 'NR==2 {
      print "df_used_bytes=" $3
      print "df_available_bytes=" $4
    }'

  sudo du -x -s --bytes "$LOG_PATH" |
    awk '{print "du_bytes=" $1}'

  sleep 900
done

df_used_bytes反映整个文件系统的使用量，du_bytes反映日志目录的可见文件量。两者都记录下来，可以区分“日志目录自身增长”和“其他数据增长”。

采样时应覆盖真实写入状态，例如日志高峰、批量任务、日志轮转时段。单次低负载采样不能证明长期留存能力。磁盘增长速度可以按以下方式估算：

日均日志增长量 ≈（第二次已用空间 - 第一次已用空间）÷ 两次采样间隔 × 一天

容量判断应至少考虑：

所需容量 ≈ 原始日志日均增长量 × 留存天数
          + 索引或解析产生的数据
          + 轮转、压缩和临时处理空间
          + 运行预留空间

这里的索引、解析和临时处理空间不能直接套用一个固定比例。不同日志格式、字段数量、索引策略和查询方式都会改变实际占用，应该在接近正式负载的环境中测量。

如果原始日志和索引位于不同文件系统，需要分别计算。原始日志目录的du很小，并不代表索引所在的数据盘也有足够空间。

形成可执行的清理依据

清理不能只依据“哪个文件最大”，还应同时满足以下条件：

1. 文件已经超过业务规定的留存期限；
2. 文件不是当前正在写入的活动日志；
3. 如果需要审计或后续查询，已完成归档并验证可读取；
4. 清理范围只覆盖已经确认的目录和文件类型；
5. 清理后重新检查df、du和inode使用率。

可以先列出候选文件，不执行删除：

APP_LOG_PATH=/var/log/app

sudo find "$APP_LOG_PATH" -xdev -type f -mtime +30 \
  -printf '%TY-%Tm-%Td %TH:%TM\t%s\t%p\n' |
  sort

上面的30只是示例，应替换为实际留存策略。-mtime +30判断的是文件修改时间超过一定天数，并不等于日志事件本身的产生时间。如果文件被复制、解压或重新生成，修改时间可能已经变化，因此合规留存不能只依赖mtime，还应结合文件名、轮转记录和日志平台的时间字段确认。

对于已经压缩、已经轮转且不再写入的日志，可以进一步缩小范围：

sudo find "$APP_LOG_PATH" -xdev \
  -type f -name '*.gz' -mtime +90 -print

确认打印出的文件全部符合留存政策，并且已经完成归档后，才考虑执行删除：

sudo find "$APP_LOG_PATH" -xdev \
  -type f -name '*.gz' -mtime +90 -delete

这条命令具有破坏性，执行前应完成以下检查：

• APP_LOG_PATH必须是明确的应用日志目录，不能使用未经确认的根路径；
• 先执行带-print的预览命令，逐行核对结果；
• 已经完成备份或归档，并确认归档可读取；
• 确认匹配条件不会包含正在写入的文件；
• 明确删除会影响历史检索，且命令本身没有自动回滚能力。

如果删除结果不符合预期，只能从已验证的归档中恢复，并恢复原有权限、属主和目录结构。不要直接对活动日志使用rm，也不要在不了解应用行为时直接执行truncate -s 0，否则可能造成日志丢失、句柄异常或应用继续向已删除文件写入。

对于由systemd-journald管理的日志，先查看其当前占用：

if command -v journalctl >/dev/null 2>&1; then
  sudo journalctl --disk-usage
else
  echo "journalctl不可用，请检查实际日志管理方式"
fi

如果决定按时间清理，可以使用类似以下命令：

sudo journalctl --vacuum-time=30d

该操作会删除超过指定时间的旧日志，执行前必须确认留存要求、归档状态和审计影响。journalctl --vacuum-time本身没有通用的撤销操作，回滚依赖事先保存的归档。若系统由logrotate管理文件日志，可先进行不修改文件的配置测试：

sudo logrotate -d /etc/logrotate.conf

-d用于调试和预览，不执行实际轮转。只有确认配置、路径、保留数量和postrotate行为都符合预期后，才应在维护窗口中执行真正的轮转操作。

验收时的正常与异常分界

使用固定阈值只能作为告警起点，不能替代增长速度和留存周期计算。以下是一个便于落地的示例策略，具体数值应根据日志增长速度、维护周期和业务容忍度调整：

例如，可以把Use%低于80%作为普通状态、80%至90%作为告警状态、90%以上作为紧急状态，但这只是运维策略示例，不是香港云服务器或某种机型的固定标准。若日志每天增长很快，即使使用率低于80%，也可能无法覆盖下一轮留存周期；反之，增长非常稳定且有明确归档机制时，单看百分比也不够准确。

更可靠的验收方式是同时满足两个条件：

• 当前Avail足以覆盖“剩余留存周期所需空间+运行预留空间”；
• 按实际采样得到的增长速度推算，在下一次清理、扩容或归档之前不会达到紧急边界。

保存检查证据

为了让后续扩容、调整留存策略或排查空间回收失败时有依据，可以将检查结果保存到受限目录：

LOG_PATH=/var/log
OUT="/var/tmp/log-disk-check-$(date -u +%Y%m%dT%H%M%SZ)"

mkdir -m 700 "$OUT"

{
  echo "timestamp=$(date -Is)"
  echo "hostname=$(hostname)"
  echo
  echo "[os]"
  cat /etc/os-release
  echo
  echo "[mount]"
  sudo findmnt -T "$LOG_PATH" -o TARGET,SOURCE,FSTYPE,OPTIONS
  echo
  echo "[filesystem]"
  sudo df -hT "$LOG_PATH"
  echo
  echo "[inode]"
  sudo df -ih "$LOG_PATH"
  echo
  echo "[directory]"
  sudo du -x -h --max-depth=1 "$LOG_PATH"
  echo
  echo "[directory_total_bytes]"
  sudo du -x -s --bytes "$LOG_PATH"
} 2>&1 | tee "$OUT/summary.txt"

if command -v lsof >/dev/null 2>&1; then
  sudo lsof -nP +L1 2>&1 | tee "$OUT/open-deleted.txt"
else
  echo "lsof未安装，未执行已删除打开文件检查" | tee "$OUT/open-deleted.txt"
fi

sha256sum "$OUT"/* | tee "$OUT/SHA256SUMS"

留证内容至少应包括：

• 检查时间和服务器标识；
• 日志路径、挂载点和文件系统类型；
• df -hT、df -ih结果；
• du目录汇总和总字节数；
• 已删除但仍打开文件的检查结果；
• 清理前后的同类输出；
• 归档或备份的校验信息。

这些文件可能包含主机名、目录名、应用名和日志文件名。对外提交前应按安全要求脱敏，不要把完整日志内容或敏感路径直接发送到无关系统。

根据复测结果决定容量是否合适

清理完成后，不能只看命令是否执行成功，应重新执行同一组检查：

sudo df -hT /var/log
sudo df -ih /var/log
sudo du -x -s -h /var/log

如果删除了已关闭的旧日志，df的Avail通常应增加，du的目录总量应下降；如果du下降而df没有明显变化，应检查删除文件是否仍被进程打开、清理对象是否位于另一个挂载点，或者同一文件系统中是否有其他目录正在同步增长。

最终判断大存储香港云服务器是否满足日志留存需求，应以实际采样得到的日均增长量、原始日志和索引的真实占用、既定留存天数以及可用空间余量为依据。发生以下任一情况时，应重新评估容量或留存策略：

• 当前可用空间无法覆盖下一个留存周期；
• df持续增长而du无法解释增长来源；
• inode先于字节容量达到告警边界；
• 日志索引或临时处理目录增长速度超过原始日志；
• 清理后空间没有按预期释放；
• 归档和删除动作没有形成可验证的留痕。

复测应在相同日志路径、相同挂载点和相近业务负载下进行，并保留前后两次证据。这样得到的结论，才足以判断当前大存储配置是否真正支撑日志分析平台的留存周期，而不是只证明某一时刻磁盘看起来还有空间。