Бэкап есть, а данных нет: 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 в облаке + еженедельный экспорт на офлайн-диск, который меняется по расписанию.