科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网服务器频道组织和协作 让数据恢复不在困难

组织和协作 让数据恢复不在困难

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

对于一个复杂的应用程序来说,恢复的时候需要考虑很多移动的部分。这个一致性的问题通常在系统级别上容易理解,但是在处理由多个应用程序组件组成的跨平台的业务功能的时候,就经常被忽略了。

来源:IT专家网 2008年10月31日

关键字: IT 数据库 数据恢复

  • 评论
  • 分享微博
  • 分享邮件

  对于一个复杂的应用程序来说,恢复的时候需要考虑很多移动的部分。

  在与高级IT执行官讨论数据恢复的时候,一个再三重复的话题就是如何对企业恢复关键应用程序并在出现重大错误的时候处理业务的能力进行精确刻画的难题。他们想要有这样的自信,即关键数据是可以恢复的,他们也在寻找能够展示这种恢复能力的衡量标准。

  现实情况就是IT基础架构变得越来越复杂,要剥掉各个抽象层,把共同决定应用程序恢复能力的各个不同的组件合计起来,都是个挑战。于是我们转而尝试确定每个单个组件的健康程度,前提是假设整体的恢复能力相当于各个部分的能力的总合。

  这并不是必要的情况。首先,对于复杂的应用程序来说,可能会有很多个移动的部分计入恢复能力,要对它们进行统计是很困难的。更重要的是,这些因素的同步是成功恢复的一个重要的障碍。

  这个一致性的问题通常在系统级别上容易理解,但是在处理由多个应用程序组件组成的跨平台的业务功能的时候,就经常被忽略了。当恢复的时候,在不同时间被拷贝或者备份的潜在的数据库就会增加恢复的时间长度,因为需要协调它们之间的冲突。

  使问题更加复杂的是,在某些情况下,互相关联的系统可能需要根据危险程度来设置不同的优先级别,采用完全不同的保护配置。例如,一个数据库可能被赋予了高优先级别,因此被完全复制以支持4个小时以下的恢复时间目标,但是一个相关的前端的基于Web的应用程序组件可能被赋予了一个基于磁带的恢复等级。然而,在灾难恢复场景中,这一点对于运营维护来说可能是完全接受的(例如重新存储服务器的一个卷),导致的结果可能是一个用户无法连接的运行的数据库。(对于4个小时的恢复时间目标来说只能如此了。)

  今天这个问题仍然在很大程度上成为一个策略或者处理演习的题目,然而有一些新出现的技术可以帮助在某种程度上解决这个问题。一个关键的难题就是组织性。相互关系的识别需要跨功能的协作。要解决它需要一些拥有适当授权的,并在业务功能级别上负有全部恢复职责的人。要能够注意到组件恢复中所有关注点,这样的人通常不存在。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章