Резервное копирование для малого бизнеса: правило 3-2-1 и проверка восстановления

Вопрос «а у нас есть бэкапы?» в небольших компаниях обычно задают после того, как что-то случилось: умер диск, шифровальщик зашифровал общую папку, сотрудник удалил базу. И часто выясняется, что копии вроде бы были, но восстановиться из них нельзя: копировалось не то, копия лежала на том же сервере или последняя удачная была полгода назад.

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

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

Классическое правило звучит так:

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

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

Что именно копировать

Начинать стоит не с выбора программы, а со списка того, без чего компания не сможет работать, и того, сколько данных можно потерять без последствий. Обычно в список попадают:

• базы данных учётных систем (их копируют штатными средствами СУБД, а не копированием файлов на ходу);
• общие папки и файловые хранилища;
• почта, если она на своём сервере;
• конфигурации серверов и сетевого оборудования - восстановить настройки роутера по памяти долго и рискованно;
• документация: схемы, пароли в менеджере паролей, инструкции.

Для каждого пункта нужно определить, как часто делать копию и сколько хранить. Например, базу учёта - каждую ночь с хранением 30 дней, файлы - ежедневно с недельными и месячными точками.

Пример: restic на Linux-сервере

Для серверов на Linux я часто использую restic: он шифрует данные, хранит их с дедупликацией (повторяющиеся блоки не занимают место дважды) и умеет работать с разными хранилищами от SFTP до S3-совместимых облаков.

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

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic/office"
export RESTIC_PASSWORD_FILE="/root/.restic-password"

# база данных — штатным дампом, а не копированием файлов
pg_dump --format=custom --file=/srv/backup/db.dump accounting

restic backup /srv/data /srv/backup/db.dump /etc --exclude-caches --tag nightly

# хранить 7 ежедневных, 4 еженедельных и 6 ежемесячных копий
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# проверка целостности части данных репозитория
restic check --read-data-subset=5%

Скрипт запускается по расписанию (systemd timer или cron), а результат каждого запуска должен попадать в мониторинг: «копия не сделалась» это событие, о котором нужно узнать сразу, а не через месяц.

Копия существует, только если из неё восстановились

Самое важное правило. Резервное копирование, которое ни разу не проверяли восстановлением, - это надежда, а не защита. Я закладываю проверку в регламент:

1. Раз в месяц восстанавливаю случайный набор файлов в отдельную папку и сравниваю с оригиналом.
2. Раз в квартал разворачиваю копию базы данных на тестовом сервере и проверяю, что учётная система с ней запускается.
3. Записываю, сколько времени заняло восстановление. Это ответ на вопрос «сколько мы будем стоять, если сервер умрёт».

# восстановление последней копии во временную папку для проверки
restic restore latest --target /tmp/restore-test --include /srv/data/documents
diff -r /srv/data/documents /tmp/restore-test/srv/data/documents && echo "Совпадает"

Короткий чек-лист

• Есть список критичных данных и требования к частоте копий.
• Минимум одна копия хранится вне офиса и недоступна для удаления с рабочих компьютеров.
• Копии зашифрованы, ключи хранятся отдельно.
• Об ошибках копирования сразу приходит уведомление.
• Восстановление регулярно проверяется, результат записывается.

Резервное копирование - часть работ по серверам и DevOps и обязательный пункт при обслуживании инфраструктуры.