Чому бекапів недостатньо: як я додав механізм апаратних снапшотів у свій KVM-пристрій

У більшості інфраструктур слово бекап сприймається як фінальна гарантія безпеки. Зробили копію, отже, у разі проблем усе можна повернути як було. Але на практиці саме бекапи часто зникають першими. Коли зловмисник отримує доступ до системи, він починає не з сервісів чи логів. Його перша ціль — історія. Те, що дозволяє повернутися назад або розібратися, що саме сталося.

Це добре знайомо тим, хто, як і я, працює з self-hosted сервісами, homelab або звичайним залізом без BMC та IPMI. У таких середовищах резервні копії часто лежать десь поруч із основною системою, монтуються тими самими ключами та залежать від тієї ж операційки. Коли систему ламають, вся ця конструкція рушиться водночас. Саме з цього спостереження в мене й виникла ідея додати механізм снапшотів безпосередньо в KVM-пристрій.

Досить швидко я зрозумів, що класичний IP-KVM вирішує лише половину проблеми. Він дає картинку та керування клавіатурою, але не відповідає на головне питання: що робити, якщо сам хост більше не заслуговує на довіру. Якщо операційку зламали, root-доступ втрачено або диски зашифровані, звичайний KVM стає просто інструментом для спостереження за катастрофою в прямому ефірі.

Логіка мого рішення виявилася простою. Якщо вже є окремий фізичний пристрій, який живе за межами хоста і не залежить від його ОС, то чому б не винести туди й контроль над історією даних. Це не черговий агент у системі і не копіювання кудись у мережу. Це апаратно відокремлений рівень, який хост не може змінити заднім числом.

Я поєднав KVM із механізмом снапшотів. Для сервера це виглядає максимально просто, як звичайний USB-накопичувач. Туди можна зберігати критичні речі: конфіги, інфраструктурний код, ключі чи документи, які не мають покидати мережу. Жодних спеціальних драйверів чи магії на хості не потрібно.

Але всередині пристрою реалізована інша логіка. Файлова система та її історія контролюються не сервером, а самим KVM. Запис іде у звичайному режимі, але коли активність вщухає, створюється read-only снапшот. Минулі стани більше неможливо змінити або видалити з боку хоста, навіть за наявності повного адмінського доступу.

Моя мета тут не в тому, щоб зробити ще один бекап. Йдеться про фіксацію історії, яку хост не може переписати заднім числом. Коли сховище заповнюється, запис просто зупиняється. Я свідомо відмовився від автоматичного очищення чи ротації, оскільки будь-який такий механізм означає ризик втратити минуле.

При цьому жодного vendor lock-in немає. Снапшоти — це звичайні підтоми Btrfs. Накопичувач можна фізично витягти, підключити до будь-якої Linux-системи та змонтувати стандартними інструментами.

У такій архітектурі KVM перестає бути просто віддаленим монітором. Він стає останнім рівнем контролю, коли все інше вже не працює. Через нього можна не лише бачити BIOS, а й мати доступ до незмінної історії файлів, навіть якщо основна система повністю знищена.

Це не заміна класичних бекапів чи реплікації. Це інший клас інструментів — своєрідна чорна скринька для інфраструктури. Вона не рятує від усього, але дозволяє зберегти контекст у момент, коли програмним механізмам на хості вже не можна вірити. Мені йшлося саме про захист від зламаного хоста, а не про протидію фізичному доступу. Саме для таких сценаріїв снапшоти в KVM і мають сенс. Не як зручність, а як остання страховка на найгірший випадок.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті