Другая хорошая стратегия сохраняет второй репозиторий SVN и синхронизирует его с основным с svnsync, обычно с рычагом постфиксации.

Основное преимущество состоит в том, что, если первый репозиторий понижается по любой причине, Вы можете immediatly переключаться на резервный и продолжать работать с ним без любого времени простоя.

Если Вы hotcopy поврежденный repo поверх Вашего ранее неповрежденного резервного копирования, то да, Вы потеряете свое неповрежденное резервное копирование.

Если Вы обеспокоены этим, то, поскольку другие сказали, необходимо повернуть резервные копии.

Вы могли также расположить работать 'svnadmin, проверяют' автоматически также.

Я реализовал план резервного копирования относительно SVN предприятия 1.4.x репозиторий (размещенный в Windows в то время), использовав python сценарий svn-backup-dumps.py

Я вызываю svn-backup-dump.py от a post-commit сцепитесь для инициирования возрастающих резервных копий для определенного пересмотра. Я использовал schtasks запланировать еженедельное "полное" резервное копирование с помощью того же сценария.

Восстановление (который мы должны были сделать дважды из-за удаления с толстыми пальцами каталога в репозитории) относительно просто: захватите новое полное резервное копирование, восстановите его. Примените incrementals через последний пересмотр.

Я не изучил улучшения/изменения для 1,5 в этой области, но я полагаю, что подобный план работал бы хорошо на Вас.

У меня была неудача в прошлом с одними только горячими копиями. Если это - код, который обновляется и фиксируется много раз в течение дня, это могло бы стоить более подробно стратегии резервного копирования.

Call me old school, but what about sub-versioning to a partition and then ghosting on a schedule?

The svnsync option suggested by Davide Gualano sounds good too. I'm leaning towards this option to prevent unnecessary partitioning of my drives (this may also rub other admins the wrong way and not make sense on some of my VPS environments).

Addition

I have been using the svnadmin 'dump' command a lot lately. This works a lot like the mysql dump command, in that it exports your repository out into bak create commands. This command could be implemented as a crontab / scheduled task and then copied to an external drive as a file. Example commands:

svnadmin dump c:\svn\project > c:\dumps\project.bak

svnadmin load c:\svn\project < c:\dumps\project.bak

Then use robocopy / you copying tool of choice to move the file to another location. This is useful if you want to move the files completely off the repo server but there is no external access to subverion.

I still haven't got this down to a fine art. When I move these files between machines, I occassionally get something like 'UUID mismatch'. I have been resolving this by deleting / under-scoring the project folder, then using:

svnadmin create c:\svn\project

svnadmin load c:\svn\project < c:\dumps\project.bak

This should remove the error. You may need to re-create or restore links with Eclipse or other projects. If the UUID is broken, it may affect other people using the project too, so this should be a consideration.

You could use this method as a fall-back for Hotcopy. Between them you should be able to retore the repo.

P.S. Ken, it looks like svn-backup-dumps.py has been moved here: http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svn-backup-dumps.py