Как я избавил бухгалтеров от вечернего ритуала с флешкой и .dt-файлом

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

Ручной бэкап — это не бэкап, это лотерея

У одного клиента, торговая компания на 18 рабочих мест, главный бухгалтер архивировала базу каждый вечер уже три года. Дисциплинированно. Пятница. Отпуск. Она заболела — грипп, две недели дома. Никто не выгружал базу. На пятнадцатый день сервер ушёл в перезагрузку после обновления Windows и не поднялся. RAID-контроллер решил, что один из дисков пора списать. Восстанавливали с бэкапа недельной, если не двухнедельной давности. Потеряли документы по трём отгрузкам и часть банковской выписки.

Дело не в человеке. Дело в том, что ручной процесс держится на одном человеке, его памяти и его желании задержаться на пять минут после восьмичасового дня. Заболел, уволился, забыл — и цепочка рвётся. А сервер не спрашивает, было ли у бухгалтера настроение вчера сделать копию.

Плюс к этому ручная выгрузка почти всегда лежит в той же папке, на том же диске, а иногда и на том же сервере, что и рабочая база. То есть при отказе диска пропадает и база, и бэкап одновременно. Красиво, ничего не скажешь.

Что вообще такое .dt и как его выгружать без интерфейса

.dt — это формат выгрузки информационной базы 1С, полный слепок конфигурации и данных. Через толстый клиент его делают вручную: Конфигуратор — Администрирование — Выгрузить информационную базу. А есть способ проще — командная строка. Платформа 1С:Предприятие умеет выполнять эту же операцию без открытия окна, параметром /DumpIN.

Выглядит это примерно так: 1cv8.exe DESIGNER /F"C:\Base1C" /N"Администратор" /P"пароль" /DumpIN "D:\Backup\base_20260729_2200.dt" /Out"D:\Backup\log.txt". Один такой .bat-файл, положенный на сервер, и база выгружается без единого клика человека. Для файловой базы это буквально минуты работы, если знать синтаксис, — но синтаксис у 1С капризный, лишний пробел в пути или неверная кодировка лога, и скрипт молча падает.

Если база клиент-серверная, на связке 1С + сервер SQL, то тут два уровня защиты: во-первых, штатный бэкап средствами MS SQL или PostgreSQL (полное резервное копирование БД), во-вторых — та же выгрузка .dt через кластер сервера 1С для переносимости между версиями и на случай миграции. Мы обычно делаем оба варианта: SQL-бэкап — для быстрого восстановления «как было», .dt — как универсальная страховка, которую можно поднять хоть на другом железе.

Планировщик заданий Windows — тот самый будильник, который не забывает

Дальше .bat-файл вешается в Планировщик заданий Windows (Task Scheduler) на ежедневный запуск, скажем, в 22:00, когда все уже разошлись и никто не держит базу открытой. Задание настраивается с учётной записью, у которой есть права и на 1С, и на сетевую папку назначения, галка «выполнять вне зависимости от того, вошёл ли пользователь в систему» — обязательна, иначе задание умрёт при первом же перезапуске сервера без активной сессии.

Отдельный момент — что делать, если в момент бэкапа кто-то из сотрудников забыл закрыть 1С и держит базу залоченной. Для файловой базы это критично: выгрузка либо не начнётся, либо упадёт с ошибкой блокировки. Решение простое — перед запуском /DumpIN скрипт принудительно завершает процессы 1cv8.exe на сервере (для терминальных серверов это нормальная практика в нерабочее время) или, что аккуратнее, использует функционал блокировки регламентных заданий 1С, которая мягко просит пользователей выйти за 10-15 минут до старта.

У одного клиента, юридическая фирма на 12 мест, мы дополнительно поставили уведомление в общий чат в Telegram: бот пишет «бэкап базы 1С выполнен успешно, 340 МБ» или, если что-то пошло не так, «бэкап НЕ выполнен, база заблокирована пользователем Иванова И.И.» — и тогда уже я, а не директор фирмы, узнаю о проблеме первым.

Ротация — почему нельзя просто копить файлы вечно

Тут частая ошибка: настроили выгрузку, обрадовались, а через полгода диск назначения забит под завязку. База весит 2-3 ГБ, бэкап за полгода ежедневных копий — это 500-900 ГБ, если ничего не чистить. Причём половина этих файлов клиенту вообще не нужна: кому интересен бэкап от вторника три месяца назад, если есть свежий?

