Как сделать резервную копию средствами субд

Обновлено: 04.07.2024

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

Организации, где есть системные администраторы

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

Организации, где нет системных администраторов

В небольших организациях, как правило нет системного администратор. В лучшем случае нанимают приходящего специалиста. В таком случае все организационно-технические вопросы резервного копирования баз главбуху или директору придётся взять на себя. Рассмотрим подобную ситуацию.

Как часто надо делать бэкап 1С?

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

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

За какие периоды хранить бэкапы информационных баз 1С?

Ежедневное резервное копирование баз 1С 8 в большинстве случаев это правильное решение. Но нет особого смысла хранить ежедневные бэкапы, например, за 10 лет. Поэтому возникает задача создания какой-то оптимальной стратегии хранения бэкапов. Формального решения она не имеет. На практике обычно придерживаются следующей схемы.

Последние несколько дней. Ежедневно делать бэкап и хранить их за последнюю неделю, 10 или 30 дней.
Последние несколько месяцев. Делать бэкап после закрытия месяца и сдачи регламентированной отчётности. Хранить их за последние, например, 24 месяца.
Последние несколько лет. Делать бэкап после закрытия декабря и сдачи годовой отчётности. Хранить их за последние, например, 5 лет.

Где хранить бэкапы 1С?

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

Ориентироваться будем на файловую базу 1С Предприятие 8. По техническим причинам её объём не может превышать 4 Гб. В случае, если объём базы приближается к этому пределу, то срочно надо переводить её в клиент-серверный режим работы.

Если базу не сжимать архиваторами, то потребуется хранилище объёмом не менее 4*(30+24+5)=236 Гб. По современным меркам – это вполне себе скромный объём. Но многое зависит от того, где будет размещаться бэкап информационных баз 1С.

В небольших организациях часто встречается ситуация, когда компьютер имеет один единственный не размеченный жесткий диск С. В этом случае он занимает весь объём физического диска. Это не хорошо. Надо обязательно разбить его хотя-бы на два логических диска: на C и D. Есть, как минимум, две причины, по которым не следует информационную базу и её архивные копии хранить на системном диске C.

Риск потери данных. Операционная система всегда располагается на диске С. При её переустановке неопытный пользователь может отформатировать диск C и тем самым безвозвратно уничтожить рабочую базу и все архивы 1С Предприятие 8.
Замедление и зависания в работе. Не все пользователи знают, что на диске С всегда должно оставаться не менее 10% свободного пространства. Часто у таких пользователей на нём свободными остаются буквально несколько Мб. В результате при запуске 1С Предприятие 8 идёт долгий процесс поиска свободное место для открытия своих временных файлов. В лучшем случае программа откроется через продолжительное время. В худшем она зависнет.

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

Самое быстрое и недорогое решение – это приобрести USB-флешку подходящего объёма. Молодые информационные базы редко превышают объём в 1 Гб. Поэтому при ежедневном бэкапе одной информационной базы за последние 30 дней хватит флешки объёмом в 32 Гб. Такая флешка стоит от 600 до 1000 рублей. На 64 Гб в районе 2000 рублей.

Покупать ли для резервирования флешку объемом 128 или 256 ГБ большой вопрос. Их цена колеблется от 3000 до 10000 рублей. За эту цену можно приобрести жесткий диск значительно большего объёма.

Очень важно, чтобы в компьютере было, как минимум, два физических диска (не путать с логическими). Лучше три! Первый (диск С) необходим для установки на него операционной системы и всех используемых вами программ. Второй используем для хранения всевозможных данных, в том числе информационные базы 1С Предприятие 8. Третий используем для хранения резервных копий баз 1С.

Для операционной системы в большинстве случаев достаточно 60-80 Гб. Но лучше иметь запас. Например, носитель ёмкостью в 500 ГБ, скорее всего перекроет, все возможные запросы. Обойдётся эта покупка приблизительно в 2300 рублей. Относительно объёма двух других дисков конкретных рекомендаций дать невозможно. Здесь всё очень индивидуально.

На встроенный в компьютер жесткий диск целесообразно записывать ежедневные резервные копии. Желательно, чтобы он был достаточно быстрым и надёжным. Это позволит быстро создавать резервные копии и также быстро при необходимости восстанавливать их.

А вот резервные копии 1С за месяц и за год целесообразно хранить на отдельном носителе, вне компьютера. Это существенно повысит надёжность и безопасность ваших данных. Для этих целей хорошо подойдет внешний жесткий диск или облачное хранилище. Не дай Бог, конечно, но, если в офисе случится пожар или зальёт водой, то диски в компьютере могут выйти из строя. Здесь и пригодится внешний носитель. Разумеется, если он хранится в сейфе или в другом помещении.

Стоимость внешних дисков сравнима со стоимостью обычных жёстких дисков, встраиваемых в компьютер.

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

Разные модели обладают различным количеством отсеков для жестких дисков: 1, 2, 4, 8 и больше. Технология виртуализации данных, позволяет объединяет несколько дисков в один логический элемент, так называемый RAID-массив. Это значительно повышает надёжность хранения данных и производительность системы.

Цены на сетевые хранилища, главным образом, зависят от количества отсеков, на два диска примерно по цене будет 12000 рублей, а на четыре диска стоить около 24000 рублей.

Хранение резервных копий в облачном хранилище сегодня стало достаточно обыденным делом. Обусловлено это доступностью интернета, высокой надежностью и безопасностью хранения данных. Отметим, если вы Арендуете 1С в облаке, то беспокоиться об резервном копировании особо не стоит, т.к. услуга уже настроена включена во все тарифные планы. Наша компания МАРС Телеком, как официальный партнёр фирмы 1С, предоставляет облако 1С в аренду с уже настроенным резервным копированием информационных баз 1С.

Программы резервного копирования информационных баз 1С

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

Вручную с помощью буфера обмена

В месте размещения информационной базы находим файл 1Cv8.1CD и выделяем его. Нажимаем комбинацию горячих клавиш Ctrl+C. Затем переходим в место, где храним архивы резервных копий и нажимаем на комбинацию Ctrl+V. Это и есть простейший бэкап или резервное копирование через буфер обмена операционной системы. Тоже самое можно сделать через контекстное меню, вызываемое щелчком левой кнопкой мышки.

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

Автоматическое резервирование средствами Windows

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

Резервное копирование встроенными средствами программы 1С

Подчеркнём, что данная обработка пригодна только для резервного копирования баз, работающих в файловом режиме.

Бэкап средствами СУБД

Если база работает в клиент серверном варианте, то в качестве СУБД обычно используются MS SQL, Postgre или DB2. Эти СУБД обладают встроенными средствами резервного копирования. Клиент-серверный режим не накладывает ограничений на размеры информационных баз.

Бэкап средствами СУБД можно создавать, не выгоняя пользователей из программы 1С Предприятие 8. То есть они могут спокойно продолжать работу. При этом бэкап будет создан без ошибок.

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

Резервному копированию баз данных в MS SQL отводится огромное значение. Правильно настроенное, оно поможет уберечь базу данных от повреждений и даже потери. Уделите несколько минут прочтению статьи и напомните (или узнайте) важные аспекты работы по бэкапам, а также как грамотно настроить в MS SQL Server резервное копирование баз данных. Это оградит от многих проблем.

Зачем это нужно

Специалисты рекомендуют настраивать регулярное копирование, используя различные его типы. Лучше всего сохранять копии за последние семь дней.

Пользователь должен понимать, что механизмы резервного копирования БД не смогут выполнять его онлайн, в реальном времени. Для достижения этих целей существуют иные технологии.

Способы создания

В MS SQL Server резервные копии можно создавать несколькими способами. Рассмотрим используемые инструменты:

MS SQL Management Studio

Графический интерфейс SSMS прекрасно подходит для разовых операций. Он может применяться к различным базам данных.

Для этого необходимо:

Открыть MS SQL Management Studio. Выбрать БД, которая будет копироваться и кликнуть по ней правой кнопкой мыши. Выбрать Задачи, после чего – Создать резервную копию.
Откроется окошко, в котором необходимо оставить полный тип копий и прописать путь к резервному файлу. Если возникла необходимость – путь можно изменить, удалить, создать новый. Файл можно сохранить как на локальном диске, так и на сетевом.
После успешного окончания процесса появится уведомление об этом.

Командная строка (sqlcmd)

Создание бэкапов с помощью командной строки sqlcmd используется для автоматизированного копирования любых данных. Может применяться в Windows и Linux.

Для данного способа понадобится утилита sqlcmd:

-Q "BACKUP DATABASE [ ] TO DISK = N' ' "

