Бэкап есть, а данных нет: 7 граблей резервного копирования в офисе до 50 рабочих мест

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш и пятнадцать лет занимаюсь IT-обслуживанием московских юрлиц. За эти годы у меня скопилась коллекция историй про бэкапы, и почти все они одинаковые: «Женя, у нас тут такая ситуация…» и дальше — слёзы. Эта статья — попытка не дать вам стать ещё одной строчкой в моей коллекции.

Почему IT-директор обязан лично разбираться в бэкапах

В офисе на 30–40 рабочих мест за бэкапы обычно отвечает либо системный администратор-одиночка, либо подрядчик, либо «как-то само». Все три варианта — мина замедленного действия. Системный администратор в отпуске, у подрядчика «всё нормально по отчёту», а самотёк ломается в первый же сбой питания.

Когда падает сервер 1С с базой за пять лет — отвечать перед собственником будет не сисадмин и не подрядчик. Отвечать будете вы как IT-директор. Поэтому минимум раз в квартал я прошу клиентов лично, в моём присутствии, нажать кнопку «восстановить из бэкапа» в тестовой среде. Без отговорок, без «у нас есть отчёт о выполнении». Только реальное восстановление.

Грабля №1: бэкап лежит на том же сервере

Январь 2026. Юридическая фирма из 18 человек, на старом физическом сервере крутится 1С, файловое хранилище и почта. Бэкап настроен — ежедневная архивация на «второй жёсткий диск этого же сервера». Контроллер RAID отказывает, забирает с собой оба диска. Бэкапы умерли вместе с продуктивом.

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

Грабля №2: «отчёт зелёный» — а внутри ничего нет

Самая болезненная история апреля 2025. Архитектурное бюро, 24 рабочих места. Подрядчик присылал ежедневный отчёт «бэкап 1С: успешно». Год. Когда понадобилось восстановить базу после сбоя, выяснилось: скрипт копировал не файл базы, а директорию с временными файлами 1С. То есть успешно копировал пустоту. Двенадцать месяцев. Восстановление обошлось в 380 тыс. руб. ручного труда бухгалтерии.

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

Грабля №3: бэкап доступен из сети — шифровальщик его съел

Производственная компания в Подмосковье, август 2025. Бухгалтер открыл письмо с «накладной» от мнимого контрагента. Шифровальщик прошёлся по всем доступным сетевым папкам, включая папку \\NAS\backup, куда автоматически складывались архивы. Через 40 минут зашифровано: рабочие станции, сервер 1С, NAS целиком.

Урок: бэкап, который виден из сети с правами на запись, — потенциально утерянный бэкап. Современные шифровальщики специально ищут шары с буквами «backup», «архив», «копия». Защита: либо физическое отключение носителя после копирования, либо включение режима неизменяемости (object lock в облаках, WORM на ленте).

Грабля №4: ушёл сотрудник — увёл доступы

Зима 2026. Логистическая компания, 32 человека. Уволился системный администратор, у которого были все пароли от хостинга, облачных хранилищ и удалённых бэкапов. Передачи дел не было. Через два месяца истекла подписка на облачное хранилище — карта-плательщик принадлежала ему лично. Хостер удалил данные через 14 дней. Восстанавливать уже было нечего.

Чек-лист, который я навязываю каждому клиенту: все доступы в корпоративном KeePass с резервной копией; платежи за инфраструктуру с корпоративной карты юрлица, а не с личной карты сотрудника; уведомления об оплате — на групповой адрес it@yourcompany.ru, а не на конкретного человека; договоры с облачными провайдерами — на компанию, а не на физлицо.

Грабля №5: «сделаем 1С через коробочный Битрикс24, там же бэкап есть»

Часто слышу: «Зачем нам своя инфраструктура, у нас всё в облаке». В 2026 году это уже не оправдание. Кейсы марта 2026: блокировка аккаунта одного популярного российского сервиса по жалобе конкурента — две недели простоя. Технический сбой у крупного облачного провайдера — потеряны данные клиентов, не попавшие в бэкап последних 6 часов. Компания «не заплатила вовремя» из-за переноса банковских реквизитов — данные отправлены в архив без возможности быстрого извлечения.

Правило, которое я повторяю как мантру: данные, которые нельзя выгрузить в свой бэкап, — не ваши. Сервис в облаке — это операционное удобство. Защита данных требует независимой копии в другом месте. Для Битрикс24, AmoCRM, Яндекс 360, Microsoft 365 — у всех есть API для регулярной выгрузки, и мы это автоматизируем для каждого клиента.

Грабля №6: бэкап делается, но не помещается обратно

Ноябрь 2025. Дизайн-студия, 26 рабочих мест. Файловый сервер 4 ТБ, бэкап шёл на NAS на 6 ТБ. Когда сервер сгорел, при восстановлении выяснилось: каналу в офисе нужно 38 часов, чтобы скачать архив с удалённого NAS обратно. Студия стояла полтора суток. После этого мы внедрили двухуровневую схему: горячий бэкап в офисе на отдельном NAS (восстановление за 2 часа) плюс холодный — в облаке для катастрофы.

Параметр, который IT-директор должен лично знать про свою систему резервирования, — RTO (Recovery Time Objective). Это сколько времени пройдёт от инцидента до возврата к работе. Не часы и не дни на бумаге, а реальные часы на стенде. Если RTO больше восьми часов, а бизнес теряет миллион в день простоя — схема резервирования не годится.

