在日本服务器部署网站前，先确认两件事：第一，网站文件、数据库、配置和上传内容都能恢复，而不是只有一份压缩包；第二，实际挂载网站目录的文件系统，能够容纳新版本、临时文件、日志增长、数据库变更以及回滚副本。只要备份无法完成、恢复没有验证，或磁盘容量只能勉强覆盖当前文件，就不应直接切换生产流量。

可以按照“现状核对—变更准备—分步实施—验证观察—回滚条件”执行。容量核对重点不是看服务器总硬盘有多大，而是确认网站所在挂载点的可用空间、inode、数据增长和备份暂存空间；备份核对重点也不是确认任务是否运行过，而是确认备份内容完整、存储位置独立，并且能够在隔离环境中恢复。

现状核对：先确认网站到底需要保护什么

建立网站数据清单

部署前先列出网站运行所依赖的对象，避免只备份代码、不备份真正产生业务数据的目录。

配置文件中的密钥不能因为“已经备份”就随意复制到公共目录或提交到代码仓库。备份介质应限制访问权限，并记录谁可以读取和恢复。缓存、构建产物和临时文件可以不纳入长期备份，但必须先确认它们确实能够重新生成。

如果网站目录尚未确定，可以在 Linux 环境中先查看系统版本和目录挂载关系：

cat /etc/os-release
findmnt -T /srv/www

/srv/www 只是示例路径，应替换为实际网站目录。findmnt 返回的挂载点，才是后续容量核对的重点。网站目录可能位于独立数据盘，也可能与系统目录共用根分区，不能仅凭服务器面板显示的总容量判断。

核对容量、inode和大文件

以下命令适用于常见 Linux 环境，执行前将路径替换为实际目录：

df -hP /srv/www
df -iP /srv/www
du -xhd1 /srv/www 2>/dev/null | sort -h
find /srv/www -xdev -type f -size +1G -printf '%s %p\n' 2>/dev/null | sort -n

需要分别关注四项结果：

1. df -hP 查看实际挂载点的总容量、已用容量和可用容量。
2. df -iP 查看 inode 使用情况。小文件数量过多时，即使还有字节空间，也可能无法创建新文件。
3. du -xhd1 用于定位代码、上传文件、日志和缓存分别占用了多少空间。
4. 大文件列表用于发现异常日志、旧压缩包、构建产物或误上传文件。

容量估算可以按下面的关系进行：

变更所需空间 = 新版本文件空间 + 临时解压或构建空间 + 数据库备份暂存空间 + 回滚版本空间 + 日志和业务增长余量

如果备份文件与网站位于同一个文件系统，还应把备份文件本身计入本次变更的占用量。更稳妥的做法是先将备份写入独立存储位置；如果必须在日本服务器本机暂存，则应在备份完成后再次检查 df，确认备份没有把生产分区推到无法写入的状态。

不要用一次检查结果代替容量规划。至少记录当前使用量，并结合近期日志、上传文件、数据库和备份目录的增长趋势估算余量。没有历史监控数据时，应把首次部署视为高风险变更，先保留足够的临时空间，并在上线后建立按日或按小时的容量监控。

变更准备：把备份策略变成可执行条件

先确定RPO和RTO

备份频率应由业务能够接受的数据丢失量决定。

• RPO：故障发生后，最多可以接受丢失多长时间内的数据。
• RTO：从故障发生到网站恢复服务，最多可以接受多长时间。

例如，网站每天只有少量内容更新，备份策略可以围绕每日变更安排；如果网站持续接收订单、留言或上传内容，就需要更频繁的数据库保护。这里不能直接套用固定的“每天备份”或“每周备份”，因为频率必须与实际写入量和业务影响相匹配。

备份策略至少要回答以下问题：

• 哪些文件和数据必须恢复？
• 备份运行失败后，谁会收到通知？
• 备份保留多少个恢复点？
• 备份副本是否与生产磁盘相互独立？
• 恢复时是否需要停止写入？
• 最近一次恢复测试是什么时候完成的？

