Резервное копирование виртуалок: образ целиком или файлы внутри

MAATRIX

Рано или поздно у любого, кто держит виртуалки, возникает вопрос: бэкапить саму VM целиком как чёрный ящик, или заходить внутрь гостевой ОС и копировать конкретные файлы и базы? Ответ — не «или-или», а «в каком пропорции», и если выбрать неправильно, вы либо тратите диск на бэкапы, которые никогда не понадобятся целиком, либо восстанавливаетесь неделю после того, что можно было поднять за десять минут.

Два подхода к бэкапу виртуалки

Смотреть на резервное копирование VM можно с двух разных точек.

Снаружи, с уровня гипервизора. Для гипервизора виртуальная машина — это диск (или несколько), конфигурация (сколько ей выделено CPU, памяти, какие сетевые интерфейсы) и текущее состояние. Бэкап на этом уровне снимает всё сразу, не заглядывая внутрь гостевой ОС и не зная, Ubuntu там или Windows, PostgreSQL или просто веб-сервер с статикой. Один механизм — для любой VM.

Изнутри, с уровня гостевой ОС. Для процесса, который работает внутри VM (агент бэкапа, cron-скрипт, дамп базы), виртуальная машина — это просто сервер: диск, файловая система, запущенные сервисы. Бэкап на этом уровне копирует то, что скрипту явно сказали копировать — конкретную директорию, дамп конкретной базы, конфиги конкретного приложения.

Разница не в инструментах — она в *единице бэкапа*. В первом случае единица — вся VM. Во втором — набор файлов и данных, которые вы сами определили как важные. У обоих подходов есть законное место, и путаница обычно возникает именно тогда, когда пытаются одним заменить другой полностью.

Бэкап на уровне гипервизора: снимаем всё целиком

Если вы работаете в Proxmox VE, штатный инструмент — vzdump, который либо гонит бэкап напрямую на диск/NFS, либо, что удобнее, отправляет его на Proxmox Backup Server с дедупликацией и инкрементальными снапшотами через dirty bitmap. Задача в кроне выглядит примерно так:

vzdump 101 102 103 --storage pbs-storage --mode snapshot --compress zstd

Здесь 101 102 103 — ID виртуалок, --mode snapshot — снятие без длительной остановки VM (через снапшот диска на уровне QEMU), --compress zstd — сжатие на лету. Результат — файл (или набор блоков в PBS), из которого можно поднять VM целиком: тот же диск, та же конфигурация CPU/памяти/сети, то же самое состояние операционной системы вплоть до последнего установленного пакета.

Главное преимущество этого подхода — простота и единообразие. Вам не важно, что внутри VM: Docker с десятком контейнеров, голая база данных или почтовый сервер с самодельными скриптами. Механизм бэкапа один и тот же, настраивается один раз на уровне гипервизора, а не отдельно в каждой гостевой системе. Если вы администрируете десяток VM с разным содержимым, это экономит реальное время — не нужно помнить, что в VM №7 бэкап настроен через restic, а в VM №12 вообще не настроен, потому что «руки не дошли».

Второе преимущество — полнота. Образ включает абсолютно всё: саму ОС, установленные пакеты, системные конфиги, права доступа, всё, что вы когда-либо накрутили руками и забыли задокументировать. Восстановление из такого бэкапа — это не «настроить сервер заново и накатить данные», а поднять точную копию того, что было в момент снятия образа. Для катастрофического сценария (сгорел хост, диск умер, случайно снесли не ту VM) это разница между часом простоя и днём ручной реконструкции.

Минусы тоже реальные:

• Объём. Бэкапится весь диск, включая временные файлы, кэши, логи, которые никому не нужны через неделю. PBS частично решает это дедупликацией на уровне чанков — повторяющиеся блоки между бэкапами (и даже между разными VM с похожей ОС) не хранятся заново, — но по сравнению с точечным бэкапом важных данных объём всё равно больше.
• Восстановление целиком, даже если нужен один файл. Классический образ раньше означал: чтобы вернуть один случайно удалённый конфиг, надо было поднимать всю VM в отдельном месте, монтировать её диск и вытаскивать файл руками. Современные инструменты вроде PBS это смягчают — есть proxmox-backup-client file-restore и File Restore в интерфейсе, который монтирует бэкап образа как read-only и даёт скачать отдельные файлы или папки без полного разворачивания VM. Но это всё равно дополнительный шаг по сравнению с «просто взять файл из бэкапа файлов».

Бэкап изнутри гостевой ОС: только то, что важно

Второй подход — то, что делали задолго до виртуализации: смотрим внутрь сервера и бэкапим конкретно то, что критично.

Для базы данных это дамп:

mysqldump --single-transaction --routines --triggers dbname | gzip > /backup/dbname_$(date +%F).sql.gz

или для PostgreSQL:

pg_dump -Fc dbname > /backup/dbname_$(date +%F).dump

Для файлов — архивирование конкретных директорий (конфиги nginx, файлы приложения, загрузки пользователей) через tar, rsync или специализированные инструменты вроде restic/Borg, которые дают дедупликацию, шифрование и версионирование на уровне отдельных файлов.

Плюс такого подхода — гранулярность и экономия. Бэкапится только то, что реально нужно восстановить: база на 2 ГБ вместо диска на 40 ГБ, где 38 ГБ — операционная система и установленные пакеты, которые проще накатить заново из образа дистрибутива или Ansible-плейбука, чем хранить их бэкап месяцами. Восстановление тоже точечное: нужен вчерашний файл — взяли вчерашний файл, не разворачивая ничего вокруг.

