Мы использовали рабочую резервную копию в 2 часа ночи через crontab для gitlab. Был начат проект по автоматизации всего процесса резервного копирования / восстановления, и мы в основном там. Одной из проблем, с которой мы постоянно сталкиваемся, является то, что в последнее время обновления омнибуса довольно часты, и поскольку резервное копирование, а затем автоматическое обновление происходит в шахматном порядке, наши резервные копии отстают на 24 часа, и поэтому мы получаем ошибки несоответствия версий при восстановлении на день сразу после обновления.
Более сложное решение - встроить проверку версии в наш скрипт резервного копирования / восстановления и отложить на 24 часа, но это не кажется идеальным, если не усложнять мониторинг того, как долго работа откладывается по сравнению с установленным расписанием один раз за неделю или каждую вторую субботу месяца для тестов.
Самое простое решение, которое, как я думал, будет лучшим путем, - это просто увеличить частоту резервного копирования gitlab и использовать опцию STRATEGY = copy подробно здесь . Тем не менее, после изменения cron для отображения расписания резервного копирования один раз каждые 6 часов я не вижу фактического увеличения количества резервных копий.
Есть ли ограничение в gitlab относительно того, как часто можно запускать резервное копирование?
Старый Крон (один раз в день в 2 часа ночи):
- 0 2 * * * / opt / gitlab / bin / gitlab-rake gitlab: резервное копирование: создать CRON = 1 && /root/datadog_success_push.sh
Новый Cron (работает не так, как ожидалось - «В 30 минут каждый шестой час с 0 до 23»)
- 30 0/6 * * * / opt / gitlab / bin / gitlab-rake gitlab: резервное копирование: создать STRATEGY = copy CRON = 1 && /root/datadog_success_push.sh