Как выбрать место для хранения резервных архивов: критерии, варианты и ошибки

Выбор места для хранения резервных копий — это не вопрос «куда положить файлы», а архитектурное решение, определяющее, восстановится ли бизнес после сбоя, кибератаки или пожара. Правильный выбор балансирует между скоростью восстановления (RTO), допустимой потерей данных (RPO), стоимостью владения (TCO), требованиями регуляторов и физической изоляцией копий от производственной среды. В статье разбираем основные варианты размещения, ключевые параметры сравнения и типичные ошибки, которые приводят к невосстанавливаемым данным.

Почему «просто внешний диск» — это не стратегия

Многие начинают с подключения USB-диска к серверу или настройки бэкапа на второй раздел того же RAID-массива. Это покрывает только сценарий «упал один диск» или «случайно удалили файл вчера». Оно не защищает от: пожара/наводнения в серверной, шифровальщика, зашифровавшего все доступные сетевые шары, кражи оборудования, ошибки администратора, удалившего и продакшн, и бэкап одной командой, а также от требований аудиторов к географической изоляции копий.

Правило 3-2-1 остаётся базовым ориентиром: три копии данных на двух разных типах носителей, одна копия — вне основной площадки (offsite). Современные интерпретации расширяют его до 3-2-1-1-0: одна копия — офлайн/immutable (неизменяемая), ноль ошибок при верификации восстановления. Место хранения напрямую определяет, какие пункты этого правила вы можете выполнить.

Ключевые критерии оценки места хранения

Перед сравнением конкретных вариантов зафиксируйте свои требования по каждому параметру. Без исходных цифр любой выбор будет случайным.

• RTO (Recovery Time Objective) — за сколько часов/минут нужно восстановить критичные сервисы. От этого зависит, допустимо ли «достать ленты из сейфа и доехать до ДЦ» или нужен мгновенный доступ к горячим копиям.
• RPO (Recovery Point Objective) — максимально допустимая потеря данных во времени. Если RPO = 0, нужна синхронная репликация; если RPO = 24 часа — достаточно ночного бэкапа.
• Объём и прирост данных — текущий размер полного бэкапа, ежедневный инкремент, горизонт роста на 3–5 лет. От этого зависят капитальные расходы (CapEx) на железо и операционные (OpEx) на облачное хранилище.
• Тип нагрузки — в основном последовательная запись (бэкап) и редкое, но критичное последовательное чтение (восстановление), или частые случайные доступы (например, для мгновенного монтирования виртуальных машин из бэкапа).
• Требования комплаенса — 152-ФЗ (персональные данные), ГОСТ Р 57580, PCI DSS, GDPR, отраслевые регуляторы (ЦБ, ФСТЭК, ФСБ). Часто диктуют: хранение только на территории РФ, сертифицированные ДЦ, шифрование в покое и в пути, журнал доступа, неизменяемость (WORM).
• Бюджет TCO на 3–5 лет — включает железо, электричество, охлаждение, rack-пространство, лицензии ПО для бэкапа, поддержку, пропускную способность канала до offsite, стоимость исходящего трафика (egress) из облака при восстановлении.
• Команда и процессы — есть ли люди, которые настроят и будут поддерживать ленточную библиотеку, мониторят здоровье дисков, тестируют восстановление раз в квартал? Если нет — сложные on-premise решения станут «черным ящиком», который не работает в момент ЧП.

Основные варианты размещения: сравнение по практическим параметрам

Критерий	Локальные диски (DAS/NAS/SAN в той же стойке)	Offsite на своей площадке (второй ДЦ, филиал)	Публичное облако (S3-совместимое, Veeam Cloud Connect, спец. BaaS)	Ленты (LTO) в сейфе / стороннем хранилище
RTO	Минуты–часы (горячая копия)	Часы (требует доставки/подключения)	Часы–дни (зависит от канала и egress)	Дни (физическая доставка + чтение)
RPO	Минуты (частая репликация)	Минуты–часы (асинхронная репликация)	Минуты–часы (зависит от полосы)	Дни–недели (только периодическая запись)
Кап. затраты (CapEx)	Высокие (железо, стойки, УПС, охлаждение)	Очень высокие (вторая инфраструктура)	Нулевые (OpEx модель)	Средние (библиотека, ленты, сейф)
Опер. затраты (OpEx/год)	Электричество, диски, лицензии, администрирование	Удвоенные OpEx основной площадки	Хранение + исходящий трафик + API-запросы	Ленты, хранение, логистика, проверки
Защита от шифровальщика	Низкая (доступно из продакшн-сети)	Средняя (если изолированная сеть/учётки)	Высокая (Object Lock, IAM, разные аккаунты)	Максимальная (air gap, физическая изоляция)
Защита от физических рисков (пожар, вода)	Нет (та же стойка/здание)	Есть (если реально удалённая площадка)	Есть (георепликация по зонам/регионам)	Есть (оффлайн, другое место)
Соблюдение 152-ФЗ / суверенитета	Полный контроль	Полный контроль	Только у российских провайдеров с сертификацией ФСТЭК/ФСБ	Полный контроль
Сложность эксплуатации	Низкая–средняя	Высокая (две инфраструктуры)	Низкая (управляется через API/панель)	Высокая (ручные операции, логистика)
Масштабируемость	Ограничена слотами/портовыми лицензиями	Ограничена закупками	Практически неограничена	Ограничена слотами библиотеки и логистикой

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

Гибридная схема: как это выглядит на практике

Типичная зрелая схема для среднего бизнеса (10–50 ТБ бэкапа, RTO 4 часа для ТОП-систем, RPO 1 час, бюджет ограничен, есть требование 152-ФЗ):

1. Tier 0 (горячий): Локальный NAS/SAN на быстрых дисках (NVMe/SSD) или дедуплицирующее хранилище (Data Domain, ExaGrid, либо софтовый Veeam/Veritas на референсном железе). Хранит последние 7–14 дней инкрементов + недели полных. Даёт RTO в минуты для частых запросов «восстановить вчерашний файл/БД».
2. Tier 1 (тёплый, offsite): Репликация с Tier 0 в облако российского провайдера (Selectel, Yandex Cloud, SberCloud, Timeweb, Cloud.ru и др.) в S3-совместимое хранилище с Object Lock (WORM) на 30–90 дней. Канал — выделенный VPN/прямой коннект (Direct Connect/Interconnect) для предсказуемой скорости и отсутствия счетов за интернет-трафик. Покрывает пожар в основном ДЦ и шифровальщика (Object Lock не даёт зашифровать/удалить бэкапы даже админу облака).
3. Tier 2 (холодный, архивный/юридический): Ежемесячные/квартальные полные копии уходят на ленты LTO-9 (18 ТБ нативные, 45 ТБ сжатые) или в тот же облачный S3, но в класс хранения «Archive / Cold» (стоимость хранения в 5–10 раз ниже, восстановление за часы). Ленты уезжают в банковский сейф или специализированное хранилище (Iron Mountain, АрхивАриум и аналоги). Закрывает требования аудиторов к долгосрочному хранению (5–7 лет) и физическому air gap.

Такой подход даёт: быстрое восстановление 95% запросов с локального Tier 0, выживаемость при катастрофе Tier 1 в облаке, юридическую неуязвимость Tier 2 на лентах/в холодном облаке. TCO ниже, чем у двух своих ДЦ, а надёжность выше, чем у «только облако» или «только локально».

Носители информации: что выбрать под каждый Tier

HDD (SATA/NL-SAS) — работачая лошадка Tier 0 и Tier 1 on-premise

Дешевые $/ТБ, высокая плотность (18–24 ТБ на диск), предсказуемая durée de vie 5–7 лет при нагрузке «записать раз, читать редко». Риск: URE (невосстанавливаемые ошибки чтения) при ребилде больших RAID-массивов. Решение: RAID 6/RAID-Z2/Z3, дедупликация, регулярные скрабинги, замена дисков по SMART/возрасту заранее, а не по факту отказа.

SSD/NVMe — для кэша, дедупликации, мгновенного восстановления (Instant VM Recovery)

Дороже в 5–10 раз за ТБ, но дают IOPS для одновременного чтения множества потоков при восстановлении виртуальных машин прямо из бэкапа. Используются как кэш-дедупликации (metadata) или как «горячая зона» для последних 1–3 дней бэкапов. Не оправданы для глубокого хранения.

Ленты LTO-9 (LTO-10 в 2025–2026) — золотой стандарт Tier 2

Стоимость носителя ~$15–18/ТБ (LTO-9), срок хранения 30 лет при условиях, полная изоляция от кибератак (offline), низкое энергопотребление в хранилище. Минусы: последовательный доступ (восстановление 1 ТБ = 2–3 часа чистого чтения + поиск), нужна библиотека ($10к–50к+), ПО для управления лентами (LTFS, Veeam Tape, Veritas, Commvault), квалифицированный персонал. Ленты не устаревают — они сменяют роль с «основного бэкапа» на «архив/air gap».

Объектные хранилища (S3 API) — де-факто стандарт для Tier 1 в облаке

Версионирование + Object Lock (Compliance/Governance mode) = неизменяемость на заданный срок. Классы хранения: Standard (горячий), Infrequent Access (тёплый), Archive/Glacier/Deep Archive (холодный). Важно: при выборе провайдера проверяйте стоимость исходящего трафика (egress) и API-запросов (PUT/LIST/GET) — при полном восстановлении 50 ТБ это может стать сюрпризом в счете. Российские провайдеры часто дают бесплатный входящий трафик и фиксированный/бесплатный исходящий внутри своей экосистемы (до своих VM), что критично для RTO.

Безопасность и изоляция: защита от ransomware и ошибок админов

Место хранения должно быть изолировано от производственной среды по трём векторам:

• Сетевая изоляция: хранилище бэкапов не должно быть доступно из продакшн-сети по SMB/NFS/iSCSI с учётками доменных админов. Используйте выделенные VLAN, firewall, однонаправленную репликацию (push от бэкап-сервера к хранилищу, а не pull), отдельные сервисные аккаунты с MFA и без интерактивного входа.
• Иммутабельность (Immutability / WORM / Object Lock): записанный бэкап нельзя изменить, зашифровать, удалить или переименовать до истечения срока удержания (retention). Поддерживается: S3 Object Lock (AWS, S3-совместимые облака, MinIO, Cloudian), ленты (физически), специализированные апплайансы (Data Domain Retention Lock, ExaGrid Retention). Это единственная надёжная защита от шифровальщика, получившего админские права на бэкап-сервере.
• Шифрование: в покое (AES-256 на уровне хранилища или ПО бэкапа) и в пути (TLS 1.2+). Ключи управления (KEK/DEK) лучше держать в отдельном KMS (HashiCorp Vault, облачный KMS, аппаратный HSM), а не на бэкап-сервере. При потере ключей — бэкапы становятся бесполезными, поэтому процедура эскроу ключей обязательна.

Скрытые расходы и ловушки TCO

При расчёте стоимости часто упускают:

• Egress traffic (исходящий трафик) при восстановлении из облака. 50 ТБ × $0.01–0.02/ГБ = $500–1000 за одно полное восстановление. У российских провайдеров часто бесплатно внутри своей сети, но платно «в интернет».
• API requests (PUT/LIST/GET). При миллионах мелких файлов счет за LIST/GET может превысить стоимость хранения. Используйте агрегацию мелких файлов в тарболы/виртуальные диски перед загрузкой в S3.
• Лицензии ПО для бэкапа «за сокет» / «за ТБ» / «за VM». При росте инфраструктуры лицензии часто едят бюджет быстрее железа. Сравнивайте модели: Veeam (за нагрузку), Veritas/Commvault (за ТБ/фронтенд), открытые решения (BorgBackup, Restic, Kopia, Duplicati) + своё S3 — нет лицензий, но выше трудозатраты на поддержку.
• Тестирование восстановления. Нетестированный бэкап = отсутствие бэкапа. Плановые восстановительные учения (quarterly fire drill) требуют времени инженеров, свободных ресурсов (хост для тестовой VM), изоляции тестовой среды. Заложите это в OpEx.
• Замена дисков/ленто при росте и старении. HDD меняют каждые 4–5 лет профилактически. Ленты LTO — каждые 2 поколения (LTO-9 читает LTO-8 и пишет LTO-9; LTO-10 будет читать LTO-9). Планируйте миграцию данных на новые носители заранее.

Типичные ошибки при выборе места хранения

