Если файл настроек машины повредился: где лежит старая версия

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

Что произойдёт, если этот файл повредится, где лежит старая версия и на что смотреть, если вы правите его вручную?

Сначала хорошая новость: повреждённый файл затрагивает только свою машину

У каждой машины свой отдельный файл. Опечатка в одном не роняет панель, не останавливает остальные машины, не затрагивает сервер.

Симптом обычно такой: эта машина перестаёт появляться в списке или отказывается запускаться. Всё остальное продолжает работать как обычно. Знайте это до того, как впадёте в панику, потому что первое впечатление обычно «система сломалась», а это не так.

Как он повреждается

Правка вручную. Самая частая причина. Запятая, кавычка, неверно написанное имя ключа.

Правка при работающей машине. Даже если файл не повредится, произойдёт нечто неожиданное: ваше изменение вступит в силу при следующем запуске, а вы будете считать, что оно подействовало сразу. Либо система сама обновит файл и перезапишет написанное вами.

Запись, прерванная на середине. Пропало питание, заполнился диск, процесс убит. Файл остался наполовину.

Третий случай самый коварный и заслуживает отдельного заголовка.

Наполовину записанный файл хуже, чем отсутствие файла

Если файла нет, это очевидное состояние. Программа посмотрит, не найдёт, скажет «нет» и продолжит со значениями по умолчанию. Такое состояние обрабатывается легко.

С наполовину записанным файлом не так. Он выглядит как файл. Программа проверяет, что он есть, находит его, доверяет ему и пытается работать с неполными данными внутри. Беда всплывает не в момент чтения, а после.

Решение простое и годится для любой записи: не перезаписывайте файл напрямую. Сначала запишите под временным именем, затем переместите на место. Перемещение либо происходит целиком, либо не происходит вовсе; промежуточного состояния нет. Тогда содержимое файла либо старое, либо новое, но никогда не половина.

Если вы пишете сценарий, который трогает настройки Proxmox, эта единственная привычка стоит больше, чем весь остальной код, который вы напишете.

Старая версия лежит в двух местах

Внутри резервной копии. Копия машины несёт не только диск, но и файл настроек в том виде, в каком он был на тот момент. При восстановлении копии настройки возвращаются вместе с ней. Большинство думает о копии только как о данных и никогда не замечает, что держит в руках путь восстановления.

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

Но эти двое не заменяют друг друга, и разница важна: запись снимка лежит внутри того же файла. Если сам файл уничтожен, эта запись уходит вместе с ним. Резервная копия лежит в другом месте. Настоящий путь восстановления это копия; снимок лишь точка, к которой вы, возможно, захотите вернуться.

Если собираетесь править вручную

Сначала остановите машину.

Сделайте копию перед правкой и положите эту копию в другое место. Место, где живут настройки, создавалось для настроек; не оставляйте там резервные копии.

После изменения запустите машину и убедитесь, что она действительно работает. Не откладывайте до следующей перезагрузки и не забывайте; забытая незаконченная правка возвращается спустя месяцы неисправностью, которую никто ни с чем не связывает.

Общее правило: «файла нет» и «файл повреждён» это разные состояния

Путь восстановления в программе обычно пишут, держа в голове состояние «файла нет», потому что оно приходит на ум первым. Состояние «файл есть, но его содержимое повреждено» на ум не приходит.

А между тем по-настоящему опасно именно второе, как раз потому, что о нём не подумали. И выглядят они по-разному: отсутствующий файл несёт признак, повреждённое содержимое нет.

Что делает Atlas

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

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

Причина была ровно в правиле выше: ветка восстановления писалась под состояние «файла нет». Ошибка повреждённого содержимого такого признака не несёт, поэтому ветка её не ловила и ошибка уходила наверх.

Отложенные копии никогда не убирались. Каждое повреждение оставляло постоянный файл, и предела их числу не было. Измерено на работающей машине: две из них лежали там месяцами. Это то же правило, что записано в других статьях этой вики: у всего, что пишет, должен быть потолок.

Два откладывания в один и тот же момент давали одно имя, и вторая копия перезаписывала первую, так что одна повреждённая версия исчезала беззвучно.

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