Резервная копия 1С, из которой действительно можно восстановиться

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

У резервной копии одна задача — дать возможность восстановить работу. Если восстановиться из неё нельзя, это не копия, а успокоительное. Ниже — как копировать базу 1С так, чтобы это было правдой, и как проверить, не дожидаясь аварии.

Три способа сделать копию базы 1С

Способ зависит от того, как работает ваша база: файловая она (весь учёт лежит в одном файле 1Cv8.1CD) или клиент-серверная (данные хранятся в СУБД — MS SQL или PostgreSQL). Если не уверены, посмотрите в окне запуска 1С: у файловой базы в нижней строке будет путь к папке, у клиент-серверной — имя сервера и базы.

Выгрузка в файл .dt

Делается в конфигураторе: меню «Администрирование» → «Выгрузить информационную базу». Получается один файл с расширением .dt, в котором есть и конфигурация, и все данные.

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

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

Автоматизировать выгрузку можно: конфигуратор умеет запускаться в пакетном режиме с параметром /DumpIB, а в новых версиях платформы 8.3 есть отдельная утилита ibcmd. Но для больших клиент-серверных баз .dt не стоит делать единственным способом копирования — для них есть средства СУБД.

Копия файла 1Cv8.1CD

Для файловой базы всё просто: вся база — это файл 1Cv8.1CD в папке базы. Скопировали файл — получили полную копию. Восстановление тоже простое: положить файл обратно или в новую папку и добавить её в список баз.

Это самый быстрый способ, но у него одно жёсткое условие: в момент копирования в базе никто не должен работать. Ни пользователи, ни конфигуратор, ни фоновые обмены и регламентные задания. Почему это так важно — ниже, в отдельном разделе.

Проверить физическую целостность скопированного файла можно утилитой chdbfl.exe, которая лежит в папке bin установленной платформы. Запускайте её на копии, а не на рабочей базе.

Резервное копирование средствами СУБД

Если база клиент-серверная, правильный способ — штатное резервное копирование MS SQL или PostgreSQL. Эти системы умеют делать согласованную копию прямо во время работы пользователей.

В MS SQL обычно настраивают связку: полная копия раз в сутки, разностные копии и копии журнала транзакций в течение дня. Это позволяет восстановить базу не только «на вчерашний вечер», но и на конкретный момент — например, на 11:40, за пять минут до того, как кто-то запустил не ту обработку. В PostgreSQL для этого используют pg_dump для отдельных копий базы и непрерывное архивирование журналов (WAL), если нужно восстановление на момент времени.

Обратная сторона — это нужно настроить и потом следить: за местом на дисках, за ростом журналов, за тем, что задания действительно отрабатывают. Без администратора такая схема со временем ломается незаметно. И да, простое копирование файлов базы данных (.mdf, .ldf или каталога данных PostgreSQL) при работающей СУБД резервной копией не является.

Сравнение в одной таблице

Способ	Для какой базы	Пока пользователи работают	Плюсы	Минусы
Выгрузка .dt	Любой	Лучше не делать	Универсальный формат, удобно переносить	Медленно на больших базах, загрузка заменяет базу целиком
Копия 1Cv8.1CD	Файловой	Нельзя	Быстро и просто	Копия при открытой базе может оказаться битой
Средства СУБД	Клиент-серверной	Можно	Копии на ходу, восстановление на момент времени	Нужны настройка и контроль

Если сомневаетесь, нужен ли вам вообще переход на клиент-серверный вариант, — об этом отдельная статья «Файловая или клиент-серверная 1С».

Почему нельзя копировать файл базы, когда в ней работают

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

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

Коварство в том, что Windows может спокойно скопировать открытый файл базы без единого предупреждения. Скрипт копирования отработает, файл нужного размера появится в папке, все будут уверены, что копия есть. Программы, которые копируют файлы «на лету» через снимки диска, снижают риск, но не гарантируют, что внутри файла базы согласованное состояние.

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

