- Настройка задачи резервного копирования базы 1С:Предприятия средствами СУБД
- Документация по ОС Windows
- Резервное копирование 1С
- Базы 1С в SQL, как настроить резервное копирование
- Решение для бэкапа баз 1С в SQL (MS SQL или PostreSQL), а так же автономного сервера 1С
- Сторонние программы для резервного копирования 1С
- Рассмотрим программу Effector Saver
- Как настроить резервное копирование 1с средствами sql
Настройка задачи резервного копирования базы 1С:Предприятия средствами СУБД
В случае клиент-серверного варианта работы 1С:Предприятия рекомендуется создавать бэкапы информационной базы средствами СУБД (MS SQL, PostgreSQL).
Главное преимущество данного способа бэкапа, это то что перед запуском не требуется завершать работу всех пользователей в системе. Но есть и недостаток, так для MS SQL невозможно создать устройство бэкапа расположенное на сетевом диске, поскольку видны только локальные, физически подключенные диски.
Приступим к настройке задачи бэкапа базы 1С средствами СУБД, в нашем примере это — Microsoft SQL Server.
Для добавления новой задачи, на панели инструментов нажимаем «Задачи» – «Добавить задачу».
Из списка выбираем тип новой задачи «Резервное копирование файлов и баз данных» и нажимаем «Создать». Откроется окно настройки новой задачи.
Нажимаем «Выбрать базу 1С:Предприятия из списка и заполнить основные параметры». Откроется диалог выбора подключенных баз данных 1С:Предприятия, где выбираем базу и нажимаем кнопку «Выбрать».
После, увидим информационное сообщение «Укажите параметры подключения к SQL серверу!», нажимает «Ок». Переходим во вкладку «База Microsoft SQL».
В поле «Сервер:» указываем имя SQL сервера. Если для соединения с сервером применяется встроенная авторизация SQL, устанавливаем флаг «SQL — авторизация», заполняем поля «Пользователь:» и «Пароль:» указанного пользователь.
В поле «База:», из выпадающего списка выбираем базу данных и нажимаем кнопку «Проверить». В случае успешной проверки, нажимаем «Ок» и заполняем поле «Вариант:».
Доступны следующие варианты выполнения бэкапа базы данных:
- «база данных полностью» — выгрузка всех данных указанной базы. Если база большая, то ее резервирование займет длительное время.
- «база данных частично» — выгрузка выполняется на основе последней полной копии данных. Использование разностных копий, ускоряет процесс резервирования базы.
- «лог транзакций» — резервные копии журналов транзакций позволяют выполнить восстановление базы данных, файла, файловой группы или страницы до контрольных точек сбоя или на указанный момент времени.
Переходим во вкладку «Хранилище архивов». Нажимает на кнопку
Если вы в первый раз настраиваете хранилище архивов или вам необходимо создать новое хранилище, то для этого в открывшемся окне, нажмите «Создать новое хранилище» и выберите место хранения для нашего бэкапа.
В случае выбора облачного хранилища, вам потребуется пройти авторизацию и разрешить работу Effector Saver с выбранным хранилищем.
После, прохождения авторизации, нажмите на кнопку
Обратите внимание: Effector Saver имеет доступ только к тем файлам и папкам Google Диска, которые были созданы в программе. Доступ к другим данным пользователя на Google Диске у Effector Saver отсутствует.
Если же необходимое хранилище бэкапа уже существует, вы можете использовать его снова. Для этого в открывшемся окне из списка выберите хранилище для нашего бэкапа.
Далее устанавливаем флаг «Автоматически удалять устаревшие резервные копии» и заполняем параметр «Хранить количество копий». Нажимаем «ОК».
Переходим во вкладку «Файл архива». Поле «Имя файла архива:» оставим незаполненным, чтобы оно формировалось из наименования задачи и окончания имени архива.
Далее, установим флаг «Шифровать файл архива» и заполним поля «Пароль:» и «Подтверждение:». Так, файлы будут защищены внутри архива и при попытке открыть его будет запрошен пароль.
Переходим во вкладку «Расписание автозапуска». Устанавливаем флаг «Запускать по расписанию». В поле «Периодичность:» из списка выбираем периодичность запуска задачи. В поле «Время начала:» указываем время запуска задачи. Нажимаем «Сохранить».
На этом настройка задачи завершена.
Простой способ проверить задачу, это выполнить ее не дожидаясь запуска по расписанию. Для этого щелкните на задаче правой кнопкой мыши и выберите «Выполнить сейчас».
После завершения работы задачи во вкладке «Журнал задач» отобразятся дата и результат выполнения.
Для подробного просмотра результата выполнения задачи, выберем в меню «Журнал задач» — «Открыть запись», или клик мыши по записи выполнения задачи.
Во вкладке «Бэкапы» можно просмотреть список созданных файлов бэкапа в результате выполнения задачи. Для подробного просмотра, выберем в меню «Бэкапы» — «Открыть подробности», или клик мыши по записи выполнения задачи.
Источник
Документация по ОС Windows
Записная книжка по ОС Windows
Резервное копирование 1С
Тема сегодняшней статьи как и какими программами настроить резервное копирование баз 1С наиболее эффективно
Базы 1С в SQL, как настроить резервное копирование
Решение для бэкапа баз 1С в SQL (MS SQL или PostreSQL), а так же автономного сервера 1С
Есть один нюанс, который превращает резервное копирования 1С в нетривиальную задачу, если кто-то из пользователей работает в базе, копирование невозможно. Мои пользователи работают круглосуточно, а значит кто-то всегда работает с базой. Для резервного копирования базу надо заблокировать для изменений, а этого не сделать, пока кто-то работает в 1С.
Выход есть — воспользоваться специальным инструментом встроенным в 1С и им сделать выгрузку базы.
Для этого нам понадобится утилита из комплекта автономного сервера 1С ibcmd.exe.
Исполняемый файл входит в состав дистрибутива 1С. Обычно располагается C:\Program Files\1cv8\ \bin
Скрипт бэкапа 1С для баз хранящихся SQL:
// Выгрузка dt без отключения пользователей
//уточняем текущее время с небольшой погрешностью и округлям до часов
set tt=%time%
set /a ttt=%time:
0,2%
if %ttt% lss 10 (set hour=0%ttt%) else (set hour=%ttt%)
//создаем папку — имя текущая дата
mkdir E:\1Cbakup\base1\%date%
C:\ ibcmd.exe infobase —dbms=mssqlserver —db-server=localhost —db-name=example_base —db-user=adm —db-pwd=12345678 dump D:\backup\%date%\example_base_%date%_%hour%.dt
После выполнения скрипта мы получим в папке с текущей датой файл с именем backup_текущая дата_время запуска скрипта.dt
Файл является копией базы 1С, без документов, которые были изменены в момент запуска скрипта. Т.е., если кто-то создал документ и его редактировал в момент запуска скрипта, этот документ сохранен не будет. На мой взгляд это малая плата за возможность иметь полную копию базы.
Пробежимся по ключам запуска ibcmd.exe подробнее
—dbms=mssqlserver — тип сервера SQL (в нашем примере MS SQL Server), если у Вас PostgreSQL, укажите postgresql
—db-server=localhost — адрес севера, в нашем примере скрипт выполняется на сервере с базой, поэтому localhost. Если вы выполняете скрипт на другом сервере или локальной рабочей базе, надо указать IP адрес сервера SQL.
—db-name= имя базы данных, в нашем примере это example_base, Вам надо указать имя своей базы.
dump D:\backup\%date%\example_base_%date%_%hour%.dt — замените путь, куда вы хотите складывать дамп баз.
ВАЖНОЕ ЗАМЕЧАНИЕ ПО БЕЗОПАСНОСТИ РЕЗЕРВНОГО КОПИРОВАНИЯ
Хранение бэкапа в папке доступной с самого копируемого сервера не безопасно. В случае заражения вирусом вида шифровальщик или иных деструктивных действий по отношению к данным на сервере, есть большой шанс потери резервной копии данных. Рекомендуется использовать доступную папку только для промежуточного бэкапа с дальнейшим переносом данных в другое место.
Если настройка системы резервного копирования с переносом данных на внешнее хранилище по каким-либо причинам Вам недоступна, не используйте для файла дампа базы 1С расширение .dt, замените его на любое другое, к примеру на .tti Шифровальщики ищут файлы с известными расширениями, чтобы их зашифровать.
Сторонние программы для резервного копирования 1С
Рассмотрим программу Effector Saver
Программа удобна, легко настраивается, позволяет делать копии баз 1С на FTP и SFTP, что решает проблему безопасности хранения бэкапа.
Подробнее как настроить работу программы можно найти на сайте производителя в разделе документации.
Я остановлюсь только на том важном моменте, что файловые базы 1С не позволяют сделать копию базы без завершения сеансов пользователей.
В программу встроен механизм завершения сеансов, для копирования файловых баз 1С, его надо обязательно настроить.
В большинстве случаев двух этих решений достаточно для организации резервного копирования баз данных 1С.
Источник
Как настроить резервное копирование 1с средствами sql
Сегодня рассмотрим один из вариантов обслуживания баз 1С в СУБД MS SQL.
Содержание:
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания
1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
MS SQL Server поддерживает три модели восстановления:
1) Simple (Простая) — хранится только необходимый для жизни остаток журнала транзакций.
2) Full (Полная) — хранится весь журнал транзакций с момента последнего резервного копирования журнала транзакций.
3) Bulk logged (С неполным протоколированием) — часть операций записываются в очень компактном формате. В остальном идентична Full.
Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).
MS SQL поддерживает три типа формирования резервных копий:
1) Full (Полная копия)
2) Differential (Дифференциальная копия, Разностная копия)
3) Log (Резервная копия журналов транзакций)
Не путайте понятия: полная модель восстановления и полная резервная копия — разные вещи.
Рассмотрим подробно три типа формирования резервных копий.
1) Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени. Состоит из копии файлов данных и журнала транзакций на момент завершения формирования резервной копии.
2) Разностная резервная копия
Хранит данных, изменившиеся с момента последней Полной резервной копии. При восстановлении нужно сначала восстановить Полную резервную копию в режиме NORECOVERY, потом можно применить любую из последующих Разностных копий. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Обратите внимание: без предыдущей Полной резервной копии Разностная копия бесполезна. Каждая последующая Разностная копия будет хранить все данные, входящие в предыдущую Разностную резервную копию, сделанную после предыдущей Полной копии. Поэтому каждая следующая Разностная копия больше предыдущих, пока снова не сделать Полную копию. Соответственно для восстановления на какой-то момент времени достаточно последней Полной резервной копии и последней Разностной копии. Промежуточные копии для восстановления не нужны.
3) Резервная копия журналов транзакций
Содержит копию журналов транзакций за некоторый период. Обычно с момента прошлой Резервной копии журналов транзакций до момента формирования текущей Резервной копии журналов транзакций. За счет этого Резервные копии журналов транзакций позволяют (с учетом Полной и Разностной копий) восстановить базу данных на любой момент времени. Резервная копия журналов транзакций высвобождает место в файле журнала транзакций, что позволяет ITишники избавиться от шринка базы данных.
Обратите внимание: набор Резервных копий журналов транзакций по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного Полного или Разностного резервного копирования должен быть внутри периода этой цепочки.
2. Постановка задачи по созданию планов обслуживания
В организации N работают по шестидневке с 8:00 до 17:00. Обед с 12:00 до 13:00.
Имеется в MS SQL база данных с именем Moodle.
Что нужно сделать:
1) Проверить модель восстановления базы данных, должна быть Полная.
2) Создать план обслуживания, который будет создавать Полную резервную копию базы данных каждое воскресение в 17:00. Очищать хранилище от устаревших резервных копий старше 15 дней.
3) Создать план обслуживания, который будет создавать Разностную копию базы данных каждый день в 21:00 кроме воскресения.
4) Создать план обслуживания, который будет создавать Резервную копию журналов транзакций два раза в день, в 12:00 и в 17:00, кроме воскресения.
3. Создание плана обслуживания (Полная копия)
Запускаем SQL Server Management Studio, в Обозревателе объектов проходим по ветке Управление — Планы обслуживания.
Источник