Чтобы автоматизировать скрипт, следует воспользоваться планировщиком. В нем необходимо создать задание по его запуску согласно расписанию.

PowerShell

Создание бэкапов с помощью PowerShell может использоваться только на новых системах, т.к. на старых он не доступен. Специалисты рекомендуют использовать именно этот способ резервирования данных.

Для бэкапа необходимо импортировать модуль import-module sqlps –DisableNameChecking.

Можно воспользоваться синтаксисом: Backup-SqlDatabase -ServerInstance -Database -BackupFile

Как и в предыдущем способе, для запуска скрипта по графику, его следует размещать в планировщике.

Типы резервного копирования

В Microsoft SQL Server принята практика разных типов резервного копирования. Пользователям доступно:

полное – делается резервная копия всей БД. Может выполняться различными способами;
дифференциальное или разностное – осуществляется копирование данных с того момента, когда осуществлялось ее последнее полное резервирование. Осуществляется специальной командой с добавлением опции DIFFERENTIAL;
логов или инкрементальное.

Рассмотрим их подробнее.

Полное копирование (Full Backup)

В SQL Server под полным копированием (Full Backup) понимают создание полной резервной БД, включая все данные и объекты системных таблиц. Полный бэкап не усекает (truncate) журнала транзакций. Она является основным типом создания бэкапов, которое должно предшествовать любому типами резервирования.

Полный бэкап выполняется с помощью различных инструментов (SSMS, T-SQL, PowerShell). Восстановить базу можно всего за один шаг, т.к. для этого не потребуется иных копий (разностных или инкрементальных).

Для полного копирования данных действует ряд ограничений:

Если оно производилось поздними версиями SQL Server, то такие копии невозможно восстановить в более ранних версиях.
В транзакциях, как в явных, так и неявных, инструкция BACKUP недопустима.

Свойству TRUSTWORTHY в процессе создания резервной копии базы будет присвоено значение OFF.
В версиях, начиная с SQL Server 2012 (11.x) и более поздних, не поддерживаются параметры PASSWORD и MEDIAPASSWORD. Но восстановление копий с паролями доступно.

Для пользователей, имеющих роли sysadmin, db_owner, db_backupoperator, по умолчанию доступны BACKUP DATABASE и BACKUP LOG. Помешать выполнению резервирования могут проблемы как с владельцем, так и с разрешениями у физических файлов на устройстве.

Полное копирование в SSMS

Создавая задачу в MSSQL Server Management Studio, можно сформировать соответствующий скрипт T-SQL BACKUP. Для этого следует нажать кнопку Скрипт, а затем указать его назначение.

Когда в SQL Server компонент Database Engine подключится к нужному экземпляру Microsoft, следует развернуть в обозревателе дерево сервера.
Если нужна пользовательская база данных, то следует развернуть узел База данных. Если потребуется обозначить системную БД – развернуть соответствующий узел.
Отобрав базу данных, которая будет копироваться, щелкнуть на ней мышкой, выбрать Задачи и затем команду Создать резервную копию… .
В появившемся окошке отобранная БД будет приведена в виде раскрывающегося списка. При необходимости, она может быть изменена на любую другую базу данных.
В раскрывшемся списке Тип резервной копии следует выбрать необходимый вариант. По умолчанию выбран тип Полная.
В разделе Компонент резервного копирования выбрать База данных.
Произвести проверку, куда сохраняются файлы по умолчанию в разделе Назначение (в папке ../mssql/data).

Для выбора иного устройства можно воспользоваться раскрывающимся списком Создать резервную копию на. Для добавления объектов резервного копирования и/или целевых объектов, необходимо щелкнуть Добавить. Для увеличения скорости можно копии распределить между набором файлов.

Для просмотра содержимого, созданного ранее целевого объекта копирования, его необходимо выделить и кликнуть Содержимое. А для удаления такого объекта – кликнуть Удалить.

При необходимости следует проверить все параметры, которые доступны на страницах параметров: носителя и резервного копирования.
Кликните ОК для запуска процесса
При успешном завершении бэкапа необходимо закрыть появившееся диалоговое окно, кликнув ОК.

Когда полный бэкап БД сделан, можно выполнять иные типы резервирования: дифференциальные и журналов транзакций. Когда резервное копирование выполняется на url-адрес на странице Параметры носителя, недоступным будет параметр Перезаписать носитель.

