Как мы снизили время создания бэкапов Git с 48 часов до 41 минуты

[nin-jin]

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

[M_AJ]

Так вроде общеизвестно, что Торвальдс написал первую версию Git меньше чем за неделю.

[vadimr]

Не проще бэкапить диск виртуальной машины git? Кстати на файловой системе с cow это работает мгновенно.

[BadNickname]

Cнапшоты cow - это не бэкапы.

[vadimr]

Снапшоты – конечно, не бэкапы, но мгновенно скопированный файл с образом диска можно затем бэкапить в своё удовольствие.

virsh suspend git
cp --reflink /vm/git-disk.raw /vm/tmp/git-disk.raw
virsh resume git
tar -cvf - /vm/tmp/git-disk.raw > /dev/st0
rm /vm/tmp/git-disk.raw

Примерно так.

Ну если очень хочется, то можно shutdown делать.

[13werwolf13]

тогда уж `btrfs send | btrfs recive` ну или zfs кому как больше нравится, в случае проблем с основным сервером с такого "бекапа" можно загрузиться сразу а не долго восстанавливать.

[zatorax]

Плюс за zfs. Читаю и вижу сильных программистов но очень слабых админов

[BadNickname]

Админство вымирает как явление, увы.

[navion]

Простой сервиса без гарантии консистентности и без возможности развернуть бекап на другом инстансе.

[vadimr]

Бекап в данном случае – это виртуальная машина, как же без гарантии? Простой составляет десяток секунд.

Авторы, со своей стороны, предлагают простой, исчисляемый часами.

[BadNickname]

Ох, давайте не будем погружаться в дебри дикой дичи.

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

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

[vadimr]

Битая база данных гораздо скорее приведёт к тыкве вместо логического бэкапа.

[BadNickname]

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

[vadimr]

Если удастся узнать. А не так, что молча сделается пустой или полупустой бекап.

Конечно, по-хорошему надо разворачивать обратно и тестировать, но...

[falcon4fun]

Про application aware бэкапы вы видимо не слышали, да? :)

Ну это раз. Два: диск успешно пристегивается к любой виртуалке или вся ВМка развворачивается в том же Виме методом Instant Recovery. Проверить работоспособность ВМки - примерно пару минут, не рекаверя ее физически :) Про всякие SureBackup и прочие штуки я уж промолчу.

Как в целом и про то, что если ц вас там кривые метаданные и битое фс дерево - это уже ваши проблемы: не стоит дергать из розетки ни вмку, ни серв, ни айскази/фц сторадж. Вопрос битой ФС не решается 3-2-1 правилом как бэ в целом. Задача другая :DDD

Ах да. Пре-бэкап и пост-бэкап скрипты забанили что ли уже? Хоть обпроверяй все возможные статусы всего и вся.

[BadNickname]

не стоит дергать из розетки ни вмку

Мне кажется что снапшот с диска живой виртуалки очень близок к выдёргиванию вилки из розетки. Может я слишком стар, туп и чего-то не знаю.

[vadimr]

Ну сделайте ей shutdown, будет неживая.

А так вообще полезно использовать транзакционные ФС и отдельно хранить разделы системы и данных.

[falcon4fun]

Есть crash-consistent бэкап. Есть application aware бэкап.

https://bp.veeam.com/security/Design-and-implementation/Application_Aware_Processing.html

https://www.nakivo.com/blog/crash-consistent-vs-application-consistent-backup/

З.Ы. Ну и оффтопа немного: один хрен, бэкапя базы, нужен application aware. Трункейтить логи то как минимум нужно из всех баз :D

[navion]

У авторов даже до фикса бекап происходил онлайн, но с RPO в 48 часов из-за длительности процесса. Плюс у них работает репликация через кластер gitaly и бекап нужен на случай удаления базы стажером повреждения логической структуры базы.

[vadimr]

В статье написано совсем другое (раздел "Резервное копирование в крупных масштабах").

