К обсуждениям

restic diff завершается panic: как не спутать сбой команды с повреждением репозитория

Редакция VOne Технологии

Безопасный порядок действий при concurrent map read and map write в restic diff: остановка повторов, проверка блокировки и целостности до любых repair или prune.

Остановите повтор и сохраните контекст

После panic не запускайте ту же команду в цикле и не переходите сразу к операциям изменения репозитория. Сохраните версию restic, backend, идентификаторы двух снимков, фильтр пути и точный текст ошибки без адресов доступа. Официальная документация определяет diff как сравнение содержимого двух снимков и допускает ограничение сравнения отдельными подпапками. Значит, безопасный минимальный повтор возможен только позже и на узкой области, если проверка целостности не выявила проблем. Сам факт аварии read-only команды не является доказательством повреждения данных. Если в это время выполнялись backup, forget, prune или check, сначала дождитесь их штатного завершения и не вмешивайтесь в блокировки.

Проверьте активные процессы до unlock

Сообщение о блокировке после аварии не означает, что lock можно немедленно удалять. Сначала убедитесь на всех машинах, имеющих доступ к репозиторию, что активного процесса restic нет. Руководство по устранению неполадок отмечает: прерванная команда обычно не повреждает репозиторий, но может оставить блокировку, которую после такой проверки снимают вручную. Не используйте unlock, пока другой backup или обслуживание ещё работает. Зафиксируйте время создания блокировки и хост в обезличенном виде. Если принадлежность lock неясна, остановитесь и согласуйте окно обслуживания: параллельное изменение важнее скорости восстановления команды diff.

Начните с check, а не с repair

Официальная диагностика ставит restic check первым шагом при подозрении на проблему репозитория. Обычная проверка исследует структуру и ссылки, а вариант с чтением данных значительно дороже: документация предупреждает, что полное чтение загружает содержимое репозитория. Запланируйте его с учётом объёма и стоимости backend, не запускайте импульсивно на рабочем канале. Команды repair index и другие виды ремонта применяются только к подтверждённому типу повреждения; они не являются лечением panic в diff. До получения результата check нельзя утверждать ни целостность, ни повреждение. Сохраните вывод, предварительно удалив URL, ключи и имена файлов.

Сузьте diff после чистой проверки

Если check завершился без ошибок и блокировок нет, повторите сравнение на одной небольшой подпапке между теми же снимками. Затем, при стабильном результате, увеличивайте область ступенями. Матрица «малый путь или весь снимок × локальный или удалённый backend» помогает определить границу, но меняйте только одну ось. Не выполняйте prune ради ускорения и не создавайте искусственные изменения в резервной копии. Для issue достаточно версии, операционной системы, типа backend, размеров снимков, границы пути и обезличенного стека panic. Критерий остановки — повторный panic на малой области, ошибка check или неясная активная блокировка. В таком случае дальнейшие модификации репозитория опаснее диагностической пользы.

Материал подготовлен редакцией VOne с применением ИИ для порядка безопасных проверок; семантика diff, check и unlock вручную сверена по официальной документации restic.

Источники и проверка

Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.

Ответы

0 опубликовано
Ответов пока нет. Вы можете начать обсуждение.

Ваш ответ

Добавьте свой опыт или уточнение по теме.

Вы публикуете как Аноним Аватар отличает разговоры, но не раскрывает личные данные.

Ответ появится сразу. Не публикуйте личные данные, ключи и приватные ссылки.