Восстановление и бэкапы#

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

Сначала бэкап — чеклист#

Сними это, прежде чем что-то стирать. Именно они делают каждый последующий шаг обратимым.

Вендорский стек (на уровне файлов, возобновляемый rsync — не сырой dd по WiFi): вендорский ~/klipper как git bundle, ~/printer_data/config, ~/printer_data/build/*.bin, и сборочные конфиги под каждый чип ~/klipper/.config* (полезные затравки, даже несмотря на устаревшие flash-офсеты).
SWD-дамп тулхеда, прежде чем ты его сотрёшь — самый надёжный точный откат для F103:
```
openocd -c "adapter driver cmsis-dap" -c "transport select swd" -c "adapter speed 1000" \
  -f target/stm32f1x.cfg -c "init" -c "halt" \
  -c "dump_image vendor-f103-FULL-flash.bin 0x08000000 0x10000" -c "shutdown"
```
Валидный дамп открывается вменяемой таблицей векторов (начальный SP в RAM 0x2000xxxx, reset-вектор во флеши 0x0800xxxx), а не сплошными 0xFF/0x00.
Полный образ eMMC (модуль в USB-ридере): один dd всего устройства с его SHA256 — единственный бэкап, который захватывает таблицу разделов, boot-раздел и rootfs. Сними его до любых работ с ОС, а не после. См. снятие образа eMMC.

Бэкап-матрица показывает, какой артефакт принадлежит какому слою и как часто он меняется. Тот, что реально теряют, — это конфиг: положи его в git первым.

ОС не грузится#

Мёртвая ОС никогда не трогает MCU — слой 2 переживает слой 3. Так что это пересборка только ОС, и MCU возвращаются ровно такими, какими были:

Есть полный образ eMMC? Восстанови его: один dd обратно через ридер, и ты там же, где был.
Нет образа? Пересобери ОС начисто — с чистого листа с eMMC-ридером, если он есть, или на месте, если нет. Потом восстанови конфиг и переподключись: klippy ready с обоими CAN-UUID — доказательство того, что MCU выжили.

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

Неудачная прошивка MCU#

Тулхед (F103). Восстанавливается по CAN, пока жив его CAN-совместимый Katapult. Если само приложение повреждено и ты снял SWD-дамп, восстанови его по SWD (см. прошивку). У тулхеда нет USB и нет CAN-восстановления, если пропал сам Katapult — поэтому бутстрап делается SWD-один-раз.
Мейнборд (H750). Пока жив Katapult, перешиваешь через USB-Katapult. Только повреждённый загрузчик вынуждает лезть SWD в закопанный хедер мейнборда. Твой откат-из-исходников — это вендор-эквивалентная прошивка, скомпилированная из твоего забэкапленного вендорского ~/klipper под тем же офсетом 0x8020000.
Нет бэкапа и застрял? asnajder/zero-config публикует прошиваемые через ST-LINK вендорские recovery-образы для мейнборда (включая его Katapult), тулхеда и MCU термокамеры. Это сторонние готовые бинарники непроверяемого происхождения — только аварийный запасной вариант, а не рутинный источник.

Не трогай питание или USB посреди записи. Чистая прошивка восстанавливается через Katapult, но прерванная запись, которая повредит сам Katapult, — единственный случай, вынуждающий лезть SWD в закопанный мейнборд. Сначала сними свой SWD-дамп — это твой откат.

Потеря конфига#

Конфиг — самый волатильный слой и тот, что теряют чаще всего. Восстанови printer.cfg вместе с его блоком SAVE_CONFIG (таблица частот eddy, tap_threshold и bed mesh живут там и их не перепечатать), плюс saved_variables.cfg. Детали — на странице конфига Klipper. Потом пересними снапшот в git — и после каждой сессии тюнинга впредь.