是否有备份PB级数据并将其存储的好方法？

我开始看到具有数百TB数据的客户端（在SQL Server安装中）。随着一些企业中数据总量接近PB的有意义的部分，我想在此探讨一下集体知识库，以了解处理这些数据量的人们正在采取哪些措施来保护它。

显而易见的问题是，使用企业级存储，大量甚至是RAID-5，存储这么多数据的多个备份的费用过高。

我看到的选项如下：

1. 在另一个数据中心中创建数据的镜像副本，并不断将差异发送给它（使用适用于您的数据源的任何机制，例如日志传送或使用SQL Server进行数据库镜像）
2. 使用强大的压缩算法进行定期备份（可能仅在数据很容易被严重压缩的情况下才适用）
3. 分段备份数据的关键/更改部分。
4. 不要备份数据并信任腐败神。

我看到默认情况下采用了选项4，作为HA / DR专家，它确实很吓人，但是我建议采取什么替代措施？我认为＃1是最好的方法，但是当建议使用除＃4和＃3以外的任何替代方法时，通常会回答“我不这么认为”。

现在，这当然取决于数据的变化率和关键程度。无需回答这个问题，因为我在Microsoft工作期间曾经负责SQL Server的所有HA功能，因此我精通“取决于”这一论点-这是我的口号：-)

我会很想听到我错过的任何替代方案，或者听到其他人都在同一条船上，并且没有现实的替代方案，那就是花很多钱来增加存储空间。

在此先感谢您-我们将对所有经过深思熟虑和明确表示的答案给予应有的感谢。

根本的想法-所有需要的存储信息甚至有用吗？

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

数据库中的数据是否适合存储在数据库中？例如，将压缩的数千兆字节的核心文件保留在支持组织的数据库中是否真的有任何实际好处？

数据库中是否有很多重复的数据？例如，每周有一本10MB的通讯，每千人有十本吗？

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

另一个想法-保持大量数据使公司承担责任。根据法律，必须保留一些数据。但是，应将某些数据“切碎”，因为如果将这些数据意外或恶意地发布给不适当的参与者，则会带来风险。

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

麻烦的是，整个过程对于所涉及的服务器是不可见的。如果您使用的是SQL Server，则应将文件组设计为将变化率较低的事物（例如3年前的销售档案）和变化率较高的事物（例如当前的销售）保持在单独的文件组中。它们甚至不必完全是只读的-您只需要设计它，以便可以对每个文件组使用不同的复制方法。SAN设备可以通过网络，磁带或SAN同步lun，这意味着您可以来回运送SAN的一部分。这对于诸如LeftHand之类的设备更为有效，因为SAN由一组参与的单位组成。

然后，您可以自动通过电线同步低变化率的东西，并将高变化率与sneakernet同步。（听起来好像我倒退了，但这是真的-由于音量的原因，您无法通过电缆同步高变化率的东西。）甚至有些低端齿轮现在也可以适应这种情况：LeftHand可让您复制到其他数据中心中的LeftHand单元，然后将它们运送到异地数据中心。插入它们，通过更改IP和组将它们加入到远程端，现在它们已成为远程备份SAN的一部分。LeftHand的销售策略非常出色：在您的主数据中心中并排设置两个SAN，使其同步，然后可以将其中的一部分运送到远程数据中心，而其中一些仍保留在当前数据库中。数据中心保持同步。逐渐移动'

不过，我还没有达到PB级。您知道他们说什么-理论上，理论上和实践上都是相同的。在实践中...

选项1是镜像，几乎和＃4一样糟糕：任何破坏数据且没有立即发现的bug都会破坏两个副本。

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

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

人们对抱怨抱怨没有额外的TB的在线存储空间感到厌烦，因为磁盘很便宜-磁盘可能很便宜，但是托管存储肯定不是那样。

如果存储备份的成本过高，那么以安全的方式存储数据的成本过高，因此建议的解决方案不可行。

进行备份的最重要原因之一是可以防止用户错误（大多数硬件故障问题可以通过硬件解决方案来解决），但是即使数据库镜像也不能针对已删除的表提供保护（好的，您可以对此进行保护，但是仍然可以）可能使不可拆卸的东西进入您的数据库-除非数据库太大的原因是它只能发出插入内容。

