Я настраиваю cron для резервного копирования моего репозитория SVN (8 ГБ) на другой сервер. Но иногда я получаю ошибки и чувствую, что это неправильный способ вернуть svn на удаленный сервер.
Я использовал команду rsync -avz myrepo.
Пожалуйста, предложите мне хороший способ сделать резервную копию svn на удаленный сервер. Я не могу заархивировать файлы и передавать их ежедневно, так как это 7 ГБ.
Спасибо
Резюме: rsync должно быть идеально для резервного копирования репозитория svn, до тех пор, пока вы не создаете резервную копию репозитория, который в настоящее время активен. Я подозреваю, что вы пытаетесь сделать резервную копию активного репозитория, что проблематично.
Деталь:
Вы не говорите, о каких ошибках сообщается, что затрудняет любую попытку диагностики. Я регулярно жалуюсь на наших пользователей - если приложение дает вам конкретное сообщение сообщить об этом конкретном сообщении людям, у которых вы запрашиваете диагностику / поддержку, даже если сообщение на самом деле «произошла ошибка» или подобное (как это действительно происходит).
Я предполагаю, что проблемы, о которых сообщается, связаны с отсутствием файлов (они присутствовали во время первоначального сканирования, но были перемещены / переименованы / удалены до завершения резервного копирования), заблокированы или, по-видимому, изменены, пока rsync их читал. Вы увидите аналогичные ошибки (или, что еще хуже: связанные, но не зарегистрированные проблемы) с большинством методов резервного копирования, если выполняете резервное копирование действующей службы svn, и вы не полностью остановите службу svn перед запуском резервного копирования.
Остановка всего доступа к репозиторию во время выполнения резервного копирования может быть недоступна для вас, даже если это делается глубокой ночью (поскольку у вас могут быть удаленные разработчики, которые работают в разное время). В этом случае есть несколько вариантов, в том числе:
Использовать hot-backup.py сделать полную резервную копию репозитория, пока он жив как описано в этом разделе из свободно доступных Контроль версий с помощью Subversion который обычно считается рекомендуемым к чтению. Это не будет подходить непосредственно для вашего удаленного резервного копирования, так как это приведет к тому, что полное репо будет каждый раз отправляться по линии, но вы можете сделать резервную копию во временной локальной области и выполнить rsync (или что-то еще) на основе этого, а не живого репозитория.
Если вы работаете в Linux и используете LVM для разбиения диска, вы можете использовать средство создания моментальных снимков LVM для выполнения аналогичных действий, описанных в варианте 1. См. Вот и Вот например, документация по технике. Это означает прекращение доступа к службе SNV на короткое время, на время, необходимое для создания моментального снимка, но это почти мгновенно, поэтому вероятность возникновения проблемы гораздо меньше, чем необходимость останавливать его для всей операции резервного копирования. .
Используйте инкрементные резервные копии живого репозитория, также упомянутые в приведенной выше книге SVN.
Техника LVM будет быстрее, чем hot-backup.py-then-sync, но он недоступен для вас без дополнительной работы и обучения, если вы уже не используете LVM и не знакомы с ним. Его преимущества в том, что он почти наверняка будет значительно быстрее и будет использовать меньше дискового пространства (хотя в наши дни дисковое пространство доступно довольно дешево). Снимки LVM действительно влияют на производительность записи, пока они присутствуют, но разница вряд ли будет заметна, если только ваш репозиторий не очень очень занято, и производительность все равно вернется к норме в конце резервного копирования, когда вы удалите моментальный снимок.
В hot-backup.py имеет то преимущество, что дает вам локальную резервную копию, если у вас ее еще нет - если вы храните версию «горячей копии» на другом компьютере, вы можете восстановить ее гораздо быстрее, чем вы можете восстановить удаленную копию, если основная машина умирает в случае, если не влияет на другой (например, сбой контроллера диска). Также, вероятно, будет проще реализовать, если вы уже не используете LVM и не знакомы с ним.
Инкрементное резервное копирование будет быстрее, чем оба этих метода, но менее просто, чем горячее копирование-затем-синхронизация, и восстановление после полной аварии потенциально более сложно, если вы не используете инкрементные резервные копии для создания полной копии репо на другом конце (а не просто сохранение дополнительной информации). В любом случае рекомендуется перестроить репозиторий на другом конце, поскольку это способ проверить, действительно ли ваша резервная копия действительна - даже с помощью других методов вы должны регулярно проверять свои резервные копии (мантра: резервная копия не является хорошей резервной копией, если она не был протестирован).
В итоге, rsync идеально подходит для резервного копирования репозитория svn (как и многие другие методы, но я большой поклонник rsync в большинстве случаев я сам) до тех пор, пока вы не создаете резервную копию репозитория, который в настоящее время активен - вам необходимо остановить службу или выполнить резервное копирование из какой-либо формы моментального снимка.
Как насчет svnsync (часть svn) на другой сервер, на котором также работает svn? В качестве транспорта вы можете использовать ssh + svn.
Непосредственное копирование живого репозитория svn - плохая идея.
Вы можете заглянуть в svnadmin dump --incremental в папку и rsync, что. Таким образом, вам нужно будет передавать только приращения.
Альтернативой является svnadmin hotcopy который делает идентичную копию живого репо, и вы rsync это.
Вы можете создать резервную копию активного репозитория SVN, также с помощью rsync, при условии, что:
Также нет смысла копировать содержимое подкаталога transaction /, поскольку текущая транзакция не может быть надежно скопирована.
Репозиторий, скопированный таким образом, будет согласованным и будет содержать данные до последнего коммита перед копированием файла db / current.