我想知道不同商店备份其存储库的频率。我听说有些人甚至每5分钟就可以避免在恢复后担心,通过每个人的本地项目查找并合并恢复后丢失的任何未提交的更改。
当我为一个15人左右的开发团队管理svnserver时:
我们是3名开发人员,我每晚都在备份。
但这实际上取决于您安装svn的服务器。也许它正在做影子副本,它是一个冗余服务器,......这也取决于开发人员的数量,项目有多大。
我认为没有一个有效的答案。
大多数人对备份采取了相当宽松的态度,并采用了“曾经的蓝月政策”。
直到那一天。
你知道那一个。
那天之后,你会很擅长。你认为你永远不想失去超过一天的工作,而你确定这就是发生了什么!在回答这个问题时,我们将subversion存储库和trac数据库的每日rsync执行到非现场位置。
和其他我们每天4:30备份一样。但是,有一点很重要,切勿将备份服务器放在同一个房间内。还可以不时将备份DVD移动到其他位置。如果发生灾难,你不会放松一切。
1名开发人员我每天凌晨3点备份它。
我使用winzip压缩整个存储库并将其上传到远程ftp,因此我所拥有的备份位于不同的物理位置,以防止因盗窃或火灾而导致数据丢失。
我不保留旧备份,因为svn存储库本身包含所有历史记录。
我只是使用winzip的内部调度来进行自动压缩和ftp上传。简单有效
我很少备份我的个人svn存储库 - 自从1.4天之前我一直在手动执行一次,并且应该真的设置svnsync
一段时间。 svnsync
很棒。另一方面,对于个人存储库,备份对我来说稍微不那么重要;我会失去一些历史记录,但重要的一点是在几个远程工作站的检查中,这些工作站本身都备份了;实际内容不会丢失。
在工作中,其他人管理备份,并且我对设置没有任何线索可能不是一件好事。
但是,严肃地说,现在,使用svnsync,合理的备份是很容易设置的。当然,它不会包含你的提交钩子,这并不好 - 但是对所有内容进行简单的远程备份肯定是件好事。至于提交钩子,你只需要单独支持它们。由于它们几乎从不改变,所以这是可行的。使用svnsync,你真的可以将镜像设置为每5分钟备份一次 - 最重要的是,同步镜像本身就是一个完全有效的svn存储库,如果你计划它,它几乎可以立即用作替换svn服务器。主服务器关闭(您需要解决诸如访问控制之类的问题,并将svnsyncs挂钩替换为您的正常设置,并且您希望为新服务器提供与旧服务器相同的DNS名称,以实现真正无缝的转换) 。
日常。无论有多少人。只需将备份作为cron作业运行。
(在家我每周备份一次)
进行每日备份 - 将它们放在另一个分区,机器,物理站点上 - 并以对数方式清除旧备份(这是一个示例,使其适应您的上下文):
或者遵循Dilbert方法:
(来源:ntpro.nl)
因此,不要忘记将备份副本偶尔安装到一次性Subversion服务器上,以确保一切正常。
在考虑经常或是否备份的时候。想想一天/周的工作对你来说有多大价值。在任何专业环境中,几个开发人员日的成本可能等于备份服务器的成本以及设置cron作业以运行svnadmin dump
的几分钟。除非您的数据(或时间)对您毫无价值,否则您应该至少每天备份。
理想情况是拥有存储库的完整热镜像,这也有助于减少单个服务器上的负载。如果您正在考虑为Subversion(或CVS)设置备份过程,请查看WANdisco。它们提供各种群集/镜像解决方案,允许您扩展存储库并透明地从错误中恢复。
Subversion High Availability提供持续热备份,同时使开发人员和管理员自动且透明地进行故障转移和灾难恢复。
(来源:wandisco.com)
如果您有多个站点或大型站点,您还可以将其群集或多站点系统视为无共享负载平衡的Subversion群集。
(来源:wandisco.com)
好吧,现在我考虑一下,实际上没有理由不能更频繁地自动备份存储库。也许它应该。
我在个人/咨询项目中使用SVN,我是唯一的开发人员。
我在开发的每一天结束时将它备份到闪存驱动器。
在我们有3-5名开发人员但不使用SVN的办公室,我们每晚都会备份一次中央存储库。