Полное копирование с помощью T-SQL

Для выполнения полного бэкапа базы данных с помощью Transact-SQL, необходимо выполнить соответствующие инструкции BACKUP DATABASE и указать:

наименование БД для формирования копии;
устройство, куда будут сохраняться скопированные данные.

Базовая структура синтаксиса T-SQL для создания полной копии БД выглядит следующим образом:

BACKUP DATABASE database TO backup_device [ , …n ] [WITH with_options [ , …o ] ] ;

database – база данных, которая будет копироваться;
backup_device [ , …n ] – показывает список устройств, которые будут использованы для резервирования. Может указываться как физическое (когда используются параметры DISK/ TAPE), так и логическое устройство (если оно определено);
[WITH with_options [ , …o ] ] – указывает необходимое число параметров, o.

При необходимости следует указать нужное количество параметров WITH.

Резервная копия, созданная по команде BACKUP, сохраняется по умолчанию в набор носителей, созданный ранее. Все копии, созданные до этого, сохраняются. С помощью параметра NOINIT можно явно задать значение.

Для форматирования носителя копии используется параметр FORMAT в следующем предложении:

Он может использоваться при первичном обращении к носителю либо в том случае, когда требуется сделать перезапись всех данных, созданные ранее. Если потребуется, то можно новому носителю присвоить наименование и описание.

Однако при использовании в инструкции BACKUP предложения FORMAT следует проявить крайнюю осторожность. Неправильное использование этого предложения удалит все наборы, которые ранее были созданы и хранились на носителе.

Полное копирование с помощью PowerShell

Чтобы создать полный бэкап в PowerShell, следует использовать командлет (упрощенную команду) Backup-SqlDatabase. Чтобы отметить, что эта резервная копия является полной, необходимо задать параметр BackupAction вместе с Database (оно применяется по умолчанию). Этот параметр не относится к обязательным при полном резервировании БД.

Для использования PowerShell понадобится специальный модуль SqlServer. Выполнение команды Get-Module-Name SqlServer поможет выяснить – установлен модуль либо нет. Для установки модуля понадобится в сеансе PowerShell на правах администратора выполнить команду Install-Module-Name SqlServer.

Открывая PowerShell из SSMS, чтобы подключиться к SQL Server, не потребуются учетных данных. В них нет необходимости, т.к. для подключения между PowerShell и SQL Server используются учетные данные пользователя в SQL Server Management Studio.

Дифференциальное (разностное) копирование

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

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

Советы по использованию дифференциальных бэкапов базы данных:

Их следует использовать в тех случаях, когда на создание полного требуется много времени.
Для уменьшения объемов созданных дифференциальных бэкапов, необходимо делать полный.
После формирования полного бэкапа данных, все дифференциальные копии, сделанные ранее, становятся не актуальными.

При использовании дифференциального копирования рекомендуется придерживаться следующего плана его организации:

полное осуществляется раз в определенное количество дней;
разностное – каждый раз спустя определенное количество часов.

В том случае, когда оборот данных в день довольно высок, вышеприведенный план окажется неприменим, т.к. его реализация будет занимать много места на дисковом пространстве. К примеру, если вес полного бэкапа составляет 280 GB, а дифференциального, спустя 60 минут, – 4 GB, то по истечению суток вес дифференциальных наборов уже составит 96 GB. Потому, в приведенном примере использование дифференциального резервирования не оправданно.

Другие виды

Кроме вышеперечисленных, существуют иные виды копирования:

При резервном копировании журнала транзакций выполняется копирование всех транзакций, которые имели место после выполнения предыдущего резервного копирования. После этого происходит урезание журнала, для освобождения дисковое пространство. Этот вид копирования относится к инкрементальному. Для полной модели восстановления необходима вся последовательность резервных наборов, начиная с полной.
Бэкап Tail-Log, хоть и выделен отдельно, по сути является простой операцией, описанной в предыдущем пункте с опцией NORECOVERY. Его следует выполнять накануне восстановления копии журнала транзакций. Это позволит не упустить те транзакции, которые происходили после крайнего копирования до текущего момента.
Бэкап Copy-only (создание резервной копии только для копирования) не является базовой ни для разностных, ни для копий журнала транзакций. Создание Copy-only применяется лишь когда необходимо снять полную резервную копию, не задев текущей цепочки резервных копий. Именно эти нюансы и отличают Copy-only от стандартного полного бэкапа данных.
Частичное резервное копирование Partial backup применяется не часто. Его основная функция – копирование групп файлов read-only.
Также применяется резервное копирование отдельных файлов и или их групп.

