27 марта 2026 г.Бэкап VPS нужен для защиты данных. Как правило, от их безвозвратной потери, которая может возникнуть как следствие взлома(-ов), «человекошибок» или банальных поломок оборудования.
Бэкап позволяет быстро восстановить работу, минимизируя простои. А потерю данных – и вовсе нивелируя.
Только вот на первый взгляд кажется, что нормально забэкапить ВПС – сложно. Причем, очень. Но на деле все несколько проще. Мы подготовили небольшой гайд – читайте дальше: разберемся, что к чему.
Что такое правила бэкапа 3-2-1 и почему это «золотой стандарт» защиты данных
Стратегия 3-2-1 – ходовой вариант для бэкапа VPS.
Она учитывает сразу три вариации рисков: технические сбои, человеческий фактор и потенциально-реальную катастрофу (взять все то же затопление серверной, например).
(3) копии данных
Первая цифра в формуле выше означает, что всегда должно быть как минимум три копии. Оригинал – первая из них. Дальше – две других. Они дадут право на ошибку: вы всегда сможете восстановить актуальную версию или откатиться к более ранней, если проблема вдруг обнаружится не сразу.
(2) разных типа носителей
Второй момент – это хранить копии на двух разных типах носителей.
Любой «физический» вариант может выйти из строя, и часто это происходит по +- схожим причинам. Иначе говоря: если хранить две копии на двух хардах, которые лежат друг на друге, и случится скачок напряжения, сгореть могут оба сразу.
Так что варианты следует комбинировать.
Например, можно держать одну копию на небольшом SSD для быстрого и оперативного восстановления, а вторую – на условном HDD. Облако – тоже не самый плохой вариант.
(1) оффсайт-копия
В довершении – оффсайт копия. Она хранится за пределами основного местоположения. Это – реальное спасение на случай форс-мажора.
Пожар, потоп, кража, даже банальные перебои в электричестве – все это может сделать локальные копии недоступными сразу же.
Собственно, по этой причине «выносная» копия обязательно должна находиться в ином месте. Например, в другом здании. Причем, «здании» – это как самый минимум. Кто-то переносит их даже в другую область, и нельзя сказать, что это прямо уж лишено смысла.
Выбираем инструмент: почему rsync идеален для наших задач
С теорией более или менее разобрались, но как вообще бэкапить сервера в реальном сценарии? VPS, например?
Rsync может хорошо помочь с этим. Его фишка – в так называемом «дельта-кодировании». То есть когда программа запускается повторно, она не перезаписывает файлы целиком. Вместо этого rsync анализирует, какие блоки данных изменились с прошлого раза, и передает лишь только их.
Это сильно экономит что трафик, что всегда уместно.
Также rsync работает поверх SSH, что априори означает наличие шифрования. Не нужно будет думать и о том, как защищать бэкапы по ходу дела. Rsync также позволяет настраивать исключения, так что при необходимости можно будет легко убрать из бэкапа папки с кэшем или временными файлами, чтобы не забивать свободное место мусором.
Важно: Если просто синхронизировать папку с сервера на внешний диск через rsync -av /source /destination, файлы в папке назначения сами по себе удаляться не будут — даже если на сервере их уже стерли. По умолчанию rsync только добавляет новые данные и обновляет изменившиеся. А вот удаление на принимающей стороне включается отдельно, через флаг --delete. То есть именно команда вроде rsync -av --delete /source /destination будет поддерживать точное зеркало источника. И это удобно, но с оговоркой: если файл удалили по ошибке, повреждение тоже может «доехать» до копии при следующей синхронизации.
Впрочем, rsync умеет не только зеркалить данные, но и помогать с версионными бэкапами. Для этого используют --link-dest: с ним можно создавать копии хоть за каждый день, при этом неизменившиеся файлы не дублируются физически, а переиспользуются через жесткие ссылки. В итоге место расходуется заметно экономнее, а на руках остаются отдельные точки восстановления. То есть при необходимости можно вернуть файл не только в его текущем виде, но и таким, каким он был неделю или даже месяц назад.
Проектируем архитектуру 3-2-1 для проекта
Начнем с основ.
Для сайта, бота или магазина архитектура должна давать быстрый RTO (время восстановления) и разумный RPO (точка восстановления). Что до схемы, то основная – это, собственно, и VPS сервер.
Также должна присутствовать локальная резервная копия. Внешняя – тоже. А вот носителей может быть несколько. На первом уровне, скажем, – локальный диск, а на втором – NAS/другой диск. На третьем же – удаленный сервер по SSH, который и будет обеспечивать вынос за пределы площадки.
Что копировать: готовим данные к бэкапу. Что не копировать
Просто копировать все подряд – идея сомнительная, если и вовсе не откровенно плохая. Это приведет к переполнению диска и к бардаку в целом. Так что нужен точечный подход. Ниже – список того, что всегда имеет смысл бэкапить:
- Код и файлы проекта – обычно директории /var/www или /home/user/project.
- Конфигурации – папки с настройками сервера (/etc/nginx, /etc/apache2), скрипты запуска и, естественно, SSL-сертификаты.
- Базы данных – копировать служебные файлы БД (например, в /var/lib/mysql) «на горячую» нельзя – гарантированно получите сломанный архив. Поэтому перед синхронизацией всегда стоит сделать дамп. Как вариант – с помощью mysqldump или pg_dump.
А вот – без чего точно можно обойтись:
- Виртуальные системы – папки /proc, /sys, /dev, /run и прочие создаются системой при загрузке. Копировать их нет никакого смысла.
- Мусор и временные файлы – директории с кэшем (/var/cache) и временными файлами (/tmp). Их избегаем. А логи (/var/log) архивировать можно, но часто этого делать все равно не нужно. Если они и пригождаются, то в основном для аналитики.
- Сами бэкапы – не храните резервные копии внутри папки, которую будете копировать. Сильно замусорится.
Пишем скрипт автоматического бэкапа с rsync
Скрипт пишется в rsync через командную строку. Чтобы скопировать содержимое одной папки в другую, используется флаг «-r».
Например: sudo rsync -r директория1/ директория2
Важно: Немного по поводу слэша выше – если он есть, в папку скопируются только файлы из «директории1». Если слэш опустить, скопируется сама папка целиком – вместе со всем содержимым внутри.
Для создания же «полноценных» копий чаще используется флаг «-a». Он сохраняет не только сами файлы, но и все их атрибуты: взять все те же права доступа.
Например: sudo rsync -a директория1/ директория2
По SSH, кстати, тоже можно создавать копии – команда в данном случае будет выглядеть примерно так:
sudo rsync -avz --progress --delete -e «ssh -p 2026» [email protected]:~/backup_data
Флаги -avz отвечают за архивный режим, вывод и сжатие при передаче. Ключ -delete – за синхронизацию. Он удаляет файлы, которых больше нет в оригинале. Конструкция -e «ssh -p 2026» указывает, что передача идет по SSH, а [email protected] – это просто учетные данные и сам адрес сервера-хранилища.
Важно: Как мы уже упоминали выше, кэш и логи можно (да и нужно) исключать из бэкапа. Но не упоминали мы того, что rsync предлагает под это целый отдельный ключ – собственно, exclude. Он подойдет, если нужно исключить один-два типа файлов. Например, --exclude *.png добавит в исключения все картинки этого формата.
Автоматизируем по расписанию (cron)
Ручной запуск бэкап-тестов хорош сам по себе, но для реальной работы, конечно, так или иначе понадобится автоматизация – всего самостоятельно не переделаешь. Самое первое и основное, что понадобится для ее настройки, – это поработать над сервером-клиентом. Тут нужно отредактировать конфиг /etc/rsyncd.conf.
Он заполняется: указываются пути для логов и файла процесса, а затем описывается отдельный блок данных. Также прописывается, какая папка будет копироваться (path = /var/log) и от имени какого пользователя (uid = root). Здесь же указывается путь к файлу с паролем (secrets file = /etc/rsyncd.scrt), где и будут храниться данные для авторизации бэкап-пользователя.
Важно: После создания файла на него обязательно выставляются права 0600 – то есть только рут-доступ.
На сервере же нужно будет написать скрипт, который сможет забирать данные.
Делается это путем создания файла – /bin/server_backup.sh. В нем описываются переменные: IP адрес сервера-источника (srv_ip), имя модуля (srv_dir=data), пользователя (srv_user=backup) и локальная папка. Последняя – как раз для сохранения бэкапов.
Строка запуска rsync в скрипте будет использовать все эти переменные для подключения к источнику и скачивания данных в папку /current/. Дополнительно стоит настроить и систему инкрементных бэкапов: старые версии файлов будут складываться в /increment/ с пометкой даты.
Когда скрипт отлажен и нормально запускается вручную, остается добавить его в расписание. Для этого нужно открыть редактор планировщика (командой sudo crontab -e) и сделать пару вещей – синтаксис cron прост: пять полей (минута, час, день месяца, месяц, день недели) и команда. Например, запись 40 13 * * * /bin/server_backup.sh будет значить, что скрипт будет запускаться каждый день, и делать это в 13:40.
Проверка восстановления
Все сделано, но нужно убедиться в работоспособности. Вот как можно проверить бэкап:
- Развернуть изолированный тестовый хост с той же виртуальной платформой/хранилищем.
- Скопировать на тест-хост выбранный бэкап.
- Выполнить восстановление образа/файлов/дисков.
- Запустить VM и проверить загрузку ОС.
- На уровне приложений проверить сервисы (преимущественно сам сервер и БД).
- Сверить данные – контрольные суммы/количество файлов/базы.
Если все хорошо, то тестовую машину можно удалять. При проблемах – задокументировать ошибки и сделать откат.
Мониторинг и алерты: как понить, что бэкап сломался
Скрипт может и сломаться. Причин на то много, и вдаваться во все из них сейчас смысла нет. Куда важнее понимать, как все это дело обнаруживать.
И вот здесь отлично помогает постоянный мониторинг. А если конкретнее, то:
- Логирование – всегда есть смысл парсить файл /var/log/backup.log. Нужно периодически проверять, не появляются ли там ошибки.
- Подключение метрик – крайне желательно подключить и сторонние системы мониторинга. Они должны отслеживать «свежесть» бэкапа и его размер. С первым все понятно, что до второго – если он стал подозрительно небольшим, возможно, данные попросту не скопировались.
- Настройка алертов – настройте себе отправку уведомлений при сбое задачи в cron. Сделать это можно хоть на почту. Ну или в любое другое место, куда будет удобно. Для критичных проектов желательно использовать несколько разных каналов.
Итог здесь довольно простой: бэкап VPS — это не про «на всякий случай», а про нормальную и предсказуемую работу проекта. Один раз собрать внятную схему, понять, что именно копировать, куда складывать копии и как потом все это поднимать обратно, — уже половина дела. Дальше остается только следить, чтобы механизм действительно работал. Потому что сам по себе факт наличия бэкапа еще ничего не гарантирует. Гарантию дает только успешное восстановление — без паники, спешки и неприятных открытий в самый неподходящий момент.