«У нас есть бэкап» — самая большая ошибка в ИТ
На словах бэкап есть почти у всех. А на деле за этой фразой может стоять что угодно: RAID, диск рядом с сервером, флешка по пятницам или надежда, что прошлый айтишник что-то настроил. И ценность бэкапа равна нулю до аварии — становится бесценной в ту минуту, когда переделать уже нельзя.
«Бэкапом» могут называть что угодно, а что в реальности?
Почти каждый руководитель уверен, что с резервным копированием у него порядок. А проверяется эта уверенность ровно один раз — в тот день, когда данные уже пропали.
За фразой «да, у нас бэкапы есть» может стоять буквально что угодно. RAID в сервере, внешний диск рядом с ним, флешка, которую кто-то иногда подключает, копия трёхмесячной давности — или просто вера, что прошлый айтишник всё настроил.
Пока ничего не случилось, такой уверенности хватает. А потом приходит первая авария — умер диск, зашифровались файлы, кто-то снёс базу 1С — и выясняется, что слово «бэкап» было, а самого бэкапа нет. Файлы либо есть, либо их нет. И переделать в этот момент уже ничего нельзя.
У резервного копирования необычное свойство: пока всё спокойно, его польза почти незаметна, а в момент аварии становится решающей. Поэтому сначала разберём пять привычных заблуждений, из-за которых понятие «бэкап вроде есть» превращается в «бэкапа нет», а потом — как должно быть устроено нормальное копирование.
«Бэкапы есть» — утверждение, которое почти никто не проверял
Наличие бэкапа обычно декларируют, но подтверждают редко. А проверять его нужно именно до аварии — потому что после неё исправлять уже поздно.
За формулировкой «бэкапы есть» может скрываться что угодно: RAID, внешний диск рядом с сервером, ручное копирование на флешку, устаревшая копия или предположение, что предыдущий администратор всё настроил как надо.
До первого инцидента этого набора кажется достаточно. А в момент аварии выясняется, что декларация была, а пригодной к восстановлению копии — нет. Данные либо восстановимы, либо нет. Промежуточного состояния не существует, и переделать в эту минуту уже ничего нельзя.
У резервного копирования необычное свойство: до аварии его ценность почти нулевая, а в момент аварии — критическая. Разберём пять типовых заблуждений, которые превращают «бэкап есть» в «бэкапа нет», а затем — требования к корректному копированию.
Пять заблуждений, из-за которых «бэкап есть» = «бэкапа нет»
Во всех пяти случаях люди были уверены, что с копированием у них всё хорошо. Ровно до того дня, когда копия понадобилась.
Пять типовых заблуждений, обнуляющих резервное копирование
Объединяет их одно: во всех случаях рабочий бэкап предполагался, но не проверялся — до того момента, когда копия потребовалась.
Про бэкапы решает владелец данных, а не админ
Обычно всё отдают на откуп айтишнику: «настрой бэкапы». Но у каждых данных есть конкретный владелец — человек или отдел, — и часть решений может принять только он.
У любых данных есть владелец — конкретный человек или отдел.
Какие данные критичны, сколько работы можно потерять, что нельзя терять никогда — на это отвечает именно владелец. База 1С — её владелец главбух, и именно он знает, сколько дней работы можно потерять без катастрофы. Клиентская база — руководитель продаж. Договоры и документы — директор или юрист. У каждого набора данных есть свой ответственный. И админ не может и не должен решать за них, что для них критично.
Админ — это тот, кто реализует. А что копировать, как часто и сколько хранить — согласовывают с владельцами данных. И как минимум эти люди должны иметь право голоса, когда утверждают бюджет и технические решения по бэкапам: ведь рискуют именно их данные. Тогда это уже осознанное решение тех, чьи это данные, а не просто «админ что-то там настроил».
Политику бэкапа задаёт владелец данных, а не администратор
Технически копирование настраивает админ. Но исходные требования задаёт владелец данных — конкретный человек или отдел: только он знает их ценность и допустимые потери.
У каждого набора данных есть владелец — конкретный человек или отдел.
Перечень критичных данных, допустимый объём потери и глубину хранения задаёт именно он — из техники эти параметры не выводятся. База 1С — владелец главбух: он определяет, сколько работы допустимо потерять (фактически — целевую точку восстановления, RPO). Клиентская база — руководитель продаж. Документы — директор или юрист. У каждого набора данных — свой ответственный, и требования к его защите задаёт он, а не администратор.
Администратор реализует политику, но не назначает её. Требования согласуют с владельцами данных, и они же должны иметь право голоса при утверждении бюджета и технических решений. А уже на основе требований строится регламент: объекты, периодичность, глубина и места хранения — и под него считается бюджет на ёмкость и хранение.
Четыре вопроса, на которые отвечает бизнес
Когда на эти четыре вопроса есть ответы — из них складывается нормальная политика копирования. А без ответов получается «как-то настроили».
Четыре параметра, которые задаёт бизнес
Ответы на эти четыре вопроса формируют политику копирования. А без них конфигурация получается случайной.
Правило 3-2-1
Чтобы не держать всё это в голове, есть короткое правило, которым пользуются во всём мире. Три цифры, которые описывают нормальный бэкап.
Если коротко: три копии, на двух разных видах носителей, и одна из них — физически в другом месте. Это разумный ориентир, а не жёсткий закон. И чем ближе ваша схема к 3-2-1, тем меньше шансов, что одно событие уничтожит и данные, и все копии разом.
Правило 3-2-1
Отраслевой ориентир для проектирования схемы хранения копий. Три числа, описывающие минимально устойчивую конфигурацию.
Формулировка: три копии, два разных носителя, одна off-site. Это инженерный ориентир, а не норматив: чем ближе схема к 3-2-1, тем меньше вероятность, что одно событие уничтожит оригинал и все копии одновременно. Современная вариация — добавить ещё одну неизменяемую или офлайн-копию как защиту от шифровальщика.
Где жить бэкапам
Правило 3-2-1 говорит «несколько копий на разных носителях». Рассмотрим основные места, где эти копии живут — у каждого свои сильные и слабые стороны.
Идеального варианта здесь нет — у каждого способа есть цена, и каждый закрывает одни риски, но оставляет открытыми другие. Поэтому и подход правильный не «выбрать один». Правильный — собрать из нескольких способов систему. Например: локальная копия для быстрого восстановления плюс облако или лента для хранения вне офиса. Так быстрый, но уязвимый способ страхуется медленным, но надёжным — и вместе они дают то, чего поодиночке не даёт ни один.
Где размещать копии
Реализация 3-2-1 на практике — это выбор носителей и площадок. Основные варианты и их компромиссы по скорости, стоимости и устойчивости.
Универсального варианта нет: каждый носитель выигрывает в одном (RTO, стоимость, устойчивость к шифровальщику) за счёт другого. Рабочий подход — комбинация уровней, а не один носитель. Типовая схема: быстрый локальный уровень для оперативного восстановления плюс off-site (облако или лента) на случай потери офиса и для защиты от шифровальщика. Уровни дополняют друг друга и вместе закрывают и RTO, и требование 3-2-1.
Бэкап нужно проверять — регулярно и руками
Можно сделать всё правильно — и всё равно остаться без данных, если ни разу не проверить, что из копии действительно можно восстановиться.
Мы у своих клиентов делаем это регулярно — и иногда находим проблемы. Именно потому, что проверяем. Ведь куда лучше найти проблему с бэкапом в спокойной обстановке, чем в момент, когда данные уже потеряны. Есть старая шутка: «админы делятся на тех, кто не делает бэкапы, и тех, кто уже делает». А на самом деле типов три — и нормальный это третий: те, кто проверяет сделанные бэкапы.
Проверка восстановимости — регулярно и вручную
Корректно настроенный бэкап без регулярной проверки восстановления остаётся неподтверждённым — то есть фактически ненадёжным.
На нашей практике регулярная проверка периодически выявляет проблемы — именно потому, что проводится. А обнаружить дефект копии в штатном режиме дешевле, чем в момент аварии. Классическая формулировка «администраторы делятся на тех, кто не делает бэкапы, и тех, кто уже делает» неполна: третий и целевой тип — те, кто проверяет восстановимость сделанных копий.
Наши принципы — применительно к бэкапам
Резервное копирование — это прямое воплощение всех четырёх принципов сразу.
Четыре принципа — применительно к бэкапам
Резервное копирование — прямая реализация всех четырёх принципов на уровне сохранности данных.
«А что насчёт …?»
Вопросы про бэкапы, которые задают чаще всего — и которые выходят за рамки «настройте копирование».
Может, и это частая беда. Мало просто положить копию на отдельное устройство: если оно постоянно подключено к сети и доступно с заражённого сервера, вирус зашифрует и бэкап вместе со всем остальным.
Защита — в том, чтобы хотя бы одна копия была недоступна для вируса. Это либо офлайн-копия (носитель, который физически отключают после копирования и уносят), либо неизменяемые копии — когда хранилище технически не позволяет переписать или удалить уже сделанный бэкап в течение заданного срока. Плюс отдельные доступы: учётка, под которой работает сервер, не должна иметь права стирать бэкапы.
Это вопрос, про который чаще всего забывают. Одно дело — «копия есть», другое — как быстро из неё реально поднимется работа. Если у вас 500 ГБ данных, а единственная копия — в облаке на небыстром канале, восстановление может занять сутки. А сутки простоя — это уже не «данные не потеряны», это серьёзные убытки.
И скорость напрямую зависит от того, где лежит копия — как раз про это секция «Где жить бэкапам» выше. С локального диска или выделенного сервера в офисе восстановление идёт быстро. А из облака большой объём может тянуться по интернету часами. Лента LTO хранит данные дёшево и надёжно, но достать и прочитать её — это уже не минуты. У каждого места хранения своя скорость восстановления.
Поэтому время восстановления стоит прикинуть заранее и понять, устраивает ли оно вас. Именно ради скорости копии и комбинируют: локальная — чтобы восстановиться быстро, удалённая (облако или лента) — на случай, когда локальной уже нет. Ведь важна не только сохранность данных, но и то, как быстро бизнес вернётся к работе.
Есть несколько простых признаков, по которым легко себя проверить. Тревожно, если: вы не помните, когда последний раз реально восстанавливались из копии (или не делали этого никогда), копия лежит на том же сервере или в том же шкафу, что и оригинал, копируются «какие-то папки», а про базы 1С, почту и настройки никто не думал, никто не следит, не кончилось ли место и не сыплются ли ошибки.
Если хотя бы один пункт про вас — это повод разобраться, не дожидаясь аварии. Ведь «всё устраивает» в бэкапах слишком часто означает «никто не проверял». А самый честный тест — прямо сейчас попробовать восстановить из копии один важный файл и одну базу.
Да, нужно — и это неочевидно. Распространённое заблуждение: «оно в облаке, значит уже защищено». Провайдер действительно отвечает за своё железо — но не за ваши действия. Удалили важное письмо или файл, уволенный сотрудник всё подчистил, увели доступ к аккаунту, шифровальщик прошёлся через синхронизацию — и провайдер тут не поможет.
Поэтому облачные данные тоже стоит копировать — отдельно от самого облака. Есть сервисы, которые специально бэкапят почту и облачные документы в независимое хранилище. А правило то же: копия должна быть отдельно от оригинала — даже если оригинал «в надёжном облаке».
Чаще всего это не космос. Базово нужно место под копии — отдельный диск или NAS — плюс время на нормальную настройку и последующие проверки. Облачная копия добавляет небольшую помесячную плату за объём. И это вполне подъёмные для бизнеса деньги.
А правильнее сравнивать не с ценой железа. Сравнивать надо с ценой потери. Сколько будет стоить неделя ручного восстановления, потерянная база 1С или остановка компании на два дня — обычно в разы больше, чем вся система копирования. Вкладываться разумно в то, что реально снижает риск: отдельная и удалённая копия, защита от шифровальщика, регулярная проверка. А переплачивать за избыточные мощности не нужно.
Вопросы за рамками базовой настройки
Что чаще всего спрашивают, когда «просто настроить копирование» уже недостаточно.
Да, если копия постоянно доступна по сети со скомпрометированного узла, она шифруется вместе с оригиналом. Размещения «на отдельном устройстве» тут недостаточно — важна недоступность копии для атакующего процесса.
Рабочие подходы: офлайн-копия (носитель отключают после задания), неизменяемые (immutable) бэкапы с запретом перезаписи и удаления в течение заданного срока, изоляция репозитория и отдельные учётные данные — сервисная учётка рабочих систем не должна иметь прав на модификацию бэкапов. И минимум одна копия из схемы 3-2-1 держится вне сетевой досягаемости.
Это целевое время восстановления (RTO), и его часто упускают. «Копия есть» не равно «быстро восстановимся»: восстановление сотен ГБ с удалённого хранилища по ограниченному каналу может занять часы или сутки — а это прямой простой бизнеса.
RTO напрямую определяется выбором носителя — см. секцию «Где жить бэкапам». Локальный диск или backup-сервер дают минимальный RTO. Восстановление из облака ограничено пропускной способностью канала. А лента LTO — надёжно и дёшево, но время доступа и чтения высокое. У каждого уровня хранения своя скорость восстановления.
Поэтому RTO оценивают заранее и сопоставляют с допустимым простоем, а схему строят многоуровневой: быстрый локальный уровень для оперативного восстановления плюс off-site на случай потери офиса. И продумывают сразу оба параметра — допустимую потерю данных (RPO) и допустимое время простоя (RTO).
Экспресс-самоаудит. Тревожные признаки: тестовое восстановление никогда не проводилось или дату не вспомнить, копия лежит рядом с оригиналом (тот же сервер или шкаф), в охвате только «папки», без БД, почты и конфигураций, отсутствует мониторинг успешности заданий, свободного места и ошибок.
Любой совпавший пункт — основание для ревизии до инцидента. «Всё устраивает» в контексте бэкапов обычно означает «никто не проверял восстановимость». А объективный тест — контрольное восстановление критичного файла и одной БД прямо сейчас.
Да. Заблуждение «в облаке — значит защищено» игнорирует модель разделяемой ответственности: провайдер отвечает за доступность инфраструктуры, но не за логическую целостность ваших данных. Удаление, действия уволенного сотрудника, компрометация аккаунта, шифрование через синхронизацию — всё это зона ответственности клиента.
Облачные сервисы (почта, документы, облачная 1С) копируются в независимое от провайдера хранилище — для этого есть специализированные решения backup SaaS. А принцип неизменен: копия отделена от оригинала, даже если оригинал размещён в облаке.
Базовые затраты: ёмкость под копии (диск/NAS), время на настройку и регулярные проверки, а при использовании облака — помесячная плата за объём off-site копии. Для малого и среднего бизнеса это умеренные суммы.
Корректная база сравнения — не стоимость железа, а стоимость инцидента: ручное восстановление, потеря БД, простой на несколько дней обычно кратно дороже всей системы копирования. Инвестировать имеет смысл в то, что снижает риск (отдельная и off-site копия, защита от шифровальщика, проверки восстановимости), без избыточной ёмкости «про запас».
Если «бэкапы вроде бы есть» — но никто не проверял
Посмотрим, что и куда у вас копируется сейчас, вместе с вами определим, какие данные критичны и сколько работы нельзя терять, выстроим нормальную схему (несколько копий, отдельно и вне офиса, защита от шифровальщика) и настроим регулярную проверку восстановления. Чтобы в день аварии бэкап оказался реальным, а не просто словом.
Бэкап, который реально восстанавливается
Аудит текущего охвата и схемы хранения, согласование требований с владельцами данных (перечень объектов, RPO, глубина), проектирование политики по 3-2-1 с off-site и защитой от шифровальщика (офлайн / неизменяемые копии), автоматизация заданий и мониторинг. Настройка регулярного тестового восстановления с контролем RTO. Включение в охват БД (корректная выгрузка 1С), почты, конфигураций и контроллеров домена.