针对由图像/数据库/办公文件/ svn存储库/

我正在为我们的小公司寻找一个简单的现场(即不在线)备份解决scheme。 目前我们共有约4TB的数据,可能每年增加〜500GB。 每天数据变化的难度要小得多 – 平均而言,我估计远低于1GB。

所有的数据只能从内网访问,大多数机器运行的是Windows,有些则在MacOS下运行。

详细数据如下:

(a)大部分数据是图像/video/文档(pdf)等等,我估计2.5TB。

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

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

(d)一些程序只有二进制源代码,并被“归档”为zip文件。 新版本被添加,有些旧版本有时会恢复,但旧版本不会被更改。 这些程序占用大约80GB。

(五)一些个人备份(电子邮件等)和其他的东西大约需要1TB我猜。

(f)我们在单个Microsoft SQL服务器上也有less量的数据。 这应该不足1GB。

现在我们每星期一到星期五晚上都会从networking磁盘到本地服务器磁盘到服务器上的磁带机进行完整备份。 我们轮换星期五的录像带,也就是我们有录像带,标有mo,tue,wed,thu,fri1,fri2。 这意味着我们不能在最糟糕的情况下超过2周。

什么是这个异构系统的一个很好的解决scheme

(a)很less访问,很less更改,很less添加数据,

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

(c)在“通用”版本控制下经常访问相当小的数据,

(d)大量添加的二进制大文件(〜100MB),很less读取,从不改变(应该可选地是一次性的)和

(e)诸如办公室文件,数据日志,很less添加/更改的邮件文件夹等杂项数据

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

我坚持使用编程,版本控制和计算机,但对于备份策略是新的。 所以如果解决scheme维护起来很简单,那就太好了。

如果可能的话,像SVN / Git提供的版本会更好,所以最后一次成功的备份允许恢复每个备份的文件(而不是手动删除)。

到目前为止,该战略的问题是:

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

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

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

    =>如果备份时间达到24小时,该怎么办?

  • 恢复备份是相当痛苦的
  • 恢复一个月前我删除/修改/覆盖的东西是不可能的

解决scheme应该解决所有这些问题。

时间使用详情:

  • 从networking上的其他服务器收集数据到备份服务器:02:15

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

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

  1. backing up takes a long time (17 hours) – 在周末执行完全备份,并在一周内执行增量备份。 这将在一周内减less备份窗口,并且还会减less备份集所需的存储量。

  2. There's not enough time to test the backup – 你准备testing什么? 您应该每周或每个月从备份集中对小数据集执行一次testing还原。 您不需要testing还原整个备份集。 还原一些文件和一两个数据库。

  3. Hard to tell if the backup is really working – 请参见第2节。您需要testing备份中的还原数据,以确定它们是否正在运行。 您应该经常这样做,以确保备份和备份过程每周都是可靠的。

  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 – 获取足够的备份媒体,以满足您的恢复需求。 确定每周需要多less备份媒体,以及需要多less周才能恢复。 然后乘以两者。 这会给你一个粗略的想法,你需要多less备份媒体,并将帮助你确定你的备份媒体轮换时间表。

编辑

为了解决您的意见:

就恢复数据而言,取决于备份软件以及您使用的备份介质types。 BackupExec使用磁带和备份的磁盘目录。 查找需要恢复的数据不需要“读取”磁带,直到find数据。 它只需要在BackupExec的“恢复select”窗口中查找数据。 find数据所在的媒体后,只需将该媒体提供给BackupExec即可。 为了进一步说明,BackupExecbuild议执行备份到磁盘,然后将这些备份复制(复制)到磁带。 如果您提供足够的磁盘空间来运行整整一周的备份,那么在整个星期内可能需要恢复的所有数据都将保存在磁盘上,并且不需要您根本无法交换磁带。 您只需select要恢复的数据,BackupExec就可以在磁盘媒体上find它。

至于要执行的备份types,这取决于您。 我build议每周增量备份和每日增量备份,因为每日增量备份将运行得更快,并且比每日差异备份更小,从而为您节省时间和金钱(就备份窗口和备份介质而言)。 需要差异备份来恢复数据的情况相当less,而且我从来没有在IT行业13年中遇到这种情况。

这闻起来很可疑,对不起。

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

4000GB不是一个大的备份,不应该花17个小时。 你如何做到这一点 – 1Gbitnetworking? 也许是时候把一个体面的基础设施。 用于备份服务器的10g骨干,如带有本地更改代理的MIcrosoft DPM,以及允许用户进行单个文件恢复的function,备份服务器中10-12tb的磁盘空间用于在磁盘上保留一些备份(用于用户快速恢复) 。

这是众所周知的和logging的东西 – 它在我看来这是主要是你如何使备份是坏的定义。 从硬件不够到软件不够。 你应该重新评估你的设置。

我正在总结给出的build议:

  • 得到一个专用的备份服务器,这样一旦所有数据都在备份服务器上,生产服务器就不能自由更改
  • 如果备份时间太长,则从每天的完整备份切换到周五的完全备份,以及从周一到周四的增量/差异备份
  • 备份testing在星期五备份完成后就足够了 – 或者我们每天都有专门的备份服务器(只要它是自动化的,因此不需要我的时间)
  • 获取足够的磁带,以便我们可以恢复很久以前的数据
  • 为了加速恢复,除了在磁带上进行备份之外,还可以考虑备份到磁盘
  • 一周中增量备份是首选,因为它们速度更快,差异备份的优势很less使用

存储库/数据库和备份方面没有单独的处理方式(除了数据库备份时不能使用数据库)。