Резервное копирование в облако: схема хранения и восстановление

Рабочая схема: быстро восстановить рядом, пережить аварию — вне площадки

• Основные данные: 1С, файлы, почта, виртуальные машины, настройки сети.
• Локальная копия: быстрый возврат файла или сервера без ожидания скачивания терабайтов.
• Копия вне площадки: доступна, когда основной сервер и локальное хранилище потеряны.
• Независимый контроль: защищённая учётная запись, оповещения и аварийный комплект восстановления.

Локальный RAID защищает от части отказов дисков; он не сохраняет историю удалений и не заменяет backup. Облачная ВМ с той же учётной записью администратора и доступным на запись сетевым диском также может попасть под ту же атаку.

Базовые принципы разобраны в статье об архитектуре резервного копирования. Здесь сосредоточимся на выносе копии за пределы основной площадки.

Облако, синхронизация, snapshot и backup — разные вещи

Схема 3–2–1 — ориентир: рабочие данные и две копии, раздельные носители/системы хранения, одна копия вне площадки. Важнее проверить общие причины отказа: один tenant, один администратор, один договор, один ключ или один канал могут объединить формально разные копии.

Независимая или неизменяемая копия усиливает схему. Но ни количество объектов, ни само слово «облако» не доказывают сохранность данных.

Шаг 1. Составьте паспорт данных и восстановления

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

1. Объект: сервер, база, каталог, объём занятого места, владелец.
2. Согласованная копия: каким средством и в какой момент она получается.
3. RPO: сколько последних изменений допустимо потерять.
4. RTO: сколько времени есть на возврат работоспособного процесса.
5. Хранение: ежедневные точки, длительная история, особые требования.
6. Приёмка: кто подтвердит корректность восстановленных данных.

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

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

Шаг 2. Рассчитайте объём: исходные данные плюс сохранённые изменения

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

Оценка для заданного горизонта хранения:
V = (B + ΣΔ + G + M) / (1 - R)
B — объём первой сохранённой копии
ΣΔ — новые уникальные данные всех сохраняемых изменений
G — дополнительные длительные/полные копии, не учтённые выше
M — метаданные, временные данные и служебный запас
R — доля свободной ёмкости, например 0,25

Условный пример: после пилота первая копия занимает 2 ТБ, прирост сохранённых уникальных данных — 50 ГБ в сутки. Для 30 ежедневных точек считаем 29 приростов: 2 + 29 × 0,05 = 3,45 ТБ. Добавим условные 0,25 ТБ на служебные данные: 3,70 ТБ. Чтобы оставить 25% ёмкости свободными, нужно 3,70 / 0,75 ≈ 4,93 ТБ. Это пример без дополнительных GFS-копий, заблокированных старых версий и архивного класса.

• Все числа примера — в десятичных ТБ/ГБ: 1 ТБ = 1000 ГБ. Если программа показывает TiB/GiB, переведите единицы до расчёта.
• 50 ГБ — измеренный прирост хранения, а не обещанный коэффициент дедупликации.
• При еженедельных независимых full или длинной блокировке объектов объём будет другим.
• В эластичном облаке вместо свободных дисков контролируют квоту и бюджет. Формула помогает установить пороги, но не создаёт скидку на фактически хранимые данные.

Подробно о локальном хранилище — где хранить резервные копии.

Шаг 3. Проверьте и выгрузку, и обратный канал

Скорость исходящего интернета ограничивает первую копию, входящий канал и хранилище назначения — массовое восстановление. Заявленные 1 Гбит/с не означают, что backup получит эту скорость весь день: есть рабочий трафик, VPN, задержка, потери и лимиты API.

Минимальное время передачи, часы:
t = V_ГБ × 8000 / (S_Мбит/с × 3600)

2 ТБ = 2000 ГБ при 100 Мбит/с: 44,4 часа
При полезной скорости 70 Мбит/с: 63,5 часа
50 ГБ при полезных 70 Мбит/с: около 1,59 часа

Это арифметическая оценка для десятичных единиц; полезную скорость измеряют. Тысячи мелких объектов, чтение источника, шифрование, распаковка, сборка дисков и восстановление журналов увеличивают полное время.

• Первую полную копию планируют отдельным окном, затем проверяют возраст облачной точки.
• Если дневные изменения не помещаются в доступное окно, очередь копирования будет расти.
• Для жёсткого RTO рассмотрите локальный быстрый backup или восстановление рядом с облачным репозиторием.
• Заранее согласуйте seed/export на носителе, если провайдер предоставляет такую услугу; это не универсальная возможность.

Ошибка проекта: обещать восстановление 2 ТБ за четыре часа при обратном канале 100 Мбит/с, потому что сам backup успешно запускался каждую ночь.

