Правило бэкапа 3-2-1: как разложить копии, чтобы не потерять бизнес за одну ночь

Раз в квартал мне звонит новый клиент с одной и той же фразой: «У нас всё зашифровано, бэкапа нет, что делать». Восемь лет в этом бизнесе, и я до сих пор не привык к тому, как спокойно директора относятся к резервным копиям — пока не приходится за одну ночь объяснять учредителям, что база 1С за три года пропала. Расскажу, как раскладываю бэкапы у своих клиентов, чтобы такого разговора не было вообще.

Почему одной копии всегда мало

У одного клиента — небольшая юрфирма на 18 рабочих мест — стоял NAS Synology, на него каждую ночь сливалась база 1С и папка с договорами. Красота. Пока шифровальщик не зашёл через RDP, который кто-то по доброте душевной пробросил наружу без второго фактора. Зашифровало сервер. И NAS тоже — он был примонтирован как сетевой диск, вирус до него дотянулся за двадцать минут.

Резервная копия, которая лежит рядом с оригиналом, — это не резервная копия. Это вторая мишень для того же самого события. Пожар в серверной сожжёт оба диска одинаково хорошо. Скачок напряжения убьёт и сервер, и NAS в соседней стойке. Шифровальщик, если у него есть доступ к сети, до бэкапа доберётся так же легко, как до продакшена — и часто именно бэкап шифрует в первую очередь, зная, что это единственный шанс жертвы обойтись без выкупа.

Поэтому в отрасли давно есть простое правило — 3-2-1. Три копии данных, на двух разных носителях, одна из которых физически в другом месте. Не потому что так красиво звучит, а потому что за этим стоят реальные разборы полётов десятков компаний, которые потеряли всё.

Что на самом деле означают эти цифры

Тройка — это оригинал плюс две копии. Не три копии в дополнение к рабочим данным, а именно так: рабочая база — это уже первая единица. Дальше нужны ещё две. Двойка — это про носители: если оригинал лежит на SSD в сервере, копии не должны обе лежать на дисках того же типа в той же коробке. Внешний жёсткий диск, лента LTO, облако, NAS другого производителя — подойдёт любое сочетание, лишь бы отказ одного носителя не тянул за собой другой.

Единица в конце — самая важная и самая часто игнорируемая часть правила. Одна копия должна физически находиться не там, где стоит сервер. Не в соседней комнате, не в серверной этажом ниже — а в другом здании, а лучше в другом городе. Причина банальна: пожар, залив, кража оборудования, обесточивание всего офиса разом накрывают одну точку целиком.

Я обычно объясняю клиентам так: представьте, что завтра ваш офис выгорел полностью, вместе со всем, что в нём стояло. Через сколько часов вы снова сможете работать? Если ответ «никогда» или «не знаю» — правила 3-2-1 у вас нет, что бы ни говорил админ.

Копия №1: рабочая, в офисе, для быстрого восстановления

Первая копия — она же самая недооценённая с точки зрения важности. Это бэкап, который лежит рядом, но не является тем же диском. Задача простая: если слетела база 1С из-за кривого обновления релиза или админ случайно удалил таблицу — восстановиться за 10 минут, а не за сутки. У большинства моих клиентов на торговле и в медклиниках это Veeam Backup, который каждую ночь снимает образ виртуалки с 1С на отдельный физический диск или на NAS внутри той же локальной сети.

Здесь важна одна деталь, о которой почти никто не думает заранее: у этой копии должна быть глубина хранения хотя бы в 2-4 недели точками восстановления. Шифровальщик редко срабатывает мгновенно после проникновения — он может неделю тихо сидеть в сети, шифруя понемногу и удаляя теневые копии, прежде чем сработает основной удар. Если у вас в истории только вчерашняя ночная копия, а заражение случилось три недели назад, вы восстановите уже заражённые данные.

У клиента-производственника мы держим на этом уровне глубину в 30 дней с ежедневными точками и еженедельными полными копиями. Диск на 4 ТБ обошёлся тысяч в 15, окупился один раз — когда бухгалтер случайно затёр базу зарплаты за месяц до расчёта премий.

Копия №2: другой носитель, желательно — с изоляцией от сети

Вторая копия должна пережить то, что убило первую. Практически это значит: другой тип носителя и, что критично в 2026 году, offline или immutable-хранение. У шифровальщиков последних лет любимая тактика — получить права администратора и удалить или зашифровать всё, до чего дотягивается сеть, включая сетевые бэкап-хранилища. Если ваш NAS постоянно подключён и виден из общей сети — он под тем же ударом, что и сервер.

Решения тут разные по бюджету. Для компании на 10-15 рабочих мест достаточно ротации внешних дисков: один диск подключается на ночь для копирования, потом физически отключается и уносится в сейф или домой к директору. Грубо, но работает — вирус не может зашифровать то, что не подключено. Для компаний покрупнее ставим NAS с поддержкой immutable-снапшотов (у того же Synology или QNAP это встроенная функция) — снапшот нельзя изменить или удалить даже с правами администратора в течение заданного периода.

У клиента из сферы бухгалтерского аутсорсинга мы в прошлом году развернули именно такую схему: Veeam пишет копии на отдельный сервер с ZFS и еженедельными immutable-снапшотами на 14 дней. Обошлось в районе 180 тысяч рублей под ключ вместе с железом. Дешевле, чем один месяц простоя при потере базы 40 клиентов.

