Когда вы просите работающий экземпляр GitLab создать полный архив резервной копии с помощью gitlab-rake gitlab:backup:createкоманды:
- Выполняет ли GitLab какие-либо действия для заморозки состояния приложения?
- Существует ли риск создания технически рабочей резервной копии, которая будет содержать несогласованное состояние?
В деталях:
- Что происходит, когда новые коммиты отправляются во время создания резервной копии?
- Вообще говоря, что может произойти, если во время резервного копирования будут инициированы какие-либо изменения?
- Есть ли кэш, который ставит изменения в очередь для применения к базе данных или записи в файлы/репозитории?
На данный момент я понятия не имею, что происходит при архивации изменяемого репозитория или при создании резервной копии базы данных, в которой выполняются транзакции?
Сегодня я прочитал резервный код GitLab.gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backupно не смог найти ни одного намека на свои вопросы.Я не пишу код на Ruby, так что это мне не поможет...
GitLab просто запускает tarкоманду для файлов, которые нужно резервировать.
В документации GitLabdocs.gitlab.com/ee/raketasks/backup_restore.html#backup-strategy-optionутверждается, что:
Если данные изменяются во время чтения tar, может возникнуть ошибка file changed while we read, что приведет к сбою процесса резервного копирования. Чтобы бороться с этим, в версии 8.17 представлена новая стратегия резервного копирования, называемая copy. Стратегия копирует файлы данных во временное местоположение перед вызовом tar и gzip, избегая ошибки.
Аргумент STRATEGY=copyзаставляет gitlab-rake gitlab:backup:createзапустить rsync -aкоманду копирования всех файлов перед созданием архива с расширением tar.
Насколько я понимаю, в документации указано, что при использовании copyстратегии GitLab никогда не создаст технически поврежденный архив и никогда не потерпит неудачу при его создании. Я предполагаю, что эта стратегия гарантирует, что сгенерированный архив можно восстановить, но как насчет состояния согласованности данных?
Можем ли мы гарантировать, что архив резервных копий содержит согласованное/чистое состояние снимка экземпляра GitLab?
Я не могу найти никакой информации в документации по этому поводу.
Я хочу сделать резервную копию GitLab без прерывания работы.
Я знаю, что могу остановить GitLab на несколько секунд и сделать снимок тома LVM или файловой системы вместо использования интегрированного механизма резервного копирования, но я не хочу прерывать работу GitLab.
Вы можете запустить резервное копирование GitLab, прервав все службы, кроме postgresqlодной, чтобы при резервном копировании не произошло никаких изменений с помощью интегрированного механизма GitLab, но вам все равно придется на некоторое время отключить службу для своих пользователей.
Бонус: мои вопросы актуальны также для создания снимков тома LVM или файловой системы!
решение1
Есть много вопросов о последовательном резервном копировании Gitlab, но я не нашел хорошего ответа.
Некоторые из вопросов:
- https://stackoverflow.com/questions/24066283/how-to-make-a-consistent-gitlab-backup
- https://stackoverflow.com/questions/15825735/gitlab-is-the-backup-rake-task-atomic
Я могу процитировать тебя@SørenLøvborgответ, который кажется правильным:
Сами репозитории резервируются с помощью
git bundle, поэтому они также должны быть безопасными. Загрузки — это простые файлы и однократная запись, поэтому здесь тоже не должно быть проблем. База данных может быть не идеально синхронизирована с репозиториями и файлами, но не так, чтобы это приводило к потере данных. В целом, кажется совершенно безопасным делать резервную копию во время работы GitLab, даже если она не атомарная.
Редактировать:Вы уже получили официальный ответ отКоманда Gitlab.