Question

我有一个非常大的（~6GB）SVN存储库，为此我编写了一个批处理文件脚本来每天进行增量备份。该脚本检查上次备份的运行时间，并仅转储此后的修订版。

文件的名称为：backup-{lower_revision}-{higher_revision}.svn，例如：backup-156-162.svn，backup-163-170.svn。

这意味着我有很多小转储文件，我猜这很好（比很多6GB转储文件要好），但是我有点担心要从中恢复多少工作我需要这些备份。

为了减少文件总数，我已经开始在每个月的第一天进行完全转储，但是，如果我需要在30日恢复，那将是30个转储文件可能需要一段时间

我一直在考虑的是：

手册：
svnadmin load c:\myRepo < backup-1-10.svn
等待
svnadmin load c:\myRepo < backup-11-24.svn
等待
等...
批处理文件使上述过程不那么繁琐
将每个文件附加在一起并进行一次加载（如果可能的话？）

使用这些文件的最佳方法是什么？我需要恢复吗？

ps：操作系统是Windows

Answer 1

您应该通过编号[01,02，... 31]来重命名文件，以便轻松排序文件对于转储，了解哪些修订版本并不重要。

我采用了不同的方法，因为像这样加载一个巨大的回购需要一些时间，所以你应该考虑以下几点：
您可以使用 svnadmin hotcopy 每周/每月热备份一次存储库。每天都应该进行增量转储，以获取最新的修订版本，以便检索您必须调用的最新修订版本 svnlook最年轻[live_repo] - ＆gt;为您提供实时存储库的最新版本

svnlook最年轻[copied_repo] - ＆gt;为您提供每周热门备份所备份的最新修订

现在您可以使用两个版本号从您的live-repo运行转储优点：

更快地让备份的存储库重新启动并运行（转储需要数小时！）
少转储文件
减少脚本工作量
通过post-commit-hook扩展到“per-commit”-backups，这样你就会失去任何修改

Answer 2

无论您提出哪种解决方案，我都肯定会建议您进行试用版恢复。通过这种方式，您可以验证流程是否符合您的实际需求，并且当您需要在愤怒中使用它时，您将能够成功完成该流程。

我会尝试你现在的过程，如果过程是可以容忍的，那么更简单更好，不要乱用它。如果看起来很多工作，那么一定要寻找优化机会。

Answer 3

我建议每天运行一个dump命令，并保留最后5个转储。那是你的30场演出。

这是一个运行我使用的自动转储但我手动删除备份的脚本：

::This script backs up the subversion repository.

::Reset Temp backup storage

rmdir /S /Q C:\SVNBACKUP
mkdir C:\SVNBACKUP

::Initiate SVN backup. Use svadmin hotcopy
svnadmin dump /svn/myProj1 > /home/username/myProj1Bak

for /f "tokens=2-4 delims=/ " %%g in ('date /t') do (
  set mm=%%g
  set dd=%%h
  set yy=%%i
)

if exist "\\networkdrive\Clients\SVN\%mm%-%dd%-%yy%" (
  rd /S /Q "\\networkdrive\Clients\SVN\%mm%-%dd%-%yy%"
)

xcopy "/home/username/myProj1Bak" "\\networkdrive\Clients\SVN\%mm%-%dd%-%yy%" /s /i

Answer 4

彼得的命令实际上是：

svn look youngest [live_repo]
svn look youngest [copied_repo]

从多个文件恢复SVN备份

4 个答案: