Правило резервного копирования 3-2-1 означает, что у компании должны быть три экземпляра информации, два типа хранения и как минимум одна резервная копия за пределами основной площадки. В число трех экземпляров входят рабочая информация и два резервных набора. При этом экземпляр считается независимым, только если его нельзя потерять из-за того же события, что и оригинал. RAID, синхронизация и снимок на том же хранилище сами по себе не заменяют резервное копирование, а для дополнительной защиты от шифровальщиков используют расширенную схему 3-2-1-1-0.
Что такое правило 3-2-1 и как его считать
Правило 3-2-1 помогает распределить информацию так, чтобы отказ оборудования, ошибка администратора или авария на площадке не уничтожили все экземпляры одновременно.
- 3 экземпляра. Оригинал и две резервные копии. Три файла в разных папках на одном диске не подходят.
- 2 типа хранения. Например, локальное дисковое хранилище и отдельное облачное. Смысл не в названиях устройств, а в снижении общих точек отказа.
- 1 экземпляр вне основной площадки. Он должен пережить пожар, затопление, отключение электропитания или другую аварию в офисе.
Правило популяризировал фотограф Питер Крог в книге The DAM Book, опубликованной в 2009 году. Сегодня этот принцип применяют не только для фотографий, но и для баз 1С, файловых серверов, виртуальных машин и другой корпоративной инфраструктуры.
Что не считается резервной копией: RAID, синхронизация и снимки
Главный критерий независимости простой: сохранится ли резерв, если с оригиналом произойдет конкретное неприятное событие? Проверьте не только отказ диска, но и удаление файлов, шифрование вредоносной программой, пожар и компрометацию учетной записи администратора.
| Вариант | Считается копией? | Почему |
|---|---|---|
| RAID-массив | Нет | Защищает от некоторых отказов дисков, но не от удаления файлов, шифровальщика или отказа всего массива. |
| Синхронизация с облаком | Не сама по себе | Она может переносить изменения, удаление и шифрование на связанные экземпляры в зависимости от направления и настроек. Нужны независимые версии и отдельные права доступа. |
| Снимок виртуальной машины на том же хранилище | Нет | При отказе хранилища или его компрометации можно потерять и машину, и снимок. |
| Внешний диск, постоянно подключенный к серверу | Условно | Он поможет при отказе основного диска, но останется доступен вредоносной программе и учетным записям сервера. |
| Резерв на том же NAS | Обычно нет | Общие диски, контроллер, учетные записи и площадка создают общие точки отказа. |
| Облачный архив под отдельной учетной записью | Да, при условиях | Он должен находиться в отдельной среде, быть недоступным для удаления из рабочей консоли и не зависеть от той же инфраструктуры. |
Фраза «это уже 3 копии» имеет смысл только после проверки независимости каждого экземпляра. Даже односторонняя синхронизация не становится полноценным бэкапом автоматически: выясните, сохраняются ли предыдущие версии и можно ли вернуть состояние до удаления или шифрования.
Как считать 3-2-1, если копии находятся в облаке
Облачный резерв может закрывать сразу два требования: отдельный тип хранения и площадку вне офиса. Но само размещение информации в облаке еще не доказывает независимость.
Проверьте три условия:
- Для управления резервами используются отдельные учетные данные, не совпадающие с учетными данными администратора рабочей инфраструктуры.
- Экземпляр находится в отдельной инфраструктуре или центре обработки данных, а не на том же локальном хранилище под другим именем.
- Администратор рабочей системы не может удалить резерв из своей обычной консоли.
Репликация внутри облачной инфраструктуры помогает пережить отказ отдельного устройства, но не обязательно защищает от удаления пользователем с административными правами. Провайдер отвечает за свою инфраструктуру и условия сервиса, а компания должна контролировать доступ, настройки резервирования и возможность восстановления.
Проверьте свою схему резервного копирования: 5 вопросов
- Экземпляры действительно независимы? Если в расчет входят только RAID, синхронизация или снимки на том же хранилище, схема не соответствует принципу 3-2-1. Начните с проверки вариантов в таблице выше.
- Используются разные типы хранения? Если оригинал и оба резерва находятся на одном типе устройства или в одном хранилище, добавьте отдельную среду с другим профилем отказа.
- Есть резерв вне офиса и проверено место его хранения? Уточните физическое расположение ЦОД. Если в архиве есть персональная информация граждан РФ, отдельно проверьте применимые требования российского законодательства.
- Есть экземпляр, который нельзя удалить из-под администраторской учетной записи? Если все задания и репозитории управляются одним аккаунтом, изучите изоляцию доступа и защиту от удаления. Подробности приведены в разделе о схеме 3-2-1-1-0.
- Вы проверяли восстановление и знаете его время? Успешное завершение задания не доказывает, что система запустится. Проведите тест и сравните результат с целевым временем восстановления, RTO.
Почему 3-2-1 недостаточно против шифровальщиков: схема 3-2-1-1-0
Если злоумышленник получает доступ к консоли резервного копирования, он может попытаться удалить задания и репозитории, включая экземпляры за пределами офиса. Несколько резервов не помогут, если всеми можно управлять из одной скомпрометированной учетной записи.
Расширение 3-2-1-1-0, которое продвигает Veeam, добавляет два требования:
- +1: еще один экземпляр, защищенный от удаления или изолированный от сети по принципу air-gap.
- 0: ноль ошибок при проверке восстановления. Резервы регулярно проверяют, а не просто считают успешные задания.
У изолированного экземпляра есть ограничение: он может содержать информацию только на момент последнего подключения. Защита от удаления позволяет хранить более свежие точки, но действует в пределах заданного срока. Поэтому эти механизмы полезно сочетать.
Для критичных систем встречаются и более строгие схемы, например 4-3-2: четыре экземпляра, три площадки и два резерва вне основной. Конкретная архитектура зависит от требований к доступности, бюджету и допустимому времени простоя.
Пример схемы 3-2-1 для небольшой компании с 1С
Допустим, в компании работают сервер 1С на SQL и файловый сервер. Практическая схема может выглядеть так:
- Рабочая инфраструктура: базы 1С, SQL и корпоративные файлы на основных серверах.
- Первый резерв: локальный репозиторий в изолированной подсети с отдельными учетными данными. Он нужен для быстрого восстановления после типовых сбоев.
- Второй резерв: облачное хранилище LanCloud за пределами офиса, в российском ЦОД уровня TIER III.
- Дополнительная защита: экземпляр с ограничением на удаление, если такая возможность подтверждена для выбранной конфигурации, либо отключаемый носитель, подключаемый по графику.
Синхронизация файлов в этой схеме не заменяет резервное копирование и в расчет трех экземпляров не включается.
Для 1С и SQL важно использовать резервирование с учетом приложения. Простое копирование файлов работающей базы может не обеспечить согласованное состояние и корректное восстановление. Выбирайте поддерживаемый способ создания резерва базы и проверяйте его в тестовой среде.
Первичная передача полного набора в облако может занять значительное время. В Cloud Backup от LanCloud предусмотрены сжатие, дедупликация и ускорение передачи по WAN до 50 раз по данным провайдера. Фактический результат зависит от объема, канала связи и особенностей нагрузки.
Где хранить резерв вне офиса
Для компании, работающей в России, при выборе площадки важно учитывать не только надежность ЦОД, но и требования к персональной информации. С 1 июля 2025 года часть 5 статьи 18 Федерального закона № 152-ФЗ устанавливает ограничения на использование баз данных за пределами РФ при сборе, записи, систематизации, накоплении, хранении, уточнении и извлечении персональных данных граждан России, с предусмотренными законом исключениями.
В резервных архивах 1С, CRM, кадровых систем и почты могут находиться персональные сведения. Поэтому до выбора места хранения нужно определить состав информации, применимые требования и допустимую схему обработки. Формулировку этого абзаца необходимо проверить у юриста перед публикацией.
Шифрование до отправки в облако снижает риск раскрытия информации при передаче и хранении. В Cloud Backup LanCloud предусмотрено шифрование на стороне клиента. Ключ необходимо хранить отдельно от резервного хранилища и вне той же инфраструктуры. Если он потерян, восстановить зашифрованный архив может оказаться невозможно.
Как часто делать копии и сколько хранить версии
Частота резервирования зависит от допустимой потери информации. Для этого используют два показателя:
- RPO показывает, за какой период изменений компания может позволить себе потерять информацию. Чем меньше допустимый период, тем чаще должны выполняться задания резервного копирования.
- RTO определяет, за какое время систему необходимо восстановить. От него зависит способ восстановления: отдельного файла, базы, сервера целиком или всей инфраструктуры.
Если для восстановления нужно скачать из облака несколько терабайт, перед запуском важно оценить пропускную способность канала и время передачи. Cloud Backup LanCloud позволяет восстанавливать серверы непосредственно в облако. Это может помочь сократить зависимость от готовности локальной площадки. Для сценариев, где требуется аварийное восстановление всей инфраструктуры в облаке, рассмотрите Cloud DRaaS.
Не менее важна глубина хранения. Если вредоносная активность оставалась незамеченной дольше срока хранения версий, доступные экземпляры могут оказаться зараженными или уже содержать поврежденную информацию. Срок нужно выбирать с учетом характера содержимого, требований бизнеса и возможного времени обнаружения инцидента.
Как проверить, что из бэкапа можно восстановиться
Проверка должна подтверждать не только целостность файла, но и работоспособность восстановленной системы.
- Выберите резерв и восстановите сервер, базу или приложение в изолированную тестовую среду.
- Измерьте время от начала восстановления до готовности системы к работе и сравните его с целевым RTO.
- Проверьте прикладные функции: доступность базы 1С, целостность содержимого, открытие документов, вход пользователей и работу необходимых служб.
- Зафиксируйте дату теста, использованную точку восстановления, результат, затраченное время и выявленные проблемы.
Ежеквартальная проверка и дополнительный тест после крупных изменений инфраструктуры могут служить отправной точкой, но это ориентир, а не универсальная норма. Для критичных систем частоту определяют исходя из требований бизнеса. После атаки перед восстановлением нужно проверить архив на признаки вредоносного воздействия.
FAQ: частые вопросы о правиле 3-2-1
Сколько места займут три экземпляра?
Оцените размер полной резервной копии, объем инкрементальных изменений и глубину хранения. Упрощенная формула: полная копия + инкременты за весь срок хранения с учетом числа сохраняемых цепочек. Затем учтите эффект сжатия и дедупликации. Итог зависит от частоты изменений, политики хранения и особенностей содержимого, поэтому лучше оценивать объем по результатам тестового задания.
Хватит ли одного внешнего резерва?
Один внешний экземпляр лучше, чем хранение всей информации на одной площадке, но он не закрывает все риски. Если его удалить, повредить или зашифровать, восстановить содержимое может быть неоткуда. Для базовой схемы 3-2-1 нужны два резервных экземпляра, один из которых находится вне основной площадки. Дополнительный изолированный или защищенный от удаления резерв повышает устойчивость к атакам.
Можно ли хранить резерв у того же провайдера, где размещены серверы?
Да, если он действительно отделен от рабочей инфраструктуры: находится в отдельной среде или ЦОД, управляется с независимыми учетными данными и защищен от удаления из основной консоли. Перед выбором схемы уточните, какие механизмы изоляции и защиты доступны в конкретном сервисе.
Как часто тестировать восстановление?
Единого интервала для всех компаний нет. В качестве начального ориентира можно проверять восстановление ежеквартально, а также после крупных изменений в инфраструктуре, политике резервирования или составе приложений. Для критичных систем тесты могут требоваться чаще. Важно фиксировать результат и проверять соблюдение RTO.
Настройте резервное копирование за пределами офиса
Правило 3-2-1 работает, когда экземпляры независимы, размещены на разных типах хранения и хотя бы один находится за пределами основной площадки. Для дополнительной устойчивости предусмотрите защиту от удаления и регулярно проверяйте восстановление.
Cloud Backup от LanCloud позволяет хранить резерв вне офиса в ЦОД уровня TIER III, использовать шифрование на стороне клиента и восстанавливать серверы в облаке. Условия бесплатного тестового периода необходимо подтвердить перед публикацией.
Если задача состоит не только в сохранении резервов, но и в быстром запуске всей инфраструктуры при аварии, изучите аварийное восстановление всей инфраструктуры в облаке с помощью Cloud DRaaS.
