NexNode
Все гайды
ЭксплуатацияНовичок

Бэкапы VPS: как не потерять данные и восстановиться за 10 минут

Настраиваем автоматические резервные копии сервера: что копировать, куда складывать, как проверять и как восстановиться после сбоя.

10 мин чтенияобновлено 29 июля 2026 г.

О бэкапах вспоминают дважды: когда настраивают сервер по инструкции и когда уже всё потеряли. Второй случай встречается заметно чаще.

Терять данные можно по-разному, и взлом тут далеко не на первом месте. Гораздо чаще виноваты обычные вещи: удалили не тот каталог, обновление сломало базу, диск на сервере вышел из строя, забыли продлить оплату и провайдер удалил машину.

Разберём, как настроить копии за полчаса и один раз.

Правило трёх копий

Классическое правило звучит так: три копии данных, на двух разных носителях, одна — вне основной площадки.

Для обычного сайта или бота это переводится просто:

  1. Рабочие данные на сервере
  2. Копия на том же сервере — для быстрого отката
  3. Копия у другого провайдера или на своём компьютере — на случай, если сервер исчезнет целиком

Третий пункт — самый важный и самый пропускаемый. Копия, лежащая на том же диске, что и данные, не спасёт при отказе диска.

Снимки провайдера — не бэкап

Многие провайдеры предлагают снапшоты. Это удобно, но они хранятся в той же инфраструктуре и привязаны к вашему аккаунту. Заблокировали аккаунт, ошиблись в оплате, случился сбой у провайдера — исчезнет и сервер, и снапшоты. Держите хотя бы одну копию снаружи.

Что вообще копировать

Не нужно снимать образ всего диска — это долго и дорого. Копировать стоит только то, что нельзя восстановить командой установки:

  • базы данных — почти всегда самое ценное
  • загруженные файлы: картинки, документы, вложения
  • конфигурации: /etc/nginx, файлы служб systemd, .env с настройками
  • сертификаты /etc/letsencrypt
  • код, если он не хранится в Git

А вот системные пакеты, node_modules и подобное копировать бессмысленно: они ставятся заново одной командой.

Шаг 1. Дамп базы данных

Копировать файлы базы «как есть» нельзя — она может быть в процессе записи, и копия окажется битой. Нужен дамп.

Для PostgreSQL:

терминал
root@vps:~#pg_dump -U postgres имя_базы | gzip > /var/backups/db-$(date +%F).sql.gz

Для MySQL или MariaDB:

терминал
root@vps:~#mysqldump -u root -p имя_базы | gzip > /var/backups/db-$(date +%F).sql.gz

Подстановка $(date +%F) добавит дату в имя файла — получится db-2026-07-29.sql.gz.

Шаг 2. Скрипт резервного копирования

Соберём всё в один файл. Создайте его:

терминал
root@vps:~#nano /usr/local/bin/backup.sh
#!/usr/bin/env bash
set -euo pipefail

DEST=/var/backups/nexnode
DATE=$(date +%F-%H%M)
mkdir -p "$DEST"

# база данных
pg_dump -U postgres mydb | gzip > "$DEST/db-$DATE.sql.gz"

# файлы и настройки
tar -czf "$DEST/files-$DATE.tar.gz" \
    /opt/myapp/uploads \
    /etc/nginx \
    /etc/letsencrypt

# удаляем копии старше 14 дней
find "$DEST" -type f -mtime +14 -delete

echo "[$(date '+%F %T')] бэкап готов: $DATE"

Сделайте файл исполняемым и проверьте:

терминал
root@vps:~#chmod +x /usr/local/bin/backup.shroot@vps:~#/usr/local/bin/backup.sh

Строка с find важна: без неё копии будут копиться, пока не кончится диск. Две недели — разумный запас.

Шаг 3. Запуск по расписанию

Пусть скрипт работает сам каждую ночь:

терминал
root@vps:~#crontab -e

Добавьте строку:

0 4 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Это «каждый день в 4 утра». Ночь выбрана не случайно: нагрузка минимальна, и снятие копии никому не мешает.

Шаг 4. Копия за пределами сервера

Вот тот шаг, который обычно пропускают. Настроим отправку копий на другую машину.

Сгенерируйте ключ для доступа и разложите на второй сервер, затем допишите в конец скрипта:

# отправляем копию на запасной сервер
rsync -az --delete "$DEST/" backup@ЗАПАСНОЙ_IP:/backups/мойсервер/

Нет второго сервера — подойдёт облачное хранилище. Многие провайдеры дают объектное хранилище за 2–5 ₽ за гигабайт в месяц, что при объёме копий в пару гигабайт стоит копейки.

Проще: готовый инструмент

Если хочется шифрования и версионности из коробки, посмотрите restic или borg. Они умеют хранить только изменения, поэтому вторая и последующие копии занимают в разы меньше места, а данные шифруются перед отправкой.

Шаг 5. Проверка — самое главное

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

Проверяйте раз в месяц, руками:

терминал
root@vps:~#ls -lh /var/backups/nexnode | tail -5root@vps:~#gzip -t /var/backups/nexnode/db-*.sql.gz && echo "архивы целы"

И хотя бы раз попробуйте восстановиться на чистом сервере. Именно так вы узнаете, что забыли включить в копию.

Как восстановиться

База данных:

терминал
root@vps:~#gunzip -c /var/backups/nexnode/db-2026-07-29.sql.gz | psql -U postgres mydb

Файлы:

терминал
root@vps:~#tar -xzf /var/backups/nexnode/files-2026-07-29.tar.gz -C /

Дальше перезапустить службы — и сервер живой.

Сколько это занимает по деньгам

Копии сайта средних размеров — это единицы гигабайт. Хранение на объектном хранилище обойдётся в 20–100 ₽ в месяц. Второй дешёвый сервер под бэкапы — от 250 ₽.

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

Что дальше

Копии есть — теперь стоит защитить сам сервер, чтобы восстанавливаться приходилось пореже. И настроить мониторинг: он предупредит о проблеме раньше, чем она превратится в потерю данных.

Если ищете второй сервер под хранение копий, подойдёт самый дешёвый тариф из каталога — для бэкапов важен только объём диска.