如何备份存储服务器?

我正在考虑实现一个非常大的存储服务器作为其他几个服务器(所有基于Linux的)的现场NAS。

非常大,我的意思是介于4TB和20TB之间的可用空间 (尽pipe实际上我们不太可能把它做成20TB)。

存储服务器为了保证数据的安全性和性能,将采用RAID 10,但我们仍然需要备份解决scheme,包括非现场备份。

我的问题是: 你如何备份这么多的数据!?

这不像我可以连接一个便携式硬盘驱动器,并传输文件。 我们目前没有其他设备有这么多的存储空间。

我是否需要为第二个非现场存储服务器预算,还是有更好的解决scheme?

处理大小的数据有很多种方法。 这很大程度上取决于你的环境和你愿意花多less钱。 总的来说,有一些整体“从服务器获取数据”的策略:

  • 通过以太网就像在盒子上说的那样,数据被传送到Some Where Else处理。 20TB复制1GbE需要很长时间,但可以完成。 硬件可以帮助(例如10GbE链接,或在某些情况下NIC绑定)。
  • 通过存储子系统如果使用光纤通道,请将其发送到FCnetworking上的其他设备。 如果您有SAS,请将其发送到SAS连接的设备。 一般比以太网更快。
  • 将其发送到另一个磁盘arrays将其发送到连接到同一服务器的另一个存储区。

这是100公里的观点。 一旦你开始放大,事情会变得更加分散。 如前所述,LTO5是针对这些高密度负载devise的特定磁带技术。 另一个相同的存储arrays是一个很好的目标,特别是如果你可以使用像GlusterFS或DRBD的东西来获取数据。 另外,如果你需要一个备份轮转或只是在数组失败的情况下保持运行的能力将影响你放置的位置。

一旦你确定了一个100公里的视图方法,进入软件将是下一个大任务。 影响这个因素的因素就是你可以在你的存储服务器上安装的东西(如果它是一个NetApp,那么一个存储器就是一个Linux服务器,另一个是完全不同的东西) ,您select了哪些硬件(例如,并非所有的FOSS备份软件包都能很好地处理磁带库)以及您需要哪种备份保留。

你真的需要弄清楚你想要什么样的灾难恢复。 简单的实时复制比较容易,但是不能让你只从上个星期才恢复。 如果从上周恢复的能力对你来说很重要,那么你需要devise这样的事情。 根据法律(在美国和其他地方),一些数据需要保存7年以上。

简单的复制是最容易的。 这是DRBDdevise的目的。 一旦最初的副本完成,它只是发送更改。 这里复杂的因素是networking局部性,如果你的第二个arrays不靠近主DRBD可能是不可行的。 您需要第二台存储服务器,至less要有第一台存储空间。


关于磁带备份…

LTO5可以容纳1.5TB的数据而无需压缩。 喂这些怪物需要非常快速的networking,这是光纤通道或6Gb SAS。 由于您需要备份大于1.5TB的内容,因此您需要查看自动加载器(这里是一个示例: 链接 ,来自HP的24插槽1驱动器自动加载器)。 有了支持它们的软件,他们会为您更换中档备份磁带。 他们很棒。 您仍然需要将磁带发送到异地,但是与备份需要的时候挂在一起的时间相比,您可以自己加载磁带。

如果磁带给你的是“ 遗留的 ”,那么虚拟磁带库的速度可能会更快(例如Quantum的链接 )。 这些假装是磁带库备份软件,而实际存储的东西磁盘强劲(你希望)重复数据删除技术。 如果你喜欢这样的事情,那些更有爱心的人甚至会把虚拟磁带复制到真实的磁带上,这对于非现场旋转来说是非常方便的。


