Бэкап файловых и SQL баз 1С (в облако и с шифрованием)

Ниже будет подробно рассказано о том, как создать резервную копию базы данных в MS SQL Server 2012. В младших версиях (например в MS  SQL Server 2008) алгоритм получения резервной копии аналогичен.

0. Оглавление

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

Запускаем утилиту «SQL Server Management Studio». В Microsoft Windows Server 2012 (R2) ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 (R2) в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Среда SQL Server Management Studio».

Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).

Затем в обозревателе объектов (Object Explorer) раскрываем вкладку «Базы данных» (Databases), кликаем правой кнопкой мыши по базе, из которой необходимо выгрузить данные и в контекстном меню выбираем «Задачи» (Tasks) — «Создать резервную копию…» (Back up…).

Откроется окно настройки свойств резервного копирования базы данных. Здесь можно выбрать:

• Базу данных (Database) для которой создается резервная копия — выбрана база данных с которой мы начинали действия.
• Тип резервной копии (Backup type) — по умолчанию полная (Full). Подробно о различных типах резервных копий читайте здесь.
• Установить флаг «Только резервная копия» (Copy-only Backup) — признак того, что создаваемая резервная копия будет изолирована от обычной последовательности резервных копий SQL Server.
• Компоненты резервного копирования (Backup component) — всю базу данных (Database) или только выбранные файлы (Files and filegroups).
• Срок действия резервного набора данных (Backup set will expire) — период, после которого эта резервная копия может быть перезаписана без явного пропуска проверки на истечение срока. Если выбрано через 0 дн. (After: 0 days), файлы резервной копии не будут перезаписываться.
• Назначение (Destination) — путь к файлу резервной копии на выбранном диске (Disk).

Для того, чтобы изменить или добавить место расположения и имя файла резервной копии или устройства резервного копирования, нажмем «Добавить» (Add…), в окне выбора места расположения резервной копии выберем каталог и имя файла, и закроем все окна нажав «ОК». Для удаления назначения резервного копирования, выделим его в списке и воспользуемся кнопкой «Удалить» (Remove).

Определившись с общими настройками резервного копирования переходим на вкладку «Параметры» (Options).

Здесь установим флаг «Проверить резервную копию после завершения» (Verify backup when finished) для обеспечения больше надежности и установим параметр «Сжимать резервные копии» (Compress backup) для экономии дискового пространства, после чего нажмем «ОК» для запуска процесса создания файла резервной копии.

Если резервное копирование выбранной базы данных завершилось успешно, увидим соответствующее сообщение.

Ну а в указанном ранее каталоге найдем непосредственно сам файл резервной копии выбранной базы данных.

О восстановлении базы данных из резервной копии, можно прочитать в статье «Восстановление базы данных из резервной копии в MS SQL Server 2012»

 2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).

Сформировавшийся отчет содержит в себе следующие данные:

• Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
• Успешные операции резервного копирования (Saccessful Backup Operations)
• Ошибки операции резервного копирования (Backup Operation Errors)
• Успешные операции восстановления (Saccessful Restore Operations)

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

Помогла ли Вам данная статья?В этой статье я хочу поделиться опытом резервного копирования файловых и SQL баз 1С в локальное, сетевое и облачное (на примере Google Drive) хранилище с помощью Effector Saver. ПО является платным: 2500₽. Переход на новую версию (с 3 на 4) также является платным: 1250₽. Писал инструкцию для друга, но думаю она пригодиться и кому-то из вас. И как всегда, в комментариях, вы научите меня чему-то новому =) В конце инструкции приведен пример журнала, по которому хорошо видна скорость выполнения задачи.Цель: Автоматическое создание шифрованных бэкапов по расписанию с отчётом об ошибках на почту.Логика бэкапов:

• Ежедневно последние 30 шт (срок хранения 1 месяц)
• Ежемесячно 1 числа последние 24 шт (срок хранения 2 года)
• Ежегодно 1 февраля последние 10 шт (срок хранения 10 лет)
• Бэкапы выгружаются в хранилище бэкапов (локальное или сетевое) из под учётки backup
• Бэкапы выгружаются в облако Goole Drive (возможно с собственным OAuth ID Client/Secret)
• Отправка отчета об ошибках на электронную почту

Небольшое пояснение