Мы делаем ротацию по схеме «дед-отец-сын»: ежедневные копии хранятся 14 дней, из них по одной в неделю переносится в архив на 8 недель, и по одной в месяц — в долгосрочное хранение на год. Реализуется это через PowerShell-скрипт с Get-ChildItem и фильтром по дате создания файла: всё, что старше порога и не попадает в правило «оставить», удаляется автоматически после успешного создания новой копии — то есть сначала убеждаемся, что новый бэкап реально создался и не битый, и только потом чистим старое.

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

Куда складывать копии — правило 3-2-1, но по-человечески

Классика резервного копирования — три копии данных, на двух разных носителях, одна из которых вне офиса. Применительно к небольшой компании до 50 рабочих мест это выглядит так: рабочая база на сервере, .bat-скрипт кладёт .dt на отдельный физический диск того же сервера (не в ту же папку, не на тот же раздел), а третья копия синхронизируется в облако или на NAS в другом здании через robocopy или rclone по расписанию сразу после локального бэкапа.

Ставить NAS для этого необязательно — иногда хватает недорогого облачного хранилища вроде Яндекс.Диска или Облака Mail с настроенным клиентом синхронизации, если объёмы небольшие. Для баз побольше мы используем Veeam или обычный rclone на Backblaze — дешевле, чем кажется, при объёме 20-30 ГБ архивов это 300-500 рублей в месяц.

Важно: копия вне офиса нужна не от пожара соседей, а в первую очередь от шифровальщиков. Если сервер поймал вирус-шифровальщик, а бэкап лежит на соседнем сетевом диске с теми же правами доступа — зашифрует и его тоже. Облачная копия с отдельной авторизацией и, желательно, версионированием — единственное, что спасёт в такой ситуации гарантированно.

Проверка бэкапа — файл есть, а толку от него ноль

Самая частая иллюзия безопасности — «у нас же бэкапы есть, вон папка, файлы каждый день появляются». А то, что последние три недели там выгружается файл на 4 КБ вместо привычных 900 МБ, потому что закончился пароль администратора 1С и скрипт падает на авторизации, — никто не проверял. Файл создаётся, дата свежая, размер никто не смотрит.

Мы завели простое правило: раз в месяц один из выгруженных .dt реально разворачивается в тестовую базу — либо на отдельном тестовом сервере, либо локально у инженера. Это занимает 15-20 минут, но снимает все вопросы. Заодно проверяется, что база открывается, а не просто существует как набор байт.

Плюс автоматическая проверка размера файла в самом скрипте: если новый бэкап меньше, скажем, 70% от размера предыдущего — это подозрительно, и уведомление в Telegram или на почту должно об этом сообщить отдельно, а не просто «бэкап выполнен». Такая мелочь один раз спасла клиента из производственной сферы: база вдруг начала выгружаться в разы меньше, оказалось — регламентное задание случайно удалило половину документов за квартал ночью, и без проверки размера это заметили бы только при следующей сверке с налоговой.

Сколько это стоит и что это реально экономит

Настройка автоматической выгрузки с ротацией и уведомлениями под ключ у нас стоит от 8000 до 15000 рублей разово, в зависимости от того, файловая база или клиент-серверная, сколько баз и нужна ли облачная синхронизация. Дальше это просто работает без абонентской платы, разве что облачное хранилище — 300-1500 рублей в месяц в зависимости от объёма.

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

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

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

А если 1С работает на терминальном сервере с 15 пользователями одновременно?
Схема та же, только скрипт учитывает нерабочее время всех терминальных сессий, а не одного компьютера. Обычно ставим выгрузку на 23:00-00:00, когда сессии уже закрыты по регламенту, плюс мягкое предупреждение пользователям за 15 минут через отправку сообщения в сессию.

Нужно ли останавливать работу пользователей ради бэкапа?
Для файловой базы 1С — да, на время самой выгрузки база должна быть свободна от блокировок, обычно это 2-10 минут ночью. Для клиент-серверного варианта на SQL можно делать бэкап без остановки пользователей вообще, это не мешает работе.

Сколько бэкапов реально нужно хранить, не разоряясь на диски?
Мы обычно советуем 14 ежедневных, 8 еженедельных и 12 ежемесячных копий — этого хватает почти для любой ситуации, от случайной порчи данных до проверки годовой давности, а весит это разумно за счёт ротации, а не бесконечного накопления.

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