Backup GitLab, який не можна відновити, є просто великим файлом

Більшість self-hosted інстансів GitLab мають нічне завдання резервного копіювання, і більшість людей, які його налаштували, ніколи з нього не відновлювалися. Це проблема, бо архів, який створює GitLab, навмисно неповний. Відновіть його на свіжому сервері без файлів, які він пропускає, і ваші репозиторії повернуться, тоді як ваші змінні CI, налаштування двофакторної автентифікації і реєстрації runners перетворяться на нечитабельні дані. Ось що містить повний backup GitLab, як переміщувати його, не послаблюючи безпеку, і як довести, що він працює.

Що завдання backup включає, а що пропускає

На пакетній (Omnibus) інсталяції завдання backup:

sudo gitlab-backup create STRATEGY=copy

Воно пише один tar-архів у каталог backup, зазвичай /var/opt/gitlab/backups. Цей архів містить базу даних, Git-репозиторії, завантаження, об’єкти LFS, артефакти CI, pages, пакети і, якщо увімкнено, container registry. STRATEGY=copy копіює дані перед архівуванням, що уникає помилок, коли файли змінюються під час довгого backup на завантаженому інстансі.

Чого він не містить, навмисно:

• /etc/gitlab/gitlab-secrets.json, ключі, які використовуються для шифрування чутливих стовпців у базі даних.
• /etc/gitlab/gitlab.rb, ваша конфігурація.
• Сертифікати й ключі TLS під /etc/gitlab/ssl, якщо ви тримаєте їх там.
• Хостові ключі SSH в /etc/ssh, які клієнти ваших розробників уже записали.

GitLab пропускає їх, щоб один викрадений архів не містив і зашифровані дані, і ключ, який їх розшифровує. Це здорове міркування, і воно покладає роботу з їх окремого резервного копіювання на вас.

Чому файл secrets такий важливий

Змінні CI/CD, токени реєстрації runners, seeds двофакторної автентифікації, паролі інтеграцій і кілька інших значень шифруються в базі даних ключами з gitlab-secrets.json. Відновіть базу даних без відповідного файлу secrets, і GitLab запуститься, репозиторії будуть на місці, а потім pipelines провалюються, користувачі з двофакторною автентифікацією не можуть увійти, а runners треба реєструвати знову.

Робіть резервну копію каталогу конфігурації як окремого артефакту:

sudo gitlab-ctl backup-etc --backup-path /var/opt/gitlab/config-backups

Це створює tar каталогу /etc/gitlab, включно з файлом secrets. Тримайте його в іншому місці, ніж архів даних, під суворішим доступом, і тримайте відповідні пари разом у вашій політиці зберігання. Архів даних від понеділка і файл secrets від четверга можуть не узгоджуватися, якщо між ними щось ротували.

Для контейнерних інсталяцій команди ті самі, виконуються всередині контейнера, а /etc/gitlab є тим томом, який ви на нього змапили. Переконайтеся, що цей том є частиною того, що ви резервуєте; легко зробити backup лише тому даних.

Забирайте backup, а не штовхайте його

Звичайна схема є cron-завданням на сервері GitLab, яке копіює архів на хост backup. Це означає, що сервер GitLab тримає облікові дані, які можуть писати у ваші резервні копії. Якщо GitLab скомпрометовано, скомпрометовано і спосіб дістатися резервних копій та видалити їх.

Розверніть напрямок. Хост backup підключається до GitLab і забирає файли. GitLab не тримає облікових даних для хоста backup і не має мережевого шляху до нього. На боці GitLab обмежте те, що може робити ключ хоста backup, forced command в authorized_keys:

command="/usr/local/bin/backup-send",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... backup-puller

де backup-send є маленьким скриптом, який не робить нічого, крім потокової передачі найновішого архіву даних і відповідного йому архіву конфігурації. На хості backup завдання забирає обидва, перевіряє їхні розміри й контрольні суми і сповіщає, якщо якогось бракує або він старіший за очікуване.

Потім забезпечте напрямок на firewall: хост backup може відкривати з’єднання до GitLab, ніщо в мережі GitLab не може відкривати з’єднання до хоста backup.

Правила відновлення, які варто знати до того, як вони знадобляться

Backup GitLab відновлюється лише на ту саму версію і редакцію GitLab, яка його створила. Запишіть версію в назву архіву або в супутній файл під час backup:

sudo gitlab-rake gitlab:env:info > gitlab-env-$(date +%F).txt

Якщо ви втратите сервер, а єдиний інсталятор, який знайдете, буде новішим, ви спершу встановите стару версію, відновитеся, а потім оновитеся підтримуваним шляхом. Знаючи це заздалегідь, ви перетворюєте довгу ніч на заплановану процедуру.

Саме відновлення, на свіжій інсталяції відповідної версії:

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# put gitlab-secrets.json and gitlab.rb back into /etc/gitlab first
sudo gitlab-ctl reconfigure
sudo gitlab-backup restore BACKUP=<archive-id>
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true
sudo gitlab-rake gitlab:doctor:secrets

Остання команда є тією, що має значення. gitlab:doctor:secrets проходить зашифрованими стовпцями і повідомляє про будь-які, які не може розшифрувати. Якщо вона повідомляє про помилки, ваш файл secrets і ваш архів даних не належать одне одному.

Доводьте за розкладом

Відновлення, яке ви не протестували, є надією. Зробіть його рутиною:

• Збудуйте одноразову VM в ізольованій мережі без маршруту до production.
• Встановіть версію GitLab, записану разом із backup.
• Відновіть найновішу пару конфігурації та даних.
• Запустіть gitlab:check і gitlab:doctor:secrets.
• Клонуйте відомий репозиторій, порівняйте hash його останнього коміту з production і відкрийте сторінку змінних CI якогось проєкту.
• Запишіть результат і час, який це зайняло, потім знищіть VM.

Заміряйте й час. Тривалість відновлення є вашим справжнім часом відновлення, і на великому інстансі вона зазвичай довша, ніж люди гадають.

Друга, незалежна копія коду

Повний backup захищає весь застосунок. Для самих репозиторіїв просте дзеркало дає вам другу копію, яка взагалі не залежить від інструментарію GitLab:

git clone --mirror git@gitlab.example.com:group/project.git
git -C project.git remote update --prune

Запускайте це з боку backup для репозиторіїв, які ви не можете собі дозволити втратити. Воно не відновить issues або merge requests, але означає, що історія вашого коду переживе навіть архів backup, який ви не можете прочитати.

Коротка версія

• gitlab-backup create є половиною backup. gitlab-ctl backup-etc є другою половиною.
• Тримайте secrets і дані відповідними парами, збереженими окремо, із суворішим доступом до secrets.
• Сторона backup тягне; GitLab не має шляху до власних резервних копій.
• Записуйте версію GitLab з кожним архівом.
• Відновлюйте за розкладом і щоразу запускайте gitlab:doctor:secrets.

Саме так ми захищаємо інстанси GitLab, які експлуатуємо для клієнтів у власних дата-центрах. Якщо ви хочете, щоб ваш власний шлях відновлення перевірили, ми радо допоможемо.

Поговоріть з інженером

Related

Пов’язане: Managed source control на GitLab · Managed офісні документи на Nextcloud