• Данная инструкция приводится как готовый пример использования, который можно и нужно адаптировать под свои задачи.
• Задания могут запускаться в одно время, т.к. поддерживается параллельное выполнение заданий, что ощутимо сокращает время для бэкапов.
• Дополнительное копирование выполняется на основе задачи, т.е. выполняется копирование последнего уже созданного бэкапа. Например, если дополнительное копирование должно быть выполнено 10 числа, а бэкап выбранной задачи от 10 числа завершился с ошибкой (а мы не стали вмешиваться), то дополнительное копирование сделает копию для последнего успешного бэкапа выбранной задачи, в нашем примере будет от 9 числа.
• В программе можно настроить выгрузку баз средствами 1С в виде .dt файлов, с автоматической блокировкой/разблокировкой базы и выкидыванием пользователей. В данной инструкции такой способ не рассматривается, как ненадежный способ резервного копирования формата .dt.

1. Установка и настройка Устанавливаем, запускаем. — Сервис > Параметры

• АвтозагрузкаЗапускать как служба Windows (сервер) пользователь backup, пароль свойПояснения по пользователю backup, для чего отдельная учетка
• Параметры агентаРазрешить параллельную работу потоковых задач: 5 Выбираем от мощности сервера и скорости канала интернет (для выгрузки в облако)Использовать указанный каталог временных файлов: \NASBackupTempПояснения по использованию сетевого пути
  

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

  1. для backup на запись
  2. для учетки из под которой работает служба MS SQL Server на запись
  3. админам на чтение

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

• Файлы архивовВарианты окончания имени архива: yyyy.mm.dd_hh.nn.ss Для эстетики и имя без пробелов (старая привычка)
• СлужебныеOAuth данные приложения в облаке — Обновить данные ClientID / ClientSecretТут вносить изменения не обязательно, но как всегда есть небольшое НО
  

  Недавно я получил ошибку выгрузки бэкапов в облако из-за превышения лимитов OAuth. Ошибка была только один раз, разработчики устранили эту проблему, но зачем ждать её снова. Я решил получить свой OAuth на Google Диск и забыть об этом. Инструкция с картинками, как получить свой Client ID и Secret нашел тут: https://github.com/Cloudbox/Cloudbox/wiki/Google-Drive-API-Client-ID-and-Client-Secret

2. Подготовка — Сервис > Управление хранилищами > Создать

• Локальная/сетевая папка: Тут все понятно, следуя нашей логике бэкапов (в начале статьи) создаем 3 хранилища для удобства \NASBackupEveryDay \NASBackupEveryMonth \NASBackupEveryYear
• Google диск: Создаем подключение к облаку Google диск. Название дадим по нашей логике: EveryDay Жмем кнопку Авторизация, вводим логин/пароль, готово.Если вы это настраиваете удаленно на сервере или чужом компьютере
  

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

  Выбираем путь к папке в облаке, аналогично: Backup/EveryDay Дополнительные облачные хранилища для ежемесячных и ежегодных копий делаем через копирование (Создать > Скопировать) В итоге получаем 3 облачных хранилища: EveryDay (Google Диск) EveryMonth (Google Диск) EveryYear (Google Диск) На этом настройка Управление хранилищами закончена.

3. Создание задач резервного копирования3.1. Задачи > Добавить задачу > Резервное копирование файлов и баз данных (SQL)

• Основные параметрыВключить в архив бэкап базы SQL (на примере Microsoft SQL Server)
• База Microsoft SQL Прописываем все реквизиты. Проверяем, что на MS SQL сервере открыт TCP 1433 порт. Жмем: Проверить
• Хранилище архивов — Добавляем хранилище \NASBackupEveryDayАвтоматически удалять устаревшие резервные копии: 30 — Добавляем хранилище EveryDay (Google Диск)Автоматически удалять устаревшие резервные копии: 30
• Файл архиваИмя файла архива: название базыОкончание имени архива: yyyy.mm.dd_hh.nn.ss АрхивированиеФормат: 7zСжатие: без сжатияПочему без сжатия?
  

  При резервном копировании SQL базы стоит рассмотреть 2 варианта 1. Сжатие базы средствами SQL сервера. — Быстрый, но сжимает хуже чем 7z. Если выбрали этот вариант, то нужно: — Выбрать: без сжатия (т.к. сжимать уже сжатый .bak файл без толку) — В свойствах MS SQL сервера включить: Параметры базы данных > Сжимать резервные копии. 2. Сжатие базы средствами 7z — Медленный, но сжимает лучше чем SQL. Если выбрали этот вариант, то нужно: — Выбрать: максимальное сжатие — В свойствах MS SQL сервера отключить: Параметры базы данных > Сжимать резервные копии. В SQL бэкапах я использую первый вариант, хоть он и сжимает по хуже, зато выгрузка делается за считанные минуты (а то и секунды). А вот второй вариант может растянуться на часы. В будущих версиях программы разработчики обещали подумать над тем, чтобы добавить опцию сжатия MS SQL баз в свойства задачи, чтобы не бегать в свойства MS SQL сервера.

  Шифровать архивыШифровать имена файлов Устанавливаем пароль (запишите его, если забудете, то бэкапы будет не восстановить)