Скачивание — только часть времени восстановления

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

Пример: локальная копия создана в 02:00, а перенос в облако оборвался. В 15:00 площадка потеряна; последняя пригодная внешняя точка содержит данные вчерашней ночи. Время запуска сегодняшнего задания не делает облачный RPO равным 13 часам.

Шаг 4. Выберите способ, соответствующий вашим нагрузкам

Не переносите живой каталог PBS или репозиторий другого продукта утилитой синхронизации наугад. Полнота объектов, индексы, блокировки, retention и служебные операции должны оставаться согласованными.

В PBS Sync Jobs параметр remove-vanished может удалять на целевой стороне исчезнувшие объекты источника. В защищённой внешней копии это отдельное осознанное решение. Нужны собственная политика хранения и проверка того, что удаление источника не уничтожит нужную историю. Pull на независимой площадке уменьшает необходимость хранить её управляющие секреты на источнике, но сам по себе не делает копию неизменяемой.

Возможности Veeam сверяют с руководством Backup Copy. Здесь не предполагается, что любое из названных ПО работает с любым S3 и любой блокировкой без дополнительных условий.

Шаг 5. Разделите доступ к данным, backup и облаку

• Сервисная учётная запись: доступ только к нужному бакету/префиксу и требуемым операциям.
• Администратор облака: отдельный вход с MFA; ключ администратора не кладут на защищаемый сервер.
• Оператор восстановления: проверенный путь получить копию и ключ расшифрования при потере обычной инфраструктуры.
• Сеть: исходящий TLS к нужным endpoint; управление — через VPN/выделенный management. Не открывайте SMB/NFS и административные консоли всему интернету.
• Аудит: изменения IAM, retention, ключей, жизненного цикла и удалений отслеживаются отдельно от журнала backup.

Кража ключа S3 с правами удаления может лишить компанию копий даже при исправном шифровании. Шифрование скрывает содержимое; оно не запрещает удалить зашифрованный объект. Отдельный tenant помогает только при независимых полномочиях, контактах восстановления и оплате.

Проверьте потерю AD, DNS и менеджера паролей: аварийный доступ не должен целиком зависеть от них же. Аварийные секреты хранят отдельно и выдают по установленному порядку, а не в общей TXT-папке.

Object Lock: защита версий, а не универсальная кнопка

S3 Versioning хранит версии, но при достаточных правах их можно удалить. Object Lock ограничивает удаление защищённой версии на срок; governance и compliance имеют разную модель обхода и управления. Эти различия описаны в документации Amazon S3; у выбранного S3-провайдера сверяйте собственные правила, например Yandex Object Storage.

• Подтвердите поддержку версии продукта и режима неизменяемости поставщиком backup.
• Задайте срок защиты, учитывая обнаружение шифровальщика и период хранения чистой точки.
• На тестовом наборе проверьте, какие удаления запрещены, какие разрешены и что видит restore.
• Учтите стоимость защищённых старых версий и невозможность немедленно очистить их.
• Не отправляйте служебные lock-файлы и временные объекты под произвольную default-retention без проверки совместимости.

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

Практика: пилот restic → S3 на Linux

Пример рассчитан на выделенный Linux backup-узел и уже подготовленный непубличный S3-бакет. Источник /srv/backup-source содержит согласованные файлы для копирования, а не открытые файлы живой СУБД. Команды запускаются в Bash; секреты вводят интерактивно. Endpoint s3.backup.example.net и имя бакета — учебные значения, их обязательно заменяют.

1. Проверьте поддержку REST API S3, endpoint, регион, CA/TLS, квоту и лимиты операций.
2. Создайте отдельный бакет/префикс, запретите публичный доступ, выдайте сервисный ключ.
3. Уточните требуемые операции IAM для restic, включая удаление служебных locks. Политика «только PutObject» не является универсально рабочей.
4. Установите restic из доверенного источника, зафиксируйте версию. Ниже использованы команды из stable-документации, которая на дату проверки показывала 0.19.1.

restic version
restic help backup
restic help restore
restic help forget
getent ahosts s3.backup.example.net
openssl s_client -connect s3.backup.example.net:443   -servername s3.backup.example.net -verify_hostname s3.backup.example.net -verify_return_error </dev/null

Параметры OpenSSL проверяют цепочку доверия и имя сервера; SNI сам по себе не проверяет имя. DNS и TLS подтверждают отдельные этапы подключения, но не права на бакет и не работоспособность backup. Не обходите ошибки сертификата отключением проверки. Способ установки приведён в официальной инструкции.

Шаг 6. Подготовьте секреты и новый репозиторий