Грабля №7: бэкап есть, а ключи шифрования нет

Свежий случай, март 2026. Финансовая компания внедрила «умное шифрование» бэкапов AES-256. Ключ хранил админ. Админ уехал в отпуск, не выходя на связь. Сгорел диск с базой 1С. Архив есть — расшифровать нечем. Купировали с помощью переписки в Telegram через родственников. Восстановили за пять дней с потерей нервов и денег на простое.

Шифрование бэкапов — обязательная вещь, особенно если копии лежат в публичном облаке. Но ключ должен быть продублирован: у директора в сейфе, у IT-директора в личном KeePass, у подрядчика по аудиту в зашифрованном виде. Нельзя, чтобы ключ существовал в одном экземпляре.

Что считается нормой бэкапа в 2026 году для офиса до 50 РМ

За годы практики я свёл стандарты в одну табличку. Это то, что мы проектируем для каждого нового клиента в АйТи Фреш:

Каждая позиция — это конкретная техника, конкретный софт и конкретный бюджет. Я не верю в «универсальное решение для всех» — у каждого офиса свой набор приоритетов. Но в любом случае правило 3-2-1 должно соблюдаться: три копии, два разных типа носителей, одна — в другом месте.

Сколько это всё стоит

Чтобы IT-директору было от чего считать бюджет, вот реальные цифры за апрель 2026, которые мы озвучиваем клиентам АйТи Фреш:

• Аудит существующей системы бэкапов. Смотрим что и куда копируется, проверяем восстановление, выдаём отчёт. 18 000–25 000 руб., 2–3 рабочих дня. Нередко после аудита клиент хватается за голову.
• NAS Synology или QNAP среднего класса с дисками. 95 000–150 000 руб. за устройство 4×8 ТБ в RAID 6 с горячей заменой. Это разовая покупка на 5–7 лет.
• Настройка системы резервирования. Veeam Backup для физики, Proxmox Backup для гипервизоров, Restic/Borg для файловых данных, скрипты для облачных сервисов. 35 000–60 000 руб. под ключ.
• Облачное хранилище в РФ. Selectel или VK Cloud для 500 ГБ–1 ТБ с object lock — 2 500–5 500 руб./мес.
• Постоянный мониторинг и тестовые восстановления. Включены в наш тариф «Стандарт» — 110 000 руб./мес для офиса 25 ПК.

Итого первичные вложения для типичного офиса 30 рабочих мест с 1С, AD и файловым сервером — порядка 200–280 тыс. руб. единоразово плюс 5–7 тыс. руб./мес за хранилище. Сравните с 480 000 руб. потерь в случае ниже и 2–3 неделями простоя бухгалтерии.

Кейс из апреля 2026 — почему я снова про это пишу

На прошлой неделе мне позвонили в среду в 22:40. Бухгалтерская компания, 26 человек, не наш клиент. Их предыдущий админ держал бэкапы 1С в облаке на личном Google Drive. Аккаунт заблокирован за нарушение политики (что-то про шифрованные архивы — Google решил, что это вредонос). Восстановление аккаунта от Google идёт уже шестой день. Базы за два года — недоступны.

Договорились на пятницу провести аудит и взять их на сопровождение. Сделаем нормальный бэкап с тремя копиями, шифрованием, immutable-режимом и регулярными тестами. Но осадок будет — потеряют минимум полторы недели первичной документации, потому что Google пока молчит. Это рабочий 2026 год, и подобные истории прилетают мне раз в две-три недели.

FAQ — что спрашивают про бэкапы юрлица

Как часто надо проверять восстановление из бэкапа?

Минимум раз в квартал — поднимать тестовую копию ключевой системы (1С, файловый сервер, почта) на отдельной машине или в виртуалке и убедиться что она работает. Раз в месяц — автоматический контроль целостности архивов. Раз в год — полные учения с условным восстановлением всего офиса.

Где должен лежать второй экземпляр бэкапа?

Не на том же сервере и не у того же провайдера. Минимум — отдельный физический NAS в офисе плюс российское облако (Selectel, VK Cloud, Яндекс) с включённой блокировкой удаления. Идеально — третья копия у другого провайдера или на отчуждаемом носителе в сейфе.

Сколько стоит нормальный бэкап для офиса до 50 РМ?

Под ключ 65–95 тыс. руб. за внедрение (NAS, ПО, настройка, документация) плюс 3–6 тыс. руб./мес за облачное хранилище 500 ГБ–1 ТБ и постоянный мониторинг в рамках абонентки. Для офиса с 1С, AD и файловым сервером — окупается за один предотвращённый инцидент.

Бэкап моего хостера или Битрикс24 считается?

Эти бэкапы — удобство, но не страховка. Если у вас увели аккаунт, провайдер заблокировал, а юрист найдёт вас в санкционном списке — данные исчезнут вместе с сервисом. Всегда нужна вторая копия в другом независимом месте.

Шифровальщик зашифровал и бэкапы — что делать?

Если бэкапы лежали на доступной из сети шаре — поможет только immutable-копия (с защитой от удаления) или физически отключенный носитель. Поэтому в наших проектах мы делаем object lock в облаке + еженедельный экспорт на офлайн-диск, который меняется по расписанию.