• Расписание автозапуска: Запускать по расписанию: включить Ежедневно 03:00

3.2. Задачи > Добавить задачу > Резервное копирование файлов и баз данных (файл)

• Основные параметрыВключить в архив файлы
• ФайлыПуть к файлам: Выбираем путь к папке в которой лежат файловые базы 1С, например «D:Bases» Если хотим сделать бэкап всех баз в подкаталогах, выбираем:Имена сохраняемых файлов, каталогов…: 1Cv8.1CDВключить подкаталоги (рекурсивно) Если хотим сделать бэкап выборочных баз в подкаталогах, выбираем:Имена сохраняемых файлов, каталогов…: Buh1Cv8.1CD Trade1Cv8.1CD
• Хранилище архивов — Добавляем хранилище \NASBackupEveryDayАвтоматически удалять устаревшие резервные копии: 30 — Добавляем хранилище EveryDay (Google Диск)Автоматически удалять устаревшие резервные копии: 30
• Файл архиваИмя файла архива: название базыОкончание имени архива: yyyy.mm.dd_hh.nn.ss АрхивированиеФормат: 7zСжатие: максимальноеШифровать архивыШифровать имена файлов Устанавливаем пароль (запишите его, если забудете, то бэкапы будет не восстановить)
• Расписание автозапуска: Запускать по расписанию: включить Ежедневно 03:00

Основные задачи ежедневного резервного копирования настроили, переходим к дополнительным4. Задачи > Добавить задачу > Дополнительное копирование

• Основные параметрыЗадача резервного копирования — источник: выбираем нужную задачуХранилище… источник: выбираем хранилище \NASBackupEveryDay
• Хранилище архивов — Добавляем хранилище \NASBackupEveryMonthАвтоматически удалять устаревшие резервные копии: 24 — Добавляем хранилище EveryMonth (Google Диск)Автоматически удалять устаревшие резервные копии: 24
• Файл архиваИмя файла архива: название базыОкончание имени архива: yyyy.mm.dd_hh.nn.ss АрхивированиеФормат: 7zСжатие: без сжатияШифровать архивыШифровать имена файлов Устанавливаем пароль (запишите его, если забудете, то бэкапы будет не восстановить)
• Расписание автозапуска: Запускать по расписанию: включить Ежемесячно. Все месяцы 1 числа. 05:00

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

• Хранилище архивов — Добавляем хранилище \NASBackupEveryYearАвтоматически удалять устаревшие резервные копии: 12 — Добавляем хранилище EveryYear(Google Диск)Автоматически удалять устаревшие резервные копии: 12
• Расписание автозапуска: Запускать по расписанию: включить Ежемесячно. Февраль 1 числа (год закрыт) 05:00

Дополнительные задачи резервного копирования настроили, переходим к формированию отчета на почту5. Задачи > Добавить задачу > Отправка отчетов

• Основные параметрыКоличество дней…: 1
• Расписание автозапуска: Запускать по расписанию: включить Ежедневно 07:00

