Стратегия бэкапов для VPS: снапшоты, файловые копии и проверка восстановления
Сервер спокойно работает месяцами, и о копиях вспоминают в момент аварии: после неудачного обновления, случайно удалённого каталога, взлома или сбоя диска. Именно тогда выясняется, что снимок лежит на том же хранилище, архив не распаковывается, а последний дамп базы сделан полгода назад. Неприятно, зато знакомо многим.
Грамотное резервное копирование VPS складывается из нескольких слоёв. Снапшоты дают быструю точку отката, файловые бэкапы хранят данные отдельно от сервера, а регулярные проверки показывают, что копии вообще можно восстановить. В статье разберём, как собрать эти слои в одну схему, какие инструменты взять и как проверять результат без лишних усилий.
Материал пригодится тем, кто администрирует один или несколько Linux-серверов: от небольшого сайта до сервиса с базой данных и очередями.
Базовые понятия: снапшот, бэкап, RPO и RTO
Начнём с терминов, потому что их часто путают.
Что такое снапшот
Снапшот — это снимок состояния виртуального диска на определённый момент. Гипервизор запоминает, какие блоки меняются после создания снимка, поэтому он готов за секунды и в начале почти не занимает места. Откат возвращает сервер в то самое состояние: пакеты, конфигурации, файлы, пользователи. Проще говоря, это кнопка «отмотать назад». Перед обновлением системы, миграцией приложения или правкой критичных настроек удобно сделать снапшот сервера: если что-то пойдёт не так, откат займёт несколько минут.
Что такое файловый бэкап
Файловая копия — это выгрузка нужных данных во внешнее хранилище: каталогов с приложением, конфигураций, дампов баз данных. Обычно после первой полной копии сохраняются только изменения, поэтому повторные запуски проходят быстро и занимают мало места. Для этого применяют rsync, restic, BorgBackup, duplicity или обычный tar с отправкой по SSH.
RPO и RTO
Две аббревиатуры определяют всю схему. RPO (recovery point objective) показывает, сколько данных вы готовы потерять, если авария случится прямо сейчас: час, сутки, неделю. RTO (recovery time objective) отвечает на вопрос, за какое время сервис должен вернуться в строй. Бэкап раз в сутки означает RPO до 24 часов. Если интернет-магазин получает заказы каждые несколько минут, суточная копия слишком редкая, и базу придётся копировать чаще.
Правило 3-2-1
Классическая формула проста: три копии данных, на двух разных типах хранилищ, и одна из них за пределами основной площадки. Для VPS это выглядит так: рабочие данные на самом сервере, снапшот на стороне провайдера и файловая копия в отдельном хранилище или на другом сервере в другом дата-центре.
| Параметр | Снапшот | Файловый бэкап |
|---|---|---|
| Что сохраняется | Весь диск целиком, иногда и память | Выбранные каталоги, файлы и дампы |
| Скорость создания | Секунды или минуты | Минуты и часы, зависит от объёма |
| Скорость отката | Очень высокая | Зависит от размера и канала |
| Где хранится | В инфраструктуре провайдера, рядом с сервером | Во внешнем хранилище по вашему выбору |
| Восстановление отдельного файла | Неудобно, обычно откатывают весь диск | Просто, достаточно вытащить нужный путь |
| Срок хранения | Короткий, дни или пара недель | Длинный, месяцы и годы |
| Лучший сценарий | Страховка перед изменениями | Защита от потери данных и сервера целиком |
Как построить схему резервного копирования шаг за шагом
Шаг 1. Составьте перечень данных
Сначала определите, что вообще нужно сохранять. Обычно набор выглядит так:
- каталоги приложений и сайтов, например /var/www и /srv;
- конфигурации из /etc и юнит-файлы systemd;
- базы данных, причём через дампы, а не копированием файлов на работающем сервере;
- файлы, которые загружают пользователи, и медиа;
- ключи, сертификаты и секреты, только в зашифрованном виде.
Системные каталоги /proc, /sys, /dev и /tmp в копию не входят. Пакеты операционной системы проще поставить заново из репозиториев, чем хранить их годами.
Шаг 2. Настройте снапшоты
Снапшоты создают из панели управления провайдера или по API, поэтому их легко автоматизировать. Разумный минимум: снимок перед каждым значимым изменением и регулярный, раз в сутки или раз в неделю, с хранением трёх-семи последних. Длинные цепочки снимков держать не стоит. Каждый следующий усложняет работу диска, а место под накопившиеся изменения растёт.
Отдельно о базах данных. Если снимок сделан в момент активной записи, при откате СУБД окажется в состоянии «как после внезапного отключения питания» и будет восстанавливаться через журнал. Обычно это проходит гладко, но гарантий нет. Перед важным снимком можно кратко остановить запись или сбросить буферы на диск, а для критичных баз вдобавок делать отдельный дамп.
Шаг 3. Настройте файловую копию во внешнее хранилище
Для примера возьмём restic. Он шифрует данные по умолчанию, делает дедупликацию и умеет работать с SFTP, S3-совместимыми хранилищами и локальными дисками. Репозиторий создаётся один раз:
restic -r sftp:backup@10.0.0.5:/srv/restic initСама копия делается одной командой. Укажите каталоги из вашего списка и папку с дампами баз:
restic -r sftp:backup@10.0.0.5:/srv/restic backup /etc /var/www /srv/app /backup/dbПароль репозитория храните в файле с правами 600 и передавайте через переменную RESTIC_PASSWORD_FILE. Доступ к хранилищу настройте по SSH-ключу, без пароля в скрипте. Старые версии чистятся политикой хранения:
restic -r sftp:backup@10.0.0.5:/srv/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneВ итоге у вас остаётся неделя ежедневных копий, месяц еженедельных и полгода ежемесячных. Для большинства небольших проектов такого запаса хватает.
Шаг 4. Делайте дампы баз данных
Копировать файлы работающей базы напрямую рискованно: часть страниц может оказаться записанной наполовину. Надёжнее снять логический дамп и положить его в каталог, который затем уйдёт в общий бэкап. Для PostgreSQL подойдёт такая команда:
pg_dump -Fc -f /backup/db/app.dump appdbДля MySQL и MariaDB с таблицами InnoDB используют согласованный дамп без блокировки таблиц:
mysqldump --single-transaction --routines --events appdb | gzip > /backup/db/app.sql.gzЧто немаловажно, дамп нужно хранить не только в виде файла. Раз в месяц загрузите его в чистую СУБД и убедитесь, что он читается: повреждённый дамп обнаруживается только при попытке восстановления.
Шаг 5. Задайте расписание и сроки хранения
Расписание вытекает из RPO. Ниже пример для небольшого проекта, который можно взять за основу и подстроить под себя.
| Что копируем | Как часто | Сколько хранить | Чем |
|---|---|---|---|
| Диск сервера целиком | Перед изменениями и раз в неделю | 3–5 последних | Снапшот у провайдера |
| Каталоги приложения и конфигурации | Раз в сутки ночью | 7 дней, 4 недели, 6 месяцев | restic или borg |
| База данных | Раз в сутки, для активных сервисов чаще | 14 дней и ежемесячные точки | pg_dump или mysqldump |
| Проверка восстановления | Раз в месяц | Журнал результатов | Тестовый сервер |
Запуск по расписанию обеспечит cron или таймер systemd. Строка для cron выглядит так:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1[/code>
Ночное окно выбирают не случайно. Копирование нагружает диск и сеть, и лучше, чтобы оно не пересекалось с пиковой посещаемостью. Скрипт можно запускать через nice и ionice, тогда он будет вести себя тактичнее по отношению к основным процессам.
Шаг 6. Проверяйте восстановление
Копия, которую ни разу не разворачивали, остаётся предположением. Раз в месяц, а для критичных сервисов раз в неделю, поднимайте отдельный тестовый сервер и восстанавливайте на него последнюю копию. Такой тест восстановления показывает не только целостность архива, но и реальное время возврата в строй, которое вы сравниваете с RTO. Сервер для проверки можно создать на час на VPS Serverspace и удалить сразу после теста, поэтому платить за простаивающую машину не придётся.
Для начала проверьте сам репозиторий, а затем восстановите последнюю версию в отдельный каталог:
restic -r sftp:backup@10.0.0.5:/srv/restic check
restic -r sftp:backup@10.0.0.5:/srv/restic restore latest --target /srv/restore-test| Что проверить | Как | Признак успеха |
|---|---|---|
| Целостность репозитория | Команда restic check | Завершение без ошибок |
| Состав файлов | Сравнить размер и число файлов с боевым каталогом | Расхождения объяснимы |
| База данных | Загрузить дамп в чистую СУБД и выполнить пару запросов | Таблицы на месте, число строк близко к боевому |
| Работа приложения | Запустить сервис на тестовом сервере | Страница открывается, вход работает |
| Время восстановления | Засечь путь от пустого сервера до рабочего сервиса | Укладывается в заданный RTO |
Результат каждой проверки записывайте в журнал: дата, что восстанавливали, сколько времени ушло, что пошло не так. Через пару месяцев у вас появится реальная статистика, а заодно готовая инструкция на случай настоящей аварии.
Шаг 7. Настройте уведомления
Скрипт, который молча падает, хуже его отсутствия: создаётся ощущение защищённости. Пусть он проверяет код возврата и при ошибке отправляет письмо или сообщение в мессенджер. Хорошо работает и обратный подход: скрипт после успешного бэкапа обращается к сервису мониторинга, и если сигнала нет в ожидаемое время, приходит тревога. Так вы узнаете о проблеме в день сбоя, а не через месяц.
Плюсы и минусы комбинированной схемы
Плюсы
Каждый слой закрывает свою задачу. Снапшот возвращает сервер за минуты после неудачной правки, файловая копия переживает потерю самой виртуальной машины, а проверки подтверждают, что всё это работает на практике. Отдельный плюс в гибкости: можно вернуть один потерянный файл недельной давности, не трогая остальное. Схема легко автоматизируется и со временем почти не требует внимания.
Минусы
Настройка занимает время, особенно в первый раз. Внешнее хранилище стоит денег, причём расходы растут вместе с объёмом данных и сроками хранения. Нужна дисциплина: проверки восстановления легко отложить на потом, и именно их чаще всего пропускают. Ещё одна цена — ответственность за ключи шифрования и доступы, потеря которых лишает смысла все остальные усилия.
Ограничения и риски
Согласованность данных
Снимок диска во время активной записи и копия «на лету» могут оказаться несогласованными. Для баз данных это решают дампами и журналами, для файлов приложения — коротким переводом в режим обслуживания или заморозкой файловой системы. Если вы работаете с высоконагруженной СУБД, изучите механизмы непрерывной архивации журналов: они дают восстановление на конкретный момент времени.
Зависимость от одной площадки
Снапшоты живут в той же инфраструктуре, что и сервер. Проблема с аккаунтом, ошибка при удалении проекта или сбой площадки лишат вас и сервера, и снимков одновременно. Именно поэтому правило 3-2-1 требует копию в другом месте.
Вымогатели и ошибочные удаления
Если у сервера есть права на запись и удаление в хранилище бэкапов, злоумышленник или собственный кривой скрипт сотрёт и копии. Выдавайте серверу отдельную учётную запись, которая может только дописывать данные. Для restic для этого есть rest-server в режиме append-only, у borg аналогичный режим, а S3-совместимые хранилища поддерживают неизменяемые версии объектов.
Ключи и пароли
Зашифрованная копия без пароля бесполезна. Храните пароль репозитория в менеджере паролей и в бумажном или офлайн-экземпляре в надёжном месте, а не только на самом сервере, который вы собираетесь восстанавливать.
Законодательство и нагрузка
Если в копиях есть персональные данные пользователей, проверьте требования закона о персональных данных: в Казахстане к местам хранения баз с такими данными существуют отдельные правила. Не забывайте и о ресурсах: копирование нагружает диск, процессор и канал, а большой объём исходящего трафика может стоить денег.
Практические сценарии
Сценарий 1. Небольшой сайт на WordPress
Сайт с редкими обновлениями и умеренной посещаемостью. Здесь хватает ночного дампа MySQL и архива каталога wp-content, которые уходят через restic во внешнее хранилище. Перед обновлением плагинов или темы делают снапшот. Раз в месяц на тестовый VPS разворачивают копию и проверяют, что сайт открывается. RPO в сутки для такого проекта приемлем.
Сценарий 2. Сервис с PostgreSQL и частыми записями
Приложение, в котором данные меняются каждую минуту, а потеря последних часов недопустима. Суточных дампов мало. К ним добавляют непрерывную архивацию журналов, например через pgBackRest или WAL-G, и получают возможность откатить базу на нужную минуту. Снапшоты оставляют для страховки перед миграциями схемы, а файловую копию настраивают на отдельный сервер в другом дата-центре.
Сценарий 3. Обновление системы или релиз
Вы собираетесь перейти на новую версию дистрибутива или выкатить крупный релиз. Накануне делаете снапшот сервера, затем обновляетесь и проверяете работу сервисов. Если всё в порядке, через пару дней снимок удаляют, чтобы не копить длинную цепочку. Если нет, откат занимает несколько минут, и сервис возвращается в рабочее состояние без долгих разбирательств.
Сценарий 4. Подозрение на взлом
Здесь важно помнить: откат на снапшот вернёт и всё, что было на диске в момент снимка, включая закладки, если взлом произошёл раньше. Поэтому ищите точку до заражения. Файловые репозитории с историей версий помогают выбрать нужную дату и сравнить состояния. После восстановления закройте уязвимость, смените пароли и ключи и проверьте, что хранилище копий осталось нетронутым. Если у сервера нет прав на удаление бэкапов, у нарушителя тоже их нет.
Типичные ошибки
| Симптом | Причина | Решение |
|---|---|---|
| Копия есть, но восстановить её не удаётся | Архив повреждён, а восстановление ни разу не проверяли | Запускать проверку репозитория и регулярно разворачивать копию на тестовом сервере |
| После отката база выдаёт ошибки | Снимок сделан во время активной записи | Делать дампы и сбрасывать буферы на диск перед снимком |
| Копии пропали вместе с сервером | Всё хранится на том же диске или в том же аккаунте | Выносить копию в другое хранилище и в другой дата-центр |
| Новые копии перестали создаваться | Хранилище заполнено, политики хранения нет | Настроить forget и prune, следить за свободным местом |
| Копия на месте, а открыть её нельзя | Пароль хранился только на упавшем сервере | Держать пароль в менеджере паролей и в офлайн-копии |
| Бэкап не работал неделями, никто не заметил | Скрипт падает молча | Проверять код возврата и подключить уведомления |
Итоги
Надёжная схема держится на трёх опорах. Снапшоты нужны для быстрого отката перед изменениями, файловые копии во внешнем хранилище защищают данные при потере самого сервера, а регулярный тест восстановления подтверждает, что копии рабочие. Начните с малого: определите RPO и RTO, настройте ночной бэкап с дампом базы, добавьте снапшот перед каждым серьёзным изменением и поставьте в календарь первую проверку. На практике именно она оказывается самым полезным шагом, потому что вскрывает слабые места, пока авария ещё не случилась.
Если нужна площадка для боевого сервера или для тестовых развёртываний, можно взять VPS и собрать описанную схему на практике. Больше материалов по администрированию серверов есть в блоге Serverspace. Именно такой тест восстановления можно делать на временном сервере без лишних затрат. Резервное копирование VPS тогда превращается из разовой настройки в понятную регулярную практику.
FAQ
Может ли снапшот заменить резервную копию?
Нет. Снапшот хранится рядом с сервером, живёт недолго и защищает от неудачных изменений, но не от потери аккаунта, ошибки при удалении проекта или сбоя площадки. Для полноценной защиты нужна отдельная файловая копия во внешнем хранилище.
Как часто делать бэкап VPS?
Частота зависит от того, сколько данных вы готовы потерять. Для небольшого сайта обычно хватает одной копии за ночь. Для сервиса с активными записями в базу копии делают чаще и добавляют архивацию журналов транзакций, чтобы потери измерялись минутами.
Где лучше хранить файловые копии?
Не на том же диске и не в той же инфраструктуре, что сам сервер. Подойдёт другой VPS в другом дата-центре, S3-совместимое хранилище или отдельный сервер под бэкапы. Главное, чтобы выход из строя основной площадки не затрагивал копии.
Как часто проверять восстановление?
Для большинства проектов достаточно раза в месяц. Для критичных сервисов проверку проводят еженедельно, а также после любых заметных изменений: смены хранилища, переезда на новую версию СУБД, обновления скриптов бэкапа.
Нужно ли шифровать резервные копии?
Да, особенно если они лежат вне вашего сервера. В копиях часто оказываются конфигурации, ключи и персональные данные. Restic и borg шифруют данные по умолчанию, главное не потерять пароль и хранить его отдельно от сервера.
