备份服务器应该使用RAID吗?


17

我被要求使用Symantec Backup Exec设置新的备份服务器,该服务器存储在硬盘而不是磁带上,因为备份大小超出了磁带容量。

我想知道这是否真的有意义,或者备份服务器运行任何形式的RAID是否有任何优势,因为它是“备份”?

对我而言,证明增加成本的好处不是很大。

我很想看看别人的想法。

谢谢!



1
从我的角度来看,这与他问“是否有理由在备份服务器上使用RAID”而不是“将RAID用作备份”不是一个真正的问题。这几乎是问题的相反方面。
半径

我同意,只是发布了链接,因为一些答案是相关的。
Andrioid

其他海报的好答案。我没有什么要补充的,但是我会争辩说,如果“ ..好处不足以证明增加的成本。”,您可能没有意识到自己正在冒险工作。节省几百美元值得危及您的工作吗?如果您花费相对较少的钱来避免对公司和您的职业造成彻底的灾难,那么没人会少想您。只是我的两分钱。
osij2is

Answers:


16

Imo,使用raid有很多好处。

如果备份计算机的磁盘出现故障而没有RAID,那么您将丢失所有备份。您需要多长时间重建它们?

另外,如果由于磁盘故障而丢失了所有备份,请成功重建它们,然后需要查找以前备份但由于该磁盘故障而丢失的内容,该怎么办。

如果没有其他问题,磁盘现在是如此便宜,以至于如果您需要从故障中恢复,那么将磁盘放入RAID 5的额外磁盘成本可能会比您花费的时间少。


1
更不用说某些RAID级别在磁盘速度方面的巨大优势。如果您要重建备份,则读取速度可能会成为问题,RAID5或RAID10会有所帮助。
Russ Warren

1
请注意,实际的磁盘容量太大,以至于相同的RAID配置变得不那么安全。我指的是这样的事实:磁盘尺寸较大(每个扇区)也增加了故障概率。.这个简单的统计事实很可能使磁盘故障后的RAID重建也使幸存的磁盘死亡。 ..使超级安全的RAID1 + HS成为完全不可靠的系统...因此,请勿将非常大的磁盘用于容错RAID系统。参见hds.com/assets/pdf/…–
drAlberT

11

除非在非常特殊的情况下,否则服务器计算机应具有冗余磁盘(请考虑一堆又一堆的“横向扩展” 1U应用服务器,例如Google)。没有冗余磁盘的服务器计算机是定时炸弹。

话虽这么说,备份不是备份,除非它不在现场并且离线。如果它在现场但离线(抽屉中的胶带),那么当建筑物烧毁时,它就消失了(请参阅从服务器中清除烟灰 )。如果它不在现场但在线,则容易受到攻击和“腐败”。

现在,请继续关注有关磁盘与磁带等的宗教观点。


磁盘+磁带。在任何方面,任何一个都不比另一个更好。磁盘可以更快地将备份从主服务器上转移到备份介质服务器上,它使您的停机时间更短且可预测。您无法保证机械手#1和#0驱动器何时可用。磁带更适合异地使用。我不太在乎VTL,我喜欢这里的blob,这里有1000个数据集,对我来说,将它们全部有效地排列在磁带上。(NetBackup 6.5做得很好)。
克里斯·K

1
同意:“在任何事情上都没有一个比另一个更好”。我与您同在-磁盘到磁盘非常适合缩小备份窗口和快速还原。但是,磁带的优势在于使数据离线和离线。磁盘到磁盘到磁带是当今备份中最好的常规“最佳位置”(如果可以承受的话,其中有重复数据删除步骤)。
埃文·安德森

我们使用磁盘->非现场磁盘,以及磁盘->现场磁盘。使所有备份都易于使用。不幸的是,由于带宽成本的原因,在许多情况下这是不可能的。
Cian

7

使用RAID-10。

RAID-5对于备份服务器是愚蠢的,因为:

  • 服务器将其整个非闲置时间都花在了很多次顺序写入上。绩效很重要。
  • 磁盘利用率会随着时间的流逝而增加,因此,如果您现在不担心备份窗口,那么将来可能会。
  • 通过使用降级的磁盘操作而导致的性能下降将导致备份失败。
  • 使用RAID-5的通常借口(“磁盘太贵了,哇,哇”)是总备份容量的100%,因为您可以使用大容量SATA磁盘。
  • SATA vs. SAS对备份的重要性不高,因为您的随机I / O工作量相对较小。

完全不使用RAID是可以接受的,这取决于您是否将备份用作事实上的归档解决方案。


完全同意备份的性能方面。我的备份服务器当前是RAID-5,性能很差,并且切换RAID-10不会很有趣。

4

什么费用 硬盘很便宜,Raid 1现在已经成为主板的标准配置。

我认为您不能太小心。我已经袭击了我的主要开发机器,我定期对我的家庭服务器进行备份,而我的家庭服务器每天晚上都进行异地备份。如果它便宜,简单,无缝,我为什么不呢?


3