• Хранение бэкапов на том же массиве/в том же ДЦ, что и продакшн. Пожар, наводнение, кража стойки, массовый отказ контроллера — теряете и данные, и копии одновременно.
• Использование синхронизации (rsync, Syncthing, DFS-R) вместо бэкапа с версионированием. Синхронизация мгновенно переносит шифрование, удаление, повреждение на копию. Бэкап — это история состояний (точки во времени), а не зеркало.
• Отсутствие Object Lock / WORM на offsite-копии. «У нас есть копия в облаке» не помогает, если злоумышленник с админским доступом к консоли облака удалил бакет или включил шифрование SSE-C своим ключом.
• Игнорирование RTO/RPO при закупке. Купили ленточную библиотеку для системы, где RTO = 2 часа. Ленты физически не успеют выдать данные за это время. Или загружают ночные бэкапы в холодное облачное хранилище (Glacier Deep Archive), где восстановление занимает 12–48 часов, а бизнес ждёт 4.
• Единая учётная запись для продакшна и бэкапов. Компрометация домен-админа = полная потеря и продакшна, и всех доступных копий. Принцип least privilege + разные домены/те 넌ты/аккаунты для управления бэкапами.
• Нет документации и регламента восстановления. В стрессе ЧП никто не вспомнит, как смонтировать ленту, какой пароль от шифрования, как поднять VPN к облачному бакету. Runbook должен лежать в распечатанном виде у ответственного и в защищённом офлайн-хранилище (KeePass/Vaultwarden на флешке в сейфе).

Сценарии выбора: «если условия такие — действуйте так»

Ситуация	Рекомендуемая схема	Почему
Малый бизнес, до 5 ТБ, нет своего ДЦ, бюджет минимален, нет спеца по бэкапам	Veeam/NAKIVO/Acronis на локальном NAS (Synology/QNAP/TrueNAS) + репликация в S3 российского провайдера (Selectel, Timeweb, Yandex Object Storage) с Object Lock 30 дней	Низкий порог входа, авто-управление, оплата по факту, защита от шифровальщика через Object Lock, соответствие 152-ФЗ
Средний бизнес, 20–100 ТБ, есть серверная, свой штат админов, RTO 2–4 часа для críticos	Локальный дедуплицирующий апплайанс / референсный сервер с Veeam/Veritas + репликация в облако (S3 + Object Lock) + квартальные ленты в сейф	Баланс скорости (локально), выживаемости (облако), юридической неуязвимости (ленты), контролируемый TCO
Критическая инфраструктура / госсектор / банк: 152-ФЗ, ФСТЭК, ГОСТ, RTO 15 мин, RPO 0 для ядра	Синхронная репликация на второй сертифицированный ДЦ (Active-Active или Active-Passive) + локальные снапшоты каждые 15 мин + ленты/дисковые архивы в хранилище класса «ГосТайна/Критичная инфраструктура»	Требования регулятора диктуют архитектуру; облако допускается только сертифицированное (ФСТЭК 4-й класс, ФСБ), air gap обязателен
Распределённые офисы / retail / филиалы без ИТ на месте, канал 10–50 Мбит	Агент на каждой точке -> локальный кэш (NAS/USB-диск) -> ночная передача в центральное облако/ЦОД через WAN-ускорение (Riverbed, Veeam WAN Acceleration, Restic с дедупликацией)	Учёт узкого канала, автономность филиала при обрыве связи, централизованный контроль
SaaS-данные (M365, Google Workspace, Salesforce, GitHub, K8s etcd)	Специализированный BaaS (Veeam Backup for M365, Keepit, Metallic, AvePoint, собственное решение на Restic/Kopia -> S3)	Нативные API SaaS не дают блочного доступа; нужна гранулярность (почтовое сообщение, файл в OneDrive, объект в K8s) и долгая ретеншн

Чек-лист перед принятием решения

Пройдитесь по пунктам перед закупкой/подписанием договора. Если на какой-то пункт ответа «не знаю» — остановитесь и выясните.

1. Зафиксированы ли RTO и RPO для каждого уровня критичности систем (Tier 1 / Tier 2 / Tier 3)?
2. Известен ли текущий объём полного бэкапа и ежедневный прирост? Есть прогноз на 3 года?
3. Какие регуляторные требования применяются (152-ФЗ, PCI DSS, ГОСТ, отраслевые)? Требуется ли сертификация хранилища (ФСТЭК, ФСБ)?
4. Какой бюджет на CapEx (железо) и OpEx/год (облако, лицензии, электричество, люди)?
5. Есть ли выделенный канал до offsite-площадки (VPN, Direct Connect) с гарантированной полосой?
6. Поддерживает ли выбранное облачное хранилище S3 Object Lock (Compliance mode) и версионирование?
7. Какова стоимость полного восстановления (egress + API + время инженеров) из выбранного offsite?
8. Реализована ли сетевая и учётная изоляция бэкап-инфраструктуры от продакшн?
9. Есть ли процедура и график тестовых восстановлений (минимум раз в квартал для Tier 1)?
10. Документирован ли runbook восстановления: пароли, ключи, IP, порядок действий, ответственные?
11. Запланирована ли ротация носителей (диски 4–5 лет, ленты по поколениям) и миграция данных?

