Как GitLab гарантирует, что сгенерированный архив резервных копий воплощает чистое состояние приложения?

Когда вы просите работающий экземпляр GitLab создать полный архив резервных копий с gitlab-rake gitlab:backup:create команда:

• Делает ли GitLab что-нибудь, чтобы заморозить состояние приложения?
• Есть ли риск получить технически исправную резервную копию, содержащую несогласованное состояние?

В деталях:

• Что происходит, когда новые коммиты отправляются во время создания резервной копии?
• Вообще говоря, если во время резервного копирования инициируются какие-либо изменения, что может случиться?
• Есть ли какой-нибудь кеш, который ставит в очередь изменения для применения к базе данных или для записи в файлы / репозитории?

На данный момент я понятия не имею, что происходит, когда вы архивируете изменяемый репозиторий или когда создается резервная копия базы данных, в которой выполняются транзакции?

Я прочитал сегодня резервный код GitLab gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backup но не нашел намеков на свои вопросы. Я не пишу код на Ruby, поэтому мне это не помогает ...

GitLab просто запускает tar команда для файлов для резервного копирования.

В документации GitLab docs.gitlab.com/ee/raketasks/backup_restore.html#backup-strategy-option утверждается, что:

Когда данные изменяются во время чтения tar, может произойти изменение файла ошибки по мере его чтения, что приведет к сбою процесса резервного копирования. Для борьбы с этим в 8.17 представлена ​​новая стратегия резервного копирования, называемая копированием. Стратегия копирует файлы данных во временное расположение перед вызовом tar и gzip, избегая ошибки.

В STRATEGY=copy аргумент делает gitlab-rake gitlab:backup:create запустить rsync -a команда для копирования всех файлов перед созданием архива с tar.

В моем понимании документации сказано, что при использовании copy стратегия GitLab никогда не создаст технически поврежденный архив и никогда не потерпит неудачу в его создании. Я предполагаю, что эта стратегия гарантирует, что сгенерированный архив можно восстановить, но как насчет состояния согласованности данных?

Можем ли мы убедиться, что архив резервных копий воплощает в себе согласованное / чистое состояние моментального снимка экземпляра GitLab?

Я не могу найти никакой информации в документации по этому поводу.

Я хочу делать резервную копию GitLab без перебоев.

Я знаю, что могу остановить GitLab на несколько секунд и сделать снимок тома или файловой системы LVM вместо использования встроенного механизма резервного копирования, но я не хочу прерывать работу GitLab.

Вы можете запустить резервную копию GitLab, прервав все службы, кроме postgresql one, поэтому никакие изменения не могут произойти при резервном копировании с помощью встроенного механизма GitLab, но все же вы должны заблокировать службу для своих пользователей на некоторое время.

Бонус: мои вопросы относятся также к моментальному снимку тома или файловой системы LVM!