我开始看到客户拥有数百 TB 的数据（在 SQL Server 安装中）。由于某些企业的数据总量接近 PB 的几分之一，我想调查一下那里的集体知识库，看看处理如此大规模数据的人们正在采取什么措施来保护这些数据。
显而易见的问题是，存储如此多数据的多个备份成本过于高昂，无论使用企业级存储，甚至只是 RAID-5。
我看到的选项如下：
- 在另一个数据中心创建数据的镜像副本，并不断向其发送差异（使用任何适用于您的数据源的机制 - 例如使用 SQL Server 的日志传送或数据库镜像）
- 使用高强度压缩算法定期备份（可能只适用于数据适合沉重压缩
- 对数据的关键/变化部分进行逐块备份。
- 不要备份数据并相信腐败之神。
我看到选项 #4 被采用为默认选项，作为一名 HA/DR 专家，这确实令人感到害怕，但我建议的替代方案是什么？我认为 #1 是最好的方法，但当有人建议除 #4 和可能的 #3 之外的任何替代方案时，通常的答案是“我不这么认为”。
现在，当然这取决于数据的变化率和关键性。无需回答这个问题，因为我在微软工作时曾负责 SQL Server 的所有 HA 功能，所以我很熟悉“这取决于”的论点 - 这是我的主旨 :-)
我很有兴趣听到我错过的任何替代方案，或者听到其他人也处于同样的境地，并且除了花费大量金钱购买更多存储空间之外没有其他现实的替代方案。
提前致谢——所有经过深思熟虑并表达出来的答案都会得到应有的赞扬。
答案1
古怪的想法——存储的所有信息都是必要的或者有用的吗？
这些信息到底值多少钱？在维护和管理上花费的钱比数据本身的价值还多，这显然是荒谬的。
数据库中的数据是否适合存储在数据库中？例如，将压缩的几 GB 核心文件保存在支持组织的数据库中是否真的有任何实际好处？
数据库中是否有大量重复数据？例如，一千人是否每人保留一份每周 10MB 的新闻通讯的十份副本？
某些数据是否有“有效期”，过了这个期限，数据就没有任何价值了？回到支持组织的例子，出于各种原因，在修复程序交付后，保留客户核心文件超过几个月几乎没有任何好处。
另一个想法是，保留那么多数据会让公司承担责任。根据法律，有些数据必须保留。但是，有些数据应该被“粉碎”，因为如果意外或恶意地泄露给不适当的一方，就会带来风险。
答案2
是的，另一个选择是存储虚拟化：一种位于服务器和 SAN 之间的设备，如 IBM SVC。SVC 管理 SAN 到 SAN 的副本，并可以进行远程复制（尽管这在 PB 级别显然非常痛苦，除非您的数据更改率非常低且带宽非常高。）
巧妙之处在于整个过程对于所涉及的服务器是不可见的。如果您使用的是 SQL Server，则可以设计文件组以将变化率低的内容放在一起（例如 3 年前的销售档案），将变化率高的内容（例如当前销售）放在单独的文件组中。它们甚至不必完全是只读的 - 您只需设计它以便可以为每个文件组使用不同的复制方法。SAN 设备可以通过网络、磁带或 SAN 同步 lun - 这意味着您可以来回运送 SAN 的各个部分。对于像 LeftHand 这样的设备来说，这更有效，其中 SAN 由参与单元池组成。
然后，您可以自动通过网络同步低变化率的内容，并通过 sneakernet 同步高变化率的内容。（听起来好像我搞反了，但这是真的——由于数据量太大，您无法通过网络同步高变化率的内容。）现在，即使是一些低端设备也可以适应这一点：LeftHand 允许您复制到数据中心中的其他 LeftHand 设备，然后将它们发送到您的异地数据中心。插入它们，通过更改 IP 和组将它们连接到远程端，现在它们就是您的远程备份 SAN 的一部分。LeftHand 对此的销售宣传非常精彩：在您的主数据中心并排设置两个 SAN，使它们同步，然后您可以将它们的一部分发送到远程数据中心，而其中一些留在您当前的数据中心以保持同步。逐渐移动它们，而不会失去同步。
不过，我还没有在 PB 级别上做过这件事。你知道他们说什么——理论上，理论上和实践上是一样的。实践上……
答案3
选项 1 是镜像，它几乎和选项 4 一样糟糕：任何破坏数据的错误，如果不能立即发现，就会破坏两个副本。
如果数据至关重要，请考虑专用解决方案；例如，了解 IBM 的 Shark 产品或 EMS 等竞争产品。它们具有 Flash-copy 等功能，可让您立即创建文件的逻辑副本，而无需加倍磁盘要求；然后您可以将此副本备份到（例如）磁带。还要研究机器人磁带备份。
答案4
有趣的视频详细介绍了 myspace.com 的架构（SQL2005 后端）。不确定他们是否有单独的 PB 级数据库，因为他们使用多个数据库进行扩展。他们使用 SAN 快照备份。