Резервное копирование на сервере: схема 3-2-1 на практике

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

Что именно означает 3-2-1

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

RAID не заменяет резервную копию: он может сохранить доступность при отказе диска, но не вернёт файлы, удалённые администратором, испорченные приложением или зашифрованные вредоносной программой. Снимок на том же массиве тоже не считается независимой копией: поломка массива или доступ злоумышленника к серверу могут затронуть и данные, и снимок.

Термин. RPO — допустимый интервал потери данных: например, при ежедневном запуске копирования после сбоя вы можете потерять изменения, сделанные с предыдущего запуска. RTO — целевое время восстановления сервиса.

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

Выберите две независимые точки хранения

Локальная копия ускоряет восстановление больших объёмов: данные не нужно скачивать через интернет. Удалённая защищает от кражи, пожара, отказа площадки и инцидента, который затронул весь сервер. Цена вопроса — место, трафик, обслуживание и время, которое потребуется на тестовое восстановление.

Удобный базовый вариант — локальный репозиторий restic на отдельном диске и второй репозиторий в удалённом S3-совместимом хранилище. Схема соответствует 3-2-1 только если удалённая копия не лежит на том же физическом хранилище, а доступ к ней не сводится к тем же правам, что и на сервере.

Соберите резервирование с restic

Пример ниже рассчитан на Linux и restic 0.16.4. В командах предполагаются установленные restic и подключённый отдельный локальный диск, смонтированный в /mnt/backup. Для удалённого репозитория нужны созданный bucket и доступ, настроенный через переменные окружения AWS или механизм секретов. Не записывайте пароль репозитория и ключи доступа в скрипт, историю команд или открытый конфигурационный файл.

1. Определите, что копировать. В примере это каталоги /etc, /home и /srv. Перед запуском проверьте, где приложение хранит загрузки, конфигурацию и другие данные, без которых его нельзя восстановить. Проверка: перечень путей покрывает данные, нужные для запуска сервиса.
2. Подготовьте секрет пароля. Укажите путь к файлу, содержащему длинный уникальный пароль репозитория. Доступ к файлу должен быть только у системной учётной записи, запускающей резервирование. Проверка: эта учётная запись может прочитать файл, остальные пользователи сервера — нет.
3. Создайте локальный репозиторий. Переменная задаёт место хранения, а restic создаёт там зашифрованный репозиторий. Проверьте, что диск действительно отдельный: если он не смонтирован, путь может оказаться обычной папкой на основном диске.

export RESTIC_PASSWORD_FILE=/root/.config/restic/password
RESTIC_REPOSITORY=/mnt/backup/restic restic init

Проверка: команда завершилась без ошибки и сообщила, что репозиторий создан. Если пароль ещё не настроен, сначала организуйте его безопасное хранение; не подставляйте значение прямо в команду.

1. Создайте удалённый репозиторий. Укажите реальный bucket и путь по формату, который поддерживает ваше S3-совместимое хранилище. Перед запуском подключите учётные данные через секрет-хранилище или защищённые переменные среды. Проверка: restic init завершился успешно для удалённого адреса.

RESTIC_REPOSITORY=s3:s3.amazonaws.com/company-backups/prod-01 restic init

В примере company-backups — условное имя bucket, его нужно заменить на своё. Для другого S3-провайдера адрес может отличаться — сверьте формат с документацией провайдера и restic.

1. Сохраните данные в оба места. Запустите команды отдельно для каждого репозитория. Проверка: обе команды завершились успешно, а команда snapshots показывает свежую резервную копию в каждом месте.

RESTIC_REPOSITORY=/mnt/backup/restic restic backup /etc /home /srv
RESTIC_REPOSITORY=s3:s3.amazonaws.com/company-backups/prod-01 restic backup /etc /home /srv

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

Согласуйте копию и проверьте восстановление

Файлы, которые приложение меняет во время копирования, могут попасть в резерв не в согласованном состоянии. Особенно это важно для баз данных и загружаемых пользователями файлов. Для базы используйте поддерживаемый самой СУБД способ резервирования или сначала создавайте согласованный экспорт, а уже его включайте в копию. Не считайте копию открытых файлов гарантированно пригодной только потому, что restic завершил команду.

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

RESTIC_REPOSITORY=/mnt/backup/restic restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

Повторите её для удалённого репозитория. До настройки автоматической очистки проверьте, что нужные точки восстановления действительно создаются: слишком короткое хранение может удалить единственную копию, которая ещё не испорчена.

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

Когда схема ломается

• Копия на том же диске. Проверьте устройство, на которое указывает точка монтирования. Если диск не подключился, резервирование может записать данные на основной том и незаметно съесть его свободное место.
• Обе копии доступны на запись с сервера. Используйте отдельные учётные записи, ограниченные права и, если сервис это поддерживает, защиту от удаления или неизменяемое хранение. Отдельная площадка без отдельного контроля доступа — неполная изоляция.
• База скопирована как набор активных файлов. Используйте согласованный экспорт или штатный механизм СУБД, затем резервируйте полученный результат вместе с другими данными.
• Никто не проверял восстановление. Проводите тест не только на чтение списка резервных копий, но и на восстановление в чистую временную среду. Фиксируйте, сколько времени заняли скачивание, распаковка и запуск приложения.

Если объём велик, добавьте метрики: время последнего успешного запуска, размер новых данных, свободное место и возраст самой свежей точки. Для удалённого хранилища отдельно учитывайте цену хранения и исходящего трафика: восстановление после сбоя может стоить дороже обычной загрузки копий.

Что сделать дальше

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