Когда они спрашивают поддержку Gitlab о том, как сделать резервную копию 3 ТБ на локальном Gitlab, они отвечают, используя наш инструмент который производит tarball.
Мне это кажется неправильным на всех уровнях. Этот tarball содержит дамп postgres, образы докеров, данные репо, конфигурацию GIT LFS и т. Д. И т. Д. Резервное копирование ТБ статических данных вместе с КБ очень динамичных данных не работает правильно. И затем возникает проблема, что мы хотим делать резервную копию каждый час.
Вопрос
Мне бы очень хотелось узнать от других, как они это делают, чтобы получить надежную резервную копию.
ZFS на Linux меня устроит, если это будет частью решения.
Я бы пересмотрел то, что вы копируете, и, возможно, использовал бы "многопутевый" подход. Например, вы можете сделать резервную копию репозиториев Git, постоянно выполняя запросы Git на серверах резервного копирования. Это скопирует только diff и оставит вам вторую копию всех репозиториев Git. Предположительно вы можете обнаружить новые репозитории с помощью API.
И используйте "встроенные" процедуры резервного копирования для резервного копирования проблем и т. Д. Я сомневаюсь, что 3 ТБ исходит из этой части, поэтому вы сможете делать резервные копии очень часто с очень небольшими затратами. Вы также можете настроить базу данных PostgreSQL с теплым резервом с репликацией.
Возможно, ваши 3 ТБ получены из образов контейнеров в реестре Docker. Вам нужно их поддержать? Если да, то для этого может быть лучший подход.
В принципе, я бы порекомендовал посмотреть, что именно составляет вашу резервную копию, и резервные копии данных в различных частях.
Даже у инструмента резервного копирования от GitLab есть опции для включения / исключения определенных частей системы, таких как реестр Docker.
В течение такого короткого времени между резервными копиями (1 час) лучше всего полагаться на моментальный снимок на уровне файловой системы. и send/recv служба поддержки.
При использовании ZoL это не проблема в вашей среде, я бы настоятельно рекомендовал его использовать. ZFS - очень надежная файловая система, и вам действительно понравятся все дополнительные функции (например, сжатие), которые она предлагает. В сочетании с sanoid/syncoid, он может обеспечить очень надежную стратегию резервного копирования. Главный минус в том, что он не входит в состав основного ядра, поэтому его нужно устанавливать / обновлять отдельно.
В качестве альтернативы, если вам действительно нужно ограничиться вещами, включенными в mainline, вы можете использовать BTRFS. Но обязательно поймите его (многие) недостатки и лаваш.
Наконец, альтернативное решение - использовать lvmthin делать регулярные резервные копии (например: с snapper), полагаясь на сторонние инструменты (например: bdsync, blocksyncи т. д.) только для копирования / отправки дельт.
Другой подход - иметь два реплицированные машины (через DRBD) где вы делаете независимые снимки через lvmthin.