【.comExpress翻译】大数据已成为大多数企业组织的优先事项，它们越来越意识到数据对其成功所起的核心作用。但许多公司仍在努力解决如何在当今的现代架构中最好地保护、管理和分析数据。如果未能正确执行此操作，可能会导致停机时间延长、数据可能丢失，并可能给组织造成巨额损失。与由IT专业人员管理的传统数据平台（Oracle、SQLServer等）不同，大数据平台（Hadoop、Cassandra、Couchbase和HPEVertica等）通常由工程师或DevOps团队管理，大数据备份和恢复有一些常见的误解需要澄清。一些最常见的误区包括：误区#1：数据有多个副本，因此不需要单独的大数据备份/恢复工具。大多数大数据平台都会创建多个数据副本，并将这些副本分布在不同的服务器或机架上。这种类型的数据冗余机制可以在硬件出现故障时保护数据。但是，任何其他情况（例如用户错误、意外删除或数据损坏等）都会导致数据丢失，因为这些错误或损坏会迅速蔓延到数据的所有副本。误区2：丢失的数据可以从原始数据中快速轻松地重建。如果您仍然拥有所有原始数据来重建丢失的数据，这可能是可行的。但在大多数情况下，原始数据已被删除或不易访问。即使原始数据可用，重建丢失的大数据也可能需要数周时间，消耗大量技术资源并延长大数据用户的停机时间。误区三：备份PB级大数据不经济也不实用。PB级数据的定期完整备份需要数周时间，并且需要至少500,000美元的基础设施投资。但是，您可以采取多种措施来缓解这些问题。您可以识别对您的业务有价值的一小部分数据并仅备份该部分。使用重复数据删除等较新的备份技术来高效存储备份内容、永久增量备份来传输更改的内容以及使用商品服务器也有助于降低成本并缩短备份时间。误区4：远程灾难恢复副本可以充当备份副本。谨慎的做法是将数据副本放置在远程数据中心，以防止火灾和地震等大规模灾难。这通常是通过定期将数据从生产数据中心复制到灾难恢复数据中心来实现的。但是，对生产数据中心所做的所有更改都会传播到灾难恢复站点，包括意外删除、数据库损坏、应用程序损坏等。因此，灾难恢复副本不能充当备份副本，因为它没有可以回滚到的时间点副本。误区5：为大数据编写备份/恢复脚本很容易。如果你有技术资源，数据量不大，而且只有一个大数据平台，那么写脚本是实用的。大多数企业组织通常拥有分布在多个大数据平台上的数十TB甚至数百TB的大数据。为此类环境编写、测试和维护脚本并非易事。需要为支持的每个平台编写脚本（例如，一个脚本用于Hadoop，另一个用于Cassandra）。脚本必须进行大规模测试；在平台版本更改（从Cassandra2.1到2.2）之后，它们必须重新测试。在某些情况下，脚本可能需要定期更新，以支持平台的新功能、新API、新数据类型等。大多数组织没有意识到，编写好脚本需要大量的隐性成本和专业知识-编写大数据平台的备份脚本。恢复过程更加困难且容易出错，因为它涉及许多步骤：找到合适的备份副本，将数据复制回适当的节点，并应用特定于平台的恢复过程来恢复数据。误区6：大数据备份/恢复操作成本低廉。除了脚本的定期维护和测试之外，还有与备份和恢复相关的额外成本。额外成本包括：人员成本：必须有人负责运行脚本、确保备份成功、在需要时进行调试、执行临时恢复等。存储成本：存储备份内容需要花钱。停机成本：在此期间，管理员需要找到备份副本并将数据恢复到所需状态。特别是随着大数据环境变得更大、更复杂，这些成本可能会显着增加。误区7：快照是一种有效的大数据备份机制。快照（在特定时间点冻结??的数据状态）有时用作备份副本以防止用户错误或应用程序损坏。使用平台或存储快照进行备份时需要考虑几点。首先，快照可用于自动执行备份过程。但是，当使用存储快照时，需要额外的手动步骤来确保备份数据和元数据的一致性。其次，快照仅在数据变化不快时才有效。对于大数据平台而言，数据变化很快，压缩等技术只会加快数据变化的速度。因此，快照需要巨大的存储开销（高达50%）来保留多个时间点副本。最后，从快照恢复数据将是一个非常繁琐的手动过程。管理员或数据库管理员必须找到需要恢复的数据（如键空间或表）对应的快照文件，然后通过快照恢复到集群中相应的节点。一旦在恢复过程中出现错误，将导致数据永久丢失。总之，正在部署大数据平台和应用软件的企业组织必须意识到备份数据的重要性。平台提供的机制（如副本和快照）不足以确保适当的数据保护并最大限度地减少停机时间。正确的备份和恢复需要投资，但考虑到大数据在推动业务价值方面的作用，这是非常值得的。组织应该意识到开发自己的解决方案和部署正确的技术以满足其恢复点目标(RPO)和恢复时间目标(RTO)的隐性成本。大数据离不开备份/恢复解决方案，因为人为错误和数据损坏迟早会发生。这不是会不会的问题，而是什么时候的问题。【翻译稿件，合作网站转载请注明原译者和出处.com】
