
Комментарии 2
Первый вывод тут не технический должен быть — надо настраивать бюджеты и алерты на них.
Ваш сценарий запуска бекапов на нескольких серверах, а prune еще на одном может привести к неожиданным последствиям.
И практически гарантированно будет приводить к зависающим локам. Потерялась связь во время бекапа - получили вечный shared лок, эксклюзивная блокировка не может быть захвачена, очистка не работает.
В целом использовать restic в распределенной конфигурации стоит только если вы действительно разобрались как работает блокировка.
Я вот, сознаюсь, к определенному моменту неразобрался и поплатился… правда только временем на проверку и восстановление 15 Tb репозитория. Но происходило это с существенными приседаниями, ведь проверка и восстановление тоже делаются эксклюзивно.
В распределенной системе с restic приходится делать restic unlock перед каждым запуском. Потому что как уже писал, бекапы иногда не завершаются корректно из-за факторов внешней среды и прочей энтропии. А когда инстансов большие десятки, замучаешься это делать руками.
Ключевое условие безопасного использования unlock: сделать так чтобы на всех инстансах (хостах/vm/контейнерах) где запускаются restic был уникальный hostname в пределах всего репозитория.
Что произошло у меня:
Я люблю порядок и в определенный момент на машине делающей prune я поправил hostname в контейнере restic с дефолтного hex на restic. Как можно догадаться, на хосте запускающем бекап “порядок” (hosname restic) я навел еще раньше.
В определенный момент запустился backup и prune одновременно (кто там был первый и второй уже не помню, да это и не важно).
Как отработал restic:
restic пытается сделать unlock
смотрит на hostname. Если hostname не совпадает с информацией из файла блокировки, то он не снимает блокировку пока она не устареет. Репозиторий в безопасности.
если hostname совпадает, то он смотрит на pid процесса из файла блокировки. Если он не находит такого процесса в текущем pid namespace, то он МГНОВЕННО СНИМАЕТ БЛОКИРОВКУ ИГНОРИРУЮ СЧЕТЧИК STALE !!! (Это поведения воспроизвел на стенде после инцидента, чтобы понять его причину.)
Таким образом один из моих инстансов restic увидел что он запущен на хосте restic совпадающем с хостом из файла блокировки (но как сказано выше, это был совершенно другой хост), затем он не обнаружил процесса restic с указанным в блокировке pid и радостно её снял! Репозиторий повредился.
После исправления ошибки с hostname уже пол года не было проблем.
Так же я не подстраиваю внучную время выполнения бекапов и очисток (потому что на практике эти времена замучаешься согласовывать в меняющихся системах), настраиваю длительное (часы) ожидание освобождения блокировки.
С правильно сконфигурированном окружении все работает самостоятельно.
Должен был платить за объектное хранилище 25 рублей, которые превратились в 42000 рублей