Срок действия

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

Выполняется данная настройка в процессе настройки резервного копирования, в основном окне.

Путь расположения

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

На корневом разделе SQL Server кликнуть правой кнопкой мышки и выбрать Свойства.
Перейти к разделу Параметры баз данных. В нем опуститься к подразделу Места хранения, используемые базой данных по умолчанию. Именно здесь можно увидеть прописанный путь к месту размещения резервных наборов. Его можно изменить, воспользовавшись кнопкой (…), расположенной справа.

Общие советы

Как становится понятно, проблем с резервным копированием не должно возникать. Процесс легко настроить с помощью вышеописанных инструментов. Изучайте материал, применяйте на практике. При возникновении вопросов – обязательно задавайте. Делитесь своими мыслями и полезными советами.

Вы уже успели заметить, что обновлятор по умолчанию архивирует серверные базы 1с в формате dt.

При этом выгрузка в dt имеет ряд серьёзных недостатков:

не рекомендуется фирмой "1С" (ссылка)
требует монопольного доступа
требует много времени
требует много ресурсов сервера
нет никаких гарантий, что в такую выгрузку попадают абсолютно все данные при малейшем повреждении базы
зачастую приводит к ошибкам сервера 1с

Именно поэтому я рекомендую при первой возможности отказаться от выгрузки в dt в пользу архивации средствами СУБД.

Обновлятор умеет одинаково хорошо работать как с MS SQL Server, так и с набирающей обороты PostgreSQL.

При этом не важно на какой ОС работает сервер с установленной СУБД. Это может быть как Windows, так и любой дистрибутив Linux (CentOS, Debian, Ubuntu, ГосЛинукс, Altlinux, Rosa, МСВСфера, Red Hat).

Как включить архивацию базы средствами СУБД

1. Зайдите в свойства базы и перейдите на закладку "Архивация" и установите опцию "Включить sql архив":

Выполните необходимые настройки. При этом я не рекомендую устанавливать опцию "Дополнительно делать dt выгрузку" по причинам озвученным во введении этой статьи.

2. Далее перейдите на закладку "Общее" и укажите там сервер СУБД, если он ещё не указан:

Как восстановить созданный sql-архив через обновлятор?

Вы всегда можете восстановить базу из её резервной sql-копии. Для этого нажмите на базе правой кнопкой и выберите следующий пункт:

При этом в MS SQL Server предусмотрена защита от случайного восстановления серверной базы из резервной копии для другой базы. При попытке восстановить базу из чужой резервной копии MS SQL Server выдаст следующую ошибку:

Варианты восстановления из резервной копии

При (ручном или автоматическом) восстановлении серверной базы 1с из sql-копии вам будет предложено указать опции восстановления:

Вариант "ничего не делать с базой в кластере"

В этом случае резервная копия будет развернута в ту же самую базу на кластере 1с.

К плюсам этого варианта восстановления можно отнести то, что сохраняется старый журнал регистрации.

Но в то же время могут быть проблемы с кэшем сервера 1с, если метаданные исходной и восстановленной базы отличаются друг от друга (ведь восстановление мы делаем на уровне сервера СУБД, а кластер 1с ничего не знает об этом).

Одним из проявлений таких проблем могут быть ошибки при выполнении кода конфигурации, когда платформа 1с ругается на какой-нибудь неизвестный ей объект метаданных (например, реквизит справочника), а при проверке он оказывается на месте.

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

На тот случай, если мы не можем выполнить перезапуск кластера сразу после восстановления из резервной копии (а он желателен), рекомендуется установить галку "оставить базу заблокированной", чтобы никто не смог с ней работать пока мы не выполним перезапуск кластера.

Но если мы оставили базу заблокированной после восстановления, то следует внимательно отнестись к процедуре её разблокировки. Это можно сделать прямо из обновлятора (пункт 6.08 из меню операций), но обратите внимание, что в этом случае регламентные задачи нужно будет разблокировать отдельно (если это требуется) через пункт 6.14.

Вариант "пересоздать базу в кластере с теми же параметрами"