如果你不想使用虚拟磁带,但是仍然希望进行直接到磁盘的备份,那么你需要一个足够大的存储arrays来处理这个20TB,再加上你想要的更多的净更改数据保持。 不同的备份包处理方式不同。 一些重复数据删除技术真的很不错,另外一些却是骇人听闻的问题。 我个人不知道这方面的FOSS备份软件包的状态(我听说过Bacula),但它们可能就足够了。 许多商业备份软件包都安装有本地代理程序,用于备份服务器以提高吞吐量,这有很多优点。

LTO-5点唱机? 你需要三到十五个磁带来支持这个arrays,这不是一个疯狂的大数字。 自动点唱机将负责为您更换磁带,良好的备份软件(例如bacula)会跟踪哪些磁带上的文件。

您还需要考虑备份大型文件系统所需的时间,因为在此期间FS很可能会发生变化。 为获得最佳效果,支持快照的文件系统将非常有用,因此您可以立即获取快照,并针对该快照执行完整或增量备份,而不是针对实时文件系统。

您可能应该考虑备份到磁盘 ,因为磁带需要很长时间,并且顺序访问,恢复将永远存在。

绝对要利用差异备份或增量备份 – 只需在任何频率下对备份进行备份即可。

可能理想的解决scheme是在另一个位置安装第二个类似大小的服务器,在这个位置定期发送增量备份,如果主服务器死了,可以快速地将其交换到位。 然而,另一种select是使用可移动的驱动器 ,然后将其从现场存储。

在处理大量数据时, 将备份分解为较小的备份作业也是有意义的,如果每天都不能全部进行备份,请将备份错开,以便将A备份一天,然后设置B下一个。

一直在思考恢复过程 。 当我们不得不从一个数百兆的备份工作中恢复一个文件时,我们遇到了一个麻烦,这个工作占用了大量的内存和大量的时间来重新构build备份索引和恢复。 最后,我们无法在一天内完成,而且必须构build专门的还原服务器,以便我们的主备份服务器能够继续进行夜间工作!

– 添加 –

您还想要考虑重复数据删除技术,它可以为多个用户多次备份相同的信息,从而节省大量的空间。 作为其function的一部分,许多备份解决scheme或文件系统提供重复数据删除function。

首先,列举您所面临的风险。 一些常见的风险:

  • 灾难:您的整个网站发生了一件非常不幸的事情。
  • 人为错误(这是发生在_all_the_time_上的错误):
    • 有人决定以制造商无意使用的方式来执行存储服务器的“热插拔”function。
    • 有人运行一个悄无声息地破坏数据的进程,在发现问题之前可以可靠地备份数据。
    • 有人删除了一小时内到期的重要报告,价值数千美元。

然后评估各种风险规避解决scheme的成本,例如:

  • 异地,在线备份(远程镜像):安全免受灾难,一些(但不是全部)人为错误(仍然在线)。
  • 场外离线存储(磁带):安全免于灾难,难以快速恢复数据。
  • 现场在线备份(镜像):从一些人为错误安全,一些硬件故障,容易受到灾难。
  • 现场离线备份(磁带换带器中的磁带):绝大多数人为错误,大部分硬件故障都是安全的。

然后评估轮换策略(您希望能够恢复多久,可以承受多less数据丢失)。

然后select你的数据是值得的。

我有一个客户在两个不同的build筑物中有两个相似的12 TB系统,以1GB连接。 一个是生产系统; 它通过rdiff-backup实用程序逐步备份(每日快照)到另一个。 rdiff-backup必须在您的标准configuration库中可用。

异地,在线备份(远程镜像)

使用rsync通过ssh(只是改变) – 第一次备份必须在本地完成,但之后备份将是一件轻而易举的取决于变化

如果你需要保留更改的版本,rdiff-backup

http://www.nongnu.org/rdiff-backup/

Linux中的btrfs文件系统听起来很有希望,但仍然处于沉重的发展阶段

看看你的实际“内容”,并在计划你的策略之前,经常改变。 很多时候,人们只是一遍又一遍地把相同的数据转到磁带上,没有任何理由。

某些供应商的重复数据删除技术可以允许快照从单个文件恢复中保存,但是您总是需要异地保护。