Правило 3-2-1

Это простое правило, которое закрывает большинство сценариев потери данных:

• 3 копии данных — рабочая база и ещё как минимум две резервные;
• 2 разных места хранения — например, отдельный диск и внешнее хранилище, а не две папки на одном сервере;
• 1 копия вне офиса — в облачном хранилище, у провайдера или хотя бы на диске, который увозят домой.

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

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

Где хранить копии и где не стоит

Не на том же диске, что и база. Если диск выйдет из строя, вы потеряете и базу, и все копии разом. Это самая частая и самая обидная ошибка.

По возможности — не на том же сервере. Отдельный диск в том же сервере защитит от поломки диска, но не от кражи системного блока, пожара, затопления или вируса.

Не в общей папке, куда все могут писать. Сетевая папка «Бэкапы» с правами на запись для всех сотрудников — подарок шифровальщику.

Не на личном облаке сотрудника. Копия базы на личном Google Диске бухгалтера — это ваши данные на чужом аккаунте. Человек уволится, аккаунт останется у него.

Помните, где физически лежит внешняя копия. В копии базы 1С те же персональные данные, что и в самой базе: ИИН сотрудников, зарплаты, контакты физических лиц. Закон РК «О персональных данных и их защите» требует хранить персональные данные в базе на территории Казахстана, и резервные копии здесь не исключение. Выбирая внешнее хранилище, уточните, где находятся его серверы.

Флешка или внешний диск в ящике стола — лучше, чем ничего. Но такие копии обычно делают первые две недели, а потом про них забывают.

Как часто делать копии

Самый честный ориентир — ответ на вопрос: сколько работы вы готовы потерять и сделать заново? Если копия делается раз в сутки ночью, то при аварии в 17:00 потеряется весь рабочий день: документы придётся вводить заново по бумагам, а что-то будет потеряно насовсем.

Практические ориентиры:

• Ежедневно — минимум для любой базы, в которой работают каждый день.
• Несколько раз в день — если за день вводятся сотни документов, идут продажи или обмены с сайтом. Для клиент-серверных баз это решается копиями журнала транзакций каждые 15–60 минут.
• Дополнительно, вручную — перед любой рискованной операцией: обновлением конфигурации или платформы, установкой доработок, свёрткой базы, «Тестированием и исправлением», удалением помеченных объектов, массовой перепроводкой документов. Даже если ночная копия есть: откат на вчерашний вечер из-за неудачного обновления в середине дня обойдётся в целый рабочий день.

Сколько хранить

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

Если хранить только последние три копии, в таких ситуациях восстанавливаться будет не из чего. Разумная схема для небольшой компании:

• ежедневные копии — за последние 2–4 недели;
• еженедельные или ежемесячные — дольше, например, ежемесячные за год;
• копия на конец года — отдельно и надолго.

Важно, чтобы старые копии удалялись по расписанию, а не «когда закончится место». Иначе однажды место закончится, и новые копии просто перестанут создаваться.

Тестовое восстановление: единственная настоящая проверка

Пока вы не восстановились из копии, вы не знаете, работает ли она. Это не преувеличение: размер файла, дата в папке и отчёт скрипта «успешно» ничего не говорят о том, откроется ли база.

Как провести проверку:

1. Возьмите копию. Не обязательно самую свежую — полезно иногда проверить и недельной давности.
2. Восстановите её отдельно от рабочей базы. Для .dt — создайте новую пустую базу и загрузите в неё файл через конфигуратор: «Администрирование» → «Загрузить информационную базу». Для файла 1Cv8.1CD — положите его в новую папку и добавьте в список баз. Для СУБД — восстановите копию в базу с другим именем. Никогда не проверяйте копию загрузкой поверх рабочей базы.
3. Не дайте копии «ожить». Типовые конфигурации при запуске перемещённой базы обычно спрашивают, не является ли она копией. Ответьте, что это копия: тогда она не начнёт выполнять обмены и отправлять данные во внешние сервисы от имени рабочей базы.
4. Проверьте содержимое. База открывается без ошибок; последние документы на дату копии на месте; оборотно-сальдовая ведомость или остатки по двум-трём ключевым счетам совпадают с рабочей базой на ту же дату; печатные формы открываются; пользователи могут войти.
5. Засеките время. Сколько ушло от «нужна копия» до «база открылась» — это и есть ваше реальное время восстановления при аварии.
6. Уберите тестовую базу. Удалите её из списка баз или хотя бы назовите так, чтобы никто случайно не начал в ней работать.

