SAP S4系统HANA数据库双机热备和三重备份保护

今天在BASIS群里看到，有人说管理员把数据库删掉，再把数据库备份删除掉跑路，怎么办？

我想了一下，在我现在管理的HANA数据库环境中，即使遭遇这样的极端场景，我们的HANA数据库显然也是可以存活下来的。

因为我们的HANA数据库有三重备份保护：

第一重，数据库每天凌晨有备份放到本地。

第二重，本地备份的数据库被远程的拷贝到另一台服务器上。

第三重，NBU备份一体机把远程拷贝的备份文件再备份到自己的库里。

鼠标手说，你整这么高大上的东西，要花很多钱啊，我告诉他，我没有花一分钱：

存放第一重备份的载体是生产服务器本身的磁盘空间。

存放第二重备份的载体是开发服务器的磁盘空间。（当时为了这个点，所以我把整个磁盘只划了一个大分区来用，详情见：https://basis.blog.csdn.net/article/details/106412432 ）

存放第三重备份的NBU备份一体机，是我在机房里看到，就去联系了这个项目的管理员，这个NBU备份项目是运维部门启动的针对全公司IT系统来做备份，从ERP项目的角度真没有花一分钱。而NBU的管理员属于运维部，ERP项目组的人即使拿到了ERP系统的密码，也没有NBU备份设备的密码，所以极端场景还有NBU的备份存在。

也许你还有一个疑问，多重保护虽好，要实现这些，管理员操作得多复杂啊？我告诉你，全自动的：

第一重备份，是DB13中的定时作业实现；因为HANA数据库除了业务库还需要备份一个SYSTEM系统库，这个备份是OS上写了自动脚本来实现备份。（详情见：https://basis.blog.csdn.net/article/details/106763784）

第二重远程备份，是用SUSE原生的rsync同步功能，在OS脚本中自动实现的（详情见：https://basis.blog.csdn.net/article/details/107613205）

第三重NBU备份，在服务器上安装NBU自己的agent客户端，每天自动发起备份项目。

那么这些备份的状态怎么监控呢？自动的：

因为数据库的备份文件比较大，每天正常有备份和不正常的情况，对文件系统磁盘空间的占用是有影响的，

所以我们有一个自动统计各服务器文件系统大小的监控工具SFSM。（SFSM详情见：https://basis.blog.csdn.net/article/details/107404096）

每天清晨，SFSM统计ERP系统服务器群的文件系统信息，邮件发给一线运维的同事，一线运维的同事只需关注邮件中最后的结论，即文件系统目录空间的最大值即可。