类型：虚拟化技术
简介：基于操作系统层级的虚拟化技术，将软件与其依赖项打包为容器。
Docker容器可以删除后重新创建，但数据卷里的内容往往不可替代。WordPress上传文件、数据库数据、配置文件、证书文件和用户生成内容，都可能保存在数据卷或挂载目录中。如果只备份镜像和compose文件，恢复时仍然会丢失关键数据。
很多人以为Docker部署更安全，实际只是环境更容易重建。真正需要保护的是数据。只要数据库和上传目录没有备份，容器运行得再稳定也挡不住误删、磁盘故障和错误升级。
一、先确认数据在哪里
备份前要先确认数据位置。使用docker volume ls可以查看数据卷，使用docker inspect可以查看卷挂载路径。Compose项目中，还要检查volumes字段，分清命名卷、匿名卷和宿主机目录挂载。
WordPress场景通常至少包含两类数据：数据库数据和wp-content目录。数据库保存文章、用户、设置和插件配置；wp-content保存上传文件、主题和插件。两者缺一不可。
二、数据库备份要用正确方式
数据库不建议直接复制正在运行的数据目录。MySQL或MariaDB可以使用mysqldump导出逻辑备份，PostgreSQL可以使用pg_dump。导出文件应包含时间戳，并保存到容器外部的备份目录。
备份完成后，不要只看文件是否存在，还要检查文件大小、导出命令是否报错，并定期在测试环境恢复一次。没有验证过的备份，不能算真正可用。
三、恢复时的顺序
恢复WordPress时，可以先恢复数据库，再恢复wp-content目录，最后检查wp-config.php中的数据库连接信息。恢复完成后，访问后台和前台，检查文章、媒体文件、固定链接、插件状态和主题样式。
如果迁移到新服务器，还要检查域名解析、SSL证书、文件权限和容器网络。数据库恢复成功不代表网站完全可用，图片路径、缓存配置和反向代理也可能影响访问。
四、自动备份也要有告警
很多人配置了定时备份后就不再检查，直到恢复时才发现备份脚本已经失败很久。自动备份必须配合日志和告警，至少要知道最近一次备份是否成功、文件大小是否正常、备份目录是否还有空间。
如果条件允许，可以把备份复制到另一台服务器或对象存储中。只把备份放在同一块磁盘上，无法应对磁盘损坏或整机故障。
五、恢复演练比备份更重要
备份文件只有经过恢复验证，才算真正可用。可以定期在测试环境中恢复一次WordPress，检查文章、图片、插件、主题和固定链接是否正常。
恢复演练还能发现文档遗漏。例如只记录了备份命令，却没有记录数据库用户名、容器网络、文件权限和域名配置，真正迁移时仍然会卡住。
六、备份文件如何命名
备份文件命名最好包含项目名、数据类型和时间，例如wordpress-db-20260611.sql.gz、wordpress-content-20260611.tar.gz。清楚的命名能减少恢复时选错文件的风险。
如果同一台服务器有多个站点，更要避免backup.zip、data.sql这类模糊名称。真正发生故障时，维护者需要快速判断哪个文件对应哪个站点、哪个时间点。
七、恢复后要检查哪些页面
恢复完成后，不要只看首页。还应检查后台登录、文章页、分类页、媒体图片、表单提交、固定链接、插件设置和缓存状态。电商站还要检查订单、支付回调和邮件通知。
如果恢复到新域名或新服务器，还要检查站点地址、SSL证书、反向代理、上传路径和搜索引擎可见性。恢复是一个完整流程，不是导入数据库就结束。
八、多站点服务器的备份隔离
一台服务器上部署多个站点时，备份目录必须清楚隔离。不同站点的数据库、上传文件和配置文件不要混放，否则恢复时很容易拿错文件。
可以按域名或项目名建立目录，再按日期保存数据库和文件备份。备份脚本也要写明来源容器和目标目录，避免后期维护者无法判断备份来源。
