更新为什么会出事
核心、主题、插件的更新偶尔会引入不兼容：旧插件与新核心冲突、自定义代码依赖了被移除的函数、数据库结构变更未完成。轻则页面报错，重则整站白屏。没有备份就更新，等于把恢复能力全部押在运气上。
更新前该备份什么
- 数据库：文章、评论、用户、选项，最关键
- 站点文件：主题、插件、上传目录、根目录配置文件
- wp-config.php：数据库与密钥配置，单独存一份
- 伪静态规则（.htaccess 或 Nginx 配置）
备份要同时包含文件与数据库，缺一不可。只备份文件没备份数据库，恢复后文章与设置全丢；只备份数据库则没有插件与上传图。备份完成后，把它复制到服务器之外（对象存储或本地），存放在同一台服务器上的备份在磁盘故障时毫无价值。
推荐的更新顺序
- 确认已有一份完整的、可恢复的备份
- 在测试环境或维护窗口先更新（有 staging 环境时）
- 先更新 WordPress 核心，再更新主题，最后更新插件
- 每次只更新一个，更新后立即检查站点关键页面
- 发现异常立即停止并回滚该单项
回滚步骤
发现问题时不要慌，按以下顺序处理：
- 先定位：查看是否为单个插件导致，停用该插件看是否恢复
- 核心回滚：用备份中的 wp-admin、wp-includes、根目录文件覆盖回去（数据库一般不需回滚）
- 插件/主题回滚：用备份中的旧版本目录覆盖，或改用插件的历史版本包
- 数据库回滚：仅在数据被写坏时进行，覆盖会丢失更新后的新增内容
- 恢复后清缓存，并保留日志便于分析原因
什么时候必须回滚数据库
只有当数据本身出问题（如更新脚本修改表结构后失败）才回滚数据库。大多数插件更新导致的白屏，问题在 PHP 文件而非数据，回滚文件即可。盲目回滚数据库会造成更新期间的新评论、新订单丢失。
把恢复能力变成常态
没有验证过的备份等于没有备份。每季度做一次完整恢复演练：在测试目录或临时域名还原备份，检查前台、后台、登录、表单与图片是否正常。演练过程会暴露备份不完整、密码过期、缺少某个目录等问题——这些问题在真正出事时才发现，代价要大得多。把备份与演练写进运维日程，是站点稳定性的基石。