Резервная копия — это единственное, что спасёт данные на VPS при отказе диска, ошибке в команде, взломе или случайном удалении файлов провайдером. Никакой firewall и никакая защита от взлома не отменяют необходимость бэкапа: рано или поздно что-то пойдёт не так по причине, которую нельзя было предусмотреть заранее. Вопрос не «нужен ли бэкап», а «что именно копировать и как часто».
Резервное копирование VPS: как не потерять данные
Разбираем, что копировать в первую очередь, как настроить бэкап без сложных инструментов и как убедиться, что в критический момент копия действительно восстановится.
Коротко: что вы узнаете из статьи
Какие данные копировать в первую очередь
Не всё на сервере одинаково важно для бэкапа. Систему и установленные пакеты в большинстве случаев проще переустановить с нуля, чем восстанавливать побайтово. А вот то, что реально нельзя быстро воссоздать, стоит копировать в первую очередь:
- База данных — заказы, пользователи, содержимое CMS. Если сайт работает на MySQL или PostgreSQL, именно база чаще всего оказывается критичнее файлов.
- Файлы проекта — код сайта, загруженные изображения, документы пользователей, конфигурации приложений.
- Конфигурационные файлы сервисов — настройки веб-сервера, cron-задачи, файлы окружения с переменными подключения.
- SSH-ключи и сертификаты, если вы настраивали их вручную и не хотите перевыпускать заново.
Операционную систему и стандартный набор пакетов обычно в бэкап не включают — если сервер настраивался по понятной инструкции, повторить установку системы быстрее, чем разворачивать её из громоздкого архива. Порядок первоначальной настройки описан в статье «Первая настройка VPS» — если у вас есть чёткий сценарий настройки, воссоздать чистую систему после сбоя займёт немного времени.
Снапшоты, ручной и автоматический бэкап: в чём разница
У слова «бэкап» есть минимум три разных значения, которые часто путают:
| Способ | Что копируется | Где хранится | Когда подходит |
|---|---|---|---|
| Снапшот провайдера | Весь диск сервера целиком | Обычно на стороне провайдера, рядом с самим VPS | Быстрое восстановление всего сервера после неудачного обновления или эксперимента |
| Ручной бэкап | Выбранные файлы и база данных | Там, куда вы сами скопировали архив | Разовое сохранение перед рискованным изменением на сервере |
| Автоматический бэкап | Файлы и/или база данных по расписанию | Внешнее хранилище, другой сервер, локальный компьютер | Постоянная защита данных без ручных действий |
Наличие функции снапшотов и её условия — платно или бесплатно, сколько снапшотов хранится одновременно — зависят от конкретного провайдера, поэтому эту возможность нужно уточнять в вашей панели управления или у поддержки. Снапшот удобен для быстрого отката всего сервера, но он не заменяет независимую копию: если пропадёт доступ к самому VPS или к аккаунту провайдера, снапшот окажется недоступен вместе с сервером. Отдельная копия за пределами сервера — единственный вариант, который переживает подобные сценарии.
Как настроить автоматическое резервное копирование
Дальше — рабочая связка для Linux-сервера: архивация файлов, выгрузка базы данных и перенос копии за пределы VPS по расписанию. Все команды выполняются в терминале — если вы ещё не подключались к серверу по SSH, сначала стоит прочитать «SSH-подключение к VPS».
Шаг 1. Архивация файлов проекта
Команда tar собирает выбранную папку в один сжатый архив:
tar -czvf /home/backup/site-$(date +%F).tar.gz /var/www/site-c — создать архив, -z — сжать через gzip, -v — показывать процесс, -f — указать имя файла. Часть с датой в имени файла нужна, чтобы новые архивы не перезаписывали предыдущие.
Шаг 2. Выгрузка базы данных
Если проект использует MySQL или MariaDB, дамп базы делается отдельной командой:
mysqldump -u имя_пользователя -p имя_базы > /home/backup/db-$(date +%F).sqlСистема запросит пароль пользователя базы данных. Для PostgreSQL аналогичную роль выполняет команда pg_dump — точный синтаксис зависит от версии СУБД и способа установки.
Шаг 3. Перенос копии за пределы сервера
Архив, который остаётся лежать рядом с самими файлами, не защищает от отказа диска или потери доступа к серверу целиком. Скопируйте его на другой сервер или локальный компьютер через rsync по SSH:
rsync -avz -e ssh /home/backup/ user@backup-host:/backups/site/Команда синхронизирует содержимое папки /home/backup на удалённый хост по защищённому SSH-соединению. Вместо второго сервера подойдёт локальный компьютер с установленным rsync или облачное хранилище с поддержкой аналогичного протокола.
Шаг 4. Автоматизация по расписанию через cron
Чтобы не выполнять команды вручную каждый раз, объедините шаги 1–3 в один shell-скрипт (например, /usr/local/bin/backup.sh) и добавьте его в планировщик задач:
crontab -eКоманда открывает редактор расписания cron для текущего пользователя.
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Строка запускает скрипт каждый день в 3:00 ночи и сохраняет вывод команды в лог-файл — удобно для проверки, что задача действительно отрабатывает, а не падает молча.
Перед тем как настраивать автоматическое удаление старых архивов внутри скрипта, дважды проверьте путь в команде
rm. Ошибка в пути или лишний пробел перед звёздочкой в маске файлов способны удалить не то, что планировалось, — восстановить удалённое без отдельной копии будет уже нечем.
Практический пример: сайт на VPS
Допустим, на сервере крутится сайт с базой данных MySQL, и его нужно защитить минимальными усилиями. Логичная схема:
- Ежедневный дамп базы данных ночью, когда нагрузка минимальна — данные меняются постоянно, и суточный интервал обычно приемлем для небольшого проекта.
- Архивация файлов раз в день — если правки в код и медиафайлы вносятся нечасто, более редкое копирование файлов оправданно и экономит место.
- Хранение 7 последних копий с автоматическим удалением более старых — этого обычно достаточно, чтобы откатиться на нужный день при обнаружении проблемы не сразу.
- Перенос копий на отдельное хранилище или второй сервер — тот самый шаг 3 из инструкции выше.
Для проекта с активным интернет-магазином, где заказы поступают каждую минуту, суточного интервала для базы данных может быть недостаточно — тогда дамп базы стоит запускать несколько раз в день, оставляя файлы сайта на прежнем ежедневном расписании.
Как проверить, что бэкап действительно восстановится
Резервная копия, которую ни разу не пробовали восстановить, — это копия с неизвестной надёжностью. Проверка занимает несколько минут и убирает главный риск: обнаружить повреждённый архив в момент, когда он реально нужен.
tar -tzvf site-2026-08-29.tar.gzФлаг -t проверяет содержимое архива без распаковки — команда покажет список файлов, если архив не повреждён, и выдаст ошибку, если он битый.
Для полноценной проверки лучше периодически — например, раз в месяц — разворачивать архив и дамп базы на тестовом сервере или локально и убеждаться, что сайт из восстановленной копии реально открывается. Это единственный способ узнать заранее, а не в момент сбоя, что процесс восстановления работает целиком, а не только на бумаге.
Типичные ошибки при резервном копировании
- Единственная копия на том же диске. При отказе диска или удалении сервера пропадает вместе с оригиналом.
- Бэкап настроен, но никогда не проверялся. Архив может годами создаваться пустым или повреждённым — если не проверять его руками, узнать об этом получится только в момент восстановления.
- Копируются только файлы без базы данных — для сайтов на CMS и с динамическим контентом это половина потерянных данных при восстановлении.
- Нет ротации копий. Если хранится только самый свежий архив, а проблема на сервере обнаружена не сразу — предыдущей рабочей версии, на которую можно откатиться, уже не будет.
- Резервные копии лежат без ограничения доступа. Архив с базой данных и конфигурациями — это те же чувствительные данные, что и на самом сервере, и его тоже стоит защищать паролями и правами доступа.
Резервное копирование логично дополнить общими мерами защиты сервера и наблюдением за его состоянием — эти темы разобраны отдельно в статьях «Безопасность VPS» и «Мониторинг VPS»: бэкап спасает данные после инцидента, а мониторинг и базовая защита снижают шанс, что инцидент вообще произойдёт.
Частые вопросы
Зависит от того, как часто меняются данные. Для сайта с редкими правками достаточно ежедневного или даже еженедельного бэкапа. Для магазина с постоянными заказами базу данных разумнее копировать несколько раз в сутки, а файлы — раз в день.
Копия на том же сервере не спасёт при полном отказе диска или потере доступа к VPS. Минимум одна копия должна храниться отдельно — на другом сервере, в облачном хранилище или локально на вашем компьютере.
Снапшот — моментальный слепок всего диска на стороне провайдера, обычно рядом с самим сервером. Бэкап в узком смысле — копия конкретных файлов и базы данных, которую вы делаете сами и переносите отдельно. Снапшоты быстрее восстанавливают весь сервер, но не заменяют независимое хранение файлов.
Если в бэкапе есть пароли, ключи доступа или персональные данные пользователей — да, особенно перед отправкой на стороннее облачное хранилище.
Ориентировочно — объём одной полной копии, умноженный на число хранимых архивов. Например, 7 ежедневных копий по 2 ГБ — это около 14 ГБ без учёта сжатия и дедупликации.
Использовать более раннюю сохранённую версию — именно поэтому стоит хранить несколько ротационных копий, а не одну-единственную последнюю.
Итог
Рабочая схема бэкапа VPS не требует сложных инструментов: архив файлов, дамп базы данных, перенос копии за пределы сервера и расписание в cron закрывают большинство сценариев потери данных. Главное — не полагаться на единственную копию рядом с оригиналом и хотя бы иногда проверять восстановление на практике, а не только сам факт создания архива.
