Backup для бизнеса: что бэкапить, куда и как часто

Любая компания живёт на данных: база 1С с проводками за пять лет, клиентская CRM, бухгалтерия, переписка, договоры на файловом сервере, конфигурации сетевого оборудования. Пока всё работает, об этих данных не думают. Но данные исчезают не «когда-нибудь теоретически», а по совершенно бытовым причинам: вышел из строя диск, сотрудник снёс не ту папку, прилетел вирус-шифровальщик и зашифровал всё, до чего дотянулся по сети.

Резервное копирование (англ. backup — резервная копия) — это страховка от всех трёх сценариев сразу. Не «копия на всякий случай», а инженерная дисциплина с понятными правилами: что копировать, как часто, куда и как проверять, что копия рабочая. Разберём по порядку.

Почему бэкап критичен: три сценария потери данных

В практике потеря данных почти всегда сводится к трём причинам — и от каждой защищает именно бэкап, а не что-то ещё.

1. Аппаратный сбой. Диски умирают — это вопрос не «если», а «когда». RAID-массив (объединение нескольких дисков для отказоустойчивости) спасает от смерти одного диска, но не от выхода из строя контроллера, скачка напряжения, который убивает весь сервер, или пожара в серверной. RAID — это не бэкап, это распространённое заблуждение, на котором горят компании.

2. Человеческая ошибка. Сотрудник удалил рабочую папку, бухгалтер откатил не ту базу, администратор выполнил команду не на той машине. По статистике инцидентов это одна из самых частых причин потери данных — и от неё не защищает ни RAID, ни синхронизация в облако (она просто повторит удаление во всех копиях).

3. Вирус-шифровальщик (ransomware). Самый разрушительный сценарий последних лет. Вредонос попадает в сеть, шифрует базы, файлы и — целенаправленно — резервные копии в доступных сетевых папках, после чего требует выкуп. Если единственная копия лежала на сетевом диске рядом с сервером, она будет зашифрована вместе со всем остальным. Подробно механику атаки и защиту мы разбирали в материале про вирусы-шифровальщики и защиту бизнеса.

Вывод простой: правильно настроенный бэкап — это единственное, что одновременно закрывает все три риска. Всё остальное (RAID, антивирус, синхронизация) — полезные, но частичные меры.

Что именно нужно бэкапить

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

• Базы 1С. Сердце бухгалтерии и учёта. Бэкапятся либо средствами самой 1С (выгрузка), либо на уровне СУБД (резервная копия базы данных). Для активной базы важен не только суточный снимок, но и журнал транзакций — чтобы откатиться не к утру, а к последнему часу.
• Базы данных (СУБД). PostgreSQL, Microsoft SQL Server, MySQL под CRM, ERP, внутренними сервисами. Бэкап БД делается их штатными средствами с учётом согласованности (consistent backup) — чтобы копия не оказалась «снимком на середине транзакции».
• Файловые ресурсы. Сетевые папки отделов, общие документы, проектные архивы. Самый понятный объект, но именно здесь чаще всего теряют данные руками.
• Корпоративная почта. Если почтовый сервер свой (Microsoft Exchange, российские аналоги) — почта бэкапится отдельно. Письма, вложения, договоры в переписке — это тоже бизнес-данные.
• Конфигурации. Настройки маршрутизаторов, коммутаторов, межсетевых экранов, серверов, AD (Active Directory — служба каталогов). Восстановить сервер из бэкапа данных без конфигурации сети — это половина работы.
• Виртуальные машины целиком. Если инфраструктура виртуализирована (zVirt, VMware и аналоги), удобно бэкапить ВМ целиком — образ машины со всем содержимым. Это позволяет поднять сервис «как был» на новом железе за минуты, а не пересобирать вручную.

Хорошая практика — составить реестр: что за данные, где лежат, кто отвечает, насколько критичны, как часто меняются. Этот реестр задаёт политику бэкапа: не всё нужно копировать с одинаковой частотой.

Правило 3-2-1 — отраслевой стандарт

Главное правило резервного копирования, признанное во всём мире, читается так:

• 3 копии данных — оригинал плюс две резервных.
• 2 разных типа носителей — например, дисковый массив и облако, или диск и лента. Чтобы одна и та же поломка не убила сразу все копии.
• 1 копия — вне офиса (офсайт). Чтобы пожар, затопление, кража или шифровальщик в локальной сети не уничтожили вообще всё.

Логика правила в том, что оно защищает от коррелированных отказов: когда одна причина (пожар, шифровальщик, сбой хранилища) бьёт сразу по нескольким копиям. Подробный разбор с примерами вынесен в отдельную статью базы знаний — правило 3-2-1. Современная вариация правила добавляет ещё одну цифру — иммутабельную (неизменяемую) копию, которую невозможно перезаписать или удалить в течение заданного срока; именно она лучше всего защищает от шифровальщика.

Как часто делать копии: RPO простым языком

