Зачем сравнивать три подхода
На VDS слово «бэкап» часто означает разные вещи. Одни считают бэкапом снимок диска у провайдера (provider snapshot), другие — регулярный репозиторий restic/borgbackup во внешнем хранилище, третьи — быстрый локальный LVM snapshot перед обновлением. Все три подхода полезны, но отвечают на разные вопросы: «как быстро подняться», «как откатиться на нужную дату», «как пережить человеческую ошибку/порчу данных».
Ниже разложим по полочкам: что именно защищает каждый метод, где у него слабые места по consistency (согласованности данных), как это влияет на RPO и RTO, и какие проверки восстановления (restore test) реально нужно делать, чтобы бэкапы не были «бумажными».
Термины: RPO, RTO и consistency
RPO (Recovery Point Objective) — сколько данных вы готовы потерять по времени. Например, RPO=1 час означает, что потеря последнего часа изменений допустима, но больше — уже проблема.
RTO (Recovery Time Objective) — сколько времени вы готовы восстанавливаться. Например, RTO=15 минут — «нужно поднять сервис очень быстро», RTO=4 часа — «в целом приемлемо, лишь бы восстановилось корректно».
Consistency — согласованность состояния. Для части задач достаточно «краш-консистентности» (как после внезапного выключения питания). Для баз данных, очередей, почтовых хранилищ и любых систем с транзакциями часто нужен более строгий режим: либо корректно остановить/заморозить запись, либо использовать нативные механизмы бэкапа.
Типовая ошибка — выбирать метод по скорости создания, а не по тому, как он восстанавливается и что будет с данными после восстановления.
Если вы часто бэкапите в объектные хранилища, полезно понимать, как работает согласованность на стороне S3-совместимых API: это влияет на проверки наличия объектов и на логику ретенции. По теме можно почитать материал про паттерны eventual consistency в S3-хранилищах.
Для быстрых лабораторий восстановления удобно иметь отдельную тестовую ВМ на таком же типе виртуализации и дисков, что и прод. Обычно проще всего это организовать на отдельном тарифе VDS.
Перед тем как полагаться на любой подход, заранее договоритесь внутри команды, что считается «успешным восстановлением», и заведите короткий runbook. Это сэкономит часы в аварии.
Provider snapshot: быстрый «образ сервера»
Provider snapshot — это снимок диска(ов) на стороне платформы виртуализации/хранилища провайдера. Обычно делается быстро и удобно: «нажали кнопку — получили точку возврата». Часто поддерживаются несколько копий и клонирование ВМ из снапшота.
Сильные стороны
- Минимальный RTO для сценариев «сервер не грузится», «сломали конфиг», «неудачный апдейт»: откат часто занимает минуты.
- Не требует настройки внутри гостя: не важно, что у вас за дистрибутив, файловая система и стек приложений.
- Удобен как страховка перед изменениями: обновления, миграции, правки конфигов, смена параметров ядра.
Слабые места и ограничения
- Consistency часто краш-уровня. Если снапшот сделан без «заморозки» файловых систем/приложений, вы получаете состояние «как после внезапного ребута».
- Зависимость от одной инфраструктуры: снапшоты живут рядом с вашим сервером. Это не замена внешнему бэкапу на случай проблем площадки, аккаунта или ошибок доступа.
- Слабая гранулярность восстановления: чаще всего откат «всего диска». Отдельный файл можно достать через временный запуск/монтирование, но это ручная операция.
- Retention и стоимость зависят от провайдера: легко накопить много «на всякий случай», а нужной точки по времени всё равно не окажется.
Когда provider snapshot — хороший выбор
Как быстрый rollback перед опасными изменениями и как оперативное восстановление при поломке ОС/загрузчика/пакетов. Особенно полезно, когда RTO важнее всего, а потеря данных в пределах текущего окна изменений приемлема.
restic и borgbackup: файловые бэкапы с историей
restic и borgbackup — инструменты для регулярных резервных копий на уровне файлов: дедупликация, шифрование, инкрементальность, проверка целостности. Их сила — в истории, экономии места и независимости от конкретного провайдера/платформы.
Сильные стороны
- Контроль RPO: можно бэкапить хоть каждые 15 минут (если нагрузка и дельта позволяют).
- Гранулярное восстановление: отдельный файл/каталог/конфиг без отката всего диска.
- Дедупликация: хранить историю месяцами часто получается сильно дешевле «полных» копий.
- Шифрование на стороне клиента: даже если хранилище «не идеально доверенное», данные защищены.
- Проверяемость: репозиторий можно регулярно проверять и рано ловить повреждения.
Слабые места и типовые ошибки
- Consistency зависит от того, что вы бэкапите. Копировать «живой» каталог с данными БД — почти всегда лотерея. Для PostgreSQL/MySQL/Redis нужны корректные методы (дампы, физические бэкапы, репликация, снимки с заморозкой).
- RTO может быть выше, чем у снапшота: развернуть систему, поставить пакеты, вернуть конфиги и данные — это время. Ускоряется автоматизацией (IaC/Ansible), но это отдельная работа.
- Нужны регулярные restore test: «бэкап создаётся» не означает «он восстанавливается».
- Секреты и ключи: потеря пароля репозитория/ключей шифрования = потеря доступа к бэкапу. Это отдельный объект защиты.
Практика: как довести файловые бэкапы до продакшен-уровня
Обычно помогает простая дисциплина: разделяйте то, что бэкапите, и заранее проектируйте восстановление.
- Политика исключений: не бэкапить кеши, временные файлы, артефакты сборки, чтобы снизить шум и ускорить окна.
- Отдельные профили: «система и конфиги», «пользовательские данные», «дампы БД».
- Регулярная проверка репозитория: проблемы нужно обнаруживать не в день аварии.
- Репетиция восстановления: минимум раз в месяц проходить реальный сценарий восстановления на тестовой ВМ.
Если вы выбираете между инструментами и местом хранения (например, локально или в удалённом репозитории), пригодится отдельный разбор: бэкапы restic/borg в S3-совместимое хранилище.
Отдельно подумайте про транспорт и доверие: TLS на панели/сервисах бэкапа и в админке хранилища — это базовая гигиена. Под задачи продакшена часто проще сразу использовать нормальные SSL-сертификаты.
LVM snapshot: локальная «точка во времени» для безопасных операций
LVM snapshot — снимок логического тома на уровне блоков. Делается быстро и часто используется как «фиксатор состояния» перед операциями, где есть риск повредить данные: апгрейд, миграция, изменение схемы, эксперимент с настройками.
Сильные стороны
- Быстрый снимок (почти мгновенно).
- Удобно для консистентного чтения: сделали снапшот, затем снимаете дамп/архив уже со снапшота, уменьшая влияние изменений «на лету».
- Хорошо ложится в техпроцессы: «снапшот → изменение → тест → либо удалить снапшот, либо откатиться».
Слабые места
- Это не бэкап сам по себе: снапшот на том же диске. Умер диск/том — нет ни данных, ни снапшота.
- Нужен запас под COW. При интенсивной записи область снапшота может переполниться — снимок станет непригодным.
- Влияние на производительность при длительном удержании: чем дольше живёт снапшот под нагрузкой, тем выше накладные расходы.
- Сложность на маленьких VDS: если диск «впритык», держать снапшоты рискованно.
Мини-паттерн: «LVM snapshot → бэкап со снапшота → удаление снапшота»
Частый рабочий вариант: сделать LVM-снимок, примонтировать его только для чтения, снять файловый бэкап (или дампы), затем удалить снимок. Так вы улучшаете consistency без долгой остановки сервиса.
lvcreate -L 10G -s -n data_snap /dev/vg0/data
mkdir -p /mnt/data_snap
mount -o ro /dev/vg0/data_snap /mnt/data_snap
umount /mnt/data_snap
lvremove -y /dev/vg0/data_snapЕсли хотите углубиться именно в «горячие» бэкапы через LVM и типовые грабли (размер COW, время жизни снимка, влияние на IO), смотрите: LVM snapshot для hot backup: размеры, время жизни, нагрузка.
Consistency по слоям: что происходит с базами данных и очередями
Самый болезненный вопрос — consistency. Снимок блоков или файловая копия не равны «корректному состоянию приложения». Несколько типичных примеров:
- PostgreSQL: crash recovery обычно работает, но для малого RPO нужна стратегия уровня PITR и архивирование WAL.
- MySQL/InnoDB: тоже умеет crash recovery, но логическая согласованность приложения (особенно при нескольких сервисах) требует продуманного процесса.
- Redis: режимы RDB/AOF имеют нюансы; снимок диска без понимания настроек персистентности может дать неожиданные потери.
- Очереди/кэши: иногда их не стоит восстанавливать как «источник истины» — проще и надежнее пересоздать.
Практическое правило: для БД делайте бэкап средствами БД (дамп/физический бэкап/репликация), а снапшоты используйте как ускоритель и страховку, но не как единственный источник правды.
Restore test: единственная проверка, которая имеет значение
Бэкап считается существующим только тогда, когда вы проверили восстановление. Иначе это просто набор файлов, которые «кажется должны помочь».
Минимальный набор restore test для VDS
- Тест загрузки: поднимается ли система/контейнеры/сервисы после восстановления.
- Тест данных: открывается ли сайт, проходят ли базовые запросы к БД, сходится ли схема/миграции.
- Тест секретов: ключи, пароли, токены доступны и не потеряны (и при этом не лежат в открытом виде где попало).
- Тест времени: замерить реальный RTO (сколько заняло), а не «примерно быстро».
Что удобно фиксировать в итоге (чтобы не повторять хаос)
- Чёткий порядок шагов восстановления (runbook) и кто его выполняет.
- Где лежат пароли/ключи и кто имеет доступ (включая «план Б»).
- Сколько места нужно для восстановления (частая причина провала restore).
- Какие проверки считаются успешным восстановлением (healthchecks/контрольные запросы/сверка файлов).
Как выбрать: короткая матрица решений
Универсального «лучше/хуже» нет — есть набор требований и рисков.
Если важен минимальный RTO
Нужен provider snapshot как быстрый откат системы целиком. Но дополняйте его внешними бэкапами: снапшот редко закрывает сценарий «удалили один важный файл неделю назад».
Если важна история и гранулярность
Базовый слой — restic/borgbackup. Это самый «бэкапный» подход: дедупликация, история, проверки, восстановление отдельных сущностей. Дальше добавляйте снапшоты как ускоритель для откатов.
Если нужно безопасно делать изменения и миграции
LVM snapshot — отличный локальный инструмент «подстраховаться» на время работ, особенно если дальше вы с него же делаете файловый бэкап или дампы.
Рабочий гибрид для большинства VDS: два слоя вместо одного
На практике чаще всего выигрывает комбинация:
- Слой 1 (оперативный): provider snapshot перед изменениями и/или по расписанию с коротким retention.
- Слой 2 (архивный): restic/borgbackup во внешнем хранилище с продуманной политикой retention и регулярными restore test.
LVM snapshot при этом — инструмент для «сделать консистентную точку» и уменьшить риск во время бэкапа/миграции, но не самостоятельная страховка.
Типовые сценарии и что в них выбрать
1) Обновляете систему/ядро/панель и боитесь, что «не взлетит»
Provider snapshot (или LVM snapshot, если вы контролируете диски) даст быстрый rollback. Файловые бэкапы оставьте второй линией обороны.
2) Сайт важен, но бюджет ограничен
Начните с restic/borgbackup: это даст историю и возможность восстановить конкретные данные. Затем добавьте снапшоты точечно перед изменениями.
3) База данных критична, нужен предсказуемый RPO
Стратегию стройте вокруг механизмов БД (дампы/физический бэкап/журналы). Снапшоты и файловые бэкапы могут быть частью процесса, но не заменой. В этом случае обязательно измеряйте реальный RPO и RTO на restore test.
Чек-лист: вопросы, которые стоит задать себе сегодня
- Какие данные на VDS являются «источником истины», а какие можно пересоздать?
- Какой реальный RPO вам нужен для БД и пользовательских файлов?
- Какой RTO допустим: минуты, часы, день?
- Есть ли внешний бэкап вне инфраструктуры провайдера?
- Когда последний раз вы делали restore test и засекали время?
- Где хранятся ключи/пароли от репозиториев и как вы их не потеряете?
Вывод
Provider snapshot, restic/borgbackup и LVM snapshot — не конкуренты в стиле «выбери один», а разные инструменты для разных частей одной задачи. Снапшот провайдера чаще всего закрывает быстрый откат (низкий RTO), файловые бэкапы дают историю и гранулярность (контроль RPO и удобство восстановления), а LVM помогает делать консистентные точки и безопасные операции, но не заменяет внешний бэкап. Лучший результат почти всегда дает комбинация и регулярный restore test — потому что именно восстановление определяет, спасет вас бэкап или нет.
