Правило 3-2-1: как построить резервное копирование небольшой компании
Обновлено: октябрь 2026
Три копии данных, два разных носителя, одна копия вне офиса — так звучит правило 3-2-1, самый известный ориентир в резервном копировании. В этой статье — что оно означает на практике для небольшой компании: примеры схем, порядок копирования данных, защита от шифровальщиков и ошибки, которые встречаются чаще всего.
ВАШЕЙ ИНФРАСТРУКТУРЫ
Что такое 3-2-1 и почему это минимум, а не гарантия
Расшифровка правила выглядит так. Три — всего три копии данных: рабочие данные на основном сервере плюс две резервные. Два — копии живут на двух разных типах носителей: например, дисковый массив сервера и NAS, или NAS и облачный репозиторий. Один — минимум одна копия находится за пределами основной площадки, в другом здании или в другом регионе.
За каждой цифрой стоит типовой сценарий потери. Одна копия — это отсутствие запаса: любой сбой при копировании оставляет вас с оригиналом и без резерва. Две копии на одном носителе или в одной комнате умирают вместе: отказ хранилища, скачок питания, пожар и кража не разбирают, какая папка «бэкап». Отсюда и требование разных носителей, и требование оффсайта.
При этом правило 3-2-1 — это нижняя граница, а не готовая защита. Оно описывает, где физически лежат копии, но ничего не говорит о том, насколько они свежие, кто имеет к ним доступ и можно ли из них вообще что-то поднять. Копия, из которой ни разу ничего не восстанавливали, остаётся надеждой: носитель формально существует, но работает ли он — неизвестно. Поэтому 3-2-1 разумно читать как первый обязательный уровень, за которым следуют расписание, версионирование и регулярная проверка восстановления — им посвящена большая часть этой статьи.
Пара уточнений, чтобы правило не превратилось в ритуал. Во-первых, копия — это не синхронизация: двусторонняя синхронизация файлов между устройствами удобно держит данные одинаковыми, но и удаление, и шифрование реплицирует с той же старательностью. Копия — односторонняя и хранит прошлые состояния, а не зеркалит текущее. Во-вторых, встречающиеся расширения правила — три носителя, одна офлайн-копия, ноль ошибок при проверке — полезны как напоминание о подстерегающих проблемах, но суть остаётся прежней: разнесённые копии, к которым есть независимый доступ.
Три копии в реальном небольшом офисе: примеры схем
Правило не требует конкретного железа — оно про роли. Носители могут быть любыми, важно лишь, чтобы копии не повторяли судьбу друг друга. Ниже две схемы, которые закрывают большинство небольших офисов.
Схема А: физический сервер или NAS с файловыми данными. Первая копия — сами рабочие данные на сервере. Вторая — автоматическое копирование по расписанию на NAS: отдельное устройство с собственным хранилищем, которое не зависит от дисков основного сервера. Третья — оффсайт: внешний диск с шифрованием, который по расписанию обновляется и уносится из офиса, либо облачный репозиторий, куда программа резервного копирования складывает зашифрованные копии. Носителей здесь три, типов — два: серверный массив, NAS и сменный или удалённый носитель.
Два практических уточнения к схеме А. Первое: первый полный проход по данным — самый долгий, его стоит запускать заранее, а не в вечер «когда-нибудь». Дальше копии инкрементальные и занимают минуты, но первое полное копирование должно успеть целиком. Второе: оффсайт не обязан быть облаком — копия на носителе, который хранится дома у владельца или в другом помещении компании, закрывает правило так же честно, важно лишь, чтобы расстояние до основного офиса было достаточным, а носитель обновлялся по расписанию, а не «когда вспомнят».
Схема Б: виртуализация на Proxmox VE (актуальная линейка 8.x). Частая подмена в этой конфигурации — снапшоты виртуальных машин вместо копий. Снапшот живёт на том же хранилище, что и машина, и отказ хранилища уничтожает их вместе. Рабочая схема выглядит иначе: регулярные резервные копии виртуальных машин средствами гипервизора уходят на отдельный NAS, а вторая линия — репозиторий Proxmox Backup Server на другой площадке: он хранит копии в сжатом и дедуплицированном виде и умеет проверять их целостность. Снапшоты при этом остаются там, где им место — быстрым инструментом «откатить неудачное обновление», но не стратегией резервирования.
У схемы Б есть деталь, которую стоит проговорить заранее: режим копирования работающих виртуальных машин. Гипервизор умеет снимать копию «на лету», с приостановкой и с остановкой машины; чем критичнее сервис на виртуальной машине, тем важнее понимать, что окно копирования для неё означает. Для файлового сервера копия на лету обычно приемлема, для учётной базы — вопрос к согласованию с теми, кто отвечает за саму базу: копия работающей базы снимается штатными средствами самой системы или в согласованный промежуток.
Отдельный случай — данные, которые и так живут в облачном сервисе: почта, CRM, учётная система у провайдера. Формально это одна копия в чужом дата-центре. Правило 3-2-1 здесь превращается в вопрос «как вытащить данные наружу»: регулярный экспорт или копия средствами сервиса на собственный носитель. Даже несовершенный экспорт раз в неделю даёт позицию, которой нет при полной ставке на чужую инфраструктуру.
Какие данные копировать в первую очередь
«Скопировать всё» — самый дорогой и самый медленный старт. Порядок задаёт простой вопрос к каждой системе: что случится с работой, если эти данные пропадут сегодня же. Ответы быстро выстраиваются в две очереди.
Первая очередь — то, потеря чего останавливает работу напрямую: учётные базы (для многих компаний это база 1С), рабочие документы и файлы, почта. Сюда же — конфигурации серверов и сетевого оборудования: восстановить сервер без его настроек — это собирать его заново по памяти. Вторая очередь — архивы, старые проекты, образы систем, данные «на всякий случай». Их копируют следом, когда первая очередь уже закрыта.
Перед настройкой стоит посчитать объёмы: сколько занимает полный проход по данным первой очереди и как быстро они растут. Из этих двух чисел следует всё остальное — хватит ли NAS, какое окно на копирование нужно ночью и с какой периодичностью физически успевает обновляться оффсайт-копия. Если полный проход занимает больше ночи, схема сама себя не настроит — придётся либо делить данные, либо менять носители.
Отдельно про то, что копировать не нужно: временные файлы, кэши, содержимое папок загрузок и прочий мусор. Они раздуют и первый полный проход, и каждый последующий, и место на носителях, не добавив восстанавливаемости. Копируют данные, потеря которых имеет цену, — формулировка «всё подряд» на практике всегда означает «что-то важное вслепую».
Список первой очереди — живой документ: компании заводят новые системы, старые уходят, процессы меняются. Разумный ритм пересмотра — раз в год и после крупных изменений: новая учётная система, переезд, рост данных в разы. Схема копирования, настроенная под инфраструктуру двухлетней давности, защищает уже другую компанию — не сегодняшнюю.
Шифрование и офлайн-копия против шифровальщиков
Шифровальщик работает с правами того пользователя, под которым запущен, и идёт по всем дискам и сетевым папкам, которые ему доступны. Отсюда неприятное следствие: копия, которая постоянно подключена к сети и доступна под учётной записью администратора, заражается вместе со всем остальным. Схема, которая считалась образцовой, оказывается пустой ровно в момент, когда она понадобилась.
Первый ответ на это — офлайн-копия: носитель, который физически отключён между сеансами копирования. Внешний диск, подключаемый по расписанию, или съёмный носитель, который забирают из офиса. Пока диск отключён, заразить его невозможно — такая копия остаётся единственной чистой точкой, из которой компания восстанавливается без переговоров с злоумышленниками.
Второй ответ — версионирование. Хранить несколько поколений копий, а не одну перезаписываемую: дневная, недельная, месячная. Тогда заражение, замеченное через три дня, не лишает последних чистых версий — откат идёт к копии до события. Глубина хранения определяется тем, как долго проблема может оставаться незамеченной; для небольшой компании набор из трёх поколений — разумный старт.
Третий ответ касается оффсайта: облачный репозиторий шифруется на стороне клиента, ключом к нему служит пароль, заданный при настройке. Этот пароль — часть схемы резервирования: хранится он отдельно от серверов и отдельно от самих копий, в порядке, известном минимум двум людям в компании. Потеря ключа означает потерю всех зашифрованных копий — с той лишь разницей, что вместо злоумышленника её виновником окажется сам владелец.
И последнее: зашифрованная копия проверяется так же, как обычная. Пароль от репозитория, при помощи которого копии создавались, стоит использовать для пробного восстановления раньше, чем это понадобится по-настоящему: механизм шифрования без теста — ещё один «зелёный индикатор», в который приходится верить.
Частые ошибки
Большинство схем ломается не на экзотике, а на шести типовых решениях, каждое из которых в момент принятия выглядело разумно.
- Копия на том же сервере. Папка «Backup» на втором диске того же массива защищает от случайного удаления файла и ни от чего больше: отказ сервера уничтожает оригинал и копию одновременно.
- Постоянно подключённый диск. Внешний носитель, который «всегда на всякий случай воткнут», — не офлайн-копия. Он доступен шифровальщику наравне с рабочими дисками.
- Снапшот вместо копии. Снапшот виртуальной машины живёт на том же хранилище и подчиняется тому же отказу. Это инструмент быстрого отката, а не резервирование.
- Одна копия без поколения. Единственная перезаписываемая копия означает: как только задание впервые отработало с ошибкой или скопировало уже повреждённые данные, чистой версии больше нет.
- Вера в зелёную галочку. «Задача выполнена успешно» в панели — утверждение о выполнении задания, а не о возможности восстановить данные. Это разные утверждения, и проверяется только второе.
- Копирование «когда вспомнят». Ручной процесс живёт до первого занятого месяца: расписание и автоматизм — то, что отличает схему от намерения.
- Копии без порядка доступа. Схема, ключи и пароли к которой известны одному человеку, исчезают вместе с ним — в отпуск, на другую работу или просто из памяти. Порядок доступа — часть схемы, а не приложение к ней.
Как проверить, что схема живая
Единственная проверка, которая что-то доказывает, — восстановление из копии. Панели и отчёты подтверждают, что задание отработало; открывается ли восстановленная база и запускается ли восстановленный сервер, видно только на практике. Полную картину даёт сочетание регулярного лёгкого контроля и периодического тяжёлого. Делает её тот, кто отвечает за инфраструктуру, — своими силами или подрядчиком, но результат фиксируется в журнале проверок: что восстанавливали, когда, что не поднялось и что поправили. Без журнала даже успешная проверка через полгода превращается в «вроде что-то проверяли».
Лёгкий контроль — еженедельный: последняя копия свежая, её объём правдоподобен, в журнале заданий нет повторяющихся ошибок. Он ловит «тихие» отказы — задание, которое месяц падает, никто не заметит без просмотра журнала. Тяжёлая проверка — ежеквартальное тестовое восстановление: один файл, учётная база, виртуальная машина целиком. Как именно его провести, что фиксировать и сколько времени это честно занимает — тема отдельного чек-листа; его интерактивная версия доступна в нашем инструменте проверки резервных копий. Пошаговый порядок такой проверки — в отдельной статье-чек-листе.
Если смотреть на правило 3-2-1 с этой стороны, оно формулируется так: три копии, две среды, один оффсайт — и никакая из них не считается рабочей, пока из неё хотя бы раз что-нибудь не восстановили.
Частые вопросы
Обязательно ли покупать NAS для правила 3-2-1?+
Нет. Правило описывает роли, а не оборудование: второй носитель — это любой независимый хранитель копий, от второго сервера до облачного репозитория. NAS — удобный и предсказуемый вариант, но не единственный.
Как часто делать копии?+
Частота равна объёму данных, который вы готовы потерять: копия раз в неделю означает, что в худший день пропадает неделя работы. Учётную базу имеет смысл копировать ежедневно, архив — можно реже. Периодичность для каждой очереди данных своя.
А если всё и так в облаке?+
Тогда в вашем распоряжении одна копия, за целостность которой отвечает сторонняя компания. Это удобно, но не равняется правилу 3-2-1: регулярный экспорт или выгрузка копий на собственный носитель закрывает разрыв.
Снапшот — разве это не копия?+
Снапшот фиксирует состояние машины на момент времени, но хранится на том же хранилище, что и сама машина. Отказ хранилища уничтожает и то и другое. Копия по правилу 3-2-1 — всегда на другом носителе.
Сколько хранить копии?+
Несколько поколений: например, дневные за неделю, недельные за месяц, месячные за год — глубина зависит от того, как долго проблема может оставаться незамеченной. Плюс офлайн-копия, которую заражение или сбой не затрагивает.
Чем копия отличается от синхронизации файлов?+
Синхронизация держит устройства одинаковыми в обе стороны: удалили файл на одном — он исчезнет и на остальных. Копия односторонняя и хранит прошлые состояния, поэтому и случайное удаление, и шифрование не расходятся по всей цепочке.
Копий нет совсем. С чего начать?+
С первой очереди данных и самой простой работающей схемы: автоматическая копия учётной базы и документов на отдельный носитель плюс оффсайт. Это не весь путь, но уже защита от самого вероятного. Дальше схема расширяется и обрастает проверками.
Связанные материалы
Свою текущую схему можно проверить самостоятельно — по чек-листу самопроверки резервного копирования: он повторяет порядок этой статьи в форме вопросов с пояснениями.
Если схема нуждается в постановке или пересмотре — от выбора носителей до автоматизации и тестовых восстановлений — это направление резервного копирования и восстановления данных.