Частоту бэкапа задаёт не ИТ-отдел из удобства, а бизнес — через простой вопрос: сколько данных мы готовы потерять при сбое? Этот допустимый объём потерь в единицах времени называется RPO (Recovery Point Objective — целевая точка восстановления).

Если RPO равен 24 часам — значит, при аварии мы согласны потерять до суток работы и откатиться к вчерашней копии. Если RPO равен 1 часу — копии (или журналы транзакций) должны сниматься минимум раз в час. Чем меньше RPO, тем чаще бэкап и тем дороже инфраструктура. Разбор RPO в паре с RTO (временем восстановления) — в статье RPO и RTO.

Ориентиры на практике:

• Базы 1С и активные СУБД — полная копия раз в сутки плюс журнал транзакций каждые 15–60 минут. Так при сбое теряется не день, а максимум час работы.
• Файловые ресурсы — раз в сутки, обычно ночью.
• Почтовый сервер — раз в сутки.
• Редко меняющиеся данные (архивы, образы конфигураций) — раз в неделю.
• Виртуальные машины — раз в сутки, критичные — чаще, с хранением нескольких точек восстановления.

Важна и глубина хранения (retention): сколько суточных, недельных и месячных копий держать. Распространённая схема — несколько ежедневных, несколько еженедельных и несколько ежемесячных копий, чтобы можно было откатиться не только на вчера, но и на состояние месячной давности (например, когда ошибку в данных заметили не сразу).

Куда складывать: локально, облако, лента

Правило 3-2-1 требует разных носителей и офсайт-копии. На практике используют комбинацию трёх вариантов.

Локально (диск, NAS, СХД). Самый быстрый вариант восстановления — копия лежит рядом, восстановление идёт на полной скорости сети. Минус: эта копия гибнет вместе с офисом при пожаре и доступна шифровальщику, если хранилище в той же сети. Поэтому локальная копия — это «первая линия», но не единственная.

Облако. Закрывает требование офсайт-копии. Данные уезжают в дата-центр за пределами офиса, переживут пожар и кражу. Российские облачные провайдеры (Yandex Cloud, VK Cloud, Selectel и др.) предоставляют объектные хранилища с поддержкой иммутабельности. Минус — восстановление больших объёмов ограничено шириной интернет-канала.

Лента (tape). Ленточные библиотеки до сих пор актуальны для долгого хранения больших объёмов: лента дёшева за терабайт, физически отключаема от сети (а значит, недоступна шифровальщику), хранится годами. Это классический «холодный» офсайт-носитель для архивов. Подробнее — в статье резервное копирование на ленты.

Рабочая схема для среднего бизнеса обычно выглядит так: первая копия — локально на СХД для быстрого восстановления, вторая — в облако как офсайт с иммутабельностью, для архивов с длинным сроком хранения — лента. Это и есть 3-2-1 на практике.

Проверка восстановления: бэкап без теста — иллюзия

Это самый недооценённый пункт и причина большинства катастроф. Компания годами «делает бэкап», а в момент аварии выясняется, что:

• задание копирования давно падало с ошибкой, но писем об этом никто не читал;
• диск назначения переполнился, и последние месяцы копии не создавались вовсе;
• архив повреждён и не открывается;
• копия есть, но из неё не поднимается рабочая база — не хватает зависимостей, версия СУБД не та, забыли про журнал транзакций.

Вывод жёсткий, но честный: бэкап, который ни разу не восстанавливали, — это не бэкап, а надежда. Единственный способ убедиться, что данные реально вернутся, — регулярный тестовый restore (восстановление) на отдельной машине по расписанию, а не в день аварии. Проверяется не только то, что архив распаковывается, но и то, что восстановленная база открывается, в ней есть свежие данные, сервис запускается. Это та работа, которая отделяет «у нас вроде есть бэкапы» от «мы восстановимся за два часа».

С проверкой восстановления тесно связан план аварийного восстановления — последовательность действий, кто что делает при катастрофе, в какие сроки. Эту тему мы разбираем отдельно в материале про план восстановления (DR), RTO и RPO.

Импортозамещение Veeam: чем заменить

Отдельная боль российского бизнеса — на чём вообще делать бэкап. До 2022 года рынок резервного копирования был де-факто иностранным. По данным отраслевых обзоров (Cloud4Y, публикации на Хабре и CNews):

• Veeam — лидер рынка, около 32% использований в РФ. С 2022 года из-за санкций вендор прекратил официальные продажи, техподдержку и выпуск обновлений для российских компаний.
• Veritas (около 18%) и Commvault (около 16%) — тоже иностранные, с теми же проблемами поддержки.
• Около 70% компаний по-прежнему работают на иностранных системах резервного копирования — без официальной поддержки и обновлений. Это накапливающийся риск: при серьёзном сбое или несовместимости с новой версией ОС обратиться будет не к кому.

Зрелые российские системы резервного копирования (СРК), на которые реально переходят:

