针对图像/数据库/office文件/svn存储库/异构数据的良好备份策略
我正在寻找一个简单的现场(即不在线)备份解决方案，为我们的小公司。目前，我们总共大约有4TB的数据，可能每年增加大约500 we。每天变化的数据量要小得多--我猜平均不到1GB。
所有数据都只能从内部网访问，而且大多数机器都在运行Windows，如果有关系的话，有些是在MacOS下运行的。
详细的数据：
(a)大部分数据是图像/视频/文件(Pdf)，我猜是2.5TB。
(b)经常访问的是我们的CAD-数据文件，但它们只占用10-20GB。这些被称为增益的集中式CAD vcs控制/访问(我认为它将数据保存在二进制数据库中)。目前，这是倾倒在晚上，然后备份。
(c)一些主要的源代码数据已经处于版本控制下(SVN，GIT)，占用不到2GB。
(d)有些程序只有二进制源代码，并以压缩文件的形式“存档”。新版本会被添加，一些旧版本有时会被恢复，但旧版本永远不会改变。这些程序大约需要80 up。
(e)一些个人备份(电子邮件等)我想其他的东西大概需要1TB。
(f)我们在一个Microsoft服务器上也有少量数据。这应该不足1GB。
现在，从网络磁盘到本地服务器磁盘到服务器上的磁带驱动器，我们每周一到周五晚上都要做一个完整的备份。我们轮流使用星期五的磁带，即我们有标记为mo、tue、We、清华、fri1、fri2的磁带。这意味着，在最糟糕的情况下，我们不能回到过去超过2周的时间。
什么是这个异构系统的好解决方案？
(a)很少访问、很少更改、很少添加数据，
(b)经常使用数据库由程序内部提供的相当小的数据，
(c)经常在“通用”版本控制下访问相当小的数据，
(d)大型二进制文件(~100 be )，它们大多是添加的，很少读取，从不更改(应该是一次性的)和
(e)很少添加/更改的杂项数据，如办公室文件、数据日志、邮件文件夹
(f) Microsoft SQL server上的数据
我坚持编程，版本控制和计算机在一般情况下，但新的备份策略。因此，如果这个解决方案维护起来非常简单的话，那就更好了。
如果可能的话，像SVN/Git这样的版本控制会很好，所以最后一次成功的备份允许恢复备份过的每个文件(而不是手动删除)。
到目前为止，该战略存在的问题如下：
- 备份需要很长时间(15小时) =>，没有足够的时间来测试备份=>，很难知道备份是否真的在工作，如果备份时间达到24小时，怎么办？
- 恢复备份是很痛苦的
- 恢复一个月前我删除/修改/重写的内容是不可能的。
解决办法应解决所有这些问题。
详细的时间使用情况：
- 通过网络从其他服务器收集数据到备份服务器: 02:15
- 将备份服务器(也充当“常规”服务器)上的数据复制到备份服务器上的另一个驱动器: 09:00。
- 将备份服务器上的所有数据从内部驱动器复制到附在备份服务器上的磁带: 03:45
回答 3
Server Fault用户
发布于 2013-01-08 17:46:43
backing up takes a long time (17 hours)-周末执行完整备份，并在一周内执行增量备份。这将减少一周内的备份窗口，也将减少备份集所需的存储量。There's not enough time to test the backup-你到底在测试什么？您应该每周或每个月从备份集中执行小数据集的测试恢复。您不需要测试恢复整个备份集。还原几个文件和一两个数据库。Hard to tell if the backup is really working--参见第2条。您需要测试备份中的还原数据，以确定它们是否正常工作。您应该经常这样做，以使您确信备份和备份过程每周都是可靠的。What to do if the backup time reaches 24 hours?-见1号。restoring a backup is quite a pain-怎么会这样？是这个过程吗？备份软件？等等restoring something I deleted/modified/overwrote a month ago is not possible-获得足够的备份媒体以满足您的恢复需求。确定每周需要多少备份媒体，以及需要多少周才能返回并从中恢复。然后把两者相乘。这将使您大致了解您需要多少备份媒体，并将帮助您确定备份媒体轮换计划。
编辑
为了回应你的评论：
就恢复数据而言，它取决于备份软件和您使用的备份介质类型。BackupExec使用备份的磁带和磁盘目录。找到需要恢复的数据不需要“读取”磁带，直到找到数据。它只需要在BackupExec的还原选择窗口中查找数据。一旦您找到了数据所在的媒体，向BackupExec提供该媒体就很简单了。为了进一步了解这一点，BackupExec建议对磁盘执行备份，然后将这些备份复制到磁带中。如果您提供了足够的磁盘空间来运行整整一周的备份，那么您可能需要在整个一周内恢复的所有数据都在磁盘上，因此根本不需要交换磁带。您只需选择要还原的数据，BackupExec就会在on媒体中找到它。
至于要执行的备份类型，这取决于您。我建议每周备份和每日增量备份，因为每天增量备份运行得更快，比每日差异备份更小，从而节省了时间和金钱(就备份窗口和备份媒体而言)。在这种情况下，需要差异备份来恢复数据是远远不够的，而且在IT行业的13年中我从未真正遇到过这种情况。
Server Fault用户
发布于 2013-01-09 13:29:22
这闻起来有点可疑抱歉。
现在我们总共大约有4TB的数据，可能每年增加大约500 we的数据。
4000 17不是一个大的备份任何手段，不应花费17个小时。你是怎么做到的-1 1gbit网络？也许是时候建立一个像样的基础设施了。10g备份服务器的主干网，类似于带有本地更改代理的MIcrosoft DPM，以及允许为用户恢复单个文件的功能、备份服务器中10-12 to的磁盘空间，以便在磁盘上保持备份(供用户快速恢复)。
这都是众所周知的和文档化的东西--在我看来，这主要是你对如何做不好的备份的定义。从硬件不足到软件不足。你应该重新评估你的设置。
Server Fault用户
发布于 2013-01-11 08:49:33
我想总结一下已经给出的建议：
- 获取专用备份服务器，以便生产服务器在备份服务器上的所有数据都已就绪后不会随意更改。
- 如果备份的时间太长，则从每天的完全备份切换到星期五的完全备份，从周一到周四的增量/差异备份。
- 备份测试在周五备份时就足够了--或者当我们每天都有专用备份服务器时(只要它是自动化的，因此不会占用我的时间)。
- 获取足够的磁带以便我们可以恢复很久以前的数据
- 为了加快恢复速度，除了磁带上的备份之外，还可以考虑对磁盘进行备份。
- 星期内的增量备份是首选的，因为它们更快，而且差异备份的优势很少被使用。
在备份方面没有单独处理存储库/数据库和“普通”数据(除了备份时不能使用数据库之外)。
https://serverfault.com/questions/464017
复制相似问题
腾讯云开发者
