Надёжная система резервного копирования возвращает бизнес к работе после удаления данных, отказа оборудования или атаки. Для этого нужны согласованные сроки, независимые копии, защищённый доступ и проверенный порядок восстановления. Покупка сервера или лицензии решает только часть задачи.
Понятные приоритеты
Что восстанавливать первым и какую потерю данных можно принять.
Несколько путей возврата
Локальная авария не должна лишать компанию всех копий.
Измеримый результат
Время восстановления подтверждается проверкой приложения.
Управляемые расходы
Объём, каналы, лицензии и сопровождение рассчитываются заранее.
Начните с бизнеса: что должно работать после аварии
Составьте список сервисов вместе с их владельцами. «Скопировать все серверы» — слишком общее задание: бухгалтерии нужна работающая 1С, отделу продаж — CRM, сотрудникам — доступ к документам. У каждого сервиса свои данные и зависимости.
RPO: допустимая потеря изменений
Как далеко можно вернуться назад по времени без неприемлемого ущерба.
- Назначьте цель для каждого критичного сервиса.
- Учтите задержку записи, передачи и появления пригодной точки.
- Проверяйте свежесть копии на резервной площадке отдельно.
RTO: допустимый перерыв
За какое время нужно вернуть согласованный объём работы сервиса после сбоя.
- Определите момент начала и окончания измерения.
- Заложите доступ к копии, инфраструктуре и специалистам.
- Завершайте проверку рабочей операцией пользователя.
Пример требований, а не готовый норматив: для учётной системы выбраны RPO 1 час и RTO 4 часа, для архива документов — другие значения. Сначала проверяют достижимость целей на имеющейся инфраструктуре. Запуск задания каждый час сам по себе не подтверждает выполнение RPO.
- Данные: базы, документы, вложения, почта, общие папки и внешние хранилища приложений.
- Среда: версии ОС и приложений, настройки, сертификаты, лицензии и установочные материалы.
- Зависимости: DNS, служба каталогов, сеть, СУБД, хранилище секретов и интеграции.
- Ответственность: кто объявляет аварию, кто восстанавливает и кто принимает результат.
Правило 3-2-1-1-0: ориентир для схемы защиты
Рабочие данные и как минимум две резервные копии.
Разные носители или технологии с учётом общих причин отказа.
Копия, доступная после потери основного помещения.
Неизменяемая либо отключённая в рамках выбранной модели защиты.
Критерий проверенного восстановления, а не обещание отсутствия сбоев.
Расширенный подход описан у Veeam. Это ориентир проектирования, а не сертификат надёжности. Две папки на одном массиве сохраняют общие риски; облачный уровень тоже нужно проверять на независимость прав, площадки и пути восстановления.
Одна внешняя неизменяемая копия может одновременно выполнять несколько условий правила. Числа не означают, что нужно покупать пять отдельных устройств. Важнее разобрать реальные сценарии потери и доказать, какая копия останется доступной в каждом из них.
Из каких уровней состоит рабочая система
Определены объекты и согласованный способ получения данных.
Отдельный репозиторий для оперативных точек восстановления.
Внешнее хранение, неизменяемость или отключённые носители по проекту.
Чтение копии, запуск приложения и контрольная операция.
Быстрая локальная копия
Помогает вернуть удалённый файл, базу или виртуальную машину без длительной передачи по внешнему каналу.
- Проверяют скорость чтения и записи под реальной нагрузкой.
- Репозиторий отделяют от повседневного доступа сотрудников.
- Потеря основного массива не должна уничтожать этот уровень.
Независимая внешняя копия
Нужна для сценария, при котором оборудование или помещение основной площадки недоступны.
- Проверяют географию, канал и отдельное управление.
- Определяют способ получения данных после аварии.
- Учитывают выдачу из архива, загрузку, ключи и стоимость.
Защита от удаления
Ограничивает изменение уже записанных точек, если атака затронула рабочую инфраструктуру.
- Выбирают поддерживаемую неизменяемость или физическое отключение.
- Проверяют срок удержания, права обхода и покрытие зависимостей.
- Ключи и каталог также включают в план защиты.
Управление и контроль
Задания, каталог, доступ, уведомления и инструкции должны пережить отказ защищаемой среды.
- Нужны отдельные роли и контролируемый аварийный доступ.
- Конфигурацию СРК и инструкции сохраняют независимо.
- Назначают ответственного за ошибки и повторные проверки.
Логическая и физическая изоляция рассматриваются в материале Кибер Бэкап о защите копий. Ограничения конкретного хранилища нужно сверять с его документацией.
Выбирайте способ копирования под приложение
Образ виртуальной машины удобен для возврата сервера целиком. Для работающей СУБД важны согласованная точка и штатный механизм восстановления. Одно задание может не покрывать документы вне базы, секреты, внешние тома и настройки интеграций.
- Виртуальные машины: совместимость гипервизора, гостевая обработка и способ возврата целой ВМ или отдельных данных.
- Базы данных: штатные бэкапы, журналы и поддержка согласованности выбранной СРК.
- Файлы: содержимое, права, владельцы и история, нужная для возврата после ошибочного изменения.
- Корпоративные приложения: совместное восстановление базы, файлов, конфигурации и зависимостей.
Например, в SQL Server требования к копированию журналов зависят от модели восстановления. Для full recovery нужны и резервные копии журнала; нельзя считать произвольный набор файлов базы достаточным планом. См. документацию Microsoft.
Зеркало может сохранить ошибочное удаление, а реплика — получить повреждённые изменения. Проверяйте, есть ли отдельная пригодная история и возможность возврата к нужному моменту. Снимок на том же устройстве сохраняет зависимость от этого устройства.
Рассчитайте ёмкость и время до закупки
Для расчёта нужны объём защищаемых данных, измеренный прирост, период хранения, схема полных и последующих копий, резерв свободного места и параллельные операции. Коэффициенты дедупликации и сжатия берут из пилота на своих данных.
Далее учитывают дополнительные полные копии, метаданные, защиту, рост и резерв операций.
Это только время переноса, без очереди, подготовки, запуска и проверки приложения.
Условный пример: 2 ТБ базы и 100 ГБ новых сохраняемых блоков в сутки за 30 интервалов дают 5 ТБ до учёта сжатия, служебных данных и резерва. Это упрощённая оценка для одной базы и цепочки изменений, а не готовый размер репозитория. Периодические полные копии и неизменяемое удержание могут существенно изменить расчёт.
Для передачи 1 ТБ при измеренной полезной скорости 50 МБ/с потребуется около 5 часов 33 минут, если считать десятичные единицы. Следовательно, такое полное чтение по каналу уже не укладывается в RTO 4 часа. Вывод — менять способ возврата или ресурсы, а затем проверять весь сценарий. Номинальные «1 Гбит/с» на интерфейсе не равны полезной скорости восстановления.
- Измерьте первичное копирование и передачу обычного суточного объёма.
- Проверьте конкуренцию записи, проверки, очистки и восстановления.
- Учтите временное место для развёрнутой системы и служебных операций.
- Согласуйте срок неизменяемости с ротацией и ростом объёма.
- Посчитайте внешнюю выдачу, архивное извлечение, лицензии и сопровождение.
Что проверять при выборе программы резервного копирования
Вместо выбора «самой надёжной марки» составьте перечень защищаемых платформ. Среди рассматриваемых продуктов могут быть Veeam Backup & Replication, Кибер Бэкап, RuBackup и Proxmox Backup Server. Название продукта не подтверждает поддержку любого гипервизора, СУБД или хранилища.
- Точные версии ОС, гипервизоров, баз и приложений в матрице совместимости.
- Способы восстановления и ограничения редакции, лицензии и поддержки.
- Поддержка выбранного дискового, объектного или ленточного уровня.
- Управление ключами, ролями, журналами и независимым доступом.
- Возможность проверить копию и документировать восстановление.
Например, у Proxmox Backup Server предусмотрены задания проверки данных, а правила хранения и освобождение места требуют понимания prune и garbage collection. Проверка целостности хранилища полезна, но не заменяет запуск приложения и приёмку его работы. Конкретную конфигурацию выбирают после пилота на нужной версии.
Контролируйте пригодность копий, а не только зелёный статус
| Сигнал | Что он показывает | Что делать |
|---|---|---|
| Возраст пригодной точки | Укладывается ли конкретный сервис и внешний уровень в RPO | Выяснить причину задержки и риск потери изменений |
| Ошибки и пропущенные объекты | Не остались ли базы, тома или новые ВМ без защиты | Назначить ответственного; проверить повтор и покрытие |
| Рост и свободное место | Хватит ли ресурсов для новых точек и служебных операций | Пересчитать прогноз; согласовать расширение или политику |
| Внешняя копия и защита | Есть ли подтверждённая передача, доступ и нужный режим удержания | Проверить конкретные точки, права и журналы |
| Последний тест возврата | Когда и с каким результатом реально проверяли сервис | Повторить по графику и после существенных изменений |
Регламент должен отвечать на три вопроса: кто получает уведомление, за какое время начинает разбор и кто подтверждает устранение. Сообщение в общий почтовый ящик без ответственного не является завершённым процессом обслуживания.
Принимайте систему через восстановление сервиса
Сначала согласуйте сценарии и критерии успеха. Затем выполните проверку на выделенной среде с контролем интеграций. Подход к периодическому возврату данных описан в AWS Well-Architected.
- Проверить покрытие. Сверить список сервисов, данные и зависимости с реально создаваемыми точками.
- Выбрать копию и сценарий. Удалённый файл, потеря сервера, потеря площадки или недоступность основного управления.
- Получить независимый доступ. Достать инструкцию, каталог, ключи и нужные установочные материалы.
- Восстановить в изоляции. Зафиксировать время, порядок действий, ресурсы и возникающие ошибки.
- Проверить работу. Открыть базу, документ или приложение, выполнить согласованную контрольную операцию.
- Сравнить с целями. Сопоставить фактическое время и возраст данных с RTO/RPO; устранить расхождения и назначить повтор.
Не назначайте одинаковую периодичность всем сервисам по привычке. График зависит от критичности и изменений: рост базы, смена версии приложения, хранилища, ключа или схемы доступа требуют пересмотра. Это также отмечено в руководстве AWS по тестированию восстановления баз.
Что должно остаться после внедрения
✓Реестр сервисов, владельцев и целей RTO/RPO
✓Схема копий, прав и независимых путей доступа
✓Регламент заданий, мониторинга и реакции на ошибки
✓Протокол возврата с результатом проверки приложения
Две памятки для начала проекта
Частые вопросы
Достаточно ли NAS для резервного копирования?
NAS может быть одним из уровней хранения. Нужно проверить независимость от рабочих данных, права, историю, внешнюю копию и восстановление. Само наличие отдельной коробки не закрывает все сценарии.
Можно ли обойтись только облачной копией?
Это проверяют по целям сервиса, доступу и полезной скорости возврата. Нужны расчёт полной загрузки, стоимость, защита учётной записи и ключей. Для короткого RTO может потребоваться локальный путь или заранее подготовленная резервная среда.
Как часто делать копии?
По допустимой потере изменений, особенностям приложения и времени создания пригодной точки. Дополнительно учитывают задержку внешней передачи. Расписание подтверждают измерениями и проверкой восстановления.
Успешное задание означает, что сервис восстановится?
Нет. Задание могло не охватить нужные данные, а доступ, ключи или зависимости могут оказаться недоступными. Нужен возврат в проверочную среду и контрольная операция приложения.
Когда понадобится репликация или резервная площадка?
Когда возврат из резервной копии не укладывается в согласованное время или нужна иная схема доступности. Репликация дополняет историю копий; её самостоятельную пригодность при удалении или атаке тоже проверяют.
Сколько стоит надёжная система?
Цена зависит от объёма, приложений, сроков возврата и хранения, площадок и сопровождения. Сравнивайте полный состав: лицензии, оборудование, каналы, внешнюю выдачу, тестовую среду и работу специалистов. Обоснованная оценка начинается с брифа и пилота.
Спроектируем резервное копирование под задачи компании
Разберём критичные сервисы, согласуем цели и проверим текущие копии. Подготовим схему, расчёт ресурсов и порядок приёмки, чтобы решение оценивалось по способности вернуть бизнес к работе.
Обсудить систему резервного копирования