Резервная копия, архив и репликация часто смешиваются, потому что все три понятия связаны с копиями данных. Но в эксплуатации они отвечают на разные вопросы. Резервная копия нужна, чтобы восстановиться после ошибки, удаления, повреждения или атаки. Архив нужен, чтобы долго хранить редко используемые данные. Репликация нужна, чтобы быстрее получить вторую актуальную копию системы или данных.
Если перепутать эти роли, возникает опасная иллюзия защиты. Компания может иметь реплику, но не иметь точки восстановления до ошибки. Или хранить архив, но не иметь рабочей процедуры запуска сервиса после сбоя.
Резервная копия: восстановиться к прошлому состоянию
Резервная копия ценна не фактом копирования, а доказанной восстановимостью. Она должна иметь историю точек восстановления, защиту от удаления, понятный срок хранения, уведомления об ошибках и регулярные тесты восстановления. Если данные испорчены сегодня, полезна возможность вернуться к состоянию до повреждения.
Резервная копия особенно важна при случайном удалении, шифровании, логической ошибке, неудачном обновлении и необходимости восстановить отдельный файл, базу или сервис. Именно поэтому резервное копирование проверяют не только по успешному завершению задания, но и по результату восстановления.
Архив: хранить старое без нагрузки на рабочую систему
Архив хранит данные, которые больше не нужны в ежедневной работе, но могут понадобиться позже. Он помогает отделить активные данные от старых, снизить нагрузку на основное хранилище и сохранить материалы в понятной структуре.
Архив не обязан обеспечивать быстрый запуск сервиса после аварии. Для него важны владелец данных, срок хранения, формат, возможность чтения через годы и процесс поиска. Юридические сроки хранения зависят от конкретной ситуации, поэтому техническая статья не заменяет правовую оценку.
Репликация: сократить простой, но не заменить историю
Репликация переносит изменения во вторую систему почти сразу или с небольшим лагом. Она помогает сократить простой при отказе основного узла: сервис можно быстрее поднять на другой стороне, если архитектура это предусматривает.
Но репликация может так же быстро перенести ошибку. Удаление, повреждение данных, неудачное обновление или шифрование могут попасть во вторую копию. Поэтому репликация улучшает непрерывность, а резервная копия дает исторические точки восстановления. Это разные защитные слои.
Как выбирать по сценарию
| Сценарий | Что помогает | Что проверить |
|---|---|---|
| Пользователь удалил файл вчера | Резервная копия | Есть ли точка до удаления и можно ли восстановить отдельный объект. |
| Нужно хранить старый проект | Архив | Есть ли владелец, срок хранения, формат и порядок поиска. |
| Отказал основной узел | Репликация и резервная площадка | Можно ли запустить сервис и какие данные могли не успеть синхронизироваться. |
| Данные зашифрованы | Защищенная резервная копия | Есть ли точка восстановления вне поврежденного контура и проверен ли возврат. |
Рабочая комбинация обычно состоит из нескольких слоев
Для бизнес-инфраструктуры ответ часто не в одном инструменте, а в комбинации: резервная копия для восстановления, архив для долгосрочных неактивных данных, репликация для непрерывности отдельных критичных сервисов. Хорошая политика говорит, что именно защищает каждый механизм, чего он не защищает, как часто проверяется и кто принимает решение при сбое.
Поэтому вопрос должен звучать не что лучше, а какой риск закрываем. Если нужен возврат к прошлой версии - проверяют резервное копирование. Если нужна быстрая работа второй площадки - проектируют репликацию и переключение. Если нужно убрать старые данные из активной системы - строят архив. Все это стоит увязывать в единую политику резервного копирования и восстановления.