В этом случае резервная копия будет восстановлена в ту же самую базу в кластере 1с, но эта база (в кластере) на определенных этапах будет удалена и добавлена вновь с теми же самыми параметрами.

Это позволит избежать проблем с кэшем сервера 1с, описанным в предыдущем варианте (см. выше), без перезапуска кластера, но в то же время разорвётся связь текущей базы с её предыдущим журналом регистрации.

И если речь идёт о восстановлении резервной копии в чистую, только что созданную базу, журнал регистрации которой пуст или не существенен для нас, то проблем нет. Но если мы восстанавливаем резервную копию в уже существующую рабочую базу - журнал регистрации обычно требуется сохранить.

Полная автоматизация восстановления журнала регистрации, к сожалению, не возможна при работающем кластере 1с, это придётся (при необходимости) сделать в ручном режиме.

Инструкция для переноса журнал регистрации из старой базы (выполняется до восстановления базы из резервной копии):

Но что если мы спохватились уже после того как выполнили восстановление из резервной копии и база в кластере 1с была удалена и добавлена вновь (то есть её идентификатор уже изменился). Как узнать папку, в которой хранится журнал регистрации старой базы?

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

Если же база уже исчезла из 1CV8Clsto.lst, то её старый идентификатор просто так уже не найти. И ничего не остаётся кроме как по очереди исследовать журналы регистрации всех подпапок из "c:\Program Files\1cv8\srvinfo\reg_1541\*\1Cv8Log" и уже по содержимому журналов регистрации устанавливать тот, что относился к нужной базе. Журналы можно просматривать или восстанавливая их в чистую (файловую) базу или же при помощи утилиты DB Browser for SQLite (если речь о новом формате хранения).

Вскоре в обновлятор будет добавлена возможность отслеживать расположение журналов регистрации (и фиксировать в отчётах при выполнении операций) для серверных баз.

Нюансы для MS SQL Server

Настройте права учетной записи sql-сервера

Прошу вас очень подробно ознакомиться с этим пунктом, особенно если ваш sql-сервер находится на другой машине (соответствующая галка в настройках сервера СУБД). Здесь много нюансов, на которые нужно обратить внимание.

Прежде всего обратите внимание на то, что служба sql-сервера работает от имени некоторой учётной записи.

И когда обновлятор просит sql-сервер сделать выгрузку в основную папку архивов для этой базы, то запись идёт от имени учётной записи sql-сервера.

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

Права на временную папку обновлятора (по умолчанию это папка 'Data\Temp' внутри обновлятора) могут понадобиться, когда архив сначала записывается во временную папку, а уже затем переносится в основную папку архивов. Такое поведение возможно, если вы настроили запись архивов в конечную папку от имени определенного пользователя для защиты созданных архивов от шифровальщиков.

Если sql-сервер находится на другой машине.

В этом случае не забудьте поставить галку "Сервер находится на другом компьютере" в настройках сервера СУБД.

. а также выполнить следующие требования.

В качестве основной папки для архивов базы должен выступать полный сетевой путь до общей папки (шары), доступной как для sql-сервера (вернее его учётной записи), так и для компьютера на котором запущен обновлятор.

Эта общая папка должна быть подключена в обновляторе здесь.

При этом использование сетевых дисков недопустимо, ведь в сеансе sql-сервера на другом компьютере никто не будет подключать этот же сетевой диск (если вы только сами не позаботились об этом специальными средствами). Указывать нужно полный сетевой путь.

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

Не сломается ли разностное копирование на sql-сервере?

Начиная с версии от 3 июля 2018 года обновлятор помечает создаваемые sql-копии как copy-only.

Подробнее о резервных копиях этого вида можно прочитать здесь.

Такие копии являются изолированными от обычной последовательности резервных копий SQL Server.

Это сделано для того, чтобы резервные копии, создаваемые обновлятором (которые он сам же и чистит) не ломали цепочку резервных копий, которые возможно создаются другими способами и могут включать в себя разностное копирование.

Итак, резервные sql-копии, которые создаёт обновлятор (начиная с 3 июля 2018 года) помечаются как copy-only, а значит не нарушают возможную цепочку архивов, которые могут включать в себя разностные копии.

Это значит, что когда вы создаёте разностную копию базы, sql-сервер в качестве опорной точки (базы) никогда не возьмёт копию, созданную обновлятором, так как она copy-only. Вместо этого он обратиться к предыдущей полной копии базы, которая создавалась не как copy-only.

