MySQL 与 MariaDB：账户、备份和恢复验证

1. 先确认数据库类型与范围#

WordPress 数据库包含文章、用户、设置和插件数据。先在 wp-config.php 中核对数据库名和主机，不要把密码公开复制出来；数据库是 MySQL 还是 MariaDB、版本多少，也要记录。

备份前确认剩余磁盘空间，选择网站公开目录之外的位置。大型数据库、非事务表或复制集需要专门方案；下面以普通单站点、以 InnoDB 为主的数据库逻辑导出为例。

2. 用匹配的导出工具创建文件#

MySQL 使用 mysqldump，MariaDB 优先使用对应版本的 mariadb-dump。-p 后不直接写密码，让客户端提示输入；不要把真实密码留在 shell 历史里。

umask 077
mysqldump -u backup_user -p --single-transaction --quick --no-tablespaces wordpress > wordpress-backup.sql

用户名和库名替换为实际值，并为备份账户授予所需权限。--single-transaction 对支持事务的表提供一致性快照，但备份期间不应同时执行表结构变更；非事务表需要锁定或停写方案。涉及存储过程、事件等对象时，按实际需要增加相应选项和权限。

3. 检查退出状态与文件内容#

ls -lh wordpress-backup.sql
head -n 8 wordpress-backup.sql
sha256sum wordpress-backup.sql

导出命令失败也可能留下一个空文件或不完整文件，必须检查命令退出状态与错误输出。head 只用于本地检查，不能把含用户数据的 SQL 发到公开渠道。压缩前先确认导出完成，再把副本传到另一处并按需要加密。

宝塔等面板的数据库备份入口更直观，但同样要确认备份时间、大小、下载位置和恢复能力，不以按钮提示为唯一证据。

4. 恢复到新的测试数据库#

先创建一个空的测试库和只访问它的用户，再导入。下面示例会写入目标数据库，因此必须确认目标是新建测试库，不是正在使用的生产库。

mysql -u restore_user -p wordpress_restore < wordpress-backup.sql

检查表数量、关键记录和应用连接。跨版本导入时关注字符集、排序规则、SQL 模式和保留字；MySQL 与 MariaDB 不能假设所有版本完全兼容。若导出文件包含 CREATE DATABASE/USE，先审阅它是否会改写到其他库。

5. 连接失败与忘记密码分别处理#

“Access denied”可能是密码错误，也可能是用户的 host 授权不匹配；“Can't connect”先看数据库服务、socket 或网络。应用迁移到容器后，localhost 的含义会变化。

忘记数据库管理密码时，优先使用现有授权管理员或面板的正规恢复流程。不要把跳过权限检查的数据库服务暴露在公网，也不要把网上的 root 重置命令直接用于不匹配的数据库版本。

6. 建立自动备份与恢复记录#

自动任务使用权限受限的客户端配置或秘密管理方式，避免把密码写进命令参数。记录开始、结束、退出状态和备份大小，失败时保留上一份成功副本。保留策略按恢复需求制定，定期做一次应用级恢复演练。

WordPress 还要同步备份上传目录、主题和配置，完整清单见备份恢复。更换域名时按迁移教程处理序列化数据，不能对 SQL 文件做盲目字符串替换。