Нельзя выбрать место для резервных копий только по цене за терабайт. Локальный диск, NAS и облако закрывают разные риски. Один вариант быстрее восстанавливает большой объем, другой лучше переживает пожар, кражу или шифрование, третий удобнее для длительного хранения. Рабочая схема обычно начинается с вопроса: какой отказ мы хотим пережить и сколько времени есть на восстановление.
Если backup лежит рядом с основным сервером, он может быть быстрым, но уязвимым к общей аварии. Если все копии только в облаке, компания лучше защищена от локальной поломки, но зависит от канала связи, учетных записей, скорости загрузки и правил хранения. Поэтому выбор должен связывать хранение с RTO, RPO, доступами, мониторингом и регулярным тестом восстановления.
При услуге резервного копирования результатом должна быть не просто покупка накопителя или подключение облака, а проверяемая модель: что копируется, куда, кто получает сигналы, как защищены копии и чем доказано восстановление.
Сначала описывают сценарии отказа
Один и тот же носитель может быть хорошим или слабым решением в зависимости от риска. Нужно отдельно рассмотреть отказ диска, поломку сервера, ошибочное удаление, шифрование рабочих данных, пожар или кражу оборудования, потерю интернет-канала и ошибку администратора. Для каждого сценария важно понять, останется ли хотя бы одна пригодная копия и кто сможет ее использовать.
| Сценарий | Что важно | Чего недостаточно |
|---|---|---|
| Удалили файлы | Версионность и быстрый доступ к недавним точкам | Одна синхронизированная копия без истории |
| Сломался сервер | Копия системы, данных и понятный порядок запуска | Архив файлов без зависимостей сервиса |
| Шифрование | Изоляция, отдельные права, неизменяемость или offline-копия | Папка backup, доступная теми же учетными записями |
| Пожар или кража | Копия вне площадки | Единственный NAS в той же серверной |
| Нет интернета | Локальная точка восстановления для критичных данных | Только облачная копия большого объема |
Локальный backup
Локальная копия хороша скоростью. Если нужно быстро вернуть файловую папку, виртуальную машину или базу после обычного сбоя, локальное хранилище часто экономит часы. Оно проще для регулярных тестов восстановления и не зависит от внешнего канала.
Главный минус - общий периметр риска. Если копия находится на том же сервере, в той же стойке и с теми же правами, она может исчезнуть вместе с production. Локальный backup не должен быть единственной линией защиты для критичных данных. Его роль - быстрый возврат после частых локальных ошибок, а не защита от всех аварий.
NAS как отдельное хранилище
NAS удобен, когда нужен отдельный узел для резервных копий: больше места, понятное администрирование, разграничение папок, расписания, отчеты и возможность вынести устройство в другую зону офиса. Для малого бизнеса это часто практичный слой между сервером и облаком.
Но NAS не становится безопасным автоматически. Нужно проверить, не подключен ли он теми же учетными записями, не виден ли он всем рабочим станциям, есть ли отдельный административный доступ, уведомления о дисках, запас места, журнал ошибок и проверенный порядок восстановления. NAS без изоляции может быть зашифрован или очищен так же, как обычная файловая папка.
Облако
Облачная копия полезна как удаленный слой: она переживает локальную аварию площадки и помогает хранить копии вне офиса. Это важно для документов, баз, конфигураций и архивов, потеря которых остановит бизнес после физического происшествия.
Ограничения облака обычно проявляются в день восстановления. Большой объем может долго скачиваться, канал связи может быть занят, а доступ к аккаунту должен быть восстановим даже при потере основного администратора. Также нужно понимать сроки хранения, правила удаления, защиту учетной записи и то, как быстро можно получить не список файлов, а рабочий сервис.
Гибридная схема
Для многих компаний рабочий вариант - не выбор одного места, а сочетание слоев. Например, локальная копия для быстрого восстановления, NAS как отдельное хранилище с контролем состояния и удаленная копия для аварии площадки. Такая схема сложнее одной папки, но она закрывает разные типы отказов.
Гибрид не должен превращаться в набор несвязанных копий. Для каждого слоя нужно знать назначение: быстрый rollback, защита от отказа оборудования, удаленное хранение, длительная история или контрольная копия критичных конфигураций. Если назначение слоя не записано, его легко перестать проверять.
Как принять решение
| Критерий | Локально | NAS | Облако |
|---|---|---|---|
| Быстро вернуть большой объем | Сильно | Сильно при нормальной сети | Зависит от канала |
| Пережить аварию площадки | Слабо | Слабо, если NAS в том же офисе | Сильно |
| Изоляция от шифрования | Требует отдельной настройки | Требует отдельной настройки | Зависит от прав, retention и удаления |
| Простота проверки | Высокая | Высокая | Нужно проверять скорость и доступ |
| Эксплуатация | Контроль дисков и места | Контроль NAS, дисков, сети и прав | Контроль аккаунта, оплаты, квот и канала |
Что проверить до внедрения
- есть ли список данных и сервисов, которые действительно входят в backup;
- для каждого сервиса известны RTO и RPO хотя бы в рабочих допущениях;
- копии не удаляются теми же правами, которыми работают пользователи;
- есть уведомления о сбоях, заполнении хранилища и устаревших копиях;
- есть копия вне основной площадки для критичных данных;
- восстановление проверено не только на уровне файла, но и на уровне нужного сервиса;
- ответственный понимает, кто действует при сбое, отпуске администратора или смене подрядчика.
Хорошая схема backup не обязана быть дорогой, но она должна быть честной. Если копия быстрая, но не переживает пожар, это нужно назвать. Если копия удаленная, но восстанавливается сутки, это тоже должно быть известно заранее. Надежность появляется тогда, когда место хранения связано с реальными сценариями отказа и подтверждено тестом восстановления.