我们单位有个十几套数据库，想集中规划一下备份，还有恢复计划这方面，想了解一下？

我们单位大大小小的数据库系统有40多套：）。涉及db2、oracle、mysql、sqlserver MongoDB、redis、 PG、 GP、TIDB、PI等 我都快数不过来了。更兴奋的是不同系统还用了不同的数据库版本，比如mysql有5.5 5.7 8.0  sqlserver2000  .2008  2016   2017  oracle 10g  11g等  不仅面临恢复的问题还要直面不同版本恢复的问题。想想都头大。  在没有备份一体机的情况下，我们任由其发展，只是对几个特别重要的数据库进行了自己编写脚本本地备份，然后通过ftp异地传输到一台大容量旧服务器上临时集中存放备份文件。 这还不算完，总不能每天登陆服务器上去检查有没有备份吧？  再做个脚本放到zabbix上对备份文件进行可视化监控，这样每天一开打zabbix就能知道哪个系统没有备份。

当然最好的状态还是购置大容量的备份一体机对备份文件集中存放，这样可以涵盖您那才十几套的数据库。 最重要的是需要实施方都给你加上，然后跟踪一个月备份情况，我们现在就遇到很多坑，有的能备份有的不能备份，有的今天备份成功了，明天就失败了  反正实施人员已经走了，你找400处理这些问题  那就慢慢等吧。。。。

数据的规模上来了，最好还是上一套备份系统，可以把所有的数据备份综合管理起来。但如果确实没条件，也可以自己规划一下，主要有以下几点：
1. 首先要对需要备份的数据库系统做一个统计和梳理，明确下各个库的rpo和rto，根据这些信息可以推算出备份的频率和保存的周期，以及需要的存储空间、大概的性能要求。

2. 所有的库都需要备份，替代不了备份。

3. 建议和管理员沟通，各个库的备份可以集中存放，也可以单独存放。但是不管怎样都建议存放在独立的磁盘空间内。和数据库的存储分开，避免数据库存储故障了，备份也拿不出来了。

4. 明确责任人，定期检查。 比如备份成功率，备份空间使用率等。

5. 按照前面的调研，定期对数据库做恢复测试，实在做不了的 备份集的校验也得做一下。

鉴于你们数据库套数比较容量也比较多，资金规划的话，鉴于采购备份软件一套或者备份一体机，带库一体机，用备份软件的备份策略自动进行备份，利于管理。定期数据验证恢复。