Практичная стратегия резервного копирования VPS (правило 3-2-1)

Автор: команда ApexVPS • Обновлено: июль 2026 • 7 мин чтения

Надежная стратегия резервного копирования VPS — это разница между восстановлением за пять минут и очень плохой неделей. Серверы выходят из строя, диски повреждаются, деплои идут не так, и одна неверная команда может стереть каталог. Учебный центр Cloudflare и большинство команд инфраструктуры сходятся на одном простом принципе: правило 3-2-1. В этом руководстве показано, как применить его к реальному виртуальному серверу, какие инструменты использовать и как планировать и тестировать резервное копирование, чтобы восстановление действительно сработало, когда оно нужно.

Что означает правило 3-2-1

Правило 3-2-1 — это десятилетиями проверенный принцип резервного копирования, который остается актуальным независимо от того, где находится ваш сервер:

• 3 копии ваших данных — рабочая копия плюс как минимум две резервные.
• 2 разных носителя или системы хранения — так что единичный сбой не может уничтожить обе копии одновременно.
• 1 внешняя копия — физически или логически отделенная от защищаемой машины.

На VPS это обычно означает ваш работающий сервер, локальный репозиторий резервных копий и зашифрованную копию, отправляемую в удаленное хранилище в другом месте. Смысл в избыточности без единой точки отказа.

Что резервировать на VPS

Блочное резервное копирование всего диска расточительно и медленно. Хороший план резервного копирования нацелен на три вещи, которые действительно сложно воссоздать.

Данные приложений и файлы

Загруженные файлы, корни веб-сайтов, тома контейнеров и все, что создают пользователи. Типичные пути включают /var/www, /srv, /home и каталог томов Docker. Если вы самостоятельно размещаете приложения, такие как файловый сервер или вики, здесь хранится ваш незаменимый контент — см. наше руководство по запуску VPS для самостоятельного размещения, чтобы узнать, как обычно организованы эти каталоги.

Базы данных

Никогда не копируйте файлы базы данных, пока служба работает — можно получить наполовину записанное, поврежденное состояние. Вместо этого экспортируйте согласованный дамп. Для MySQL или MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Флаг --single-transaction обеспечивает согласованный снимок таблиц InnoDB без их блокировки. Для PostgreSQL используйте pg_dump вместо этого:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Системная и сервисная конфигурация

Файлы, которые делают ваш сервер вашим: /etc (nginx, systemd units, cron, SSH config), списки пакетов, TLS-сертификаты и правила брандмауэра. Восстановление их по памяти после сбоя — это как раз та утомительная работа, которой резервные копии должны помочь избежать.

Выбор инструментов для резервного копирования

Три инструмента покрывают почти все случаи VPS. Выбирайте, исходя из того, насколько вы цените дедупликацию и шифрование.

restic — зашифрованные дедуплицированные снимки

restic — современный инструмент резервного копирования в одном бинарнике, который по умолчанию шифрует и дедуплицирует. Инициализируйте репозиторий один раз, затем выполняйте резервное копирование в него:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — архивы с дедупликацией

BorgBackup предлагает аналогичную дедупликацию и сжатие с несколько иным рабочим процессом:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — простое зеркалирование файлов

Когда вам нужно быстрое зеркалирование файлов на другой хост, rsync по SSH не имеет себе равных:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

Флаги -aAX сохраняют права, ACL и расширенные атрибуты; --delete поддерживает зеркало в синхронизации с источником. rsync сам по себе не хранит историю версий, поэтому многие команды сочетают его с restic или borg.

Автоматизируйте расписание с помощью cron

Резервная копия, о которой нужно помнить, — это резервная копия, которая не будет выполнена. Поместите шаги в скрипт, сделайте его исполняемым и запланируйте с помощью cron. Отредактируйте crontab с помощью:

crontab -e

Затем добавьте строки вроде этих:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

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

Храните настоящую внешнюю копию

