Бэкап есть, а восстановится ли: как проверять копии 1С и файлов реальным восстановлением

За пятнадцать лет в аутсорсинге я видел десятки компаний, у которых бэкап был. Красивый, по расписанию, с зелёной галочкой в отчёте. А когда прижимало — восстановиться не получалось. Расскажу, почему сам факт наличия копии ничего не гарантирует, и как мы в «АйТи-Фреш» проверяем, что копия реально живая.

История, после которой я перестал верить зелёным галочкам

Года три назад к нам обратилась бухгалтерская фирма на 18 человек. Сервер с 1С встал намертво — контроллер диска приказал долго жить. Штатный админ, приходящий раз в неделю, клялся, что бэкапы есть. Действительно, папка с архивами на NAS была забита файлами .dt, аккуратно по датам, каждый вечер новый.

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

С того случая у меня простое правило, которое я говорю каждому новому клиенту на первой встрече: бэкап, который ни разу не разворачивали — это не бэкап, это файл. Может, там нужные данные, а может — мусор. Узнаете только в момент, когда деваться будет некуда.

Почему копия может быть и есть, и бесполезна одновременно

Самое обидное — то, что резервное копирование в 99% случаев технически «работает». Задание в планировщике зелёное, лог без ошибок, файл создаётся, весит разумно. Проблема не в том, что копия не снимается. Проблема в том, что снятая копия не равна восстановленному состоянию.

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

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

Что значит «реальное восстановление» и почему одной галочки мало

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

Для 1С это означает разворачивание .dt или бэкапа СУБД на отдельном сервере или хотя бы временной виртуалке, запуск через 1С:Предприятие, проверку контрольных отчётов — оборотку, кассу, остатки. Для файловых архивов — реальную распаковку с проверкой контрольных сумм и открытием критичных документов: договоров, реестров, баз клиентов.

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

Как мы выстраиваем проверку у клиентов на практике

В типовой связке у нас Veeam для бэкапа виртуальных машин целиком плюс отдельная выгрузка .dt баз 1С через регламентное задание или консольный режим 1С. Двойная схема нужна ровно для того, о чём я написал выше: если сломается образ виртуалки, можно поднять базу из отдельного файла .dt, и наоборот.

Проверку мы делаем на отдельном тестовом стенде — обычно это недорогая виртуалка на Windows Server с лицензией 1С в клиент-серверном или файловом варианте, в зависимости от того, как у клиента работает прод. Раз в месяц по расписанию скрипт поднимает последнюю копию, автоматически запускает 1С в режиме тестирования и исправления, и если база открылась и прошла проверку логической целостности без критичных ошибок — присылает нам зелёный статус в Telegram. Если что-то не так — красный, и мы разбираемся руками в тот же день, а не через полгода на боевом инциденте.

Отдельно проверяем сроки хранения и версионность. У одного клиента в юрфирме было настроено хранение всего трёх последних копий — а вирус-шифровальщик просидел в сети незамеченным пять дней, успев затронуть и файлы, которые попали в архив. Спасло только то, что параллельно вёлся архив на внешнем NAS с ротацией на 30 дней. С тех пор мы всем клиентам ставим минимум 14, а лучше 30 дней хранения плюс копию в другом физическом месте — облако или второй офис. Это правило 3-2-1: три копии, на двух разных носителях, одна вне основной площадки — банально, но реально работает.

Сколько это стоит и почему это дешевле, чем кажется

Клиенты часто пугаются слова «тестовый стенд» — кажется, что это отдельный сервер, лицензии, время админа. На деле для компании на 15-30 рабочих мест хватает виртуальной машины на 2 ядра и 4 ГБ памяти, которую можно поднимать раз в месяц на пару часов и гасить — экономический эффект от постоянно включенной машины нулевой. В облаке это 1500-3000 рублей в месяц, если брать по факту использования, а не круглосуточно.

Настройка автоматизированной проверки под ключ у нас в «АйТи-Фреш» занимает обычно 6-10 часов работы инженера — это разовая история, дальше система живёт сама, присылая отчёты. По деньгам это в районе 15-25 тысяч рублей разово плюс небольшое сопровождение, если что-то ломается.

Сравните это с тем, во что обходится реальный отказ без проверенного бэкапа. У той бухгалтерской фирмы из первой истории простой длился четыре дня, пока восстанавливали данные вручную из разрозненных источников. Четыре дня — это сорванные сроки сдачи отчётности клиентам, неустойки, испорченная репутация. В деньгах вышло далеко за 300 тысяч, не считая нервов директора, который эти дни звонил мне каждые два часа.

Частые ошибки, которые я вижу почти в каждой второй компании

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

Вторая — хранение копий в том же месте, где стоит боевой сервер. Видел NAS, который стоял в соседней стойке с основным сервером в одной серверной. При скачке напряжения сгорело оба — и прод, и архив. Правило «одна копия вне площадки» существует не для галочки в чек-листе, а именно для таких случаев.

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

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

Как часто нужно проверять бэкап 1С реальным восстановлением?
Для большинства небольших компаний достаточно раз в квартал. Если 1С критична для ежедневной работы — розница, производство, логистика — лучше раз в месяц. И обязательно проверять сразу после обновления платформы, миграции сервера или смены версии СУБД, потому что именно тогда бэкапы чаще всего перестают восстанавливаться незаметно для всех.

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

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

1С и файловый архив — это разные бэкапы или можно объединить в одну систему?
Технически можно бэкапить всё одним заданием на уровне виртуальной машины, но я советую держать отдельную регулярную выгрузку .dt базы 1С в дополнение к образу всей машины. Если сломается образ целиком, у вас останется независимый файл базы, из которого можно поднять данные без привязки к конкретному серверу.