• Кибер Бэкап — продукт вендора Киберпротект (ранее развивался под маркой Acronis Infoprotect). Покрывает серверы, виртуальные машины, базы данных, рабочие станции. Подробный разбор — в статье Кибер Бэкап (Киберпротект).
• RuBackup — российская система резервного копирования корпоративного класса, ориентированная на гетерогенные среды (разные ОС, СУБД, гипервизоры). Разбор — в статье RuBackup.

Популярный сценарий полного импортозамещения связки VMware + Veeam — это связка zVirt (российская платформа виртуализации) плюс Кибер Бэкап. Так компания закрывает и виртуализацию, и резервное копирование поддерживаемыми отечественными продуктами. Стоимость лицензий и проекта миграции зависит от числа узлов и объёма данных — ориентир можно дать только после аудита; конкретные цифры варьируются от конфигурации.

Если вы откладываете замену Veeam — это тема отдельного практического разбора: чем делать бэкап вместо Veeam в 2026 году.

Роль ИТ-аутсорсера

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

Что в этой части делает ИТ-аутсорсер вроде нас:

• проектирует схему бэкапа под конкретную инфраструктуру и требования бизнеса (какой RPO, что критично, нужна ли офсайт-копия);
• внедряет систему резервного копирования (включая импортозамещение Veeam на Кибер Бэкап или RuBackup);
• настраивает правило 3-2-1: локальная копия, облако, при необходимости лента;
• ведёт ежедневный мониторинг заданий из NOC — ошибка бэкапа ловится в день её появления, а не в день аварии;
• проводит регулярные тестовые восстановления и фиксирует результат письменно;
• держит наготове план аварийного восстановления.

Мы проектируем и обслуживаем резервное копирование как часть ИТ-аутсорсинга — для нас это не отдельный продукт, а обязательный слой инфраструктуры, за который мы отвечаем по SLA.

FAQ

Чем резервное копирование отличается от синхронизации в облако?

Синхронизация повторяет изменения сразу. Если файл удалили, повредил шифровальщик или его испортил сотрудник — синхронизация послушно перенесёт повреждение во все копии. Бэкап — это снимок состояния на момент времени, к которому можно откатиться. Синхронизация защищает от поломки одного диска, но не от ошибки, удаления и шифровальщика. Полноценная защита — это именно бэкап с историей версий.

Что такое правило 3-2-1 простыми словами?

Три копии данных (оригинал плюс две резервных), на двух разных типах носителей, одна копия — вне офиса. Даже если в офисе случится пожар, кража или шифровальщик доберётся до сетевого хранилища, офсайт-копия останется целой.

Как часто нужно делать резервные копии?

Зависит от RPO — сколько данных вы готовы потерять при сбое. Для 1С и критичных СУБД обычно копия раз в сутки плюс журнал транзакций каждые 15–60 минут. Файловые ресурсы — раз в сутки. Редко меняющиеся данные — раз в неделю. Частоту задаёт бизнес, а не ИТ.

Защищает ли бэкап от вируса-шифровальщика?

Защищает, если копии недоступны для изменения из заражённой сети. Современные шифровальщики целенаправленно ищут и шифруют бэкапы в сетевых папках. Спасает офсайт-копия и иммутабельное (неизменяемое) хранилище. Одна копия на сетевом диске рядом с сервером — это не защита от шифровальщика.

Чем заменить Veeam после ухода вендора из России?

Зрелые российские СРК — Кибер Бэкап (вендор Киберпротект, ранее Acronis Infoprotect) и RuBackup. Они закрывают серверы, виртуальные машины, базы данных, файлы. Популярна связка zVirt плюс Кибер Бэкап как замена VMware плюс Veeam. Около 70% компаний всё ещё на иностранных СРК без поддержки — переход стоит планировать заранее.

Зачем тестировать восстановление, если бэкап и так делается?

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

Сколько стоит организовать резервное копирование для компании?

Зависит от объёма данных, числа серверов и ВМ, глубины хранения и того, нужно ли облако. Разовая настройка для небольшого офиса обычно укладывается в диапазон от десятков до сотен тысяч рублей, обслуживание и облачное хранилище — отдельно по объёму. Точную смету даём после аудита. Цифры ориентировочные и зависят от конфигурации и объёма данных.

Вывод

Резервное копирование — это не строчка в бюджете «на всякий случай», а инженерная дисциплина с четырьмя опорами: бэкапить всё критичное (1С, БД, файлы, почту, конфигурации, виртуалки), хранить по правилу 3-2-1, снимать копии с частотой под нужный RPO и — обязательно — регулярно проверять восстановление. На фоне ухода Veeam отдельная задача — вовремя перейти на поддерживаемую российскую СРК (Кибер Бэкап, RuBackup), не дожидаясь, пока «иностранное без обновлений» превратится в проблему.

Кибер Авангард проектирует и обслуживает резервное копирование как часть ИТ-аутсорсинга: схема под ваш бизнес, импортозамещение Veeam, ежедневный мониторинг из NOC и регулярные тестовые восстановления. Напишите нам — проведём аудит того, что у вас бэкапится сейчас, и честно скажем, восстановитесь ли вы при аварии.