Всё это позволяет создавать sql-копии через обновлятор (перед опасными операциями с базой), не боясь испортить основную схему резервного копирования.

Этапы восстановления из резервной копии (ms sql)

Для базы 1с на MS SQL восстановление из резервной копии происходит в 4 шага.

Шаг 1 (ms sql)

Обновлятор принудительно завершает все соединения (в том числе для администрирования) с базой в кластере 1с.

Шаг 2 (ms sql)

Этот шаг выполняется только, если в параметрах восстановления выбран вариант "пересоздать базу в кластере с теми же параметрами".

На этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базе на сервере СУБД), чтобы затем (после восстановления базы на сервере СУБД из резервной копии) создать её вновь с теми же параметрами.

Шаг 3 (ms sql)

Обновлятор загружает резервную копию в соответствующую базу на сервере СУБД.

Шаг 4 (ms sql)

На этом шаге обновлятор вновь создаёт базу в кластере 1с с теми же параметрами и связывает её с соответствующей базой на сервере СУБД.

Нюансы для PostgreSQL

Выбор дистрибутива

Для того, чтобы обновлятор смог работать с базами 1с на PostgreSQL в настройках сервера СУБД необходимо указать путь к папке bin установленного PostgreSQL:

Дистрибутив PostgreSQL, который мы указываем в обновляторе:

должен быть для Windows
источники дистрибутива

При этом нам не важно на какой ОС стоит сервер СУБД.

Вот пример рабочего окружения:

рабочая СУБД установлена на сервере с CentOS 7: дистрибутив PostgreSQL 9.6.9 (версия для CentOS 7)
обновлятор установлен на Windows; на этой же машине установлен PostgreSQL 9.6.9 (версия для Windows), который указан в настройках обновлятора

Важно. От указанного в настройках PostgreSQL обновлятору нужные лишь его утилиты (например, pg_dump и psql).

Сам же сервер PostgreSQL на компьютере обновлятора работать не обязан, если только этот компьютер сам не является сервером СУБД.

Чтобы отключить работу сервера СУБД после его установки, зайдите в оснастку "Службы" и отключите там запуск службы PostgreSQL, например, "postgresql-1с-9.6".

Откройте файл настроек postgresql.conf на сервере СУБД и впишите туда (вместо имеющейся) строчку:

Этапы восстановления из резервной копии (postgres)

Для базы 1с на PostgreSQL восстановление из резервной копии происходит в 10 шагов. Такое большое количество шагов обусловлено требованием отказоустойчивости к выполнению операции, чтобы учесть все возможные варианты ошибок. Чтобы не получилось так, что после операции восстановления пользователь вообще остался без рабочей базы.

Шаг 1 (postgres)

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

Шаг 2 (postgres)

Обновлятор создаёт пустую временную базу на сервере СУБД, формируя её имя следующим образом: %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c

Шаг 3 (postgres)

Обновлятор загружает резервную копию в созданную на предыдущем шаге пустую временную базу.

Шаг 4 (postgres)

Обновлятор принудительно завершает все соединения с базой (в том числе для администрирования) в кластере 1с.

Шаг 5 (postgres)

Здесь возможны два варианта

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

Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то на этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базы на сервере СУБД).

Шаг 6 (postgres)

Обновлятор ожидает 10 секунд, чтобы кластер 1с перестал использовать рабочую базу на сервере СУБД.

Шаг 7 (postgres)

Обновлятор переименовывает рабочую базу на сервере СУБД в другое имя, формируя его следующим образом: %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c

Шаг 8 (postgres)

Обновлятор переименовывает временную базу %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c в рабочую базу %ИмяРабочейБазы%

Шаг 9 (postgres)

Здесь также возможны два варианта.

Если вы выбрали вариант восстановления "ничего не делать с базой в кластере", то обновлятор на этом шаге вновь настраивает нашу базу в кластере 1с на рабочую базу %ИмяРабочейБазы% на сервере СУБД.

Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то обновлятор на этом шаге вновь создаёт базу в кластере 1с и связывает её с рабочей базой %ИмяРабочейБазы% на сервере СУБД.

Шаг 10 (postgres)

Обновлятор удаляет исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c с сервера СУБД, так как она нам больше не нужна.

