有没有一种好的方法来备份 PB 的数据并存储它？

Question

我开始看到具有数百 TB 数据的客户端（在 SQL Server 安装中）。由于某些企业中的数据总量接近 PB 的有意义的部分，我想浏览那里的集体知识库，以了解处理如此大量数据的人正在采取哪些措施来保护它。

一个明显的问题是存储这么多数据的多个备份非常昂贵，使用企业级存储，见鬼，甚至只是 RAID-5。

我看到的选项如下：

1. 在另一个数据中心创建数据的镜像副本，并不断向其发送差异（使用任何适用于您的数据源的机制 - 例如使用 SQL Server 进行日志传送或数据库镜像）
2. 使用大量压缩算法进行定期备份（可能仅适用于数据适合进行大量压缩的情况）
3. 对数据的关键/变化部分进行零碎备份。
4. 不要备份数据并相信腐败之神。

我看到选项 #4 被采用为默认值，作为 HA/DR 专家，这真的很可怕，但我有什么建议作为替代方案？我认为 #1 是最好的方法，但是当建议除 #4 和 #3 之外的任何替代方案时，“我不这么认为”是通常的答案。

现在，当然这取决于数据的变化率和重要性。无需回答这个问题，因为我在 Microsoft 工作期间曾负责 SQL Server 的所有 HA 功能，所以我精通“视情况而定”的论点——这是我的口号:-)

我很想知道我错过的任何替代方案，或者听到其他人都在同一条船上，除了花费大量资金购买更多存储空间之外，没有现实的替代方案。

提前致谢 - 所有经过深思熟虑和明确表达的答案都将得到应有的赞誉。

Answer 1

离墙的想法 - 所有存储的信息都需要甚至有用吗？

这些信息的实际价值是多少？在维护和管理上花费比数据价值更多的钱显然是荒谬的。

数据库中的数据是否适合存储在数据库中？例如，将压缩的多 GB 核心文件保存在支持组织的数据库中真的能带来任何实际好处吗？

数据库中是否存在大量重复数据？例如，每周 10MB 的时事通讯是否有 1000 人每人保留 10 份？

某些数据是否具有“到期日期”，在此日期之后它不提供任何价值？回到支持组织的例子，由于各种原因，在交付修复后超过几个月保留客户核心文件实际上没有任何好处。

另一个想法 - 保留那么多数据使公司负债。根据法律，有些数据必须保留。然而，一些数据应该被“粉碎”，因为如果意外或恶意地将其发布给不适当的各方会带来风险。

Answer 2

是的，另一个选择是存储虚拟化：一种位于服务器和 SAN 之间的设备，如 IBM SVC。SVC 管理 SAN 到 SAN 的副本，并且可以进行远程复制（尽管这在 PB 级别显然非常痛苦，除非您的数据更改率非常低且带宽非常高。）

巧妙的部分是整个过程对所涉及的服务器是不可见的。如果您使用的是 SQL Server，您可以将文件组设计为将更改率较低的内容（例如 3 年前的销售档案）和更改率较高的内容（例如当前销售）放在一个单独的文件组中。它们甚至不必完全只读——您只需要将其设计为可以对每个文件组使用不同的复制方法。SAN 设备可以通过网络、磁带或通过 SAN 同步 LUN - 这意味着您可以来回传送 SAN 的一部分。这对于像 LeftHand 这样的装备更有效，其中 SAN 由一组参与单位组成。

然后你就可以通过线自动同步低变化率的东西，并与运动鞋网同步高变化率。（听起来我倒退了，但这是真的 - 由于音量的原因，您无法通过线路同步高变化率的东西。）即使是一些低端设备现在也能适应：LeftHand 可让您复制到其他设备LeftHand 设备在您的数据中心，然后将它们运送到您的异地数据中心。插入它们，通过更改 IP 和组将它们连接到远程端，现在它们是您的远程备份 SAN 的一部分。LeftHand 在这方面的销售宣传非常出色：在主数据中心并排设置两个 SAN，让它们同步，然后您可以将它们的一部分运送到远程数据中心，而其中一些留在您当前的数据中心数据中心保持同步。逐渐移动'

不过，我还没有在 PB 级别完成此操作。你知道他们在说什么——理论上、理论上和实践上都是一样的。在实践中...

Answer 3

选项 1 是镜像，这几乎和选项 4 一样糟糕：任何损坏数据的错误，如果没有立即发现，都会损坏两个副本。

如果数据至关重要，请考虑专用解决方案；例如，了解 IBM 的 Shark 产品或 EMS 的竞争产品等。它们具有 Flash-copy 等功能，允许您立即创建文件的逻辑副本，而无需增加磁盘需求；然后您可以将此副本备份到（例如）磁带。还要研究一下机器人磁带备份。