Осталось запустить все задачи по очереди и проверить на ошибки. Пример журнала резервного копирования MS SQL базы весом 52Гб (mdf):=========================================== Задача: Base1 Вид задачи: Резервное копирование файлов и баз данных Компьютер: SRVTS0 Версия: 4.5 / 2 Запуск: По расписанию, как служба Начало: 11.11.2019 4:01:08 Конец: 11.11.2019 5:13:57 Статус: Успешное выполнение задачи =========================================== 11.11.2019 4:01:08 - Резервное копирование MSSQL базы "Base1" ... 11.11.2019 4:01:08 - SQL Server version 11 11.11.2019 4:22:15 - Выполнено 11.11.2019 4:22:15 - Резервное копирование файлов ... 11.11.2019 4:22:15 - формат 7z, без сжатия, c шифрованием заголовка 11.11.2019 4:26:50 - 1 файлов добавлено, 0 файлов пропущено 11.11.2019 4:26:50 - Выполнено 11.11.2019 4:26:52 - Загрузка бэкапа 5,41 GB в хранилище "EveryDay (Google Диск)" ... 11.11.2019 4:26:54 - Загрузка "Base1_2019.11.11_04.26.52.7z" 5,41 GB (1 из 1) 11.11.2019 5:13:57 - Загрузка удачно завершена 11.11.2019 4:26:52 - Загрузка бэкапа 5,41 GB в хранилище "\NASBackupEveryDay" ... 11.11.2019 4:26:52 - Загрузка "Base1_2019.11.11_04.26.52.7z" 5,41 GB (1 из 1) 11.11.2019 4:28:13 - Загрузка удачно завершена Из журнала видно, что загрузка в хранилище и в облако началась одновременно. Бэкап в хранилище был завершен через 27 минут. А в облако был выгружен через 1 час 12 минут от старта задачи. При условии, что параллельно в это же время выполнялось еще 4 задачи резервного копирования баз, размер которых 38Гб, 28Гб, 6Гб и 5Гб (mdf). Все задачи были одновременно запущены в 4:00 и успешно завершены до 5:15:00.Выводы: Есть конечно и небольшие недоработки, кроме тех, что уже описал в статье:

• отсутствие возможности экспорта и импорта настроек и задач в виде текстового файла (именно текстового, а не mdb и т.п., чтобы можно было легко открыть и отредактировать)
• нет визуального сохранения настроек OAuth, всегда пусто и не понятно настроено или нет.
• нет возможности быстро включить/выключать задания (нужно открывать каждое и заходить в расписание). Хотя в главном окне интуитивно так и просится двойной клик по галочке.

UPD1: Добавил информацию о стоимости ПО, спасибо

Выбор модели восстановления данных

Откройте в Enterprise Manager свойства вашей базы данных, перейдите на закладку «Options»:

SQL Server предлагает 3 модели восстановления данных:

• Simple. База данных может быть восстановлена на момент последней архивной копии, однако, Вы не сможете восстановить базу данных на момент сбоя;
• Full. База данных может быть восстановлена на момент сбоя независимо от вида операций, которые выполнялись с базой данных в момент сбоя;
• Bulk-Logged. База данных может быть восстановлена на момент сбоя в случае, если с базой данных не выполнялись массовые операции (bulk copy operations):
  • SELECT INTO;
  • CREATE INDEX;
  • Операции с полями типа text и image;
  • Операции массовой загрузки (Bulk load operations (bcp and BULK INSERT))

Выбирайте модель «Full«. Так Вы будете уверены, что в случае серьезного сбоя не потеряете информацию или потеряете только минимум (потеря информации может произойти, если будет поврежден файл транзакций).? Реклама

Более подробную информацию о моделях восстановления данных Вы можете найти в Books Online (BOL) по строке поиска «Selecting a Recovery Model» или «Simplify backup and recovery procedures».

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

Вот мы и добрались до самого интересного…

Сейчас мы настроим автоматическое создание полных резервных копий Вашей базы данных.

Запустите Enterprise Manager, откройте папку «Management», поставьте курсор на «Database Maintenance Plans» и из контекстного меню выберите пункт «New Maintenance Plan…»:

Нажмите на кнопку «Далее» в окне приветствия и перейдите к окну выбора баз данных для архивирования:

Пометьте галочкой Вашу базу данных и нажмите кнопку «Далее». Пропустите окна «Update Data Optimization Information» и «Database Integrity Check». Перед Вами появится окно «Specify the Database Backup Plan»:

<object><object>Купите 1С Бухгалтерия, а в подарок духиПри покупке 1С ПРОФ дарим сертификат на 2000 руб Летуаль/Детский мир в подарок.Узнать больше</object>

Back up the database as part of the maintenance plan — база данных целиком будет заархивирована при выполнении плана обслуживания.

Verify the integrity of the backup when complete — проверить, что полученный архив читается командой RESTORE VERIFYONLY.

Нажмите кнопку «Change…», чтобы вызвать окно для настройки графика выполнения задания:

Согласно разработанному плану полная копия базы данных должна делаться во все дни недели за исключением воскресенья в 01:00. После настройки параметров нажмите «ОК». Перейдите к следующему окну «Specify Backup Disk Directory»:

