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