Делать такую проверку стоит хотя бы раз в квартал, а также после любых изменений в схеме копирования: смены сервера, диска, скрипта или пароля.

Типичные ошибки

Бэкап на том же диске. Копии аккуратно складываются в папку D:\Backup, а база лежит в D:\1C. Диск выходит из строя — и пропадает всё. То же самое, если копии лежат на том же сервере в общей сетевой папке: от вируса это не спасает.

Копия есть, но битая. Файл базы копировался, пока в ней работали люди или шёл ночной обмен. Или база уже была повреждена, и копии месяцами сохраняли повреждённое состояние. Узнать об этом можно только восстановлением.

Скрипт, который год не работает. Когда-то приходящий администратор настроил задание в планировщике Windows. Потом сменили пароль пользователя, от имени которого оно запускалось. Или обновили платформу — а путь к 1cv8.exe включает номер версии, и старого пути больше нет. Или закончилось место на диске. Задание тихо падает каждую ночь, и никто об этом не знает. Лекарство — уведомление о результате копирования и привычка раз в неделю смотреть на даты файлов в папке с копиями.

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

Только один человек знает, как восстановиться. Если копии настраивал один сотрудник или подрядчик и инструкция есть только у него в голове, при аварии вы будете зависеть от того, возьмёт ли он трубку. Запишите в одном месте: где лежат копии, как к ним получить доступ и как из них восстановить базу.

Как это устроено у нас

В ForceCloud резервное копирование входит в стоимость любого тарифа. Копии баз делаются ежедневно с контролем целостности и хранятся 30 дней в дата-центрах на территории Казахстана, отдельно от рабочей базы. Управлять копиями вы можете сами в личном кабинете, а восстановление занимает минуты, а не полдня поиска «того самого файла».

При этом мы честно советуем клиентам не полагаться только на нас: раз в месяц выгружайте базу в .dt — сами или с помощью нашей поддержки — и сохраняйте у себя. Это и есть та самая третья копия в другом месте — и гарантия, что ваша база всегда у вас под рукой, с кем бы вы ни работали. Если планируете переезд в облако, начните с чек-листа в статье «Перенос 1С в облако».

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

Как часто нужно делать резервную копию базы 1С?

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

Можно ли просто скопировать папку с файловой базой?

Можно, но только когда в базе гарантированно никто не работает: ни пользователи, ни конфигуратор, ни фоновые обмены. Если скопировать файл 1Cv8.1CD во время работы, копия может оказаться повреждённой, причём узнаете вы об этом только при попытке восстановиться. Если нет уверенности, что все вышли, надёжнее сделать выгрузку .dt.

Чем выгрузка .dt отличается от копии файла базы?

Файл .dt — это выгрузка конфигурации и данных в универсальном формате: его можно загрузить в любую базу, файловую или клиент-серверную, на другом компьютере. Копия 1Cv8.1CD — точная копия файловой базы как есть: делается быстрее, но подходит только для файлового варианта и требует, чтобы в момент копирования в базе никто не работал.

Сколько дней хранить резервные копии 1С?

Ежедневные копии разумно хранить хотя бы 2–4 недели, потому что ошибки и заражения часто обнаруживают не сразу. Дополнительно стоит держать ежемесячные копии за год и отдельную копию на конец года. Важно, чтобы старые копии удалялись по расписанию, а не когда закончится место на диске.