正如我所见，磁带不再是可行的解决方案-现在仅使用磁盘阵列会便宜一些（尽管物理存储可能很麻烦）。因此，我认为您唯一的选择是将数据分成足够小的块，以便在合理的时间范围内还原，然后定期将其放入磁盘存储的方法（如果您拥有现金）。

有趣的视频，详细介绍了myspace.com的体系结构（SQL2005后端）。不知道它们是否具有单个PB数据库，因为它们可以扩展到多个数据库。他们使用SAN快照备份。

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

ZFS。当然，它仍然刚刚起步，但是ZFS在很多领域都可以处理这类事情。首先，它具有处理大量数据以及多种不同存储设备（本地，SAN，光纤等）的能力，同时通过校验和和“层违反”设备健康意识来保持数据安全。失败。但这如何帮助解决备份这么多数据的问题？

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

另一种方法是使用Solaris Cluster软件，只要您有足够的网络带宽，就可以在两台服务器之间建立实时镜像，如果其中一台服务器出现故障，则第二台服务器可以接管。在高可用性（HA）很重要的情况下，它更适合使用，但是我想大多数具有如此大数据的地方都希望使用HA。

而且您说Windows不支持ZFS，Windows通常是您在sqlserver中找到的位置，也许您在后端运行Sun / ZFS并通过iSCSI连接。也许这也是一个可怕的想法，但是至少值得思考一下，以便您知道不应该做的事情。

您是否已考虑将Amazon Glacier作为选择？

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

基于文件组的备份（IOW，将非易失性数据偶尔存储在某些FG上，很少备份）似乎永远不会飞起来，因为开发人员或用户不会或不能决定哪些数据是易失性的，哪些不是易失的，并且在棕地中您通常无法冒险的情况。

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

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

因此，您只能进行磁盘备份。您要进行版本控制吗？这意味着您担心返回备份2（当前数据库减去2备份）吗？还是备份3？在这种情况下，您可能会遇到问题，但是可能需要处理的只是日志备份，而不是太多的数据备份。

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

我不认为要备份第二张副本要备份多少，以便从主副本中恢复过来。这意味着硬件，损坏等，您每天都在祈祷错误不会被传送到第二个副本。这些副本很可能是采用某些快照技术制成的SAN-SAN。尽管原始副本可能是通过Fed-Ex而不是通过有线方式发送的。任何人都不容易获得移动100TB的带宽。

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

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

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

从技术上讲，存储很便宜，但在PB级则不算多。这实际上取决于应用程序，但是我想说，策略＃2和＃3的某种组合将是答案，其中＃2是给定的，而＃3取决于您可以在存储上进行多少投资以及哪种类型存储和IO /计算能力，将使您以最少的增量主义和尽可能谨慎，完整的备份摆脱困境。

另外，取决于您的带宽和数据中的变化量，像Amazon S3之类的东西也可能会发挥作用-在这种情况下，至少将其中一些存储在其他人的服务器上，让他们担心冗余会越来越多具有成本效益。

与您的存储供应商联系，他们将拥有他们以前使用过的重复数据删除产品，再加上常规压缩，通常可以将数据占用空间减少70％。当然，任何有钱花在PB级存储上的人都可能也有预算购买一个不错的备份解决方案-如果他们没有，那么您只需要问他们失去PB级会损失多少业务成本。

在大型企业数据仓库中，许多数据来自已经备份的源。我曾在Teradata和ODW安装中使用过＃4选项，但他们知道它们可以恢复一两天的事务性数据并从源系统进行转换。

对于一个零售客户（当时他们拥有世界上最大的5个DW之一，大约有200TB的容量……让您知道这是多久以前的事），他们在购买了新的Petabyte之后选择了选项＃1级Teradata服务器。旧节点将用作前一天系统的快照，而新节点将维护现有节点。从故障转移的角度来看，这也是很好的做法–每隔一段时间，他们会把整个事情都付诸东流，以进行维护，而我们只是转而使用具有老旧数据的慢速服务器。

不过，老实说，要让事情继续下去似乎是在处理/存储/等方面的巨大浪费……尤其是当最大的优势是他们的管理员和NCR技术人员必须减少晚上进行不定期维护时。