Войдите в выделенную административную Bash-сессию backup-узла. Пример использует каталог root с доступом только владельцу; для службы права адаптируют под её отдельную учётную запись. Не включайте set -x и не записывайте значения ключей в команды или тикет.

sudo -i
umask 077
install -d -m 700 /root/.config/restic-cloud

# Только для НОВОГО репозитория: не перезаписывать существующий ключ
test ! -e /root/.config/restic-cloud/repository.pass || exit 1
openssl rand -base64 48 > /root/.config/restic-cloud/repository.pass
chmod 600 /root/.config/restic-cloud/repository.pass

export RESTIC_PASSWORD_FILE=/root/.config/restic-cloud/repository.pass
export RESTIC_REPOSITORY='s3:https://s3.backup.example.net/company-backup/linux-files'
read -r -p 'S3 access key: ' AWS_ACCESS_KEY_ID
read -r -s -p 'S3 secret key: ' AWS_SECRET_ACCESS_KEY
printf '\n'
export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY
# Регион возьмите из документации своего провайдера
read -r -p 'S3 region: ' AWS_DEFAULT_REGION
export AWS_DEFAULT_REGION

restic init

Ключ репозитория здесь генерируется, а не придумывается. Сохраните его аварийную копию в независимом защищённом хранилище до передачи ценных данных. Потеря S3-ключа обычно решается его перевыпуском; потеря единственного ключа расшифрования может сделать сохранённые данные недоступными.

init выполняют один раз для нового репозитория. Для существующего используют его ключ и restic snapshots, не создают всё заново. Backend S3 и способы передачи секретов описаны в руководстве по репозиториям; управление ключами — в разделе Encryption. В production значения для задания подаются через защищённый механизм запуска; интерактивная сессия не превращается в расписание автоматически.

Шаг 7. Скопируйте и проверьте пилотный набор

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

findmnt -T /srv/backup-source
du -sh /srv/backup-source
restic backup /srv/backup-source --host backup01 --tag cloud-pilot
# Проверить код сразу после restic, до следующей команды
printf 'backup exit code: %s\n' "$?"
restic snapshots --host backup01 --tag cloud-pilot

Проверьте созданную точку и полноту исходных файлов. Для backup код 0 означает успешный проход, код 3 — часть файлов не прочитана; такой результат требует разбора, а не зелёного отчёта. Точная трактовка других кодов зависит от команды и версии. Подробности — Backing up.

Первая копия передаёт исходный набор; дальше restic переиспользует сохранённые данные. Snapshot в терминологии restic — точка репозитория, а не snapshot диска гипервизора. Дедупликация не даёт заранее известного коэффициента: сжатые архивы и заново зашифрованные файлы могут почти не сокращаться.

Для 1С и СУБД сначала получите согласованную копию

Запущенный PostgreSQL, SQL Server и файловая база 1С требуют собственного порядка получения пригодной точки. Нельзя гарантировать результат, просто читая их изменяющиеся файлы во время работы. Облачный канал переносит то, что подготовлено источником; он не исправляет несогласованность.

• PostgreSQL: логический dump либо поддерживаемая физическая копия с необходимыми WAL и параметрами восстановления.
• SQL Server: штатные backup и журналы согласно модели восстановления и требуемой точке возврата.
• 1С: способ зависит от файлового/клиент-серверного варианта; проверяется запуск восстановленной информационной базы.
• ВМ: поддерживаемый backup гипервизора и обработка приложений там, где она требуется.

Выгрузки должны попадать в финальный каталог только после успешного завершения и проверки. Файл, который ещё записывается, не следует считать готовым. Удерживайте исходную пригодную копию до подтверждения внешней передачи. Схемы PostgreSQL описаны в Backup and Restore; практический разбор 1С — резервное копирование 1С.

Шаг 8. Проверяйте структуру, данные и приложение отдельно

Проверка структуры не равна чтению всех сохранённых блоков; чтение блоков не равно успешному запуску программы. Разделите эти уровни в отчёте.

restic check
# Частичное чтение: только первая из семи частей, не вся копия
restic check --read-data-subset=1/7
# Полное чтение данных: заранее оценить окно и стоимость скачивания
restic check --read-data

Для покрытия частями нужно пройти 1/7, 2/7 … 7/7; репозиторий тем временем может меняться. Один постоянно повторяемый 1/7 не становится полной проверкой. Команды и ограничения описаны в Working with repositories. Сохраните результат, дату и объём прочитанного; при платном egress запланируйте бюджет на контроль.

Шаг 9. Восстановите на другую машину и в отдельный каталог

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

restic snapshots --host backup01 --tag cloud-pilot
# Подставить полный ID выбранной пригодной точки из snapshots
read -r -p 'Snapshot ID для проверки: ' SNAPSHOT_ID
restic ls "$SNAPSHOT_ID"
install -d -m 700 /srv/restore-test
restic restore "$SNAPSHOT_ID" --target /srv/restore-test

