RTO、RPO和SLA规划
建议更改
PDF
借助ONTAP、您可以根据业务需求轻松定制Oracle数据库数据保护策略。
这些要求包括恢复速度、允许的最大数据丢失量以及备份保留需求等因素。数据保护计划还必须考虑数据保留和还原方面的各种法规要求。最后、必须考虑不同的数据恢复场景、从因用户或应用程序错误而导致的典型和可预见的恢复到包括站点完全丢失在内的灾难恢复场景。
对数据保护和恢复策略进行微小更改可能会对存储、备份和恢复的整体架构产生显著影响。在开始设计工作之前、必须定义并记录标准、以避免使数据保护架构复杂化。不必要的功能或保护级别会导致不必要的成本和管理开销、而最初被忽视的要求可能会导致项目方向错误或需要在最后一刻更改设计。
恢复时间目标
恢复时间目标(Recovery Time目标、Recovery Time目标、Recovery Time目标、Recovery Time目标、Recovery Time目标、Recovery Time目标)定义了恢复服务所允许的最长时间。例如、人力资源数据库的RTO可能为24小时、因为虽然在工作日无法访问此数据会非常不便、但业务仍可继续运营。相比之下、支持银行总分类账的数据库将以分钟甚至几秒钟计量的最短时间。RTO不可能为零、因为必须有方法区分实际服务中断和例行事件(例如网络数据包丢失)。但是、RTO接近零是一项典型要求。
恢复点目标
恢复点目标(RPO)定义了可容忍的最大数据丢失。在许多情况下、RPO完全取决于快照或SnapMirror更新的频率。
在某些情况下、可以通过更频繁地有选择地保护某些数据来提高RPO的主动性。在数据库环境中、RPO通常是指在特定情况下可能丢失多少日志数据的问题。在典型的恢复情形中、如果数据库因产品错误或用户错误而损坏、则RPO应为零、这意味着不会丢失任何数据。恢复操作步骤包括还原数据库文件的早期副本、然后重影日志文件、以使数据库状态达到所需的时间点。此操作所需的日志文件应已位于原始位置。
在异常情况下、日志数据可能会丢失。例如、意外事件或恶意事件 rm -rf * 数据库文件的数量可能会导致所有数据被删除。唯一的选择是从备份(包括日志文件)进行还原、而某些数据将不可避免地丢失。在传统备份环境中、要提高RPO、唯一的选择是对日志数据执行重复备份。但是、由于数据会不断移动、而且很难将备份系统作为一项持续运行的服务来维护、因此这一点存在一些限制。高级存储系统的优势之一是能够保护数据免受文件意外或恶意损坏、从而提供更好的RPO、而无需移动数据。
灾难恢复
灾难恢复包括在发生物理灾难时恢复服务所需的IT架构、策略和过程。这可能包括洪水、火灾或有恶意或疏忽意图的人员。
灾难恢复不仅仅是一组恢复过程。它是一个完整的过程、可以识别各种风险、定义数据恢复和服务连续性要求、并提供具有相关过程的正确架构。
在确定数据保护要求时、必须区分典型的RPO和RTO要求以及灾难恢复所需的RPO和RTO要求。某些应用程序环境要求RPO为零、RTO接近零、以应对从相对正常的用户错误到破坏数据中心的火灾等数据丢失情形。然而，这种高水平的保护会产生成本和行政后果。
通常、非灾难数据恢复要求应严格、原因有两个。首先、破坏数据的应用程序错误和用户错误是可以预见的、几乎是不可避免的。其次、只要存储系统不被销毁、设计一个能够实现零RPO和低RTO的备份策略不难。没有理由不解决容易补救的重大风险、这就是为什么本地恢复的RPO和RTO目标应该积极主动的原因。
根据发生灾难的可能性以及相关数据丢失或业务中断的后果、灾难恢复RTO和RPO要求的差别更大。RPO和RTO要求应基于实际业务需求、而不是一般原则。它们必须考虑多种逻辑和物理灾难情形。
逻辑灾难
逻辑灾难包括由用户、应用程序或操作系统错误以及软件故障导致的数据损坏。逻辑灾难还可能包括外部人员利用病毒或蠕虫或利用应用程序漏洞进行的恶意攻击。在这些情况下、物理基础架构未损坏、但底层数据不再有效。
一种日益常见的逻辑灾难类型称为勒索软件、在这种情况下、攻击向量用于对数据进行加密。加密不会损坏数据、但在向第三方付款之前、加密将使数据不可用。越来越多的企业正成为勒索软件黑客攻击的专门目标。针对这种威胁、NetApp提供防篡改快照、在这些快照中、即使存储管理员也无法在配置的到期日期之前更改受保护的数据。
物理灾难
物理灾难包括基础架构的组件发生故障、导致其冗余能力超出范围、从而导致数据丢失或服务长时间丢失。例如、RAID保护可提供磁盘驱动器冗余、而使用HBA可提供FC端口和FC缆线冗余。此类组件的硬件故障是可以预见的、不会影响可用性。
在企业环境中、通常可以使用冗余组件保护整个站点的基础架构、直到唯一可预见的物理灾难情形是站点完全丢失。灾难恢复规划则取决于站点到站点复制。
同步和异步数据保护
理想情况下、所有数据都会在地理位置分散的站点之间同步复制。由于以下几个原因、此类复制并不总是可行甚至不可能实现：
-
同步复制不可避免地会增加写入延迟、因为必须先将所有更改复制到这两个位置、然后应用程序/数据库才能继续处理。所产生的性能影响有时是不可接受的、从而排除了使用同步镜像的可能性。
-
随着100% SSD存储的采用率不断提高、更有可能注意到额外的写入延迟、因为性能预期包括数十万次IOPS和亚微秒延迟。要充分发挥使用100% SSD的优势、可能需要重新审视灾难恢复策略。
-
数据集的字节数持续增长、在确保足够的带宽来支持同步复制方面面临着挑战。
-
数据集的复杂性也在不断增加、在管理大规模同步复制方面也面临着挑战。
-
基于云的策略通常涉及更长的复制距离和延迟、进一步排除了同步镜像的使用。
NetApp提供的解决方案既包括可满足最严苛数据恢复需求的同步复制、也包括可提高性能和灵活性的异步解决方案。此外、NetApp技术还可以与许多第三方复制解决方案(例如Oracle DataGuard)无缝集成
保留时间
数据保护策略的最后一个方面是数据保留时间、数据保留时间可能差别很大。
-
通常要求在主站点上执行14天的夜间备份、在二级站点上执行90天的备份。
-
许多客户创建独立的季度归档、存储在不同的介质上。
-
不断更新的数据库可能不需要历史数据、备份只需保留几天。
-
根据法规要求、可能需要在365天内恢复到任意事务的时间点。