Здесь Вы можете указать, в какой каталог следует помещать сделанные архивные копии и какое расширение будет у файлов архивных копий.

? Реклама

Если Вы будете архивировать несколько баз данных, имеет смысл поставить галочку «Create a subdirectory for each database«. В этом случае для каждой архивируемой базы данных будет создан свой подкаталог, в которой и будут помещаться архивные копии.

На всякий случай можно установить галочку «Remove files older than«, чтобы удалять файлы, старше установленных параметров.

Перейдите к следующему окну «Specify the Transaction Log Backup Plan»:

Поскольку мы не планируем выполнять резервное копирование файла транзакций вместе с полным копированием базы данных, сбросьте галочку «Back up the transaction log as part of the maintenance plan«.

В следующих двух окнах оставьте значения по умолчанию. В последнем окне укажите название плана обслуживания:

? Реклама

На этом создание плана обслуживания завершено. Перейдите в раздел Jobs, и в правой панели Enterprise Manager Вы увидите новое задание:

Оно создано на основе плана обслуживания «Base1C Full Backup«. Давайте запустим его и убедимся, что полная копия базы данных делается без ошибок. Щелкните правой кнопкой мыши на названии задания и выберите в контекстном меню пункт «Start Job»:

После завершения работы у меня создался файл с именем «Base1C_db_200711290147.bak»

Base1C — это имя архивируемой базы данных; db — признак того, что это копия базы данных (не файла транзакций); 20071129 — дата создания архивной копии; 0147 — время создания архивной копии.

? Реклама

На этом настройка автоматического создания полных копий базы данных завершена.

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

Переходим ко второй части графика резервного копирования — автоматическому созданию архивов файла транзакций.

Для архивирования файла транзакций мы создадим отдельный план обслуживания. Его настройка почти такая же, как для полной копии базы данных. Отличие лишь в том, что в окне «Specify the Database Backup Plan» надо снять галочку «Back up the database as part of the maintenance plan«:

а в окне «Specify the Transaction Log Backup Plan», наоборот, поставить галочку «Back up the transaction log as part of the maintenance plan«

и настроить график выполнения задания

? Реклама

В окне «Specify Transaction Log Backup Disk Directory» делаем настройки, аналогичные плану обслуживания для создания полной копии базы данных:

Расширение архивного файла оставляем по умолчанию — TRN. План обслуживания назовем «Base1C Log BackUp»:

Создание плана обслуживания для резервного копирования файла транзакций завершено. Осталось только проверить его работоспособность:

После завершения работы у меня создался файл с именем «Base1C_tlog_200711290227.bak»

Base1C — это имя архивируемой базы данных; tlog — признак того, что это копия файла транзакций; 20071129 — дата создания архивной копии; 0227 — время создания архивной копии.

? Реклама

Что еще нужно знать про резервное копирование в SQL сервере

Мы закончили настройку SQL сервера для автоматического архивирования данных программы 1С. Но это еще не все, что Вам нужно знать. Прошу Вас запастись терпением еще на 5 минут. Приведенная ниже информация будет Вам полезна:

• В разделе «Backing Up and Restoring System Databases» в BOL говорится: «Системные базы данных надо архивировать также, как и пользовательские…Важно выполнять архивирование на регулярной основе следующих системных баз данных:
  • master
  • msdb
  • model (если она модифицирована)
  • distribution (если сервер сконфигурирован как replication Distributor)»

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

Вот теперь все! Все, что касается настройки SQL сервера. Архивные копии базы данных и файла транзакций создаются. Осталось дело за малым:? Реклама

• написать BAT-файлы, которые выполняют упаковку файлов и их перенос с сервера SQL на дополнительный компьютер;
• создать задания в планировщиках заданий SQL сервера и доп. компьютера.

Эту работу я предлагаю сделать Вам самим. Если возникнут какие-то затруднения, обращаетесь по почте или ICQ.

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

Примечание: в статье отражено мое мнение по резервному копированию баз 1С. Оно может не совпадать с Вашим мнением и / или мнением других специалистов.

Мероприятия

Блоги компаний

Используемые источники:

• https://tavalik.ru/sozdanie-kopii-bd-v-ms-sql-server-2012/
• https://habr.com/post/474944/
• https://www.klerk.ru/soft/articles/106613/

</object>