Перейти к содержимому

Резервные копии: что, куда и как часто

Правило 3-2-1, что именно копировать с VPS, сколько данных можно позволить себе потерять и почему копия должна жить вне сервера.

Уровень
Новичок
Время чтения
3 мин чтения
Обновлено
Проверено на
Ubuntu 22.04, Ubuntu 24.04, Debian 12
Содержание
  1. Правило 3-2-1
  2. Что копировать
  3. Как часто и сколько хранить
  4. Проверка восстановления
  5. Защита самих копий
  6. Частые ошибки

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

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

  • 3 копии данных: рабочая и ещё две.
  • 2 разных носителя или хранилища: например, другой сервер и объектное хранилище S3.
  • 1 копия вне площадки: в другой стране, у другого провайдера или у вас дома.

Копия на том же сервере защищает только от случайного удаления файла. От взлома, ошибки при переустановке или отказа площадки она не спасёт.

Что копировать

ЧтоГде обычно лежитКак копировать
Базы данныхPostgreSQL, MySQL, RedisДамп (pg_dump, mysqldump), а не файлы базы на ходу
Файлы сайтов и загрузки/var/www, /srv, /optrsync или restic
Конфигурация/etc (nginx, systemd, cron, ssh)rsync или restic
Домашние каталоги и ключи/home, /rootrestic
Тома Docker/var/lib/docker/volumesДамп базы из контейнера плюс файлы томов
Сертификаты/etc/letsencryptВместе с /etc

Систему и пакеты копировать не обязательно: их быстрее поставить заново. Зато стоит записать, что было установлено: dpkg --get-selections > /root/packages.txt — и включить этот файл в копию.

Как часто и сколько хранить

Задайте себе два вопроса. Сколько данных не жалко потерять? Если заказы на сайте идут каждый час, ежедневной копии мало — нужна копия базы хотя бы раз в час. Это называют RPO. И за сколько нужно всё поднять? Если сайт должен вернуться за час, восстановление должно быть отрепетировано и описано по шагам. Это RTO.

Разумная отправная точка для небольшого проекта: дамп базы каждый час или раз в сутки, файлы — раз в сутки, хранить 7 ежедневных, 4 еженедельных и 6 ежемесячных копий.

Проверка восстановления

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

  1. 01Закажите временный сервер с той же ОС.
  2. 02Восстановите файлы и базу из копии по своей инструкции.
  3. 03Проверьте, что приложение запускается и данные актуальны.
  4. 04Запишите время, которое ушло на восстановление, и исправьте инструкцию.
  5. 05Удалите временный сервер.

Защита самих копий

  • Шифруйте копии, которые хранятся у третьей стороны (restic делает это сам).
  • Не давайте серверу право удалять старые копии в хранилище: взломщик, получивший сервер, не должен стереть и бэкапы.
  • Храните пароль от репозитория копий отдельно от сервера — например, в менеджере паролей.

Частые ошибки

  • Копируют файлы работающей базы данных — такая копия часто не восстанавливается. Делайте дамп.
  • Бэкап «молча» перестал работать месяц назад. Настройте уведомление об ошибке или проверяйте дату последней копии.
  • Единственная копия лежит на том же сервере.

Дочитайте до конца — статья засчитается в обучении автоматически.

  • бэкап
  • резервное копирование
  • 3-2-1
  • восстановление
  • стратегия

Статья помогла?