Стратегия резервного копирования для вашего сервера

BLACKBOX не делает автоматических резервных копий вашего сервера. Кнопка «Резервные копии» на карточке сервера на странице «Мои серверы» панели app.blackbox.md (app.blackbox.md/my-servers; с blackbox.md: «Личный кабинет» → «Панель управления» → «Мои серверы») не работает. В этом руководстве — что сохранять, где хранить копии, как автоматизировать копирование и как убедиться, что из копии действительно можно восстановиться. Все команды выполняются на сервере по SSH от имени root.

Доступно: владельцу VPS или выделенного сервера BLACKBOX с доступом root по SSH: Подключение к серверу по SSH (Windows, macOS, Linux). Команды подходят для Ubuntu, Debian, AlmaLinux и CentOS Stream.

Кто отвечает за резервные копии

У вас есть доступ root к серверу, и всё, что на нём работает, под вашим контролем, поэтому за резервные копии данных отвечаете тоже вы: Ответственность за данные на сервере и резервные копии. Глава 9 «Ограничение ответственности» Условий использования гласит: «BLACKBOX не несёт ответственности за косвенные убытки, упущенную выгоду, потерю данных или перерывы в деятельности, понесённые Клиентом или третьими лицами».

В панели нет ни автоматического резервного копирования, ни снимков (snapshot). Если нажать «Резервные копии» на карточке сервера, появится «Загрузка…», а затем сообщение backup_extra_disabled: услуга автоматического резервного копирования недоступна. На сервер и данные на нём это никак не влияет. См. Страница «Мои серверы»: карточка сервера.

Важно Сервер, удалённый кнопкой «Удалить» или при отмене заказа, восстановить нельзя. Единственные копии данных — те, что вы сделали сами и храните вне сервера.

Правило 3-2-1

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

Что сохранять

Не копируйте файлы базы данных (/var/lib/mysql, /var/lib/postgresql, /var/lib/pgsql), пока база работает: копия может оказаться несогласованной, и база из неё не запустится. То же касается томов Docker с базами данных: делайте дамп командой самой базы, запущенной в контейнере. Пример для PostgreSQL — строка для скрипта из шага 1:

docker exec ИМЯ_КОНТЕЙНЕРА pg_dump -U ИМЯ_ПОЛЬЗОВАТЕЛЯ -Fc ИМЯ_БД > "$DIR/ИМЯ_БД-$DATE.dump"

Для MariaDB или MySQL в контейнере используйте так же mysqldump (в свежих образах MariaDB — mariadb-dump) с пользователем и паролем из .env. См. также Установка Docker и Docker Compose.

Сохранять не нужно /proc, /sys, /dev, /run, /tmp, кеши, образы Docker (их можно скачать или собрать заново) и системные пакеты (их можно переустановить). Код, который лежит во внешнем Git-репозитории, отдельно копировать не обязательно — если вы следите, чтобы изменения туда действительно попадали.

Где хранить копии

Для копии offsite по правилу 3-2-1 выберите хотя бы одно место у другого провайдера или у себя в офисе. Если сервер для копий будет в BLACKBOX, обратите внимание на тарифы семейства Basic — у них большие диски, до 400 GB: Тарифы VPS: как выбрать.

BLACKBOX Cloud Storage онлайн не заказывается. На странице blackbox.md/ru/hosting/cloud-storage («Хостинг» → «Cloud Storage») кнопка «Заказать хранилище» ведёт на страницу «Контакты». Объём, цену и способы доступа вы получите в предложении от команды; уточните, какие способы доступа есть у хранилища, чтобы выбрать между restic и rsync. См. Продукты и конфигурации по запросу.

Шаг 1: ежедневный дамп баз данных через cron

Скрипт ниже каждую ночь выгружает базу данных в /var/backups/db и удаляет оттуда дампы старше 7 дней. На шаге 2 они копируются за пределы сервера. Установка баз данных: Базы данных: MariaDB/MySQL и PostgreSQL.

Файлы редактируются в nano. Если его нет (AlmaLinux, CentOS Stream), установите:

dnf install -y nano

1. Создайте скрипт:

   nano /usr/local/sbin/db-dump.sh

2. Вставьте текст ниже, замените ИМЯ_БД на имя своей базы, сохраните (Ctrl+O, затем Enter) и выйдите (Ctrl+X):

   #!/bin/bash
   set -euo pipefail
   umask 077
   cd /
   DIR=/var/backups/db
   DATE=$(date +%F)
   mkdir -p "$DIR"
   mysqldump --single-transaction --routines ИМЯ_БД | gzip > "$DIR/ИМЯ_БД-$DATE.sql.gz"
   find "$DIR" -type f -mtime +7 -delete

   Для PostgreSQL замените строку с mysqldump на эту:

   sudo -u postgres pg_dump -Fc ИМЯ_БД > "$DIR/ИМЯ_БД-$DATE.dump"

   Если баз несколько, добавьте такую строку для каждой. В MariaDB у этой команды есть и второе имя — mariadb-dump.

3. Сделайте скрипт исполняемым, запустите его один раз и проверьте, что файл появился:

   chmod 700 /usr/local/sbin/db-dump.sh
   /usr/local/sbin/db-dump.sh
   ls -lh /var/backups/db

   Если появится Access denied for user 'root'@'localhost', пользователь root базы данных входит по паролю. Запишите пароль в файл /root/.my.cnf с таким содержимым, а затем ограничьте доступ к файлу:

   [client]
   user=root
   password=ПАРОЛЬ_БД

   chmod 600 /root/.my.cnf

4. Настройте запуск каждую ночь в 02:00 (по времени сервера). Создайте файл:

   nano /etc/cron.d/db-dump

   и вставьте строку:

   0 2 * * * root /usr/local/sbin/db-dump.sh >> /var/log/db-dump.log 2>&1

В файлах из /etc/cron.d есть столбец с пользователем (root), в имени файла не должно быть точек, а последняя строка должна заканчиваться переводом строки. Символ % нельзя писать прямо в строке cron — поэтому дата вычисляется в скрипте. Если задание не запускается, проверьте, что служба cron установлена и работает.

Ubuntu и Debian:

apt update
apt install -y cron
systemctl enable --now cron

AlmaLinux и CentOS Stream:

dnf install -y cronie
systemctl enable --now crond

Дампы занимают место на диске. Если диск небольшой, храните их меньше дней (например, -mtime +3): Диск сервера заполнен.

Шаг 2: копия за пределами сервера с помощью restic

restic шифрует данные ещё на сервере, до отправки, хранит историю копий (снимков, snapshot) и при каждом запуске передаёт только изменения. В примере используется S3-совместимое объектное хранилище; вариант с другим сервером по SFTP описан в разделе про rsync. Официальная документация: restic.readthedocs.io.

Установка

Ubuntu и Debian:

apt update
apt install -y restic

AlmaLinux и CentOS Stream (restic устанавливается из репозитория EPEL):

dnf install -y epel-release
dnf install -y restic

Репозиторий и пароль

1. У провайдера хранилища создайте бакет (bucket) и пару ключей доступа. Запишите адрес сервиса (endpoint), имя бакета, ID ключа и секретный ключ.

2. Сгенерируйте пароль репозитория и выведите его на экран:

   mkdir -p /etc/restic
   chmod 700 /etc/restic
   openssl rand -base64 32 > /etc/restic/password
   chmod 600 /etc/restic/password
   cat /etc/restic/password

3. Сохраните показанный пароль в менеджере паролей.

4. Создайте файл с настройками:

   nano /etc/restic/env

   RESTIC_REPOSITORY=s3:https://АДРЕС_S3/ИМЯ_БАКЕТА/ИМЯ_СЕРВЕРА
   RESTIC_PASSWORD_FILE=/etc/restic/password
   AWS_ACCESS_KEY_ID=ID_КЛЮЧА
   AWS_SECRET_ACCESS_KEY=СЕКРЕТНЫЙ_КЛЮЧ

   ИМЯ_СЕРВЕРА — папка внутри бакета; у каждого сервера должна быть своя. Если провайдер требует указать регион, добавьте строку AWS_DEFAULT_REGION=РЕГИОН.

5. Ограничьте доступ к файлу, загрузите настройки в текущий сеанс и инициализируйте репозиторий (один раз):

   chmod 600 /etc/restic/env
   set -a
   . /etc/restic/env
   set +a
   restic init

   Ответ начинается с created restic repository.

Опасно Без пароля репозитория копии не сможет расшифровать никто, в том числе BLACKBOX. Храните пароль и вне сервера: если сервер будет потерян, без пароля восстановить ничего не получится.

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

nano /usr/local/sbin/restic-backup.sh

#!/bin/bash
set -euo pipefail
set -a
. /etc/restic/env
set +a
restic backup /etc /root /var/www /var/spool/cron /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-tag manual --prune

Сделайте скрипт исполняемым, запустите его один раз и посмотрите список копий:

chmod 700 /usr/local/sbin/restic-backup.sh
/usr/local/sbin/restic-backup.sh
restic snapshots

Ежедневный запуск через таймер systemd

1. Создайте службу:

   nano /etc/systemd/system/restic-backup.service

   [Unit]
   Description=Restic backup
   Wants=network-online.target
   After=network-online.target
   
   [Service]
   Type=oneshot
   Environment=HOME=/root
   ExecStart=/usr/local/sbin/restic-backup.sh

2. Создайте таймер:

   nano /etc/systemd/system/restic-backup.timer

   [Unit]
   Description=Daily restic backup
   
   [Timer]
   OnCalendar=*-*-* 03:00:00
   RandomizedDelaySec=30min
   Persistent=true
   
   [Install]
   WantedBy=timers.target

3. Включите таймер и проверьте время следующего запуска в столбце NEXT:

   systemctl daemon-reload
   systemctl enable --now restic-backup.timer
   systemctl list-timers restic-backup.timer

4. Запустите службу один раз и посмотрите журнал:

   systemctl start restic-backup.service
   journalctl -u restic-backup.service -n 50

Копирование запускается каждый день между 03:00 и 03:30 по времени сервера, после дампов в 02:00. Благодаря Persistent=true запуск, пропущенный, пока сервер был остановлен, выполнится при следующем включении.

Простой вариант: rsync на другой сервер

Если у вас есть второй сервер, rsync скопирует на него папки по SSH. rsync должен быть установлен на обоих серверах. Установка и параметры: Передача файлов на сервер (scp, rsync, SFTP).

1. На основном сервере создайте SSH-ключ только для резервного копирования, без парольной фразы, чтобы его мог использовать cron:

   ssh-keygen -t ed25519 -f /root/.ssh/backup_ed25519 -N ""
   cat /root/.ssh/backup_ed25519.pub

2. Добавьте показанную строку в /root/.ssh/authorized_keys на сервере для копий. Если он тоже в BLACKBOX, воспользуйтесь кнопкой «Добавить SSH-ключ» на его карточке: Добавление и удаление SSH-ключей на сервере.

3. Создайте папку назначения и выполните первое копирование вручную. При первом подключении подтвердите ключ сервера для копий, ответив yes:

   ssh -i /root/.ssh/backup_ed25519 root@IP_СЕРВЕРА_КОПИЙ "mkdir -p /backups/ИМЯ_СЕРВЕРА"
   rsync -aR --delete -e "ssh -i /root/.ssh/backup_ed25519" /etc /var/www /var/backups/db root@IP_СЕРВЕРА_КОПИЙ:/backups/ИМЯ_СЕРВЕРА/

   С параметром -R пути сохраняются полностью: на сервере для копий появятся /backups/ИМЯ_СЕРВЕРА/etc, /backups/ИМЯ_СЕРВЕРА/var/www и так далее.

4. Настройте ежедневное копирование в 03:30 в файле /etc/cron.d/backup-rsync:

   30 3 * * * root rsync -aR --delete -e "ssh -i /root/.ssh/backup_ed25519" /etc /var/www /var/backups/db root@IP_СЕРВЕРА_КОПИЙ:/backups/ИМЯ_СЕРВЕРА/ >> /var/log/backup-rsync.log 2>&1

rsync хранит только последнее состояние: с --delete файл, удалённый или испорченный на сервере, при следующем запуске исчезнет и из копии. Кроме того, файлы на сервере для копий не зашифрованы. Если нужны история и шифрование, используйте restic по SFTP на тот же сервер. Добавьте в /root/.ssh/config:

Host backup
    HostName IP_СЕРВЕРА_КОПИЙ
    User root
    IdentityFile /root/.ssh/backup_ed25519

Тогда в файле /etc/restic/env будут только эти две строки:

RESTIC_REPOSITORY=sftp:backup:/backups/ИМЯ_СЕРВЕРА-restic
RESTIC_PASSWORD_FILE=/etc/restic/password

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

Шифрование копий за пределами сервера

• restic шифрует всё паролем репозитория до отправки. Провайдер хранилища видит только зашифрованные данные.
• SSH, а значит и rsync и scp, шифруют данные только при передаче. Если место хранения вам не принадлежит, шифруйте файлы перед копированием, например с помощью gpg и пароля, сохранённого в файле (пакет gnupg в Ubuntu и Debian, gnupg2 в AlmaLinux и CentOS Stream):

openssl rand -base64 32 > /root/.backup-pass
chmod 600 /root/.backup-pass
gpg --batch --yes --pinentry-mode loopback --passphrase-file /root/.backup-pass --symmetric --cipher-algo AES256 -o ФАЙЛ.gpg ФАЙЛ

Расшифровка:

gpg --batch --pinentry-mode loopback --passphrase-file /root/.backup-pass -o ФАЙЛ -d ФАЙЛ.gpg

Содержимое /root/.backup-pass тоже сохраните в менеджере паролей.

Безопасность Файлы /etc/restic/env, /etc/restic/password и ключ /root/.ssh/backup_ed25519 дают доступ к копиям, а ключ — даже доступ root к серверу для копий. Если сервер взломают, злоумышленник сможет с их помощью удалить копии. Держите и такую копию, которую сервер удалить не может, — например, регулярно скачивайте её на свой компьютер.

Проверяйте восстановление хотя бы раз в месяц

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

1. Загрузите настройки, проверьте список копий и целостность репозитория:

   set -a
   . /etc/restic/env
   set +a
   restic snapshots
   restic check

   Последняя копия должна быть не старше 24 часов, а проверка restic check должна завершиться строкой no errors were found.

2. Восстановите настройки и дампы во временную папку:

   restic restore latest --target /root/restore-test --include /etc --include /var/backups/db
   ls -lh /root/restore-test/var/backups/db

3. Загрузите дамп в тестовую базу и проверьте таблицы и несколько свежих записей — например, последний заказ или последнюю опубликованную статью. Последнюю команду блока выполняйте только после проверки: она удаляет тестовую базу. Вместо ГГГГ-ММ-ДД подставьте дату из имени файла.

   MariaDB и MySQL:

   mysql -e "CREATE DATABASE restore_test"
   gunzip < /root/restore-test/var/backups/db/ИМЯ_БД-ГГГГ-ММ-ДД.sql.gz | mysql restore_test
   mysql -e "SHOW TABLES" restore_test
   mysql -e "DROP DATABASE restore_test"

   PostgreSQL:

   sudo -u postgres createdb restore_test
   sudo -u postgres pg_restore -d restore_test < /root/restore-test/var/backups/db/ИМЯ_БД-ГГГГ-ММ-ДД.dump
   sudo -u postgres psql -d restore_test -c "\dt"
   sudo -u postgres dropdb restore_test

4. Удалите временную папку:

   rm -rf /root/restore-test

Восстановление занимает место на диске, поэтому восстанавливайте только то, что проверяете (--include). Самая надёжная проверка — полное восстановление на другом сервере с запуском приложения: заодно это репетиция на случай реальной аварии. В варианте с rsync скопируйте дамп обратно с сервера для копий и загрузите его так же.

Дополнительная копия перед рискованными операциями

Сделайте свежий дамп и копию restic с меткой manual — её команда forget не удаляет:

/usr/local/sbin/db-dump.sh
set -a
. /etc/restic/env
set +a
restic backup /etc /root /var/www /var/spool/cron /var/backups/db --exclude-caches --tag manual
restic snapshots --tag manual

Когда копия станет не нужна, удалите её по идентификатору из столбца ID:

restic forget ID_КОПИИ --prune

Перед удалением сервера сохраните вне его пароль репозитория и настройки из /etc/restic/env: без них до копий не добраться. Скачайте также копию на компьютер с помощью rsync или scp.

Частые вопросы

Может ли BLACKBOX восстановить сервер, если я что-то удалил по ошибке? Нет. Панель не делает автоматических копий и не создаёт снимков, а удалённый сервер восстановить нельзя. Восстанавливайтесь из своих копий.

Что значит сообщение backup_extra_disabled под кнопкой «Резервные копии»? Это значит, что услуга автоматического резервного копирования недоступна. О неисправности сервера это не говорит, данные не затронуты.

Как восстановить один удалённый файл? Загрузите настройки restic, как в шаге 1 проверки восстановления. Восстановите файл во временную папку, а затем скопируйте его на место. Не восстанавливайте сразу с --target /: так вы перезапишете рабочие файлы. Чтобы взять более старую копию, укажите вместо latest её ID из restic snapshots.

restic restore latest --target /root/restore-test --include /var/www/site/config.php
cp -a /root/restore-test/var/www/site/config.php /var/www/site/config.php

У меня тариф «VPS hosting» с панелью управления. Что делать? В установленной панели управления может быть своя функция резервного копирования — уточните в поддержке, что она умеет: Тарифы «VPS hosting» с панелью управления. В любом случае копия должна храниться вне сервера.

Я потерял пароль репозитория restic. Что делать? Если файл /etc/restic/password ещё есть на сервере, пароль в нём: снова сохраните его в менеджере паролей. Если пароля больше нет нигде, копии из этого репозитория прочитать уже нельзя. Тогда создайте новый репозиторий с новым паролем и другой папкой в RESTIC_REPOSITORY и сразу сделайте полную копию.

Можно ли поручить настройку копий команде? Если не хотите настраивать сами, спросите в поддержке об администрировании сервера по запросу — с отдельным предложением: Профессиональные услуги по запросу: администрирование, DevOps, миграция.