有木有 DBA 大佬，想求教一下数据库云备份的方案

[clacf1]

我们公司生产环境是部署在微软云上的 mysql 数据库，大约有 1tb 。经过几次代码 bug ，导致数据库崩溃，现在迫切需求一种可以快速恢复的备份方案。 方案一：每天使用 mysqldump 分库全备，同时备份每小时的 binlog ，但是这个样子全备速度太慢了，全备一次得 20 小时。

有没有更好的方案呢？我们不介意付费的厂商或者方案，请大家不吝赐教。 需求就是在生产环境极限灾难下，主备机器全部挂掉，可以快速恢复至半小时前的状态。

[SpMozzi]

可以快速恢复至半小时前的状态,说明对数据一致性要求不高,可以考虑

[clacf1]

@SpMozzi 可以考虑什么方案呢？

[SpMozzi]

可以快速恢复至半小时前的状态,说明对数据一致性要求不高,可以考虑
1. 跨区 在部署一个 slave,不同区域同时挂的概率相对是很低很低的, 当同一个区挂了,可以直接切到另一个区,数据延迟也不会高.
2. 通过 xtrabackup 进行每天的全量备份, 然后将备份拷贝到另一个地方, binlog 可以根据实际情况进行备份走.
3. 直接上云实例,一样跨区部署

[yekern]

xtrabackup 全量备份以后,每几个小时或者每天走增量备份.

```
#!/bin/bash

DATA_DIR="/opt/mysql/data"

BACKUP_DIR="/data/backup"

OLD_DIR=`cat /data/backup/log/mysql-last-backup.log`

NEW_DIR=`date +%F`

MYSQL_DATABASE_HOST="地址"

MYSQL_DATABASE_USERNAME="用户名"

MYSQL_DATABASE_PASSWORD="密码"

MYSQL_DATABASE_PORT=3306

if [[ ! -d ${BACKUP_DIR}/base ]];then

echo "还未全量备份"

exit 1

fi

/usr/bin/xtrabackup --defaults-file=/opt/mysql/conf/my.cnf --backup --compress=lz4 --datadir=${DATA_DIR} --incremental-basedir=${BACKUP_DIR}/${OLD_DIR} --target-dir=${BACKUP_DIR}/${NEW_DIR} --user=${MYSQL_DATABASE_USERNAME} --password=${MYSQL_DATABASE_PASSWORD} --port=${MYSQL_DATABASE_PORT} --host=${MYSQL_DATABASE_HOST} --no-server-version-check --apply-log-only &> /data/backup/log/mysql-last-backup.log

tail -n 1 /data/backup/log/mysql-last-backup.log | grep 'completed OK!'

if [[ $? -eq 0 ]];then

echo "${NEW_DIR}" > /data/backup/log/mysql-last-backup.log

else

echo "备份失败"
echo "${OLD_DIR}" > /data/backup/log/mysql-last-backup.log

exit 1

fi
```

[clacf1]

@SpMozzi 我们有次，是因为代码问题，切了备机以后，备机也被整挂了。主从这种模式，没法低于来自代码 bug 导致的问题。这个 xtrabackup 的备份效率高吗？和 mysqldump 比较起来呢？因为涉及到快速恢复，最好可以分库备份。

[chuckzhou]

这么大数据量想要迅速恢复，只能用 btrfs 的快照，zfs 应该也可以。
采样主从方式，在从服务器上隔半个小时就建立一次快照。
出问题了就恢复最近一次的快照，然后把从切为主。
如果你网卡是 10G 以上的，用 xtrabackup 也行，恢复 1T 数据估计得 20 分钟。

[joyhub2140]

只有快照才能满足楼主需求了，不用运维去做把，我记得云厂商都有快照功能，根据快照的大小进行计费。只对数据库的的云盘打快照就行了。

[jixiangqd]

云上数据库不建议搞这么大，建议拆成多个库，使用中间件访问。
比如阿里云以前的 DRDS ，现在的 Polar-X 。

如果非要搞这么大，建议不要用开源，用云各家厂商搞的存算分离架构数据库恢复会快一些

[Worldispow]

xtrabackup 我记得是要登录服务器操作的，云数据库不具备操作条件，最好的办法是购买云厂商的数据备份服务

[buchikoma]

数据量大，还有时间点恢复的需求，为啥不直接用 rds 实例

[tool2d]

你那么大的数据量，用 binlog 也不是那么靠谱，太慢了。

最好就是二进制数据和文本数据分离，严重怀疑 1tb 直接把图片之类的保存进去了。应该学 github ，大文件走专门的通道，不要图省事用 blob ，和文本数据库混合在一起。

[wps353]

应该招个 DBA 来解决问题。/dog

[Itesting]

如果快速恢复到 X 小时前的话，可以设置配置一个 slave 节点，配置：CHANGE MASTER TO MASTER_DELAY = N;
，比如：30 分钟，180 分钟，这样这个实例就是历史的状态，如果 线上 DB 出问题可以马上恢复。相关参数官网说明链接： https://dev.mysql.com/doc/refman/5.7/en/replication-delayed.html
注意：上述方案按照钱来换时间，即使开启这个，也要开启相应的全量备份。同时设置的时间要把握好，如果决策慢了，这个 slave 节点的数据会和线上一致也无法提供服务了。

[0x1111]

1 ，还可以考虑主从外，再加一个跨区的延时 slave ，指定同步延时 1 小时或 1 天这种思路，实时业务真出问题，能有一个延时数据可以快速提供服务
2 ，xtrabackup+binlog ，这么大的数据量，备份需要时间，恢复也是需要很久的，这种可能磁盘快照会更合适，云服务快照，lvs 快照
3 ，单实例这么大的数据量，可运维性非常不友好，还是核心存储的话，真的建议治理下，看看怎么拆分。

[fredcc]

Azure Mysql 支持每日快照，每 5 分钟事务日志，可以还原到备份保留期内到任意时间点。https://learn.microsoft.com/zh-cn/azure/mysql/single-server/concepts-backup

上云了还自建 mysql 自建备份还原？

[SpMozzi]

@clacf1 这里可以考虑用多个 slave 进行分流,不要所有业务全部打到一个实例上去.xtrabackup 备份恢复速度都是远远高于 mysqldump 的. 还有你可以考虑把业务拆分成独立的实例,这样会减少数据量,恢复起来也会快很多

[whileFalse]

你是在 azure 的虚拟机上自己部署的 mysql ，还是用的 azure 托管 maysql ？

[shadowyw]

听上去像是用的 Azure Database for MySQL; 如果真是这样的话, azure 技术支持会很积极帮您选购解决方案的

[buchikoma]

@whileFalse #17 听 op 描述肯定是虚机自建 Mysql 的场景，直接用托管服务不会直接用 mysqldump ，直接用 rds 提供的定时备份就行了

[wuhao1]

不知你们是哪些内容占用了数据库的存储空间，
我们是只要是 文字内容占用，最近刚搞了，把所有文字存 硬盘，一下子节省了几百鸡的数据
不存数据库后性能上应该还会有提升！