Этот шаг можно отменить, установив галку 'Не удалять рабочую базу при восстановлении' в свойствах базы:

Эту галку имеет смысл устанавливать, если вы хотите лично контролировать результаты восстановления резервной копии и только затем самому удалять исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c.

Что из себя представляет созданная резервная копия

Обновлятор создаёт резервную копию PostgreSQL следующей командой:

С подробной документацией и ключами к команде pg_dump можно ознакомиться здесь.

Формат plain выбран по следующим причинам:

на выходе получается обычный sql файл, который, при его выполнении в чистой базе, воссоздаёт исходную базу
все другие форматы являются теми же самыми sql файлами, но пожатыми специальным образом для специальных целей; обновлятору это ни к чему, так как он сам умеет сжимать получившийся архив, если вы устанавливаете соответствующую галку в свойствах базы
формат plain является предпочтительным при проблемах с восстановлением базы из архива или повреждением самого архивного файла, так как его легко прочитать и отредактировать
формирование архива в формате plain требует меньше ресурсов сервера СУБД

Чтобы восстановить резервную копию в формате plain не нужно использовать утилиту pg_restore. Она предназначена для других форматов архивов и фактически сначала разархивирует резервную копию в plain формат, а затем выполняет её в базе через psql.

Вам нужно сразу выполнять (через утилиту psql) резервную копию в формате plain в чистой базе из шаблона template0 (это должна быть чистая база в субд, созданная не через 1с).

Обновлятор умеет это делать автоматически.

Если же хотите сделать это вручную, то создайте чистую базу (через тот же pgAdmin из шаблона template0), а затем выполните вот этот скрипт для восстановления резервной копии в эту базу:

Как разрешить (или запретить) восстановление резервной копии в НЕ пустую базу

Для PostgreSQL, обновлятор, по умолчанию, запрещает восстановление резервной копии СУБД в не пустую базу 1с.

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

Это сделано в целях безопасности, чтобы по неопытности пользователь не смог затереть рабочую базу.

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

Как изменить формат архива?

По умолчанию обновлятор выгружает резервную копию в формате plain.

При необходимости вы можете изменить формат на custom:

В этом случае восстанавливать такой архив нужно будет при помощи утилиты pg_restore (если вы делаете восстановление через обновлятор он определит тип архива и правильный способ восстановления сам).

Подробнее про форматы архивов вы можете почитать в документации к утилите pg_dump.

С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).

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

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

Данная инструкция актуальна только для файловых баз данных. В случае, если у вас клиент-серверная база, ее резервное копирование надо настраивать либо средствами СУБД (Если у вас MS SQL, настроить резервное копирование можем мы), либо с помощью сторонних программ.

Настройка резервного копирования файловой базы 1С

Раздел Обслуживание

Рассмотрим каждый из вариантов.

1С:Облачный архив

1С Облачный архив

Мастер подключения 1С облачный архив

Техническая поддержка

Сформируется письмо в техподдержку, и она поможет вам зарегистрироваться.

На локальном компьютере

Если подписки ИТС:Проф нет, то облако обойдется вам почти в 1000р/месяц. Сейчас мы разберем как сделать тоже самое, но бесплатно.

На локальном компьютере

Настройка резервного копирования файловой базы 1с

Каталог для сохранения резервных копий

Хранить только 10 последних копий

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

Настройка расписания

Каждый день. Один раз в день

Время резервного копирования

В результате должно получиться вот так:

Каждый день, с 13 15

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

Этот вариант подойдет вам, если вы последним уходите из офиса (или по крайней мере последним выходите из 1С).

В этом варианте дополнительно ничего не нужно настраивать. Просто при закрытии 1С система будет предлагать вам сделать резервную копию.

Как происходит резервное копирование при завершении работы

Окно, предлагающее сделать резервную копию

Нажмите на него, чтобы появилось вот такое окно:

Выполнить резервное копирование

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

Выгрузка резервных копий 1С в облако

Бэкапы в облаке

Готово! Настройка резервного копирования файловой базы 1С на этом завершена.

Проверка созданных резервных копий 1С

Откройте последний созданных архив с копией базы данных и извлеките содержащийся там файл в папку с новой базой:

Извлечение файла базы данных

Зайдите в новую базу и проверьте, что там есть нужные данные (например, свежие Реализации). Если база запустилась и данные на месте, значит все в порядке.

Читайте также: