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

数据库用户名、服务器地址和权限必须匹配应用配置。网站使用专用数据库用户，日常程序不应使用数据库管理员账户。

更新日期：2026-09-16

规范地址：https://stock.iftalking.com/guides/database-backup/

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

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

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

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

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

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

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

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

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

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

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

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

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

```bash
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 还要同步备份上传目录、主题和配置，完整清单见[备份恢复](https://stock.iftalking.com/guides/backup-restore/)。更换域名时按[迁移教程](https://stock.iftalking.com/guides/wordpress-migration/)处理序列化数据，不能对 SQL 文件做盲目字符串替换。


## 完成后检查

恢复成功需经过应用读写测试，不能只看 SQL 文件导入命令退出。

## 参考资料

- [dev.mysql.com · 项目文档](https://dev.mysql.com/doc/refman/8.4/en/backup-and-recovery.html)