我的工作网络出现了存储难题。
目前，我们使用版本控制（SVN）将原始文件从我们的工作站备份到集中服务器上的存储库。
读完之后，我似乎遇到了一些较大文件的问题，这些文件有时甚至大到 1 GB。每个存储库中有 100 个这样的文件，因此随着时间的推移，存储库会变得相当大。
有没有更好的软件可以使用？我想要存储库功能，但希望环境更稳定/更实用。我们确实需要对我们的集中式服务器进行备份系统大修。
更新：
根据要求，服务器和工作站的操作系统均为 XP。如果需要，可以将服务器更新为 Server 2003。
答案1
我不确定 Subversion 是否真的被设计为备份工具。你可能需要看看安克诺斯。虽然价格肯定比自制解决方案要高，但在发生严重故障后从裸机恢复是最令人满意的。
我主要在 Linux 上工作，现在已改用 R1Soft 的 CDP 服务器，但在此之前，我在办公室使用过 Acronis，效果很好。
答案2
Subversion 实际上拥有现代版本控制系统中最好的大文件处理能力。Git、Mercurial、Bazaar 等都有架构或平台特定的限制（通常是 2 或 4 GB，因为它们会将文件内存映射以执行各种操作）。如果您能够将文件推送到服务器上的 git repo，然后通过脚本在服务器上执行提交，Git 可能非常适合您作为“愚蠢的内容跟踪器”的用例。请参阅这个问题了解更多信息（以及有关不同平台上的内存映射问题的链接）。
更大的问题是，修订控制系统提供的“二进制差异”和压缩功能通常对大多数大型媒体文件无效，因为它们已经压缩并且变化很大。例如，如果您有两个电影文件，并且编辑其中一个以从中间删除 4 秒，您会认为只存储更改应该很容易。但事实上，当您编辑该文件时，即使您不重新编码视频，每个帧的时间码也会被打乱，导致几乎整个文件再次存储。如果可能的话，您可能只想关闭工具中的压缩和差异功能以节省 CPU 和备份时间。
我见过 Subversion 或 Git 唯一能很好地处理的大型文件是 SQL 数据库备份，这些备份通常具有页面结构，并且从一个备份到下一个备份变化很小。当然还有日志文件，即使使用 gzip 压缩，压缩效果也非常出色。
答案3
如果你使用 SVN（或任何其他版本控制软件）作为备份您可能需要考虑一个实际的备份系统（巴库拉，或者可能是一些商业内容）。
如果文件需要进行修订控制，您可以继续将文件签入 SVN，但根据我的经验，随着规模的扩大，SVN 是一个非常糟糕的备份系统......