我开始看到数百TB的数据（在SQL Server安装中）的客户端。 由于某些企业的数据总量接近PB的有意义的一小部分，我想借此集中知识库，看看处理这种数据量的人们在做些什么来保护它们。
显而易见的问题是，使用企业级存储，存储多个数据的多个备份是非常昂贵的，甚至只是RAID-5。
我看到的选项如下：
我看到选项＃4被采纳为默认值，作为HA / DR专家真的很可怕，但我build议作为替代select？ 我认为＃1是最好的方法，但是当我们build议除了＃4和可能的＃3之外的其他select时，“我不这么认为”是通常的答案。
当然，这取决于数据的变化率和关键性。 没有必要回答这个问题，因为我曾经在微软工作过，因为我曾经负责SQL Server的所有高可用性function，所以我非常熟悉“这取决于”的论点 – 这是我的口头禅:-)
我很想知道我错过了什么替代scheme，或者听说其他人都在同一条船上，没有什么现实的select可以花费更多的存储空间。
在此先感谢 – 所有经过深思熟虑的答复都将得到应有的重视。
脱离墙壁的想法 – 是所有需要或甚至有用的存储信息？
这些信息实际上值多less钱？ 花费更多的维护和pipe理似乎显得荒谬比数据是值得的。
数据库中的数据是否适合存储在数据库中？ 例如，在支持组织的数据库中保留压缩的多GB核心文件是否确实提供了实际的好处？
数据库中有很多重复的数据吗？ 举例来说，每一个10MB的通讯每个人都有一千个人持有十个副本吗？
有些数据是否有“过期date”，之后不提供任何价值？ 回到支持组织的例子，出于各种原因，在修复交付后的几个月内，保持客户核心文件几乎没有任何好处。
另一个想法是 – 保持这么多的数据使公司承担责任。 根据法律，必须保留一些数据。 然而，有些数据应该被“粉碎”，因为如果它被意外或恶意地释放给不适当的当事方，就会带来风险。
是的，另一种select是存储虚拟化：位于服务器和SAN之间的设备，如IBM SVC。 SVCpipe理SAN到SAN的拷贝，并且可以进行远程复制（尽pipe这在PB级别上显然是非常痛苦的，除非你的数据变化率非常低，带宽真的很高）。
光滑的部分是整个过程对涉及的服务器是不可见的。 如果你使用的是SQL Server，你可以devise你的文件组来保持一个较低的变化率（比如大于3年前的销售档案），以及在一个单独的文件组上具有很高的变化率（比如当前的销售额）。 它们甚至不必是完全只读的 – 只是想要devise它，以便可以为每个文件组使用不同的复制方法。 SAN设备可以通过networking，磁带或通过SAN同步LUN，也就是说，您可以来回传送SAN的部分内容。 对于像LeftHand这样的设备来说，这是比较有效的，SAN由一组参与单元组成。
然后，您可以自动同步低变化率的东西，并将高变化率与sneakernet同步。 （听起来好像我已经倒过来了，但是这是事实 – 你不能通过音量来同步电线上的高变化率的东西。）现在，即使是一些低端的齿轮也能容纳这个：LeftHand让你复制到其他的您的数据中心中的LeftHand设备，然后将其发送到您的非现场数据中心。 将它们插入，通过更改IP和组，将它们连接到远程端，现在它们是远程备份SAN的一部分。 LeftHand在这方面的销售业绩非常出色：在主数据中心内并行设置两个SAN，使它们同步，然后将其中的一部分发送到远程数据中心，而其中一些保持在当前状态数据中心保持同步。 逐渐移动，而不会失去同步。
不过，我还没有在PB级做这个。 你知道他们说什么 – 理论上，在理论上和实践上是一样的。 在实践中…
选项1是镜像，与＃4几乎一样糟糕：任何损坏数据并且没有立即发现的错误都会破坏这两个副本。
如果数据非常重要，请考虑专门的解决scheme; 例如阅读有关IBM的Shark产品，或者从EMS等竞争产品。它们具有像Flash-Copy一样的function，可以让您立即创build文件的逻辑副本，而不会使磁盘需求翻番。 然后您可以将此副本备份到（例如）磁带。 也考虑到机器人磁带备份。
指出那些想要存储数据的PB级存储不便宜的人。
我厌倦了没有额外的Terabyte在线存储的人，因为光盘很便宜 – 光盘可能是，但是pipe理存储肯定是不可能的。
如果存储备份过于昂贵，那么以安全的方式存储数据的成本过高，所以所提出的解决scheme是不可行的。
备份最重要的原因之一是防止用户错误（大多数硬件故障问题可以通过硬件解决），但即使是数据库镜像也不能防止掉桌（可以保护，但仍然可以可能得到不可移动的GUFF到你的数据库 – 除非数据库是如此之大的原因是它只发布插入）。
正如我所看到的，磁带不再是一个可行的解决scheme – 现在使用光盘arrays更便宜（尽pipe物理存储可能会变得笨拙）。 所以我认为你唯一的select是将数据拆分成足够小的数据块，以便在合理的时间内恢复，然后定期将数据存储到磁盘存储器中（在这种情况下，EMStypes的解决scheme可以提供帮助，如果你有现金）。
有趣的video详细介绍了myspace.com的体系结构（SQL2005后端）。 不确定它们是否具有单独的PB级数据块，因为它们与多个数据块进行扩展。 他们使用SAN快照备份。
ZFS。 当然，这还只是一个开始，但是在ZFS的devise中，有很多方面可以处理这些事情。 首先，它能够处理大量的数据，以及多种不同的存储设备（本地，SAN，光纤等），同时保持数据安全并带有校验和，并且“层违反”了设备运行状况和故障。 这怎么能帮助解决备份这么多的数据？
一种方法是使用快照。 快照，发送到磁带/磁盘/networking传输到远程站点。 后续快照只发送已发送的数据，如果需要，可以在两端保留实时数据。
另一种方法是使用Solaris Cluster软件（只要您有足够的networking带宽），您就可以在两台服务器之间进行实时镜像，如果发生故障，则第二台服务器可以接pipe。 在高可用性（HA）非常重要的情况下使用它更多，但是我猜想大多数数据库都需要HA。
而且你说在Windows上不支持ZFS，通常你可能会发现sqlserver，也许你在后端运行Sun / ZFS并通过iSCSI连接。 也许这也是一个可怕的想法，但至less值得一些思考，所以你知道不该做什么。
你有没有看过Amazon Glacier作为select？
国际海事组织，除非你有某种哥斯拉级的硬件，如果你有这么多的数据，你应该使用备份压缩技术。 我对LiteSpeed最为熟悉，但也有其他厂商的类似产品，当然，SQL2008中也有类似的function。 您可能无法获得10比1的压缩，但它确实降低了备份的存储需求，并且还可以缩小备份窗口的要求。 如果您的目标是保留多个备份集（昨天加上前一天，加上上个星期和上个月的一个，或者一系列差异加上全部数据，如果您更改了大量数据数据库），这是一个简单的存储空间问题。
基于文件组的备份（IOW，将非易失性数据放在某些FG上，并且不经常备份）似乎决不会飞，因为开发者或用户不会或不能决定哪些数据是不稳定的，哪些不是，在棕地你经常不能承担风险。
如果需要故障切换站点，除了考虑数据库镜像之外），您可能需要与客户的存储供应商联系，以了解他们是否提供类似于基于硬件的数据复制技术SRDF。 当然，复制（任何types的复制， 特别是实时复制或近实时复制）都不能替代备份。
我不认为你在磁带和磁盘上有很多select。 磁带将不可能在一个正常的备份窗口中切除它，除非您将其条带化，而且我不确定是否存在可靠性。
所以你需要磁盘备份。 你是版本吗？ 意思是你担心回到备份2（当前数据库减2备份）？ 还是备份3？ 在这种情况下，您可能会遇到问题，但您可能需要处理的是日志备份，而不是数据备份。
如果你可以将一些数据分为只读/不变，那么你可能有可pipe理的备份大小/窗口。 或者至less你希望备份技术和带宽正在赶上数据的增长。
我不认为你是在备份第二个副本，以便从主要问题中恢复。 这意味着硬件，腐败等，而且你每天都在祈祷错误没有被运送到第二个副本。 这些拷贝最有可能被制作成SAN-SAN，采用一些简单的技术。 虽然原始副本可能是通过联邦快递，而不是通过电线。 任何人都不容易移动带宽100TB。
我认为你需要1，2和3（而不是4）的组合，具有出色的日志备份pipe理。
其实我觉得在任何时候你都在看三份你的数据。 在其中一个副本上运行CHECKDB，而第二个副本用于实际接收更改。 然后你快照第二个副本到第一个，然后继续。 有了这么多的数据，我想你会需要一些勤奋的。 保罗，checkdb如何在一个多用户，在线的100TB分贝工作？
如前所述，不是日志备份，可能是一个日志读者，关键？ 你不需要从日志中恢复丢失表/用户错误，而不是备份？ 您可以通过发送SAN副本来延缓这一点，但是我没有看到这种技术。 日志传送SAN可以将更改延迟4小时（或某个时间间隔），以便在覆盖数据之前从问题中恢复。 或者一些日志读者的SAN块更改工具？ 否则，您需要pipe理这些事务日志，这可能是在各种文件系统上跟踪这些备份大约xxx小时的整个其他级别，以便您可能从非致命错误中恢复。
从技术上讲，存储是便宜的，但在PB级别，不是那么多。 这真的取决于应用程序，但我会说战略＃2和＃3的一些组合将成为答案，＃2给定和＃3取决于您可以在存储上做多less投资和存储和IO /计算能力，让您尽可能less的渐进性和尽可能谨慎，完整的备份逃脱。
另外，像Amazon S3这样的产品也可能会发挥作用，这取决于你的带宽以及数据的变化程度 – 在本卷中，至less有一部分会放在别人的服务器上，让他们担心冗余会越来越多成本效益。
向存储供应商说话，他们将拥有以前使用过的重复数据删除产品，并结合常规压缩，通常可以将数据占用量减less70％。 当然，任何有钱花在存储容量为PB上的人也可能有预算来购买一个体面的备份解决scheme – 如果他们没有，那么你只需要问他们什么损失PB级会花费他们的业务。
在大型企业数据仓库中，大部分数据来自已备份的数据源。 我已经在Teradata和ODW上安装了第四个选项，但已经知道它们可以恢复一两天的事务数据并将其从源系统中转换。
在一个零售客户（当时他们拥有世界前五名最大的数据仓库之一，大约200TB …给了你一个多久以前的想法），他们在购买了一个新的PB Teradata服务器。 旧的节点将用于前一天的系统的快照，而新的节点保持现有的。 从故障转移的angular度来看，这也是很好的 – 每隔一段时间他们就会把整件事情都拿下来进行维护，而我们只是转而使用旧的慢数据服务器。
老实说，这似乎是一个巨大的浪费处理/存储/等等，以保持事态发展…尤其是当最大的优势是他们的pipe理员和NCR技术人员不得不less夜晚进行不定期维护。