Часто задаваемые вопросы

Можно ли использовать только облако без локального хранилища?

Технически — да, если канал позволяет закачать полный бэкап за окно бэкапа и RTO устраивает восстановление из облака. Практически — рискованно: при массовом инциденте (шифровальщик на 100+ VM) одновременное восстановление всех из облака упрется в полосу пропускания и лимиты API провайдера. Локальный кэш последних 3–7 дней снимает 90% операционных запросов.

Нужен ли мне аппаратный апплайанс для дедупликации (Data Domain, ExaGrid, HPE StoreOnce)?

Если фронт-энд (входящий поток бэкапа) > 5–10 ТБ/день и нужен длительный ретеншн (месяцы) на дисках — апплайанс оправдывается за счёт экономии дисков и упрощения управления. Если меньше — софтовая дедупликация (Veeam, Veritas, Commvault, Borg/Restic) на референсном сервере с HDD/NVMe дешевле и гибче. Апплайансы создают vendor lock-in и дорогую поддержку после окончания гарантии.

Как обеспечить соответствие 152-ФЗ при хранении в облаке?

Выбирайте провайдера с сертификатом ФСТЭК (класс не ниже 3 для ПДн) и/или аттестатом ФСБ на криптографическую защиту. Договор должен включать адendum по обработке ПДн. Данные не должны выходить за пределы РФ (проверяйте регионы дата-центров провайдера). Шифрование в покое — обязательно, ключи — у вас (BYOK / внешний KMS). Журналирование доступа к бакетам — включено и выгружается в ваш SIEM.

Стоит ли хранить бэкапы на NAS с RAID 5/6 вместо специализированного хранилища?

Для Tier 0 (горячая копия, 7–14 дней) — допустимо, если NAS поддерживает снапшоты файловой системы (ZFS, Btrfs, WAFL, Btrfs на Synology/QNAP/TrueNAS) и вы делаете их каждые несколько часов. RAID 5/6 защищает от отказа дисков, но не от ошибок контроллера, файловой системы, шифровальщика с доступом к шарам, случайного rm -rf. Снапшоты + репликация в offsite — минимум. Для долгосрочного хранения (месяцы/годы) NAS с RAID не подходит — риск URE при ребилде и отсутствие WORM.

Как правильно тестировать восстановление, не ломая продакшн?

Используйте изолированную тестовую среду: отдельный кластер/хост, изолированная VLAN, без доступа в интернет и в продакшн-AD. Восстанавливайте туда VM/БД/файлы, проверяйте целостность (checksum, DBCC CHECKDB, запуск приложения), документируйте время и проблемы. Автоматизируйте через скрипты/Ansible/PowerShell + API бэкап-системы. Не тестируйте «на коленке» в момент ЧП — это гарантированный провал.

От чего оттолкнуться при принятии итогового решения

Главный принцип: место хранения выбирается под требования восстановления, а не под удобство закупки. Начните с RTO/RPO и регуляторных ограничений — они отсекут 80% вариантов. Затем посчитайте TCO на 5 лет для оставшихся: включайте железо, лицензии, канал, люди, тесты, ротацию носителей, egress. Выбирайте гибридную схему: горячее локально (скорость), иммутабельное в облаке (выживаемость от шифровальщика и катастроф), холодное на лентах/в архивном классе (юридическая неуязвимость, air gap). Документируйте runbook и тестируйте восстановление по расписанию. Без тестов у вас нет бэкапов — есть только надежда.

Материал носит информационный характер и не заменяет консультацию с сертифицированным специалистом по защите информации, аудитором соответствия (152-ФЗ, PCI DSS, ГОСТ) или архитектором ИТ-инфраструктуры. Требования регуляторов, тарифы провайдеров и характеристики оборудования меняются; проверяйте актуальные данные на дату принятия решения.