*Cube-Host– облачный хостинг!!

получить консультацию

Вход

Автоматизация резервного копирования на VPS под управлением Linux

Автоматическое резервное копирование — это основа для работы любой производственной нагрузки на VPS под управлением Linux. Даже стабильный сервер может пострадать от случайного удаления, повреждения файловой системы, сбоев при обновлении или взлома учетной записи.

В этом руководстве представлена практическая схема резервного копирования: что включить, как создавать ежедневные архивы, как хранить копии за пределами локальной сети и как проверять восстановление. Если вы размещаете реальные проекты, начните с надежного VPS под управлением Linux с достаточным объемом хранилища и стабильной производительностью диска, чтобы выполнять резервное копирование без ущерба для пользователей.

Стратегия резервного копирования для VPS под управлением Linux

Прежде чем писать какие-либо скрипты, определите простую стратегию. Это повысит надежность и значительно упростит устранение неполадок в будущем.

RPO (целевой показатель точки восстановления): какой объем данных вы можете позволить себе потерять (например, данные за последние 24 часа).
RTO (целевое время восстановления): как быстро вы должны восстановить работу сервиса (минуты или часы).
Хранение: сколько дней/недель резервных копий вы храните (например, 7 ежедневных и 4 еженедельных).
Внесайтовая копия: никогда не храните резервные копии только на том же VPS.
Тестирование восстановления: резервная копия, которую вы никогда не восстанавливаете, — это просто файл, а не план.

Что следует резервировать

Для большинства веб-сайтов и приложений «обязательный» набор резервных копий выглядит следующим образом:

Файлы веб-сайта/приложения (обычно /var/www/)
Конфигурации системы и служб (/etc/)
Пользовательские данные (/home/)
Базы данных (дампы MySQL/MariaDB/PostgreSQL)
SSL-сертификаты (часто находятся в /etc/letsencrypt/ или в конфигурационных путях вашего веб-сервера)
Секретные данные приложения и файлы среды (там, где их хранит ваше приложение)

Совет: если ваш VPS используется для контейнеров (Docker), обычно требуется создавать резервные копии постоянных томов и конфигураций приложений, а не слоев контейнеров.

Создайте безопасный каталог для резервных копий

Создайте специальную папку для резервных копий со строгими правами доступа. Это не позволит другим пользователям/процессам читать конфиденциальные резервные копии.

sudo mkdir -p /backup
sudo chown root:root /backup
sudo chmod 700 /backup

Важно: убедитесь, что путь к резервным копиям не находится внутри каталога вашего веб-сайта (например, не в папке /var/www), иначе вы можете случайно раскрыть архивы через HTTP.

Вариант 1: Создание простой архивной резервной копии с помощью tar

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

sudo tar -czf /backup/backup-$(date  %F).tar.gz 
  --one-file-system 
  --exclude=/backup 
  --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run 
  /var/www /etc /home

Если ваш VPS загружен, вы можете снизить нагрузку от резервного копирования, используя приоритеты ЦП и ввода-вывода:

sudo nice -n 19 ionice -c3 tar -czf /backup/backup-$(date  %F).tar.gz 
  --one-file-system 
  --exclude=/backup 
  --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run 
  /var/www /etc /home

Что означают опции tar

-c — создать архив
-z — сжатие gzip
-f — выходной файл
--one-file-system — не пересекать точки монтирования (помогает избежать неожиданностей)

Резервное копирование баз данных

Одних файлов недостаточно для большинства производственных серверов. Добавьте дампы баз данных в свою процедуру резервного копирования (желательно хранить их вместе с архивами).

MySQL / MariaDB (дамп всех баз данных)

sudo mysqldump --all-databases --single-transaction --routines --events 
  | gzip > /backup/mysql-all-$(date  %F).sql.gz

Совет: для автоматизации настройте учетные данные безопасным образом (например, в /root/.my.cnf) вместо того, чтобы указывать пароли в cron.

PostgreSQL (дамп всех баз данных)

sudo -u postgres pg_dumpall | gzip > /backup/postgres-all-$(date  %F).sql.gz

Проверка резервных копий

Всегда проверяйте наличие и читаемость файлов. Если вы никогда не проверяете, то архив с нулевым размером или поврежденный дамп могут появиться незаметно.

ls -lh /backup

tar -tzf /backup/backup-$(date  %F).tar.gz | head

Для дополнительной уверенности сгенерируйте контрольные суммы (полезно при передаче данных за пределы офиса):

cd /backup
sha256sum backup-$(date  %F).tar.gz > backup-$(date  %F).tar.gz.sha256

Создайте скрипт резервного копирования (рекомендуется)

Вместо сложных однострочных команд в cron, поместите свою логику в скрипт. Это значительно упростит ведение журналов, хранение и синхронизацию за пределами сайта.

sudo nano /usr/local/sbin/backup-vps.sh

Пример скрипта (измените пути в соответствии с вашим сервером):

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="/backup"
DATE="$(date  %F)"
HOST="$(hostname -s)"
RETENTION_DAYS="7"

ARCHIVE="${BACKUP_DIR}/${HOST}-files-${DATE}.tar.gz"
MYSQL_DUMP="${BACKUP_DIR}/${HOST}-mysql-${DATE}.sql.gz"
PG_DUMP="${BACKUP_DIR}/${HOST}-postgres-${DATE}.sql.gz"

mkdir -p "${BACKUP_DIR}"
chmod 700 "${BACKUP_DIR}"

# 1) Files archive (adjust folders if needed)
nice -n 19 ionice -c3 tar -czf "${ARCHIVE}" 
  --one-file-system 
  --exclude=/backup 
  --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run 
  /var/www /etc /home

# 2) MySQL/MariaDB dump (optional: remove if you don't use MySQL)
if command -v mysqldump >/dev/null 2>&1; then
  mysqldump --all-databases --single-transaction --routines --events 
    | gzip > "${MYSQL_DUMP}" || true
fi

# 3) PostgreSQL dump (optional: remove if you don't use PostgreSQL)
if command -v pg_dumpall >/dev/null 2>&1 && id postgres >/dev/null 2>&1; then
  sudo -u postgres pg_dumpall | gzip > "${PG_DUMP}" || true
fi

# 4) Checksums (helpful for integrity checks after transfers)
cd "${BACKUP_DIR}"
sha256sum "$(basename "${ARCHIVE}")" > "$(basename "${ARCHIVE}").sha256"

# 5) Retention cleanup
find "${BACKUP_DIR}" -type f -name "${HOST}-files-*.tar.gz" -mtime  "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-mysql-*.sql.gz" -mtime  "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-postgres-*.sql.gz" -mtime  "${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "${HOST}-files-*.tar.gz.sha256" -mtime  "${RETENTION_DAYS}" -delete

echo "Backup completed: ${DATE}"

Сделайте его исполняемым:

sudo chmod  x /usr/local/sbin/backup-vps.sh

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

Запланируйте ежедневный запуск скрипта (например, в 03:00). Отредактируйте файл crontab в корневой директории:

sudo crontab -e

Добавьте следующую строку:

0 3 * * * /usr/local/sbin/backup-vps.sh >> /var/log/backup-vps.log 2>&1

Совет: Проверьте журналы после первого запуска: tail -n 50 /var/log/backup-vps.log

Перенесите резервные копии за пределы сайта (rsync)

Не храните резервные копии только на том же VPS. Простой и надежный способ — копирование резервных копий на второй сервер с помощью rsync через SSH.

1) Создайте ключ SSH (на VPS)

sudo ssh-keygen -t ed25519 -a 64 -f /root/.ssh/id_ed25519 -N ""

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

sudo ssh-copy-id backupuser@remote-server

3) Синхронизируйте папку с резервными копиями

sudo rsync -az /backup/ backupuser@remote-server:/remote-backup/$(hostname -s)/

Если вы хотите автоматизировать этот процесс, запланируйте его на время после резервного копирования (например: 03:30):

30 3 * * * rsync -az /backup/ backupuser@remote-server:/remote-backup/$(hostname -s)/ >> /var/log/backup-vps-rsync.log 2>&1

Тестовое восстановление (быстрая проверка работоспособности)

По крайней мере, время от времени выполняйте тестовое восстановление в временную директорию. Это самый быстрый способ обнаружить проблемы с правами доступа, отсутствующие пути или поврежденные архивы.

sudo mkdir -p /tmp/restore-test
sudo tar -xzf /backup/$(hostname -s)-files-$(date  %F).tar.gz -C /tmp/restore-test
ls -la /tmp/restore-test | head

И проверьте контрольные суммы, если вы их используете:

cd /backup
sha256sum -c $(hostname -s)-files-$(date  %F).tar.gz.sha256

Когда следует обновить VPS

Если резервное копирование занимает слишком много времени, во время сжатия наблюдаются всплески загрузки ЦП или вход-выход диска становится узким местом, вы получите более предсказуемую автоматизацию на более мощном VPS под Linux с лучшей производительностью хранилища и дополнительными ресурсами — особенно если вы используете тяжелые базы данных или управляете несколькими сайтами.

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

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

Для большинства сайтов минимальным требованием является ежедневное резервное копирование. Если данные часто меняются (заказы, сообщения, загрузки), рассмотрите возможность более частого дампа базы данных (например, каждые 1–6 часов) с более длительным сроком хранения.

Снимки VPS — это то же самое, что и резервные копии?

Нет. Снимки могут быть полезны, но они не являются полноценной стратегией резервного копирования. Вам по-прежнему нужны независимые копии, хранящиеся за пределами сайта, и тестирование восстановления.

Как долго следует хранить резервные копии?

Простой и эффективный подход — это 7 ежедневных резервных копий плюс еженедельные/ежемесячные архивы для более длительного хранения, в зависимости от потребностей вашего бизнеса и бюджета на хранение данных.

Какую самую большую ошибку совершают люди?

Хранение резервных копий только на том же VPS и отсутствие тестирования восстановления. Тестирование восстановления вне локации — это то, что превращает «резервные копии» в реальное восстановление.

Разверните VPS на Linux, готовый к автоматическому резервному копированию

Хотите предсказуемые задания резервного копирования, стабильную производительность и достаточно места для архивов и дампов баз данных? Начните с надежного VPS под Linux и автоматизируйте ежедневную синхронизацию резервных копий за пределы локальной сети с самого первого дня.