针对图像/数据库/办公文件/svn 存储库等异构数据的良好备份策略

针对图像/数据库/办公文件/svn 存储库等异构数据的良好备份策略

我正在为我们的小公司寻找一个简单的现场(即非在线)备份解决方案。目前我们总共有大约 4TB 的数据,每年可能增加约 500GB。每天更改的数据量要小得多 - 我猜平均不到 1GB。

所有数据仅可从内联网访问,并且大多数机器运行 Windows,有些机器运行 MacOS(如果有的话)。

详细数据:

(a) 大部分数据是图像/视频/文档(pdf)等,我猜是 2.5TB。

(b) 经常访问的是我们的 CAD 数据文件,但它们只占用 10-20GB。这些文件由名为 GAIN 的集中式 CAD vcs 控制/访问(我认为它将数据保存在二进制数据库中)。目前,这些数据在晚上被转储,然后备份。

(c) 一些主要源代码数据已经处于版本控制(SVN,GIT)之下,占用空间不到 2GB。

(d) 有些程序只有二进制源代码,并以 zip 文件的形式“存档”。有时会添加新版本,有时会恢复一些旧版本,但旧版本永远不会改变。这些程序大约占用 80GB。

(e) 我猜一些个人备份(电子邮件等)和其他内容大约占用 1TB。

(f)我们在单个 Microsoft SQL 服务器上还有少量数据。这些数据应该少于 1GB。

目前,我们每周一至周五晚上都会进行一次完整备份,从网络磁盘到本地服务器磁盘再到服务器上的磁带驱动器。我们交替使用周五的磁带,也就是说,我们的磁带被标记为 mo、tue、wed、thu、fri1、fri2。这意味着在最坏的情况下,我们不能回溯超过 2 周的时间。

对于这种由以下各项组成的异构系统,有什么好的解决方案吗?

(a)大量很少访问、很少更改、很少添加的数据,

(b)由程序内部使用数据库提供的经常访问的较小数据,

(c)在“通用”版本控制下频繁访问的较小数据,

(d)大型二进制文件(~100MB),大多是添加的,很少读取,从不改变(可以选择丢弃)和

(e)办公文件、数据日志、邮件文件夹等很少添加或更改的杂项数据

(f)Microsoft SQL 服务器上的数据

我对编程、版本控制和计算机很熟悉,但对备份策略却不太熟悉。因此,如果解决方案维护起来非常简单,那就太好了。

如果可能的话,像 SVN/Git 提供的版本控制就更好了,这样最后一次成功的备份就可以恢复曾经备份过的每个文件(而不是手动删除的文件)。

该策略目前存在的问题:

  • 备份需要很长时间(15 小时)

    => 没有足够的时间来测试备份

    => 很难判断备份是否真的有效

    => 备份时间达到24小时怎么办?

  • 恢复备份非常麻烦
  • 无法恢复一个月前删除/修改/覆盖的内容

解决方案应该解决所有这些问题。

详细时间使用情况:

  • 通过网络将数据从其他服务器收集到备份服务器:02:15

  • 将备份服务器(同时充当“常规”服务器)上的数据复制到备份服务器上的另一个驱动器:09:00

  • 将所有数据从备份服务器上的内部驱动器复制到连接到备份服务器的磁带:03:45

答案1

  1. backing up takes a long time (17 hours)- 在周末执行完整备份,并在周内执行增量备份。这将减少周内的备份窗口,并减少备份集所需的存储量。

  2. There's not enough time to test the backup- 您到底在测试什么?您应该每周或每月从备份集中对小数据集进行测试恢复。您不需要测试恢复整个备份集。恢复少量文件和一个或两个数据库即可。

  3. Hard to tell if the backup is really working- 参见第 2 条。您需要测试从备份中恢复的数据,以了解它们是否正常工作。您应该经常这样做,这样您才能确信备份和备份过程每周都是可靠的。

  4. What to do if the backup time reaches 24 hours?- 参见第 1 条。

  5. restoring a backup is quite a pain- 怎么会这样?是流程吗?是备份软件吗?等等等等。

  6. restoring something I deleted/modified/overwrote a month ago is not possible- 获取足够的备份媒体以满足您的恢复需求。确定每周需要多少备份媒体以及需要多少周才能返回并恢复。然后将两者相乘。这将让您大致了解您需要多少备份媒体,并帮助您确定备份媒体轮换计划。

编辑

针对您的评论:

至于恢复数据,这取决于备份软件和您使用的备份介质类型。BackupExec 使用磁带和磁盘上的备份目录。查找需要恢复的数据不需要“读取”磁带,直到找到数据。它只需要在 BackupExec 中的“恢复选择”窗口中找到数据。找到数据所在的介质后,只需将该介质提供给 BackupExec 即可。为了进一步实现这一点,BackupExec 建议执行磁盘备份,然后将这些备份复制(拷贝)到磁带。如果您提供足够的磁盘空间来运行整整一周的备份,那么整个星期您可能需要恢复的所有数据都将在磁盘上,根本不需要您交换磁带。您只需选择要恢复的数据,BackupExec 就会在磁盘介质中找到它。

至于要执行哪种备份,则由您决定。我建议每周进行一次完整备份,每天进行一次增量备份,因为每日增量备份比每日差异备份运行速度更快,而且备份量更小,从而节省您的时间和金钱(就备份窗口和备份介质而言)。需要差异备份来恢复数据的情况很少见,而且我在 IT 行业工作了 13 年,从未真正遇到过这种情况。

答案2

这闻起来有点可疑,抱歉。

目前我们总共有大约 4TB 的数据,每年可能增加约 500GB

4000gb 绝对不是一个大备份,也不应该花费 17 个小时。您如何做到这一点 - 1gbit 网络?也许是时候建立一个像样的基础设施了。备份服务器的 10g 主干,类似 MIcrosoft DPM 的东西,带有本地更改代理和允许用户恢复单个文件的功能,备份服务器中的 10-12tb 磁盘空间用于将备份保存在磁盘上一段时间(供用户快速恢复)。

这些都是众所周知且有据可查的东西 - 在我看来,这主要是你对如何进行备份的定义,这是错误的。从硬件不足到软件不足。你应该重新评估你的设置。

答案3

我尝试总结一下已给出的建议:

  • 获取专用的备份服务器,以便一旦所有数据都存储在备份服务器上,生产服务器就不会随意更改
  • 如果备份时间过长,则从每天的完整备份切换到周五的完整备份,并从周一到周四进行增量/差异备份
  • 周五备份完成后,备份测试就足够了 - 或者当我们有专用的备份服务器时,也许每天都进行(只要它是自动化的,因此不会占用我的时间)
  • 获取足够的磁带,以便我们可以恢复很久以前的数据
  • 为了加快恢复速度,除了磁带备份外,还可以考虑将数据备份到磁盘
  • 每周的增量备份是首选,因为它们速度更快,而差异备份的优势很少被使用

在备份方面,没有对存储库/数据库和“普通”数据进行单独处理(除了在备份时不得使用数据库)。

相关内容