有没有一种好方法可以备份 PB 的数据并进行存储？

不切实际的想法——所有存储的信息是否需要甚至有用？

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

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

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

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

另一个想法是保留这么多数据，让公司承担责任。根据法律，一些数据必须保留。然而，一些数据应该被“粉碎”，因为如果它被意外或恶意地发布给不适当的各方会带来风险。

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

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

然后你可以通过网络自动同步低变化率的东西，并与运动鞋网同步高变化率。（听起来好像我把它弄反了，但这是真的——由于音量，你不能通过电线同步高变化率的东西。）即使是一些低端设备现在也能适应这个：LeftHand 让你复制到其他数据中心中的 LeftHand 设备，然后将它们运送到您的异地数据中心。插入它们，通过更改 IP 和组将它们加入远程端，现在它们是您远程备份 SAN 的一部分。LeftHand 在这方面的推销非常棒：在主数据中心并排设置两个 SAN，使它们同步，然后您可以将其中的一部分运送到远程数据中心，而其中一些留在您当前的数据中心数据中心保持同步。逐渐移动'

不过，我还没有在 PB 级别做到这一点。你知道他们说什么——理论上、理论上和实践中都是一样的。在实践中...

选项 1 是镜像，这几乎与 #4 一样糟糕：任何破坏数据且未立即发现的错误都会破坏两个副本。

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

指出那些想要存储 PB 数据的人，存储并不便宜。

我厌倦了人们抱怨没有额外的 TB 在线存储，因为磁盘很便宜——磁盘可能很便宜，但托管存储肯定不是。

如果存储备份的成本高得令人望而却步，那么以安全的方式存储数据的成本高得令人望而却步，因此所提出的解决方案是不可行的。

进行备份的最重要原因之一是防止用户错误（大多数硬件故障问题都可以通过硬件解决方案来处理），但即使是数据库镜像也不能防止删除表（好吧，你可以防止这种情况，但它仍然可能会在您的数据库中获得不可移动的废话 - 除非数据库如此大的原因是它只发出插入）。

正如我所看到的，磁带不再是一个可行的解决方案——现在只使用磁盘阵列更便宜（尽管物理存储可能很尴尬）。所以我认为你唯一的选择是将数据分成足够小的块以便在合理的时间范围内恢复，然后定期将它们放到磁盘存储中（这里 EMS 类型的解决方案可以提供帮助，如果你有现金）。

有趣的视频详细介绍了 myspace.com 的架构（SQL2005 后端）。不确定他们是否有单独的 PB 数据库，因为它们通过多个数据库横向扩展。他们使用 SAN 快照备份。

http://wtv.watchtechvideos.com/topic70.html

ZFS。当然，它还只是刚刚开始，但是 ZFS 在许多领域都旨在处理这类事情。首先，它能够处理大量数据以及多种不同的存储设备（本地、SAN、光纤等），同时通过校验和以及对设备健康和“违反层”的感知来保持数据安全失败。这如何帮助解决备份这么多数据的问题？

一种方法是使用快照。拍摄快照，将其发送到磁带/磁盘/网络以传输到远程站点。后续快照仅发送已发送的数据，如果需要，您可以在两端保留实时数据。

另一种是使用 Solaris Cluster 软件（只要您有足够的网络带宽），您可以在两台服务器之间进行实时镜像，如果一台服务器出现故障，第二台可以接管。它更多地用于高可用性（HA）很重要的地方，但我猜大多数拥有这么多数据的地方都需要HA。

你说 ZFS 在 Windows 上不受支持，你可能会在通常的地方找到 sqlserver，也许你在后端运行 Sun/ZFS 并通过 iSCSI 连接。也许这也是一个可怕的想法，但至少值得考虑一下，这样你就知道不该做什么。

您是否考虑过将亚马逊冰川作为一种选择？

IMO，除非你有某种哥斯拉级别的硬件，如果你有那么多数据，你应该使用备份压缩技术。我最熟悉 LiteSpeed，但其他供应商也有类似的产品，而且（当然）SQL2008 中内置了类似的功能。您可能无法获得 10 比 1 的压缩，但它确实减少了备份的存储需求，并且还可以缩小您的备份窗口需求。如果您的目标是保留多个备份集（昨天加上前一天，加上上周的一个和上个月的一个，或者一系列差异加上完整，如果您更改大量数据，这可能会变得很大数据库），这是一个简单的存储空间问题。

基于文件组的备份（IOW，将非易失性数据放在某些 FG 上并且不经常备份）似乎永远不会飞起来，因为开发人员或用户不会或无法决定哪些数据是易失性的，哪些不是，以及在棕地您通常无法承担风险的情况。

如果需要故障转移站点，除了考虑数据库镜像之外，您可能还想与客户的存储供应商交谈，看看他们是否提供类似 SRDF 的东西，这是一种基于硬件的数据复制技术。自然地，复制（任何类型，但特别是实时或近实时复制）不能替代备份。

我认为您在磁带与磁盘上没有太多选择。除非您将其条带化，否则磁带不太可能在常规备份窗口中将其剪切，而且我不确定是否存在可靠性。

所以你只需要磁盘备份。你是版本控制吗？意思是您是否担心回到备份 2（当前数据库减去 2 个备份）？还是备份3？在这种情况下，您可能会遇到问题，但您可能需要处理的是日志备份，而不是数据备份。

如果您可以将某些数据拆分为只读/不变，那么您可能拥有可管理的备份大小/窗口。或者至少您希望备份技术和带宽能够赶上数据增长。

我认为您的备份不如保留第二份副本以从主要问题中恢复。这意味着硬件、损坏等，并且您每天都在祈祷错误不会被发送到第二个副本。最有可能使用一些快照技术将副本制作成 SAN-SAN。尽管原始副本可能是通过联邦快递而不是通过网络传输的。任何人都不容易获得移动 100TB 的带宽。

我认为您需要 1、2 和 3（不是 4）的组合，以及出色的日志备份管理。

实际上，我认为在任何时候您都在查看 3 个数据副本。在其中一个副本上运行 CHECKDB，而第二个副本用于实际接收更改。然后将第二个副本快照到第一个副本并继续。有了这么多数据，我想你需要在这里做一些努力。Paul，checkdb 如何在在线的多用户 100TB 数据库上工作？

如前所述，日志备份和日志阅读器不是很重要吗？您不需要从日志而不是备份中恢复删除表/用户错误吗？您可以通过延迟发送 SAN 副本来缩短此操作，但我还没有看到该技术。可以将更改延迟 4 小时（或某个时间间隔）的 Log Shipping SAN，以便您在覆盖数据之前从问题中恢复。还是一些 SAN 块更改日志读取器工具？没有它，您需要管理这些事务日志，这可能是在不同文件系统上跟踪这些备份大约 xxx 小时的另一个级别，以便您有可能从非致命错误中恢复。

从技术上讲，存储很便宜，但在 PB 级别，并没有那么多。这真的取决于应用程序，但我会说策略#2 和#3 的某种组合将是答案，#2 是给定的，#3 取决于您可以在存储方面进行多少投资以及类型存储和 IO/计算能力，让您以尽可能少的增量主义和尽可能多的谨慎、完整备份摆脱困境。

或者，Amazon S3 之类的东西也可能会发挥作用，具体取决于您的带宽和数据中有多少变化——在这个数量上，至少将其中一部分放在其他人的服务器上，让他们越来越担心冗余具有成本效益。