Как масштабировать резервную копию Gitlab?

Когда вы спрашиваете у Gitlab о том, как сделать резервную копию объемом 3 ТБ на локальном Gitlab, они отвечают, используя наш инструмент, который создает tarball.

Это просто неправильно для меня на всех уровнях. Этот архив содержит дамп postgres, образы докеров, данные репо, GIT LFS и т. Д., Конфигурацию и так далее. Резервное копирование ТБ статических данных вместе с КБ очень динамических данных выглядит неправильно. И затем возникает вопрос, мы хотим делать резервные копии каждый час.

Вопрос

Мне бы очень хотелось узнать от других, как они это делают, чтобы получить последовательную резервную копию.

ZFS на Linux будет хорошо со мной, если это является частью решения.

— Sandra
источник

Почему это не так? Вы полностью сохраняете свой Gitlab, чтобы полностью его восстановить. Я не думаю, что это неправильно. Конечно, он использует гораздо больше места, чем, скажем, инкрементные резервные копии, но ... мне не важно, какой размер резервной копии.

— Леннией

Наличие резервной копии каждый час не является неслыханным делом, но невозможно сделать 3 ТБ менее чем за час с их подходом. И резервное копирование всего за один день будет составлять ~ 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.

— shodanshok
источник

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

— Сандра

Восстановление @Sandra из снимков файловой системы должно выглядеть для postgresql (и любых других правильно написанных баз данных) как общий сценарий «сбоя хоста», запускающий собственную процедуру восстановления (т. Е. Фиксацию в основной базе данных любой частично написанной страницы). Другими словами, вам не нужно переводить postgres в режим только для чтения при создании снимков.

— Шоданшок

Я бы рассмотрел то, что вы резервируете, и, возможно, использовал бы «многопутевой» подход. Например, вы можете сделать резервную копию Git-репозиториев, постоянно выполняя Git Pull на серверах резервного копирования. Это скопировало бы только diff и оставило бы вам вторую копию всех репозиториев Git. Предположительно, вы можете обнаружить новые репозитории с помощью API.

И используйте «встроенные» процедуры резервного копирования для резервного копирования проблем и т. Д. Я сомневаюсь, что 3 ТБ исходит от этой части, поэтому вы сможете делать резервные копии очень часто при очень небольших затратах. Вы также можете настроить базу данных PostgreSQL с горячим резервированием с репликацией.

Возможно, ваш 3TB исходит из образов контейнера в реестре Docker. Вам нужно поддержать это? Если так, то может быть лучший подход именно для этого.

По сути, я бы порекомендовал по-настоящему взглянуть на то, что делает ваше резервное копирование, и резервировать данные в различных частях.

Даже инструмент резервного копирования от GitLab имеет опции для включения / исключения определенных частей системы, таких как реестр Docker.

— ETL
источник

Git Pulls - не идеальная инкрементная резервная копия. git push --forceбудет либо разбивать резервные копии, либо стирать из них историю, в зависимости от того, как это реализовано.

— user371366

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

— charlie_pl

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

— user371366