[navion]

Можно цитату? Я не вижу там фразы про недоступность сервиса пользователям.

[vadimr]

А как вы интерпретируете это?

• Окна резервного копирования: для команд, чьи рабочие процессы происходят в режиме 24/7, такие длительные операции усложняют поиск подходящих окон технического обслуживания.

[navion]

Админам трудно найти окно для обслуживания репозитория, так как всё время работает бекап.

[vadimr]

А админы – не пользователи?

[navion]

Не в контексте статьи и пользоваться репозиторием (пулить, пушить) бекап не мешает.

[vadimr]

Да какая разница, пушить там или не пушить? У них проблема в том, что время бекапа не позволяет выполнять какие-то операции над репозиторием, и они это время простоя сократили своими усилиями с 48 часов до 41 минуты. Я привёл для примера команды, которыми это время можно сократить до нескольких секунд.

Если уж очень неймётся, кстати, то уже снапшот можно логически бекапить средствами гита.

[BadNickname]

Вот смотрю я на эту конструкцию, и мне сразу вспоминается анекдот про взвод солдат, танк, гусеницу и фею.

[aamonster]

Снэпшоты прекрасны для консистентного бэкапа без остановки мира, факт.

[AlexGluck]

Некоторый софт такого не позволяет(

[aamonster]

Ну да, но если можно остановить хоть на секунду для создания снэпшота – этого хватит. Куда лучше, чем ждать, пока всё сбэкапится.

[OldFisher]

Не сочтите занудством, но переход от O(N^2) даже к O(1) не станет экспоненциальным снижением сложности.

[Serge3leo]

Так и да, если сложность от N. Но если размер git репозитория M, а N - размерность промежуточной задачи (скажем, число ссылок), то экспоненциальное снижение сложности от M, почему нет? 😉

[OldFisher]

Потому что если в общей задаче сложность экспоненциальная, деление её на полином экспоненту никуда не денет.

[mpa4b]

Очевидно же, они перешли к O(N^2 * 2^(-N))! Новое слово в computer science! :)

[domix32]

Убрали дедупликаю по строкам, добавили проверку в сете. Отличная история для accidentally quadratic

[VADemon]

"Скажи мне, что ты ешь, и я скажу кто ты."

Видя код, который весело использует for-for и .indexOf внутри for -- для меня это проблема UX и отчасти документации. Вот тебе два топора на выбор: с виду хорошие, но у одного черенок треснутый и надломлется при любом ударе.

Почему? Потому что в данном случае использовать for-for было просто. А для hashmap надо:

1. Понять масштабирование

2. Подключить библиотеку (если нет, то можно ли?) Коммит от 2009 г.

3. Прочитать API и сделать

Умные там слова, когнитивная нагрузка и т.д. В этом аспекте Lua сделана удачно: таблицы одновременно массивы и hashmap, в зависимости от пользования ими (не без минусов). Но эта простота заставляет пользоваться O(1) lookups всякий раз, когда с ними удобнее. Одновременно и быстрее.

С этой стороны: не выставлять коленострелы в публичное API. А выставленные надо с пометкой на сложность обработки и масштабирование описать в доке.

[aamonster]

функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования

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

[VADemon]

https://gitlab.com/gitlab-org/git/-/issues/488

Понадобилось 15 лет. И нет, не полезли в кишки изучать "чего это у нас бэкап двое суток гит делает", а поняли только по наводке, когда в целом начали в кишках гита копаться. Потом героически починили.

We are not currently using Gitaly's repository backups solution on gitlab.com due to scalability issues with large GitLab instances.

Нет, несмотря на тон, комментарий мой позитивный. Но столько лет не задаваться вопросом "почему"? Или не давать на это времени.

[KvanTTT]

Люблю находить и внедрять подобные оптимизации. К сожалению, это далеко не всегда возможно и приходится довольствоваться ускорением хотя бы на пару процентов (например, в компиляторе Kotlin).