При исходном абсолютном пути файлы окажутся под /srv/restore-test/srv/backup-source. Цель должна быть новым изолированным каталогом с достаточным местом. Restore не выполняют поверх рабочей системы для учебной проверки.

1. Сверьте контрольный набор файлов, размеры и содержимое, владельцев и требуемые права.
2. Для СУБД выполните её собственный restore на изолированном сервере и проверьте нужную точку.
3. Запустите приложение без опасных обменов, фоновых рассылок и подключения к production.
4. Попросите владельца процесса открыть документы и выполнить согласованную контрольную операцию.
5. Запишите фактические времена, ограничения и объём скачивания.

Особенности путей и выборочного восстановления приведены в Restoring from backup. Возврат ACL и специальных метаданных зависит от ОС, привилегий и продукта; наличие файлов само по себе не подтверждает возврат всех прав.

Шаг 10. Сначала покажите план удаления, потом утверждайте очистку

Пример политики для пилота: 14 ежедневных, 8 недельных и 12 месячных точек. Это не 34 гарантированно разных снимка: периоды могут пересекаться. Выберите значения по задаче бизнеса и объёму.

restic forget --host backup01 --tag cloud-pilot   --group-by host,paths   --keep-daily 14 --keep-weekly 8 --keep-monthly 12   --dry-run

Это только план. Проверьте host, paths, tag, даты и сохраняемые точки. Применение forget и prune согласуют отдельно; здесь нет команды автоматического удаления. После забывания snapshots не все блоки немедленно исчезают: место освобождают обслуживанием репозитория.

Не настройте облачный lifecycle на удаление объектов по их возрасту: старый pack может содержать данные, нужные свежему snapshot. Retention backup и lifecycle облака согласуют как одну систему. Процедура — в Removing backup snapshots.

Расписание и мониторинг: следить за отсутствием результата

У restic нет собственного постоянно работающего планировщика. В Linux используют systemd timer/cron либо согласованную оболочку; в Windows — подходящий планировщик. Расписание должно учитывать длительность прошлого запуска и обслуживание, а секреты — быть доступны службе без ручного ввода.

• Перед копией: доступность источника, завершение dump, свободное место, время/NTP.
• После: код завершения, snapshot, возраст данных, ошибки чтения, длительность и прирост.
• Периодически: проверка блоков, восстановление, запас квоты, счета и ротация секретов.
• Независимый сигнал: нет отчёта к установленному времени — инцидент, даже если ошибку никто не прислал.

Запретите перекрывающиеся задания одной политики и согласуйте окна prune/check с копированием. Код 3 нельзя превращать в успех через игнорирование ненулевого результата. Журналы не должны содержать пароли и полные клиентские данные. Храните историю: когда начали расти очередь, длительность, объём и возраст внешней копии.

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

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION
unset RESTIC_PASSWORD_FILE RESTIC_REPOSITORY SNAPSHOT_ID
exit

Что входит в стоимость, кроме гигабайтов

• Хранение: рабочие объекты, версии, retention, временные данные и минимальный оплачиваемый срок.
• Операции: запись, чтение, перечисление объектов и запросы приложения.
• Восстановление: исходящий трафик, извлечение из архивного класса, временные диски и ВМ.
• Эксплуатация: лицензии, мониторинг, проверка копий и работа инженеров.
• Защита: независимая площадка, неизменяемость, аудит и аварийный доступ.

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

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

Три прикладные ситуации, которые стоит отрепетировать

Это учебные сценарии, а не описания выполненных клиентских работ. В третьем случае нельзя возвращать заражённую ВМ в прежнюю сеть только потому, что архив успешно распаковался. Сначала устанавливают границы инцидента и пригодность точки.

Как принять облачное копирование в эксплуатацию

1. Потеря локальной копии не закрывает доступ к внешней.
2. Подтверждены состав и согласованность данных, а не только завершение upload.
3. Измеренные объём и скорость позволяют выполнить RPO/RTO.
4. Рабочий ключ не даёт административных полномочий на всё облако.
5. Защита от удаления проверена в заявленной модели, если она предусмотрена.
6. Контрольная точка восстановлена отдельно, результат принят владельцем процесса.
7. Потеря исходного сервера, AD и обычного менеджера паролей отрепетирована.
8. Назначены ответственные, сигналы об отсутствии копии и сроки повторной проверки.

Если выполнена только первая выгрузка, корректный статус — «данные переданы». Если проверены блоки — «целостность проверена». Статус «восстановление проверено» требует отдельного восстановления и подтверждения результата.

Два документа для внедрения

Резервное копирование под задачу компании

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