【重点】RTO和RPO详解-创新互联
容灾与备份之间是之间关系容灾与备份之间是之间关系
1.容灾和备份的目的不同
容灾系统的目的在于保证系统数据和服务的“在线性”，即当系统发生故障时，仍然能够正常地向网络系统提供数据和服务，以使系统不致停顿。而备份技术的目的与此并不相同，备份是“将在线数据转移成离线数据的过程”，其目的在于应付系统数据中的逻辑错误和历史数据保存。所以，在各种容错技术非常丰富的今天，备份系统仍然是不可替代的。
2.备份是基石
备份是指为防止系统出现操作失误或系统故障导致数据丢失，而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。
3.容灾不可少
那么建设了备份系统，是否就不需要容灾系统?这还要看业务部门对RTO(恢复所需的时间指标)/RPO(能够恢复到的最新状态)指标的期望值，如果允许1TB的数据库RTO=8小时，RPO=1天，那备份系统就能满足要求。同时，备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据破坏时的数据恢复目的，而不能提供实时的业务接管功能。因此容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾往往是针对当生产系统，不能正常工作时，其业务可由容灾系统接替这些业务，继续进行正常的工作。能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难，特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。
4.容灾不能替换备份
容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了;如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。
5.解读“RTO\RPO”
RPO是你系統如出現資料遺失等問題的時間長度,以此指示系統中斷時間間隔中，資料損失的狀況.
RTO則你系統要在多少時間內回復,亦是你指的系統中斷到重新啟動間所經歷的時間長度
所以量值都是時間
RTO是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需的时间。RTO值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。容灾系统为获得最小的RTO，需要投入大量资金。
RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间;在异步数据复制方式下，RPO基本为异步传输数据排队的时间。在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库的一致性(SCN)是不相同的，RPO表示业务数据库与容灾备份数据库的SCN的时间差。发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。不同容灾方案的RTO和RPO是不相同的。
RTO (Recovery Time Objective，复原时间目标)是企业可容许服务中断的时间长度。
比如说灾难发生后半天内便需要恢复，RTO值就是十二小时;RPO (Recovery Point Objective，复原点目标)是指当服务恢复后，恢复得来的数据所对应时的间点。如果现时企业每天凌晨零时进行备份一次，当服务恢复后，系统内储存的只会是最近灾难发生前那个凌晨零时的资料。
根据以上两个简单的原则，企业不但可以对现有的数据系统作出，也可以按照既定的RTO及RPO要求，选购最适合的灾备方案。
RTO及RPO与方案售价有着密切的关系，然而完美的方案当然是RTO及RPO皆为零，表示当灾难发生后，系统立即恢复，而且完全没有数据丢失，可是其造价是非常昂贵的，而且也不一定有这个必要。
因此，最佳方案必需在RTO，RPO，维护及价钱多方面，都能达致平衡。
尤其是中小企业，在资源紧拙的情况，应先好好了解对RTO及RPO的要求，然后再看看价钱，那就比较容易找到，适合企业的方案了。
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
分享题目：【重点】RTO和RPO详解-创新互联
网页路径：http://6mz.cn/article/eippp.html