在我们繁忙的服务器上，我们最近使用以前的mysqldump/bzip2的MariaDB备份策略撞到了屋顶。
所以，我开始寻找替代方案，并很快发现了Percona Xtrabackup及其后代Mariabackup。作为物理而不是逻辑备份方法，这些方法基本上复制了服务器存储，而不是将数据库内容倾倒到复制SQL语句中，因此它们遵循一个非常不同的策略。最大的优势是备份过程引起的数据库锁定较短。另外，他们都提供增量备份，这些备份进一步缩短了连续运行的执行时间。
当然，任何备份策略都与相应的恢复过程一样好。使用逻辑mysqldump备份，该过程是直接的，甚至可以在恢复之前检查数据。使用物理备份，标准方法是恢复服务器实例整体提供的完整数据库。描述了单数据库恢复，但令人惊讶的是复杂，例如涉及在导入备份数据之前放弃外键约束并之后重新建立它们。
当然，所有这些操作都应准备并在您采用新的备份策略之前进行准备。经过更多的搜索，我想到了一个名为run-mariabackup的脚本软件包，该软件包存在于不同人维护的多个进化步骤中。尽管它看起来很有希望，但当前状态留下了多个功能。特别是单数据库修复脚本。
在告诉您链接到存储库之前，请警告：这是非常新的代码，几乎没有测试！，请将其视为实验代码，这意味着您需要彻底查看它并在将其放入任何形式的生产环境之前，请自己对其进行测试。如果您的数据对您有任何价值，请执行独立备份！在依靠它之前，请确保备份和恢复有效！
所以，这是几个小时的bash脚本和尝试各种情况的结果：
tvogel
/
run-mariabackup
叉和重写Yosijo/Run-Mariabackup
README
- forked from YoSiJo/run-mariabackup
注意：我已经在opensuse tumbleweed 20230512上对此进行了测试。
脂肪警告
这个新叉（截至2023-05-15）的测试和使用非常有限。特别是，只有Myisam和InnodB表格 在这些有限的情况下，它效果很好，但是根本无法保证它可以在您的特定环境中实现任何目的。由于它在完整的数据库服务器设置上行动可能具有许多我从未见过的数据库和复杂性，因此此脚本很可能会破坏您的方案，并且可能会产生灾难性效果。就像一个非排他性的示例一样，我没有在使用存储过程或触发器的数据库上尝试过它。
因此，只有在您自己的受过教育的评论和您自己的风险之后使用这些脚本！
另外，请分享任何疑虑和观察结果。
备份
调整一些设置以适合您的环境中的环境，备份很容易：
# ~/git/run-mariabackup/backup.sh
将以指定的间隔和之间的增量备份运行完整的基本后卫。您还可以通过将base-backup.request文件放入备份目标目录中请求新的完整基础背包，如果您想在每个星期日晚上触发cron的完整基本后卫，这很方便。
命令还将丢弃超过指定年龄的备份。
恢复
为了还原所有数据库，您可以转到代表要还原的状态的备份数据目录和：
# ~/git/run-mariabackup/restore.sh
这将使您的旧数据指导将其移开（并将其保留）并将完整的备份移回原位。
如果您仅对一个数据库感兴趣，请使用：
# ~/git/run-mariabackup/restore.sh <original> <restored>
在这种情况下，恢复的数据不是直接放回原位，而是将其放入一个名为<restored>的新数据库中，该数据库必须以前不存在。之后，您可以使用简单的mysqldump/mysql管道在检查后将数据放回原位。这也可以用于仅恢复单个表（如果这完全有意义）。
克朗
我是https://habilis.net/cronic/的忠实拥护者，所以我会为您的/etc/crontab推荐这样的东西：
# run base mariabackup once a week (Sunday night) and incremental every 12 hours
54 00 * * 1 root cronic touch /var/backup/mariabackup/base-backup.request
55 00,12 * * * root cronic /root/git/run-mariabackup/backup.sh
在此时间点，我对评论和反馈感兴趣。所以，我很高兴听到您的回音！