Резервное копирование SVN с использованием команды rsync

Я настроил cron для резервного копирования моего репозитория SVN (8 ГБ) на другой сервер. Но иногда я получаю ошибки и чувствую, что это не правильный способ для резервного копирования SVN на удаленный сервер.

Я использовал команду rsync -avz myrepo.

Пожалуйста, предложите мне хороший способ сделать резервное копирование SVN на удаленный сервер. Я не могу ежедневно архивировать файлы и передавать их, так как это 7 ГБ.

Резюме: rsync вполне подходит для резервного копирования репозитория SVN, если вы не пытаетесь резервировать активный репозиторий. Я подозреваю, что вы пытаетесь резервировать активный репозиторий, что является проблемой.

Детали:

Вы не указываете, какие ошибки сообщаются, что затрудняет диагностику. Это то, на что я часто жалуюсь нашим пользователям – если приложение выдает вам конкретное сообщение, сообщайте это конкретное сообщение людям, у которых вы просите диагностику/поддержку, даже если сообщение на самом деле “произошла ошибка” или что-то подобное (такое действительно происходит).

Я предполагаю, что проблемы, о которых сообщается, относятся к файлам, которые исчезают (они были доступны во время первоначального сканирования, но были перемещены/переименованы/удалены до завершения резервного копирования), заблокированы или, по-видимому, изменены во время чтения их с помощью rsync. Вы увидите подобные ошибки (или гораздо хуже: связанные, но не сообщенные проблемы) с большинством методов резервного копирования, если вы не полностью остановите службу SVN перед запуском резервного копирования.

Остановка всех доступов к репозиторию во время выполнения резервного копирования может быть невозможна для вас, даже если это делать глубокой ночью (так как у вас могут быть удаленные разработчики, работающие в разное время). Если это так, то есть несколько вариантов, включая:

1. Используйте hot-backup.py для полного резервного копирования репозитория, пока он активен, как описано в этом разделе бесплатно доступной книги Управление версиями с Subversion, которая в целом считается рекомендуемой для чтения. Это будет не самым подходящим способом для вашего удаленного резервного копирования, так как каждый раз будет отправляться полный репозиторий, но вы можете сделать резервное копирование в временную локальную область и выполнить rsync (или что-то еще) на основе резервного копирования этой области, а не активного репозитория.

2. Если у вас Linux и вы используете LVM для разбиения диска, вы можете использовать возможность снимков LVM для выполнения аналогичного действия, как описано в варианте 1. См. здесь и здесь для примеров документации по данной технике. Это предполагает остановку доступа к службе SNV на короткое время, пока создается снимок, но это почти мгновенно, так что вероятность возникновения проблемы меньше, чем необходимость остановить все для полной операции резервного копирования.

3. Используйте инкрементные резервные копии живого репозитория, также упомянутые в вышеуказанной книге SVN.

Техника LVM будет быстрее, чем hot-backup.py, а затем синхронизация, но она недоступна вам без дополнительной работы и изучения, если вы уже не используете и не знакомы с LVM. Ее преимущества в том, что она будет почти наверняка значительно быстрее и будет использовать меньше дискового пространства (хотя в наши дни дисковое пространство довольно дешево доступно). Снимки LVM действительно влияют на производительность записи, пока они присутствуют, но разница вряд ли будет заметна, если ваш репозиторий очень очень загружен, и производительность все равно вернется к норме в конце операции резервного копирования, когда вы удалите снимок.

Метод hot-backup.py имеет преимущество в виде того, что он дает вам локальную резервную копию, если у вас ее еще нет – если хранить “горячую копию” на другой машине, вы можете восстановить ее гораздо быстрее, чем восстанавливать удаленную копию, если основной компьютер выйдет из строя в результате события, не влияющего на другую (например, сбоя контроллера диска). Это также, вероятно, будет проще в реализации, если вы уже не используете LVM и не знакомы с ним.

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

В итоге, rsync вполне подходит для резервного копирования репозитория SVN (как и многие другие методы, но я сам большой фанат rsync в большинстве случаев использования) если вы не резервируете активный репозиторий – вам нужно либо остановить службу, либо сделать резервное копирование из какой-либо формы снимка.

Как насчет svnsync (часть SVN) на другой сервер, также работающий под svn? В качестве транспорта вы можете использовать ssh+svn.

Прямое копирование живого репозитория SVN никогда не является хорошей идеей.

Вы можете рассмотреть svnadmin dump --incremental в папку и использовать rsync. Таким образом, вам нужно будет передавать только инкременты.

Альтернативой является svnadmin hotcopy, который делает идентичную копию живого репозитория, и вы синхронизируете это.

Вы можете выполнить живое резервное копирование активного репозитория SVN, также с помощью rsync, при условии:

• используется хранилище fsfs
• вы копируете файлы в правильном порядке (сначала файл db/current)

Также нет смысла копировать содержимое подкаталога transactions/, так как текущая транзакция не может быть надежно скопирована.

Репозиторий, скопированный таким образом, будет консистентным и будет содержать данные до последнего коммита перед тем, как был скопирован файл db/current.