Як зробити масштабне резервне копіювання Gitlab?

На запит підтримки Gitlab про те, як зробити резервну копію 3TB для тих, хто знаходиться у приміщенні Gitlab, вони відповідають, використовуючи наш інструмент, який створює тарбол.

Це просто здається мені неправильним на всіх рівнях. Цей тарбол містить дамп постгресів, зображення докера, дані репо, GIT LFS та ін. Конфігурацію тощо. Резервне копіювання статичних даних разом із дуже динамічними даними KB не підходить правильно. І тоді виникає питання про те, що ми хочемо робити резервну копію щогодини.

Питання

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

ZFS на Linux зі мною буде добре, якщо це є частиною рішення.

— Сандра
джерело

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

— Ленні

Зберігання резервної копії щогодини не є нечуваним, але неможливо зробити 3TB менше ніж за годину з їх підходом. А резервне копіювання всього за один день складе ~ 100 ТБ, де зміни даних можуть бути лише 10 Мб.

— Сандра

Гаразд, це вже інше питання, не про резервне копіювання взагалі, а про часті резервні копії.

— Ленні

У своїх офіційних документах вони навіть згадують, що їх метод є повільним, і пропонують альтернативи:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

я не можу говорити з досвіду. Але мені, можливо, доведеться незабаром включити щось подібне ...

— Ленні

У Gitlab є параметри файлів конфігурації та резервного копіювання, які дозволять вам виключати розділи або йти так далеко, щоб зберігати зображення та артефакти в магазині об'єктів

— ssube

Відповіді:

За такий короткий час між резервними копіями (1 год) найкраще покластися на знімок та send/recv підтримку на рівні файлової системи .

Якщо використання ZoL не є проблемою у вашому оточенні, я б настійно радив використовувати його. ZFS - це дуже надійна файлова система, і вам дуже сподобаються всі додатки (наприклад: стиснення), які вона пропонує. У поєднанні з sanoid/syncoidцим він може забезпечити дуже сильну стратегію резервного копіювання. Основна перевага полягає в тому, що воно не включено в основне ядро, тому вам потрібно встановити / оновити його окремо.

Крім того, якщо вам дійсно потрібно обмежитися лише включеними в основний матеріал, ви можете використовувати BTRFS. Але обов’язково зрозумійте його (багато) недоліки і лаваш .

Нарешті, альтернативне рішення полягає у використанні lvmthinприймати регулярні резервні копії (наприклад: з snapper), спираючись на інструменти сторонніх виробників (наприклад: bdsync, blocksyncі т.д.) , щоб скопіювати тільки / корабель дельт.

Іншим підходом було б мати дві реплікувані машини (через DRBD), де ви робите незалежні знімки через lvmthin.

— шоданшок
джерело

Що з постгресами? Чи хотіли б зупинити gitlab та postgres на хвилину, щоб можна було зробити константний знімок? В ідеалі було б чудово, якби постгреси могли бути переведені в режим лише для читання під час зйомки.

— Сандра

Відновлення @Sandra з знімків файлової системи повинно здаватися postgresql (та будь-яким іншим належним чином написаним базам даних) як загальний сценарій "аварії з хостом", що запускає власну процедуру відновлення (тобто: привласнення до основної бази даних будь-якої частково написаної сторінки). Іншими словами, вам не потрібно переводити postgres в режим лише для читання під час зйомки.

— shodanshok

Я б переглянув те, що ви створюєте резервну копію, і, можливо, скористаєтесь підходом "багатошляху". Наприклад, ви можете створити резервні копії репозиторіїв Git, постійно працюючи через Git pull на резервних серверах. Це скопіювало б лише diff та залишило вас з другою копією всіх сховищ Git. Імовірно, ви могли виявити нові репости за допомогою API.

І використовуйте "вбудовані" процедури резервного копіювання для резервного копіювання проблем тощо. Я сумніваюся, що 3TB походить саме з цієї частини, щоб ви могли робити резервні копії дуже часто за дуже невеликі витрати. Ви також можете налаштувати базу даних PostgreSQL в режимі очікування з реплікацією.

Можливо, ваш 3TB походить із зображень контейнерів у реєстрі Docker. Чи потрібно їх підтримувати? Якщо так, то може бути кращий підхід саме для цього.

В основному, я б рекомендував по-справжньому подивитися на те, що саме створює резервну копію та резервну копію даних у різних частинах.

Навіть інструмент резервного копіювання від GitLab має варіанти включати / виключати певні частини системи, такі як реєстр Docker.

— ETL
джерело

git pull не є ідеальною додатковою резервною копією. git push --forceабо розбиває резервні копії, або видаляє історію з них, залежно від того, як вона реалізована.

— користувач371366

@ dn3s, тому ви завжди відключаєте git push --force у головному сховищі. Якщо хтось хоче змінити історію, він може зробити власну вилку і прийняти всі ризики, які вона несе.

— charlie_pl

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

— користувач371366