Комментарии 11
Ну, для начала, бекап не гита, а гитлаба.
Гитлаб - это же не только кодики, которые под vcs, это и юзеры-логины-пароли-ключи, это переменные для CI, раннеры и дофига чего еще.
Далее, было бы ошибкой предполагать, что при падении gitlab как некоего общего source of truth вы запросто сможете восстановиться без потерь. Напомню, что у Вас и тысяч Ваших коллег есть данные (кстати, потенциально неактуальные) только по тем репам, которые вы пуллили давеча. По остальным репам информации у вас нет.
При этом кто-то из нескольких тысяч Ваших коллег мог запросто запушить последние изменения и грохнуть локальную репку, а еще некоторые могли внести изменения прямо через webide гитлаба.
И даже если (теоретически) можно в итоге поскрести по сусекам и собрать хоть какое-то общее хранилище кода - времени это займет столько, что Вы триста тысяч раз пожалеете, что не бекапили гитлаб.
Децентрализация гита - она только в головах. На практике дело обстоит намного хуже.
Если я правильно понимаю механизм LFS, то в гите хранятся только хеши файлов, сами файлы хранятся на сервере, у разработчиков на компе есть файлы только от текущего комита, всех остальных нету, по типу как в SVN, где твой локальный репозиторий отражает только выбранную ревизию, а не весь репозиторий целиком.
Статья, конечно, забавная, прям начиная с фразы "по историческим причинам".
Ох, сколько ада в этом мире оправдано этими словами. Приходишь в новую компанию, видишь полную хрень, спрашиваешь: почему так? По историческим причинам!
Потом растешь до большого начальника, творишь полную хрень в интересах бизнеса (сейчас быстренько накостыляем, а потом сделаем норм). Выводишь на работу новых сотрудников, а они спрашивают, почему так. По историческим причинам, вот почему! ))
---
Детально не читал, но версия гитлаба из статьи и скрипт ротации бекапов явно устарели. Не совсем уверен, зачем он такой, но современные гитлабы как бы самостоятельно умеют ротировать свои бекапы, и даже самостоятельно заливают их на любое внешнее хранилище (например, s3)
Короче, как руководство к действию я бы не стал принимать. Есть способы намного проще.
Из-за огромного количества багов с LFS и прочими причудами вылезающими с новыми версиями(добило gitlab.com/gitlab-org/gitlab/-/issues/271576) — избавились от LFS вообще.
По опыту: гитлаб пытается в энтерпрайз, но сам — коленная поделка, собранная из говна и палок.
Вот из-за этого https://gitlab.com/gitlab-org/gitlab/-/issues/23625 мы перенесли все, что работает с LFS, на GitHub
Как мы переезжали на новую версию GitLab и внедряли LFS. А потом чинили бэкапы