执行MariaDB数据恢复时是否必须停止MariaDB Server？

核心原因三个，没有任何商量的余地：

• 运行中的MariaDB会持有数据目录下ibd、ib_logfile*、undo*这类核心文件的排他锁，进程会持续往这些文件里写数据、刷脏页。没停服务就跑恢复命令，要么mariabackup拿不到写权限直接报错退出，要么强行绕开权限覆盖文件，会出现数据库进程和恢复进程同时写同一块磁盘块的情况，最终生成的文件全是半新半旧的坏块，页校验全错，数据直接报废。
• MariaDB启动后会在内存里缓存大量和磁盘数据绑定的状态：包括未刷盘的脏页、未提交事务的上下文、表结构元数据、锁信息。就算绕开限制把磁盘文件全换成了备份的一致性版本，内存里存的还是旧数据的状态，两边完全无法对齐，后续随便跑查询、写数据都会触发元数据错乱、事务冲突，轻则业务报错重则进程直接崩溃，数据一致性没有任何保障。
• 从工具设计逻辑上，--copy-back/--move-back的作用就是把已经做完日志应用的冷一致性数据集整个覆盖到数据目录，压根没有开发和运行中实例做状态对齐、增量同步的逻辑，从根上就不支持热替换正在被使用的数据集。

完全不可能，不要尝试这类操作。所有你看到的“无感知全量恢复”方案，本质都绕开了“在原运行实例上直接跑--copy-back”的逻辑，不属于当前问题覆盖的场景：

• 第一种是用备用实例切流：你可以在另一台服务器上停掉MariaDB，正常用--copy-back把备份恢复完成，启动实例追平增量数据，之后把业务流量切到这台新实例上。整个过程业务侧感知不到停服，但恢复操作本身还是在停库状态下执行的，只是通过高可用切换把停服影响隐藏了。
• 第二种是逻辑备份恢复：如果你用的是mysqldump这类导出SQL文本的逻辑备份，确实可以在实例运行的时候直接导入数据，但这是SQL层面的逻辑写入，和mariabackup做文件级物理全量恢复根本不是同一种技术路径，物理备份的文件没有办法在实例运行时热加载生效。

别信改参数、绕文件锁强行热恢复的野路子，最后搞坏数据无法找回没有任何兜底方案。

内容的提问来源于stack exchange，提问作者Bibek Poudel