За несколько лет работы с 1С-инфраструктурой я восстанавливал данные после сбоев несколько раз. Каждый раз это был стресс — для клиента и для меня. И каждый раз выяснялось одно и то же: резервная копия либо не делалась вообще, либо делалась так что восстановиться из неё было невозможно.
Потеря базы 1С — это не редкий сценарий. Это то, что рано или поздно происходит в любой системе без нормально настроенного резервного копирования.
Из практики: в одном случае база перестала открываться после сбоя питания. Последняя рабочая копия была двухдневной давности — всё, что сделали за два дня, пришлось восстанавливать вручную.
Главное заблуждение: выгрузка .dt — это не резервная копия
Многие считают что раз в 1С есть кнопка «Выгрузить информационную базу» — значит они защищены. Это не так.
Выгрузка .dt требует монопольного доступа к базе — пока она делается, никто не может работать в 1С. На больших базах это занимает часы. Восстановление из .dt тоже занимает часы. Если сбой случится в середине рабочего дня — вы потеряете всё что было сделано с момента последней выгрузки.
Это допустимо как дополнительная мера. Как основная — нет.
Именно поэтому .dt часто оказывается “последней надеждой”, которая в критический момент либо устарела, либо не успевает восстановиться вовремя.
Как это должно работать
Правильное резервное копирование для клиент-серверной 1С делается на уровне SQL Server. Это стандартный механизм, который изначально рассчитан на работу с критичными данными и позволяет восстанавливать базу вплоть до конкретного момента времени. Оно не мешает работе пользователей, выполняется автоматически по расписанию и позволяет восстановить данные с точностью до нескольких часов.
Схема которую я настраиваю большинству клиентов: полная копия раз в неделю в воскресенье ночью, разностная копия каждый день в 23:00, резервная копия журнала транзакций каждые 2–4 часа в рабочее время. При такой схеме максимальная потеря данных при любом сбое — несколько часов, а не несколько дней.
Правило которое нарушают почти все
Хранить резервные копии на том же сервере что и базу — это не резервное копирование. Если сервер физически выйдет из строя — вы потеряете и базу, и копии одновременно.
Три копии, два разных носителя, одна — вне офиса. Это минимальный стандарт. На практике для казахстанского ТОО это выглядит так: копия на сервере, копия на сетевом хранилище или внешнем диске, копия в облаке. Настраивается один раз. В большинстве случаев, которые я разбирал, проблема была именно в этом: копии формально были, но хранились в том же месте, что и база.
Проверяли ли вы свои резервные копии
Это вопрос который я задаю всем клиентам на первой встрече. В 9 из 10 случаев ответ — нет. Резервная копия которую никто не проверял — это не резервная копия. Это файл о котором вы надеетесь что он сработает когда понадобится.
Проверка занимает 20 минут: восстановить копию на тестовом окружении и убедиться что база открывается и данные на месте. Делать это стоит раз в месяц.
Иногда выясняется, что копия есть, но повреждена или не содержит последних данных — и это становится понятно только в момент восстановления.
Что делать прямо сейчас
Если не уверены, как у вас настроено резервное копирование — лучше проверить заранее.
Подключусь удалённо и покажу:
— делаются ли копии и с какой периодичностью
— где они хранятся и достаточно ли этого
— можно ли из них реально восстановиться
Проверка занимает 15–20 минут.
В большинстве случаев уже на этом этапе становится понятно, есть ли риск потери данных.