如今,备份,近线和异地都有多个级别。Nearline是您备份到磁盘的位置。在这里,您可以将多个非常重要的数据备份集保留在附近,同时将副本从备份服务器磁盘复制到磁带,然后将磁带异地发送。这有几个好处:

  1. 备份到磁盘通常更快
  2. 您实际上有无限数量的磁盘设备,其中备份到磁带通常受限于一次必须写入的磁头数量。

就是说,您应该以与对待数据库服务器相同的冗余性来对待备份服务器磁盘。假设您的数据库服务器在中午出现故障,您可以从昨晚回滚到磁盘副本上的备份服务器并进行还原,在这里磁带可能已经是来自异地供应商的250美元紧急退货。

您应该将RAID放在运行的每台服务器上,恕我直言,而不是非RAID RAID-0废话。:-)


Anecodote:移动数据中心时,我们的某些驱动器在数据库服务器中出现故障。事实证明足以继续使用该系统存在风险。因此,我们制作了两份副本,一份通过网络复制到另一台具有磁盘空间的服务器,另一份复制到某些外部磁盘。好吧,事实证明该阵列是坏的,我们只设法获得了网络副本(谁知道使用SCSI->以太网会胜过SCSI-> SCSI)。仅仅因为您不太可能一次丢失两个不同系统上的两个磁盘,并不意味着它不可能发生。
克里斯K,2009年

2

是的,就这样做。硬盘驱动器发生故障的可能性是任何其他计算机组件的许多倍。通过使用RAID,您可以避免最可能发生的一个问题。用数据的价值衡量RAID设置的边际成本(假设是中低端服务器,成本可能低于500美元)。

话虽如此,我仅次于埃文·安德森所说的。这绝对不是您唯一的备份。Evan谈到了不在现场和离线的问题,我将在该列表中添加冗余。如果备份介质出现故障,备份作业,被盗,丢失,介质丢失等情况,则需要具有多个备份副本。


2

您是否应该在备份服务器上使用RAID?

为了冗余,我不会

如果您不习惯于还原备份系统文件的特定修订版,并且担心在备份系统磁盘出现故障时可能必须这样做。然后,是的,我将使用RAID 5或镜像,甚至使用条带化和镜像。

如果您期望在最坏的时间可能无法获得原始数据,则这样做的唯一原因。

用于将磁盘扩展为一个卷(条带化)

也许,但是请注意,如果一个磁盘死亡,则整个阵列也会死亡。

底线

我认为备份备份服务器是一种更好的做法。我知道这听起来很愚蠢,但请多多包涵。备份系统磁盘,配置文件和备份设置。这样,如果您的备份服务器出现故障,您可以尽快启动。

(编辑:对不起,关于其他答案,我读错了问题)


1

因为计划将数据而不是磁带存储在服务器上,所以在您的后服务器上使用RAID绝对有意义。

我建议使用RAID 5、1或10。

以这种方式考虑,硬盘驱动器将发生故障。使用正确的RAID设置,可以防止数据丢失。您更换发生故障的硬盘驱动器并重建RAID。

如果没有RAID保护,当硬盘驱动器失效时(有时它会失效),那么您将丢失备份。


1

这在很大程度上取决于您对“备份”的看法。

如果目标是使服务器具有与该服务器上其他服务器“实时”数据重复的服务器,则在此备份服务器上使用RAID几乎没有用,如果丢失,则服务器上的数据仍然可用。在这种情况下,您只需要有一些备用磁盘就可以在磁盘出现故障时使备份服务器在短时间内重新联机。

如果目标是及时存档备份。我的意思是每天进行一次备份,并将其保存一个月,一年左右。然后是的,您要使用RAID,因为如果丢失磁盘,则将丢失存档。如果能够从X周前的备份中恢复数据对您至关重要,则还可以将此“备份/归档”备份到另一台服务器或磁带上(磁带很适合长时间归档)(当然距离很远) )


0

生产服务器和备份服务器硬盘同时发生故障的几率是多少?如果他们在心理上是分开的(即不在同一个电网上,等等),那么这个机会真的非常低。因此,我投票反对没有RAID。

当然,请确保在备份服务器发生故障时发出警报。


1
如果生产服务器和备份服务器中的驱动器来自同一批次怎么办?机会大大增加。
Lazlow

0

我同意已经说过的话,但是如果您使用奇偶校验进行突袭,那么将有一种方法来监视驱动器和备份数据的运行状况。大多数适配器或板载控制器将通过系统日志,Windows事件或电子邮件发送警告。

如果此框只是在SMART报告驱动器故障时抛出Windows事件,则为时已晚。

重做备份所花费的时间(工时成本)要比RAID控制器和一些额外的SATA驱动器更长。

M.


0

备份到磁盘具有价值。虽然我坚定地支持论点。不过,我要说的是,如果您的备份卷是没有冗余的单个磁盘,则最终将丢失所有数据。因为您的磁盘最终将失败。

我想这取决于您是否需要备份到磁盘备份是否真的合适的解决方案。如果您不需要异地数据,也不必担心灾难恢复或长时间的数据可生存性,则无需使用磁带。我当然拥有永远不会离开磁盘且永远不会离开数据中心的备份,但是它们在那里可以纠正用户删除错误。

另外,如何增加磁带容量?那就是磁带的美,您可以随时购买另一盘磁带。但这确实需要您拥有某种磁带更换器。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.