Эксперты в подборе IT-оборудования
Способ зависит от того, как устроена ваша база. Файловую копируют тремя путями: из пользовательского режима («Администрирование» → «Обслуживание» → «Резервное копирование и восстановление»), выгрузкой в файл .dt через конфигуратор или простым копированием файла базы, когда в ней никто не работает. Клиент-серверную базу бэкапят не средствами 1С, а средствами СУБД - MS SQL или PostgreSQL.
Ниже - пошагово по каждому способу, как поставить копирование на расписание, как восстановиться и почему копия, которую ни разу не разворачивали, копией не считается.
От этого зависит всё остальное, а путают эти два варианта постоянно.
Файловая база - это папка на диске, внутри которой лежит файл 1Cv8.1CD. Так работают почти все небольшие внедрения: бухгалтерия на одном компьютере или несколько человек через общую папку.
Клиент-серверная - данные лежат в СУБД (MS SQL Server или PostgreSQL), а 1С обращается к ним через сервер приложений. Так работают внедрения от нескольких десятков пользователей.
Посмотреть можно в окне запуска 1С: выделите базу в списке, и внизу окна будет либо путь вида File="D:\Base", либо Srvr="имя-сервера";Ref="имя-базы".
| Тип базы | Чем делать копию | Чем НЕ делать |
|---|---|---|
| Файловая | Пользовательский режим, выгрузка .dt, копирование 1Cv8.1CD | - |
| Клиент-серверная | Средствами СУБД: MS SQL или PostgreSQL | Регулярной выгрузкой .dt - долго и блокирует работу |
Подходит тем, кто работает в 1С:Бухгалтерии и других типовых конфигурациях, и не хочет заходить в конфигуратор. Требуются права администратора в базе.
Копия сохраняется архивом. Здесь же, в пункте «Настройка резервного копирования», включается автоматический режим - о нём отдельный раздел ниже.
Копия рядом с базой не спасает. Если сохранить архив в ту же папку или на тот же диск, где лежит база, то при отказе диска, шифровальщике или краже компьютера вы потеряете и базу, и копию разом. Про то, куда складывать, - раздел «Правило 3-2-1».
Классический способ, к которому чаще всего и отсылают на форумах. Даёт один файл .dt со всей базой: и данными, и конфигурацией.
1Cv8.dt.Восстановление делается там же: «Администрирование» → «Загрузить информационную базу». Важно понимать, что загрузка полностью заменяет текущую базу содержимым файла, а не дополняет её.
Два ограничения, о которых стоит знать заранее. Выгрузка требует, чтобы в базе никто не работал: платформа заблокирует соединения, и посреди рабочего дня это не сделать. И на больших базах операция идёт долго - именно поэтому для клиент-серверного варианта её не используют как регулярный бэкап.
Работает только для файловой базы и только когда в ней никого нет.
Зайдите в каталог базы (путь виден в окне запуска 1С) и скопируйте файл 1Cv8.1CD в другое место. Всё - это и есть полноценная копия: чтобы развернуть её, достаточно положить файл в новый каталог и добавить его в список баз как существующую.
Способ быстрый и не требует ни конфигуратора, ни прав администратора в базе. Единственное жёсткое условие - в момент копирования база должна быть закрыта у всех. Копия файла, снятая при работающих пользователях, с большой вероятностью окажется битой, и узнаете вы об этом в худший момент.
Четыре ситуации, на которые приходится большинство обращений.
«Не удалось заблокировать информационную базу». Кто-то остался в базе. Часто это не человек, а зависший сеанс или фоновое задание. Проверьте список активных пользователей, при клиент-серверном варианте - через консоль администрирования серверов, и завершите лишние сеансы. Заодно отключите регламентные задания на время работ.
Не хватает места на диске. Файл .dt занимает заметно меньше самой базы, но во время выгрузки платформе нужно место под временные файлы. Свободного места стоит держать с запасом от размера базы, а не от размера будущего архива.
Выгрузка идёт часами и не заканчивается. Признак того, что база переросла файловый режим. Разовую выгрузку можно оставить на ночь, но как регулярную схему её пора менять на бэкап средствами СУБД - об этом следующий раздел.
«Ошибка формата потока данных» при загрузке. Классическая проблема, и причин у неё две. Либо файл повреждён - оборвалось копирование, кончилось место, отключилось питание во время выгрузки. Либо .dt пытаются загрузить на платформу старее той, на которой его делали: загружать нужно на такую же версию или новее. Отсюда практический вывод: записывайте версию платформы рядом с архивом - через год, когда копия понадобится, вспомнить будет неоткуда.
Главная развилка, на которой ошибаются чаще всего. Если база лежит в MS SQL или PostgreSQL, регулярным резервным копированием занимается система управления базами данных. Выгрузка .dt для такой базы - разовая операция для переноса или архива, но не рабочая схема бэкапа: она блокирует пользователей и на базе в десятки гигабайт идёт часами.
MS SQL Server. Копии делают командой BACKUP DATABASE, а сценарий обычно комбинированный: полная копия раз в сутки или в неделю, разностные копии чаще, и отдельно резервные копии журнала транзакций - они позволяют восстановиться не на «вчера», а на момент за несколько минут до сбоя. Настраивается через план обслуживания в SQL Server Management Studio, дальше работает по расписанию само.
PostgreSQL. Штатный инструмент - pg_dump для отдельной базы, pg_basebackup для копии кластера целиком. Копия снимается без остановки работы пользователей.
Что важно в обоих случаях: копия СУБД снимается «на горячую», не требует выгонять людей из базы и переживает базы любого размера. Разницу между полными, разностными и инкрементными копиями разбирали в отдельной статье про виды резервного копирования.
Отдельно про соседний сценарий: если 1С крутится на виртуальной машине, копию можно снимать целиком с виртуалки. Тогда бэкапом занимается уже гипервизор, а не СУБД, - подход разобран в материале про технологии резервного копирования.
Копия, которую надо делать руками, рано или поздно перестаёт делаться. Автоматизируют двумя способами.
Расписание в самой 1С. Для файловых баз на типовых конфигурациях: «Администрирование» → «Обслуживание» → «Резервное копирование и восстановление» → «Настройка резервного копирования». Там включается автоматический режим и выбирается, когда снимать копию - по расписанию или при завершении работы. Способ бесплатный и не требует администратора, но работает, пока компьютер включён и 1С запущена.
Пакетный запуск конфигуратора. Надёжнее: платформа умеет выгружать базу из командной строки, а запуск вешается на планировщик заданий Windows.
Для файловой базы команда выглядит так:
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Base" /N"Администратор" /P"пароль" /DumpIB "E:\Backup\base.dt"Для клиент-серверной вместо /F указывается сервер и имя базы:
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /S"сервер\Имя_базы" /N"Администратор" /P"пароль" /DumpIB "E:\Backup\base.dt"Версию платформы в пути подставьте свою. Обратная операция - ключ /RestoreIB.
Для клиент-серверных баз это годится как дополнение к бэкапу СУБД, а не замена ему: снимать .dt ночью раз в неделю поверх ежедневных копий SQL - разумно, вместо них - нет.
Восстановление зависит от того, как снимали копию:
| Как снимали | Как восстанавливать |
|---|---|
| Пользовательский режим | «Администрирование» → «Обслуживание» → «Резервное копирование и восстановление» → «Восстановление из резервной копии» |
Выгрузка .dt | Конфигуратор → «Администрирование» → «Загрузить информационную базу» |
Копия файла 1Cv8.1CD | Положить файл в каталог и добавить базу в список как существующую |
| Копия СУБД | Средствами MS SQL или PostgreSQL, восстановлением базы из резервного набора |
И главное, что обычно пропускают.
Копия, которую ни разу не разворачивали, копией не считается. Раз в квартал разверните последний бэкап в отдельную тестовую базу и убедитесь, что она открывается и данные на месте. Проверка занимает полчаса, а обнаружить битый архив в момент аварии - это потерять всё, что вы аккуратно копировали месяцами. Заодно вы измерите, сколько реально занимает восстановление: эта цифра нужна, чтобы обещать бизнесу реальные сроки, а не приблизительные.
Общепринятый ориентир, который стоит держать в голове: три копии данных, на двух разных носителях, одна из них - за пределами офиса.
Для небольшой компании это выглядит просто: рабочая база на сервере, ежедневная копия на отдельном сетевом хранилище, и ещё одна - в облаке или на диске, который увозят из офиса. Смысл в том, чтобы ни один единичный сбой не забрал сразу всё.
Отдельно про шифровальщиков: они целенаправленно ищут по сети общие папки с бэкапами и шифруют их вместе с рабочими данными. Поэтому копия, лежащая в сетевой папке с постоянным доступом на запись, защищает только от отказа диска, но не от вируса. Помогает копия, которую нельзя перезаписать: отдельное устройство с ограниченным доступом или облачное хранилище с защитой от удаления. Подробнее про организацию хранения - в материале о том, как выбрать сервер для бэкапов.
.dt. Работает, пока база маленькая; на выросшей базе окно ночного обслуживания перестаёт хватать.«Администрирование» → «Обслуживание» → «Резервное копирование и восстановление» → «Создание резервной копии». Нужны права администратора в базе, и на время операции остальные пользователи будут отключены.
.dt - это выгрузка платформы: один файл с данными и конфигурацией, который грузится обратно через конфигуратор. Копия 1Cv8.1CD - сам файл файловой базы, её достаточно положить в каталог и подключить. Для клиент-серверной базы файла 1Cv8.1CD не существует.
Средствами СУБД - да, копия снимается на горячую. Выгрузкой .dt и копированием файла - нет: платформа заблокирует сеансы, а копия файла при активной работе получится битой.
Ориентир - раз в сутки, обычно ночью. Правильный ответ считается от вопроса «сколько часов работы мы готовы потерять»: если ответ «не больше часа», нужны частые копии или журнал транзакций СУБД.
Одной последней недостаточно. Рабочий минимум - копии за несколько последних дней плюс еженедельный и месячный срезы, чтобы было куда откатиться, если повреждение заметили не сразу.
По теме: сервер для 1С на 10 пользователей · резервная копия данных: полное руководство · системные требования для сервера 1С
База выросла, и ночного окна на бэкап уже не хватает?
Это верный признак, что файловый режим себя исчерпал: дальше нужен клиент-серверный вариант с СУБД и нормальным расписанием копий. Инженеры ITTELO подберут конфигурацию под ваше число пользователей и размер базы, соберут и протестируют её под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
