$this->dbutil->backup() 仅生成SQL字符串而不自动写入文件，必须配合 write_file() 或 file_put_contents() 手动保存；restore() 默认仅语法校验，需显式传 TRUE 参数才执行还原，且目标数据库须预先存在。
$this->dbutil->backup() 不会自动写文件，返回的是 SQL 字符串；$this->dbutil->restore() 默认不执行 SQL，必须显式传 TRUE 才真正还原。
为什么 backup() 调用后找不到备份文件？
因为 $this->dbutil->backup() 从不写磁盘——它只生成一个包含 CREATE TABLE 和 INSERT 语句的字符串。你得自己保存。
- 必须配合
write_file()或file_put_contents()手动落盘，例如：file_put_contents('./backups/backup_'.date('Y-m-d_H-i-s').'.sql', $backup) - 目录
./backups/必须存在，且 Web 进程用户（如 www-data）有写权限；建议用绝对路径，比如/var/www/myapp/backups/ - 调用后务必检查返回值：
if ($backup === FALSE) { log_message('error', 'Backup failed'); }，否则视图、分区表或权限不足时会静默失败 - 别依赖输出缓冲或 opcache：大备份前加
ob_end_clean()，避免内容被截断
大数据库备份总超时或内存溢出怎么办？
CI 的 backup() 是全量加载到内存再拼接字符串，100MB 以上 SQL 极易触发 max_execution_time 或 memory_limit。
- 必须前置设置：
set_time_limit(0)和ini_set('memory_limit', '512M')（根据实际数据量上调） - 压缩再保存更省空间：
file_put_contents($gz_path, gzencode($backup))，体积可降至原 SQL 的 20%~30% - 不支持增量备份，每次都是全量 dump；表多或单表 >500MB 时，别硬扛——改用
xtrabackup或分表循环导出 - CLI 环境比 Web 更稳：
php index.php tools backup可绕过 Web 服务器超时限制
restore() 执行后没效果，是不是函数没起作用？
不是函数失效，是它默认只做语法解析，不真正执行 SQL。这是最容易忽略的点。
- 关键参数必须为
TRUE：$this->dbutil->restore($sql, TRUE)，第二个参数缺省是FALSE，仅校验语法 - 还原前目标库必须已存在，且最好为空：
backup()不含CREATE DATABASE，只含CREATE TABLE - 若备份含存储过程或函数，MySQL 用户需有
SELECT ROUTINE权限，否则SHOW CREATE PROCEDURE报错导致整个restore()返回FALSE - 还原无事务包装，中途出错不会回滚；生产环境建议先用
mysqldump --single-transaction备份，或直接走系统命令还原
最麻烦的其实是权限和兼容性：MySQL 8.0+ 的 secure_file_priv 不影响 backup() 生成字符串，但如果你后续想用 LOAD DATA INFILE 恢复，就得严格匹配白名单路径。这种隐性约束，往往等出问题了才意识到。