Минус ровно в том, в чём был плюс у гипервизорного подхода: это надо настраивать отдельно в каждой VM. Единого механизма нет — в одной машине дамп базы через cron, в другой restic, в третьей просто ручной tar раз в неделю «пока руки дойдут до нормального решения». Чем больше VM, тем выше шанс, что где-то бэкап настроен неправильно, забыт или тихо сломался — и это часто выясняется только в момент восстановления, что само по себе отдельная и неприятная тема.

Второй минус: бэкап файлов не восстанавливает систему. Дамп базы данных ничего не знает про версию PostgreSQL, которая была установлена, про системные лимиты, про правило в /etc/security/limits.conf, которое вы когда-то настроили под нагрузку. После полной потери VM с бэкапом только файлов вам нужно: поднять новую VM, установить ОС, установить те же пакеты той же версии, восстановить конфиги вручную (если они не входили в бэкап) — и только после этого накатить дамп базы поверх. Это не пять минут.

Сравнение: где какой подход выигрывает

Табличное сравнение полезно, но не заменяет главного вывода: это не конкурирующие решения одной задачи, а решения двух разных задач — «быстро вернуть систему целиком» и «точечно вернуть данные».

Консистентность: почему «просто скопировать диск» не всегда работает

Здесь кроется грабля, которая обычно всплывает не сразу, а в тот самый неприятный момент, когда бэкап реально понадобился.

Снапшот диска работающей VM с активной базой данных — это снимок состояния диска в произвольный момент времени. Если база в этот момент как раз пишет транзакцию (часть данных уже на диске, часть ещё в памяти или в WAL, который не долистан), наивный снапшот может зафиксировать файлы базы в промежуточном, несогласованном состоянии. При восстановлении база либо не запустится, либо запустится с поврежденными данными — и вы узнаете об этом не в момент бэкапа, а в момент, когда бэкап нужен позарез.

Это и называется проблемой консистентности (consistency), а механизм её решения — quiescing, «замораживание» файловой системы и приложений перед снятием снапшота, чтобы на диске гарантированно оказалось согласованное состояние.

Как это решается на практике:

• На уровне гипервизора. В Proxmox с установленным qemu-guest-agent внутри VM снапшот перед бэкапом может вызвать fsfreeze — гостевая ОС приостанавливает запись на файловую систему на несколько секунд, ровно на момент снятия снапшота. Это гарантирует консистентность файловой системы, но не всегда гарантирует консистентность конкретного приложения — БД может сама нуждаться в дополнительном хуке (например, mysqldump --single-transaction перед фризом, или встроенная поддержка snapshot-hook в PostgreSQL). Снапшоты в Proxmox устроены именно вокруг этого — стоит понимать механизм, прежде чем полагаться на снапшот как на бэкап баз данных.
• На уровне гостевой ОС. Штатный mysqldump --single-transaction или pg_dump работают на уровне самой СУБД — она сама гарантирует, что дамп представляет согласованное состояние на конкретный момент времени, независимо от того, что происходит с диском на уровне гипервизора. Это и есть главный практический аргумент в пользу того, чтобы для баз данных не полагаться только на образ VM.

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

Практика: как совместить оба подхода

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

Основа: бэкап на уровне гипервизора. Это ваша страховка от полной потери VM — сгорел диск хоста, случайно удалили не ту машину, авария в дата-центре. Регулярный vzdump в PBS с ежедневным (или чаще, для важных VM) расписанием и разумной глубиной хранения (retention в PBS: например, 7 ежедневных, 4 недельных, 6 месячных копий) даёт возможность за минуты поднять VM целиком в любом состоянии из истории.

Поверх: точечный бэкап критичных данных изнутри. Для баз данных — отдельный дамп с гарантией консистентности (--single-transaction для MySQL, pg_dump для PostgreSQL) с той же или большей частотой, чем образ VM, и с хранением отдельно от диска этой же VM (иначе при потере диска вы теряете и образ, и дамп одновременно — прочитайте о том, почему бэкап на том же сервере — это не бэкап). Для файлов, которые меняются часто и которые жалко терять между ежедневными снапшотами образа (код, загрузки пользователей), — rsync или restic с более частым расписанием.

Практическое распределение ответственности выглядит так:

Гипервизор (vzdump → PBS):
  - вся VM целиком, ежедневно
  - страховка от потери железа/VM
  - быстрое полное восстановление

Внутри VM (dump/restic/rsync):
  - база данных, консистентный дамп, несколько раз в день
  - критичные файлы, которые не хочется терять между образами
  - точечное восстановление без разворачивания всей VM

Дополнительный плюс такой схемы — она устойчива к ошибке в любом из двух механизмов. Если инкрементальный образ в PBS вдруг перестал сниматься (диск переполнился, забыли продлить хранилище), у вас всё ещё есть дампы баз изнутри. Если скрипт дампа базы сломался после обновления версии СУБД и никто не заметил, у вас всё ещё есть вчерашний полный образ VM. Совмещение обоих подходов требует больше места под хранение бэкапов, чем любой один из них по отдельности, но именно эта избыточность и есть смысл резервного копирования.

Отдельно стоит проверять оба механизма не только на «бэкап прошёл без ошибок», но и на «восстановление реально работает» — тестовое разворачивание образа и накат дампа поверх раз в квартал снимает большую часть неприятных сюрпризов.

Частые вопросы