同一块磁盘上的压缩包只能降低误删风险，无法应对磁盘损坏、文件系统故障或服务器整体不可用。快照可以作为快速回退手段，但不能代替独立的逻辑备份，尤其不能代替数据库一致性备份。

区分文件备份和数据库备份

网站文件通常可以按版本目录或归档文件保存，但数据库不能简单地在正在写入时复制数据目录。应根据数据库类型、运行版本和业务写入情况选择兼容的逻辑导出、物理备份或数据库原生备份方式。

执行前先确认实际使用的数据库和客户端版本：

command -v mysqldump
command -v pg_dump
mysql --version 2>/dev/null
pg_dump --version 2>/dev/null

上面的命令只用于识别环境，不代表两种数据库都需要安装。不要在未确认数据库类型、认证方式和存储引擎的情况下，直接套用其他环境的导出参数。数据库备份完成后，应检查退出状态、文件大小、生成时间和校验值；仅看到命令输出“完成”并不能证明备份可用。

文件备份可以使用归档工具，但应避开正在持续变化的缓存、临时目录和数据库数据目录。示例：

BACKUP_DIR=/var/backups/site-$(date +%Y%m%d-%H%M%S)
mkdir -p "$BACKUP_DIR"

tar -C /srv/www -czf "$BACKUP_DIR/site-files.tgz" .
sha256sum "$BACKUP_DIR/site-files.tgz" > "$BACKUP_DIR/SHA256SUMS"

这段示例仅适用于已经确认路径、权限和剩余空间，并且网站文件可以在该时点稳定读取的场景。若网站有持续上传，备份期间应启用维护模式、暂停写入，或使用应用和存储系统提供的一致性备份方式。不要把数据库目录直接打包当作数据库备份。

准备恢复测试环境

正式切换前，至少用一份备份在隔离目录或独立测试实例中恢复：

• 文件恢复到非生产目录，检查目录层级、权限和关键文件是否存在。
• 数据库恢复到独立数据库或隔离实例，不要直接覆盖生产库。
• 使用恢复后的配置启动应用，确认应用能够连接数据库和读取上传文件。
• 执行登录、页面访问、关键查询、文件上传或其他实际业务流程。
• 对备份文件执行校验，确认传输或复制过程中没有损坏。

恢复测试不应只看文件数量。数据库能够导入，也不代表应用能够正常使用；网站能够打开首页，也不代表登录、写入和上传流程没有问题。

分步实施：先保留旧版本，再切换新版本

第一步：记录变更前状态

在日本服务器上记录当前版本、配置位置、服务名称和运行状态。使用 systemd 的环境可以执行：

systemctl list-units --type=service --state=running
systemctl is-active <实际服务名>

<实际服务名>必须替换为环境中真实存在的服务，不要猜测。若系统没有 systemd，应使用该发行版实际的服务管理方式。

同时保存以下信息：

• 当前网站代码或发布目录的路径；
• 当前配置文件的校验值或备份副本；
• 当前数据库备份的文件名和校验值；
• 当前磁盘使用率和 inode 使用率；
• 当前应用版本、依赖版本和定时任务；
• 现有日志位置及变更开始时间。

如果使用版本目录发布，优先把新版本放到新的目录中，而不是直接覆盖正在提供服务的目录。例如：

install -d -m 0755 /srv/www/releases/

随后将经过检查的代码和静态文件放入 。路径、属主和权限应与当前运行版本保持一致，但不要盲目执行递归权限修改，避免覆盖上传目录或敏感配置的权限。

第二步：完成变更前备份

变更前备份应覆盖三类内容：

1. 当前生产文件和上传数据；
2. 当前数据库的一致性备份；
3. 当前配置和回滚所需的旧版本。

备份完成后检查：

sha256sum -c /var/backups/site-<时间>/SHA256SUMS
df -hP /srv/www
df -iP /srv/www

如果校验失败、备份文件大小异常、数据库导出返回错误，或备份后可用空间明显不足，应停止部署。不要为了继续上线而删除旧日志、旧备份或未知用途的文件。先定位占用来源，再通过扩容、迁移备份位置、清理已确认可重建的缓存或调整发布方式解决。

第三步：检查配置并执行小范围切换

新版本应先在不接收正式流量的条件下完成配置检查。若环境使用 Nginx，可以使用其实际版本支持的配置测试命令；若使用 Apache，则使用对应的配置检查命令。不要在未确认服务类型时直接执行某个服务的检查命令。

应用启动后，先进行本机或内部检查，再切换正式流量。采用“新目录发布、旧目录保留”的方式时，回滚只需要把当前指向切回旧版本；但必须先确认当前路径确实是符号链接或由发布工具管理，不能对普通目录直接执行替换操作。

数据库结构变更应单独控制。变更前必须已经完成数据库备份，并确认迁移脚本是否可逆。代码可以回滚，不代表数据库结构也能自动回滚；如果迁移删除了字段、改变了数据格式或执行了不可逆转换，应提前准备经过测试的反向迁移方案，或者准备从备份恢复的流程。

验证观察：从磁盘到业务逐层确认

切换后不要立即删除旧版本或旧备份，应按由低风险到高风险的顺序检查。

基础资源检查

df -hP /srv/www
df -iP /srv/www
du -xhd1 /srv/www 2>/dev/null | sort -h

确认新版本写入的是预期目录，日志没有因为路径错误持续增长，inode 没有快速耗尽。若磁盘空间在切换后异常下降，应先定位新增文件和日志来源，而不是直接删除文件。

服务和应用检查

检查服务是否处于运行状态，并查看变更时间之后的日志。使用 systemd 的环境可以参考：

systemctl is-active <实际服务名>
journalctl -u <实际服务名> --since "<变更开始时间>"

如果应用提供健康检查地址，可以从本机发起请求：

curl -fsS http://127.0.0.1/<健康检查路径>

健康检查路径必须是实际存在的接口。没有该接口时，应改用真实页面和关键业务请求验证。至少检查首页、登录或身份验证、数据库读取、用户上传文件访问，以及一项实际写入流程。涉及支付、订单或其他重要操作时，应使用测试数据或业务方确认的验证方式，避免在生产环境制造无效记录。

观察备份和日志任务

变更后的第一次备份尤其重要。确认：

• 备份任务按计划启动；
• 文件和数据库备份都产生了新恢复点；
• 备份没有将生产分区占满；
• 校验任务没有报告损坏；
• 失败通知能够送达负责人。

观察窗口不应只覆盖切换瞬间，至少应覆盖一次关键业务高峰或完整业务周期，并覆盖下一次计划备份。对于有定时任务、批处理或周期性上传的网站，还要观察这些任务是否使用了旧路径、旧配置或旧权限。

回滚条件：出现这些情况不要继续观望

满足以下任一条件时，应暂停新增变更并评估回滚：

• 变更前备份未完成，或恢复测试无法通过；
• 网站所在文件系统可用空间或 inode 持续下降，已经影响写入；
• 应用无法启动，关键接口持续失败；
• 数据库连接、查询或写入出现持续错误；
• 用户上传文件无法保存或读取；
• 定时任务执行失败，且影响业务数据；
• 新版本产生无法解释的大量日志、临时文件或重复数据；
• 关键业务指标明显低于变更前基线。

回滚时先进入维护模式或暂停写入，保留现场日志和当前版本文件，不要先删除故障版本。随后按以下顺序处理：

1. 记录当前时间、错误日志、磁盘状态和数据库状态。
2. 将网站代码、配置或发布指针切回已验证的旧版本。
3. 按旧版本要求恢复服务，并检查基础页面和关键业务。
4. 如果数据库结构已经变更，只执行经过测试的反向迁移；没有可靠反向迁移时，不要强行执行未知 SQL。
5. 如必须恢复数据库，先备份回滚前产生的新数据，再在维护状态下按恢复方案操作。
6. 回滚完成后重新执行服务、业务、磁盘和备份检查。

只有在新版本已经通过观察窗口、备份任务也成功运行，并且确认不再需要旧版本占用的空间后，才可以清理旧发布目录或临时文件。清理前应再次核对路径和备份状态，避免把唯一可回滚版本误删。这样核对日本服务器的备份策略与磁盘容量，才能把“能部署”进一步落实为“出现故障时可以恢复”。