«1» в 3-2-1 — это та часть, которую большинство пропускает. Резервная копия, хранящаяся на том же сервере, который она защищает, исчезает вместе с этим сервером. Отправляйте зашифрованную копию куда-то независимое — объектное хранилище, удаленный SFTP-сервер или другого провайдера. restic и borg оба пишут прямо в удаленные репозитории, например по SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Поскольку restic и borg шифруют данные до того, как они покидают ваш VPS, удаленный хост никогда не видит ваш открытый текст. Очищайте старые снимки по политике, чтобы хранилище не росло бесконечно:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Тестируйте восстановление — каждый раз

Непроверенная резервная копия — это слух. Запланируйте периодическое восстановление в одноразовое место и убедитесь, что файлы и базы данных возвращаются в целости:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

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

Снапшоты — это один слой, а не вся стратегия

Каждый план ApexVPS включает автоматические резервные копии — ежедневные снапшоты на Starter Pro и почасовые на Business — и они действительно полезны для быстрого отката после неудачного деплоя или случайного удаления. Но будьте честны с собой: это удобный первый слой, который хранится на нашей платформе. Они не заменяют автономную, независимо проверенную копию, которую требует правило 3-2-1. Относитесь к снапшотам платформы как к быстрой точке локального восстановления и запускайте свой собственный restic или borg для выполнения требований автономности и тестирования восстановления. Такой многоуровневый подход отличает надежную настройку от той, что основана на надежде, независимо от того, хостите ли вы приложения, такие как Nextcloud, или запускаете производственную базу данных.

Чек-лист стратегии резервного копирования для VPS

Собирая все вместе, полная стратегия резервного копирования для виртуального сервера выглядит так. Пройдитесь по ней один раз, заскриптуйте, и пусть cron продолжает выполнение:

• Определите, что важно — файлы приложений, дампы баз данных и конфигурация в /etc.
• Выберите инструмент — restic или BorgBackup для зашифрованных, дедуплицированных, версионированных резервных копий; rsync для простых зеркал.
• Согласованно дампайте базы данных — mysqldump --single-transaction или pg_dump, никогда не копируйте сырые файлы из рабочей системы.
• Автоматизируйте — запланируйте скрипт в cron и предупреждайте о любом ненулевом коде выхода.
• Отправьте одну копию в офлайн — зашифрованную, на независимом хранилище, с разумной политикой хранения.
• Регулярно тестируйте восстановление — восстановите во временное место и подтвердите целостность данных.

Сделайте эти шесть вещей, и правило 3-2-1 перестанет быть теорией и станет привычкой, на которую может опереться ваша инфраструктура. Час на настройку — ничто по сравнению с ценой обнаружения во время инцидента, что ваша единственная копия была на диске, который только что умер.

Часто задаваемые вопросы

Считаются ли снапшоты провайдера стратегией резервного копирования?

Снапшоты — это один полезный слой, но не полная стратегия. Наши ежедневные и почасовые снапшоты защищают от большинства краткосрочных ошибок, но они хранятся на той же платформе, что и ваш сервер. Полная стратегия 3-2-1 по-прежнему требует независимой, автономной копии, которой управляете вы, и восстановления, которое вы действительно протестировали.

Как часто следует делать резервное копирование VPS?

Сопоставьте частоту с тем, сколько данных вы можете позволить себе потерять. Статические файлы и конфигурации можно бэкапить ежедневно, а активные базы данных часто требуют почасовых дампов. Используйте cron для автоматизации расписания, чтобы резервное копирование никогда не зависело от памяти.

Какой инструмент лучше всего подходит для резервного копирования VPS?

restic и BorgBackup оба отличны: они дедуплицируют, сжимают и шифруют резервные копии, а также поддерживают автономные репозитории. rsync подходит для простого зеркалирования файлов, а mysqldump или pg_dump обрабатывают экспорт баз данных. Многие настройки сочетают дамп базы данных с запуском restic или borg.

Как я узнаю, что мои резервные копии действительно работают?

Проводите тестовые восстановления по расписанию. Восстанавливайте во временную директорию, проверяйте содержимое файлов и контрольные суммы, импортируйте дамп базы данных в тестовую БД. Резервная копия, которую вы никогда не восстанавливали, — это лишь предположение, а не план восстановления.