廉价的数据库备份硬件？

build议使用以下设置保存数据库备份的硬件：

5个独立的物理主机，每个都有一个Sql Server 2008数据库。每个实例都大于200Gb。每个数据库每天都会进行一次完整备份，每隔几个小时就会有一次差异。我希望将一周的备份保留在某个位置，以便在需要时快速方便地将数据库恢复到不同的方框。

目前，他们都将压缩的备份发送到一个大文件共享，这个文件共享被压垮了，导致备份频繁失败。

作为一个额外的问题，将本地备份复制到远程服务器的最快速和最具成本效益的方法是什么？

你提到目前你的备份失败了，因为它们被发送到一个单一的共享 – 看起来好像购买便宜的硬件来创build另一个共享将会有所帮助。

我想首先你需要看看你的瓶颈在哪里，然后围绕这些备份进行工程devise。如果瓶颈是networking而不是磁盘或CPU，那么你会有一个不同的解决scheme。这是高度依赖于您的数据访问模式，您有200GB的数据，但多久是SELECTED和UPDATE？

一个选项可能是设置一个主/从实例，让主SQL服务器将数据写入从服务器，备份服务器以保存活动的主服务器。

请注意，我不是DBA，但据我所知这个答案是相当准确的，希望有人比我更有知识可以进一步回答！

我会用最便宜，最大的NAS。

复制它们的有效方法是将SQL BAK文件转储到SQL服务器本身上，并调度一个robocopy BAT脚本，或者如果NAS支持FTP，则使用预定脚本中的FTP将其复制。

一个更好的方法是将SQL BAK文件直接写入NAS共享，但是你必须确定它是否可以处理IO。

在不知道预算或负载的情况下，我会考虑尝试将备份存储设备分配给几个设备，以抵消networking负载。

我不知道别人会怎么想…我不是一个数据库专家，我们没有像TB级的数据+差异存储和pipe理的大规模的东西，但我想知道将第二个NIC添加到数据库服务器，并有一个单独的交换机，连接到作为NAS设备的一对服务器。让服务器1,2和3转到备份服务器1，服务器4和5转到第二个LAN上的备份服务器2。这应该可以缓解一些networking拥塞，并且有单独的机器可能有助于减轻驱动器的一些负担并提高吞吐量。

我还考虑将外部驱动器连接到服务器，以便将其保存到“本地”驱动器，然后可以将数据从物理外部磁盘拖放到另一个系统以进行直接复制，而不是使networking或交换机饱和。它需要物理干预，但不能轻易实现自动化（尽pipe您可以编写一些只保留特定date的文件/备份的文件，以防止文件系统溢出）。这将需要5个大的外部驱动器，但它可能比饱和你的networking更快。

我相信别人有更好的想法，但。这可能是考虑入门级或便宜的东西。