一般是做异地备份和异地容灾。目前也有更好的选择，比如说用“多备份”这款工具来实现异地多云备份容灾，把MySQL数据库加密分布式存储备份到百度云、阿里云、亚马逊云、金山云、腾讯云、七牛、ucloud等，保证数据不丢失！
醴陵网站制作公司哪家好，找创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站设计等网站项目制作，到程序开发，运营维护。创新互联成立与2013年到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联。
我们就说三个层次的灾备系统的标准：首先看国际标准SHARE78，这个标准将灾难恢复分成八个层次：那么从存储结构来看，SHARE78涵盖最简单的本地磁盘的备份，到将备份的磁带存储在异地，再到建立应用系统实时的切换的异地备份系统。那么从恢复的时间点角度来看，SHARE78涵盖几天级，几小时级、几分钟、几秒级，这是零数据丢失。
SHARE78它将异地灾备的定义为如下七个级别，我们国家六个级别，它是定义七级别。
第一个级别第0级容灾方案：这个时候数据仅在本地进行备份，没有在异地备份，并且没有制定灾难恢复计划，这是最简单的一种，对吧，也是最便宜的一种。
第1级容灾方案，它将关键数据备份到本地磁带介质上，然后送往异地保存。
第2级容灾方案，就是在第1级的容灾方案的基础上，再增加了一个热备中心。
那么从第0级，第1级，第2级这三种容灾方案，到目前来说，应该说对于大中型企事业单位，已经不能再用了，已经被淘汰了。被小的机构用是另外一回事。
大机构用的都是下面要介绍的3级以上的容灾方案，或者是容灾级别。
第3级，那么在这一级中，就通过网络将关键的数据进行备份，并且存放至异地，制定有相应的灾难恢复计划，有备份中心，并且配备部分数据处理系统及其网络通信系统。
第4级的容灾方案，那么这个时候增加了备份管理软件，自动通过通信网络将部分关键数据定时的备份到异地，这么一种功能。同时还制定了相应的灾难恢复计划。
第5级的容灾方案，增加了硬件的镜像技术和软件的数据复制技术。也就是说可以实现在应用站点与备份站点的数据多备份更新。
第6级容灾方案，这个时候利用专用的存储网络，将关键数据同步镜像至备援中心，数据不仅在本地进行确认，而且需要在异地进行确认，这个异地就是备援中心那个地方进行确认，实现零数据的丢失。
第7级也就是最高级的容灾方案。那么这个时候当一个工作中心发生灾难时，能够提供一定程度的跨站点动态负载平衡和自动系统的故障切换功能，这是最高级的，这是SHARE78的情况。
灾备的7个层次
据国际标准SHARE78的定义，灾难恢复解决方案可根据以下主要方面所达到的程度分为七级，即从低到高有七种不同层次的灾难恢复解决方案。可以根据企业数据的重要性以及您需要恢复的速度和程度，来设计选择并实现您的灾难恢复计划
简单的说几句吧。其实这个解决方案呢，主要是要先考虑成本问题，其他的，技术问题其实都很容易解决，但是企业应用上，最大的限制就是成本。下面以ORACLE数据库为例，简单说说。希望对你有所帮助。(数据库类型并不重要，解决方案都是大同小异。)
1、基于存储层的容灾复制方案
这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大；系统可以实现数据的同步或异步两种方式的复制。对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。
2、基于逻辑卷的容灾复制方案
这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。
3、基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制(主要在oracle9i环境中)。
数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
1、mysqldump，mysql自带的备份，每日业务低峰期全备一次，备份完未压缩前大小10G-50G不等，不管mysql多大，这个备份最好每日都备份一次，选择业务最不忙的时候，例如凌晨3、4点钟。不建议每天备份若干次，因为备份时间长，期间占用资源比较高
2、xtrabackup，第三方percona公司出的全备+增量备份工具，根据你业务特征，如果需要恢复级别很高。例如只允许丢失半小时数据，那么就凌晨全备，之后都在前一个备份的基础上进行增量备份。对于innodb引擎表不会锁表，且增量备份时间短且占用系统资源不高，且可以实现相对实时的备份，所以还是很实用的mysql备份工具的。具体内容你上perocona官网周到xtrabackup文档好好阅读下，不是很多内容，很快能读完的。答案摘自希赛系统学院