Копия №3: другой город — облако или второй офис

Вот здесь начинается самое интересное и самое часто пропускаемое. Третья копия обязана быть географически отделена. Не «на другом этаже», а в другом населённом пункте, а лучше — в другом регионе энергосистемы. Причины прозаичные: пожар в здании, залив с этажа выше, отключение целого района электричества, кража сервера вместе с бэкапом.

Проще всего это закрывается облаком. Veeam умеет отправлять копию напрямую в S3-совместимое хранилище — я использую российские облака вроде VK Cloud или Selectel для тех, кому критично держать данные в РФ по 152-ФЗ, либо Backblaze для менее чувствительных данных. Стоимость смешная: хранение терабайта обходится в 300-600 рублей в месяц в зависимости от провайдера, а для базы 1С среднего клиента даже с историей документов редко набегает больше 200-400 ГБ.

Если офис не один, можно обойтись без облака вообще: у клиента с производством в Подмосковье и складом в другом городе мы настроили репликацию бэкапов между площадками по VPN-туннелю каждую ночь. Дешевле по деньгам, но требует, чтобы вторая площадка реально существовала и имела приличный канал — гигабитный интернет там, где раньше хватало для почты, не всегда есть.

Как это выглядит в готовом виде — реальная схема одного клиента

Возьму медклинику на 25 рабочих мест — типичный пример из моей практики. Сервер с 1С:Медицина и картотекой пациентов стоит в серверной комнате администрации. Копия №1: Veeam снимает образ каждую ночь на локальный NAS, глубина хранения 21 день. Копия №2: раз в неделю по расписанию этот же NAS реплицирует immutable-снапшот на отдельный диск, который физически отключён от сети всё остальное время. Копия №3: раз в сутки зашифрованный архив уходит в облако Selectel, ключ шифрования хранится отдельно от системы бэкапа — на случай, если скомпрометируют и её.

Полное восстановление всей инфраструктуры с нуля в облаке при потере офиса целиком — часа четыре, мы это проверяли на учениях в прошлом декабре. Восстановление одной базы из локальной копии — 15-20 минут. Разница ощутима: локальная копия для рутинных сбоев, облачная — страховка на случай апокалипсиса.

Важная деталь: расписание проверки восстановления стоит в календаре раз в квартал. Бэкап, который никогда не пробовали развернуть, с вероятностью процентов тридцать окажется битым или неполным именно в тот момент, когда понадобится. Мы это проверили на собственной шкуре у одного клиента: копия шла исправно два года, а при попытке восстановления выяснилось, что пароль от архива потерян вместе с уволившимся сисадмином.

Частые ошибки и что делать, если денег в обрез

Самая частая ошибка — бэкап на тот же физический сервер, просто в другую папку или на соседний раздел диска. Формально копия есть, по факту она умирает вместе с диском. Вторая по частоте — все копии в одной локальной сети без изоляции, что и погубило юрфирму из начала статьи. Третья — никто не проверяет, что бэкап вообще снимается: скрипт падает молча уже полгода, а письмо об ошибке улетает на почту уволенного сотрудника.

Если бюджет реально маленький — до 30 тысяч в месяц на всю IT-часть, что для микробизнеса нормально — начните с малого, но правильного. Один недорогой NAS для второй копии внутри офиса, плюс бесплатный или дешёвый облачный тариф (у некоторых провайдеров есть 50-100 ГБ почти даром) для третьей копии критичных файлов: базы 1С, бухгалтерских документов, договоров. Не всей файловой помойки за десять лет — только того, без чего бизнес реально встанет.

И последнее: КриптоПро, электронные подписи, лицензионные ключи 1С — тоже данные, которые надо бэкапить, а не только базы. У одного клиента после сгоревшего сервера восстановили саму базу за час, а вот сертификат ЭЦП для отчётности пришлось перевыпускать в налоговой две недели, потому что ключевой контейнер никто не сохранил отдельно.

Частые вопросы

Сколько стоит внедрить схему 3-2-1 для компании на 20-30 рабочих мест?
По моей практике диапазон 100-250 тысяч рублей разово плюс 3-8 тысяч в месяц за облачное хранение, если делать через Veeam с локальным NAS и облаком. Если обойтись ротацией внешних дисков вместо второго NAS, разовые вложения падают тысяч до 40-60.

Можно ли обойтись только облаком, без локальной копии?
Можно, но восстановление большой базы 1С через интернет-канал офиса может занять часы вместо минут — если канал 50-100 Мбит/с, а база весит 200 ГБ, считайте сами. Локальная копия нужна именно для скорости, облако — для выживания при потере всего офиса.

Как понять, что шифровальщик не доберётся до резервной копии тоже?
Главный признак защищённости — копия не видна как обычный сетевой диск постоянно: она либо offline большую часть времени, либо immutable (неизменяемая даже для администратора в течение установленного срока). Если бэкап-хранилище примонтировано и доступно из основной сети круглосуточно, считайте, что защиты нет.

Нужно ли шифровать сами резервные копии?
Да, особенно ту, что уходит в облако — там данные физически лежат на чужом оборудовании. Ключ шифрования нужно хранить отдельно от системы бэкапа и точно не в той же учётной записи администратора, иначе при взломе одного украдут и второе.