Бэкап базы 1с sql средствами: Настройка резервного копирования 1С + MSSQL

Настройка резервного копирования 1С + MSSQL

Резервное копирование баз 1С происходит стандартными планами обслуживания СУБД MSSQL. Система позволяет делать надежные полные, а также дифференциальные копии баз данных. Процесс резервного копирования проходит незаметно для клиента и может выполняться в рабочее время без остановки работы пользователей в 1С.

Порядок действий:

1. Необходимо запустить Microsoft SQL Server Management Studio и выполнить подключение к серверу.
2. Для ВСЕХ пользовательских баз данных отключить автоматическое обновление индексов. Это связано с тем, что обновление индексов будет производиться по указанному нами расписанию.
   1. Открываем список баз данных, выделяем базу и вызываем правой кнопкой мыши контекстное меню.

   2. Открываем опции базы, меняем значение параметра Auto update statistics с true на false.

3. Создаем новый план обслуживания Maintenance:

4. Корректируем имя субплана и настраиваем расписание. Двойной клик по имени Subplan_1.

   Пример расписания:

   При такой настройке расписания задача будет выполняться ежедневно в 0:00, кроме воскресенья.




5. При работе с индексами баз данных желательно перевести пользовательские базы из режима восстановления FULL в режим SIMPLE. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
   1. В настройках задачи добавляем код:

      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY SIMPLE WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END

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

7. После реорганизации индексов следует провести обновление статистики пользовательских баз:
   1. В настройках выбираем обновление всей статистики всех пользовательских баз с полным сканированием:

8. Сбрасываем процедурный кэш SQL-сервера и возвращаем пользовательские базы из режима восстановления SIMPLE в режим FULL. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
   1. В настройках задачи добавляем код:

      DBCC FREEPROCCACHE
      
      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY FULL WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END
      

9. Теперь необходимо добавить в субплан задачи очистки. Эти задачи способны обрабатывать только один тип файлов резервных копий. Так как создается 2 типа файлов (bak и trn), задания делаем тоже два.
   1. В настройках задания указываем путь к резервным копиям, возраст копий для удаления (4 недели) и расширение файлов.
   2. Резервные копии складываются в отдельные папки для каждой базы, поэтому включаем поиск в подкаталогах первого уровня:

   3. Настройки второй задачи отличаются расширением удаляемых файлов: trn.

10. После удаления устаревших резервных копий добавляем задачу создания новой полной резервной копии:
    1. Настраиваем добавленное задание:

    2. Указываем тип backup Full, указываем пункт все пользовательские базы без игнорирования отключенных баз.

    3. Ставим время устаревания резервных копий 14 дней.
    4. Указываем создание отдельных файлов для каждой базы данных с созданием отдельных папок для каждой базы, указываем путь для сохранения (локальный или сетевой). Расширение файлов резервных копий bak.
    5. Включаем проверку целостности резервных копий (Verify backup integrity), включаем сжатие резервных копий (Compress backup).

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

    2. Расписание и настройки для Daily_diff:

       Данный субплан будет выполняться с понедельника по пятницу дважды в день, в 12.00 и 17:00.

    3. Добавляем задачу создания разностной резервной копии:

    4. Настройки для задачи резервирования в субплане Daily_diff аналогичны таковым в Daily_full, за исключением типа резервирования: Differential.

    5. Расписание и настройки для Daily_log:

       Расписание задачи настроено на выполнение с понедельника по пятницу каждые 15 минут с 8.00 до 19.00.

       
       

12. Добавляем задачу создания резервной копии.

    Настройки задачи резервирования log отличаются типом (transaction log) и расширением (trn) резервных копий.

13. Создадим субплан Weekly еженедельного обслуживания:
    1. Настраиваем расписание:

       Задача будет запускаться каждое воскресенье в 0.00.

    2. Переводим пользовательские базы из режима восстановления FULL в режим SIMPLE. Для этого добавляем в субплан задачу Execute T-SQL Statement task.

    3. В настройках задачи добавляем код:

       DECLARE @name VARCHAR(50)
       DECLARE db_cursor CURSOR FOR
       SELECT name
       FROM master.dbo.sysdatabases
       WHERE name NOT IN ('master','model','msdb','tempdb')
       
       OPEN db_cursor
       FETCH NEXT FROM db_cursor INTO @name
       WHILE @@FETCH_STATUS = 0
       BEGIN
        EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY SIMPLE WITH NO_WAIT')
        FETCH NEXT FROM db_cursor INTO @name
       END
       

    4. Добавляем задачу перестроения индексов:

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

    6. Сбрасываем процедурный кэш SQL-сервера и возвращаем пользовательские базы из режима восстановления SIMPLE в режим FULL. Для этого добавляем в субплан задачу Execute T-SQL Statement task.

    7. В настройках задачи добавляем код:

       DBCC FREEPROCCACHE
       
       DECLARE @name VARCHAR(50)
       DECLARE db_cursor CURSOR FOR
       SELECT name
       FROM master.dbo.sysdatabases
       WHERE name NOT IN ('master','model','msdb','tempdb')
       
       OPEN db_cursor
       FETCH NEXT FROM db_cursor INTO @name
       WHILE @@FETCH_STATUS = 0
       BEGIN
        EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY FULL WITH NO_WAIT')
        FETCH NEXT FROM db_cursor INTO @name
       END
       

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

    9. Настраиваем добавленное задание:
       • Ставим время устаревания резервных копий 14 дней.
       • Включаем проверку целостности резервных копий (Verify backup integrity), включаем сжатие резервных копий (Compress backup).
       • Указываем создание отдельных файлов для каждой базы данных с созданием отдельных папок для каждой базы, указываем путь для сохранения (локальный или сетевой). Расширение файлов резервных копий bak.

    10. Указываем тип backup Full, указываем пункт все пользовательские базы без игнорирования отключенных баз.

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

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

В этой статье я хочу поделиться опытом резервного копирования файловых и 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, для чего отдельная учетка

  Для бэкапов считаю важным создавать и использовать отдельную учетную запись, например backup. Это может быть как локальная так и доменовская учетка.
  
  Доступ к хранилищу бэкапов для админов должен быть настроен для чтения, и только у учетки backup на запись. Это позволит защитить ваши бэкапы от многих опасностей (дурная голова, вирусы). А если вам понадобится внести какие-то изменения в хранилище бэкапов, то всегда можно дать себе временны доступ, или запустить любой проводник (например Total Commander) от имени учетки backup для полного доступа к хранилищу.

• Параметры агента
  Разрешить параллельную работу потоковых задач: 5
  
  Выбираем от мощности сервера и скорости канала интернет (для выгрузки в облако)
  Использовать указанный каталог временных файлов:
  
  \\NAS\Backup\TempПояснения по использованию сетевого пути

  Сетевую папку желательно разместить на компьютере с данной программой, т.е. по факту для нас это будет локальная папка (если скорость позволяет, то и любой другой сетевой путь).
  
  Доступ к папке 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 хранилища для удобства
  
  \\NAS\Backup\EveryDay
  
  \\NAS\Backup\EveryMonth
  
  \\NAS\Backup\EveryYear
• 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 порт.
  
  Жмем: Проверить
• Хранилище архивов
  
  — Добавляем хранилище \\NAS\Backup\EveryDay
  Автоматически удалять устаревшие резервные копии: 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
• Прервать выполнение задачи через: включить
  
  2 час. 0 мин.

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

• Основные параметры
  Включить в архив файлы
• Файлы
  Путь к файлам: Выбираем путь к папке в которой лежат файловые базы 1С, например «D:\Bases»
  
  Если хотим сделать бэкап всех баз в подкаталогах, выбираем:
  Имена сохраняемых файлов, каталогов…:
  
  1Cv8.1CD
  Включить подкаталоги (рекурсивно)

  Если хотим сделать бэкап выборочных баз в подкаталогах, выбираем:
  Имена сохраняемых файлов, каталогов…:
  
  Buh\1Cv8.1CD
  
  Trade\1Cv8.1CD

• Хранилище архивов
  
  — Добавляем хранилище \\NAS\Backup\EveryDay
  Автоматически удалять устаревшие резервные копии: 30
  
  — Добавляем хранилище EveryDay (Google Диск)
  Автоматически удалять устаревшие резервные копии: 30
• Файл архива
  Имя файла архива: название базы
  Окончание имени архива: yyyy.mm.dd_hh.nn.ss
  
  Архивирование
  Формат: 7z
  Сжатие: максимальное
  Шифровать архивы
  Шифровать имена файлов
  
  Устанавливаем пароль (запишите его, если забудете, то бэкапы будет не восстановить)
• Расписание автозапуска:
  Запускать по расписанию: включить
  
  Ежедневно 03:00
• Прервать выполнение задачи через: включить
  
  2 час. 0 мин.

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

4. Задачи > Добавить задачу > Дополнительное копирование

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

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

• Хранилище архивов
  
  — Добавляем хранилище \\NAS\Backup\EveryYear
  Автоматически удалять устаревшие резервные копии: 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 в хранилище "\\NAS\Backup\EveryDay" ...

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: Добавил информацию о стоимости ПО, спасибо Filex

Автоматизация резервного копирования баз 1С средствами MS SQL сервера

Эта статья не претендует на пособие по созданию резервных копий баз данных 1С, но может помочь начинающим администраторам в автоматизации рутинных процессов создания бэкапов. И так, исходные данные:

• Сервер 1С Предприятия 8.3.ххх
• Сервер баз данных MS SQL 2008 и более новее

И так переходим в консоль управления MS SQL сервера, находим под списком баз данных пункт «Агент SQL сервер» в нем подпункт «Задания» и создаем новое Задание.

Задаем название задания, например BackUP1C — можно на русском, как вам удобно! Далее, наше задание будет состоять из нескольких шагов — сколько баз, столько и шагов будет у нас. Задаем имя шага, например «КопияБДБухгалтерии», Выбираем тип скрипта, и далее вставляем сам скрипт:

Скрипт SQL:

DECLARE @to varchar(100)
DECLARE @dbname varchar(100)
DECLARE @path varchar(400)
———————————
SET @dbname = ‘bazebaze’
SET @to = ‘D:\backup\’
———————————
SET @path = @to + @dbname + ‘_’ +
cast(day(getdate()) as varchar(5)) + ‘.’ +
cast(month(getdate()) as varchar(5)) + ‘.’ +
cast(year(getdate()) as varchar(5)) + ‘-‘ +
replace(cast(CONVERT(varchar(8), GETDATE(), 108) as varchar(8))+ + ‘.bak’, ‘:’, ‘.’)
BACKUP DATABASE @dbname TO DISK=@path WITH COPY_ONLY, NOFORMAT, INIT,COMPRESSION,
NAME = @dbname,
SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM

Давайте разберем некоторые моменты:

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

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

SET @path = @to + @dbname + ‘_’ +
cast(day(getdate()) as varchar(5)) + ‘.’ +
cast(month(getdate()) as varchar(5)) + ‘.’ +
cast(year(getdate()) as varchar(5)) + ‘-‘ +
replace(cast(CONVERT(varchar(8), GETDATE(), 108) as varchar(8))+ + ‘.bak’, ‘:’, ‘.’)

Далее рассмотрим саму строку резервного копирования:

BACKUP DATABASE @dbname TO DISK=@path WITH COPY_ONLY, NOFORMAT, INIT,COMPRESSION,
NAME = @dbname,
SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM

COPY_ONLY — параметр для копирования базы данных , а также создается резервная копия только для копирования для журнала транзакций

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

COMPRESSION | NO_COMPRESSION — применяется только в SQL Server 2008 Enterprise и более поздних версиях; указывает необходимость сжатия резервной копии, переопределяя значение по умолчанию на уровне сервера. В нашем примере мы сжимаем копию.

NOREWIND и REWIND — параметры используются для магнитной ленты. Если у вас она не используется в качестве носителя, то параметры будут проигнорированы

STATS [ = percentage ] — этот параметр отвечает за отображение сообщения при каждом завершении очередного процента задания и позволяет отслеживать ход выполнения. Если процент не задан, то SQL Server выдает сообщение после каждых выполненных 10 процентов. Можете указать любой удобный для вас шаг.

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

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

Вот как это выглядит на скриншоте:

При желании вы можете сохранить данные журнала в таблице.

В итоге у вас будет несколько шагов по количеству баз (обратите внимание на параметры поведения выполнения шагов скрипта «При успехе» и «При ошибке»):

Так же тут же можно указать начальный шаг, внизу формы.

После запуска задания на выходе (так как у нас 2 шага по резервному копированию двух баз) мы на выходе получим два файла:

Так же не забываем указать время выполнения:

и при необходимости дополнительные уведомления:

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

xcopy D:\backup\*.bak \\supercomp\baza$\ /V
forfiles /P D:\backup\ /S /M *.bak /D -5 /c «cmd /c del /q /f @file»

Мы копируем с помощью команды xcopy из папки backup с диска D в сетевую папку файлы с расширением *.bak на компьютер с эпичным названием supercomp 😂

Далее с помощью команды forfiles мы в папке /P D:\backup\ по маске /M *.bak удаляем файлы старше 5 дней /D -5 с помощью внешней команды /c «cmd /c del /q /f @file»

Этот скрипт можно поместить в cmd файл и добавить в планировщик заданий. На этом всё.

Для построения скриптов SQL всегда можно заглянуть в эту шпаргалку: https://docs.microsoft.com/ru-ru/sql/

Просмотров:
379

Восстановление базы 1С из бэкапа MS SQL

Модели восстановление базы данных в MS SQL существует две «простая» и «полная». Отличаются они тем, что в полной модели восстановления ведется еще и бэкап журнала транзакций. Рассмотрим восстановление базы 1С в MS SQL на примере простой модели восстановления.

Бэкапы баз данных MS SQL хранятся в файлах с расширением .bak. Сами бэкапы баз тоже бывают двух типов: полный бэкап и разностный бэкап. В полном бэкапе содержится полная копия базы данных, а в разностном только изменения внесенные в базу с момента полного бэкапа.

Восстанавливаем полный бэкап.

В Microsoft SQL Server Managment Studio создаем базу данных в которую будет выполнятся восстановление. Как настроить базу в MS SQL для 1С рассмотренно здесь.

Выбираем созданную базу и в контекстном меню переходим Задачи — Восстановить — База данных.

Выбираем источник восстановления «С устройства» и указываем путь к файлу бэкапа. После добавления файла бэкапа отмечаем галочкой набор данных для восстановления.

Слева в меню «Выбор страницы» переходим к пункту «Параметры». В пункте параметры восстановления отмечаем «Перезаписать существующую базу данных (WITH REPLACE)».

Если восстанавливаете только полный бэкап, то в разеде состояние восстановления оставляем пункт «Оставить базу готовой к использованию»

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

Жмем ОК и дожидаемся сообщения о завершении восстановления.

Восстанавливаем разностный бэкап.

Снова в целевой базу данных выбираем из контекстного меню Задачи — Восстановить — База данных.

Указываем источник восстановления. Выбираем файл .bak разностного бэкапа.

На странице Параметры настройки оставляем как есть. В разделе «Состояние восстановления» отмечен пункт «Оставить базу готовой к использованию…».

Жмем ОК, дожидаемся завершения и переходим к добавлению базы на сервер 1С.

Добавляем базу на сервер 1С.

Запускаем в 1С настройку добавление информационной базы и выбираем пункт «Создание новой информационной базы»

На следующем шаге должен быть отмечен пункт «Создание информационной базы без конфигурации..»

Вписываем имя базы и указываем тип расположения информационной базы «На сервере 1С предприятия»

Указываем настройки для подключения к базе сервера MS SQL

Далее оставляем настройки как есть и жмем Готово. База добавлена —  запускаем 1С и проверяем работоспособность.

резервное копирование базы данных (практика)

А вы даже не знаете, в какой банк ушли деньги. И никто вам о…

через несколько месяцев работник придёт и спросит, где его З…

С чего вы взяли? Не надо окружающих считать за идиотов, знае…

А чья будет проблема, если деньги сотруднику были переведены…

Ну как- если на бомжа или на грузчика этой организации изнач…

Это в случае реорганизации

Добрый день, нужно ли составлять доп.соглашения к ТД при каж…

Я в курсе) Но я то имела в виду допросы не ифнс.

он спамом занимается, я не подписывалась на его рассылку, од…

Эксперимент «цифровой концлагерь».

Вообще-то налоговая давным-давно активно практикует допросы …

Закрываются и фирмы, работающие годами. Вы с ними работали-р…

товарищ Са… ах какой жених!

Интрига

видимо остальные 80% считают, что работать вообще вредно для…

потому что у меня ассоциируется)

К контрагентам, которые быстро закрываются, не первый год по…

А, что у Вас за мнение, вообще не понятно. Вы считаете что н…

Ну да… Дома готовка, уборка, уход за детьми или пожилыми р…

А, вы то откуда знаете заплатил он или нет? Вы ясновидящий ч…

В идеальном мире возможно)) А вот в реальном — со всеми проб…

А Вы подумали куда по НДС вызвали?

Никаких чудес, стандартная нынче ситуация — налоговики нашли…

А если бы сумма была не 6 тыс., а 6 млн.? Стали бы спорить? …

Вы читать умеете? То тыкаете мне половиной фразы, то мои сло…

Вы предлагаете не реагировать на требования ФНС, что ли? Оба…

И где вероятность то? Чем больше, тем больше это прямая зави…

неужели у Вас всё это выслушивают? включая вероятности?мои п…

Разница в том, что вы реагируете на предложения, просто пото…

это Вы ещё Администраций не видели. всех уровней. Вот где &q…

И раньше, всегда так было. Титов ни одной инициативы хорошей…

Так сейчас многие минимально все понимают — знают, что без О…

Так о том и речь идет. Как Вы можете предсказать, что Вам з…

Дичь какая- то написана в статье. Любые выплаты работнику пр…

1C — BackUp 1С автоматически

Еще пару слов о копиях баз 1С

В одной из предыдущих статей мы подробно рассматривали вопрос создания копии базы данных 1С (бэкап 1с), используя универсальное средство для файловой и клиент-серверной базы — выгрузку/загрузку информационной базы. Хотя позиция фирмы «1С» говорит нам о том, что получаемый файл dt,  не может считаться полноценным «зеркалом» — точной копией базы, поскольку в процессе загрузки файла происходят некоторые технологические операции, которые в некоторых случаях даже исправляют ошибки в базе 1С. Но об этом пойдет речь в других статьях.

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

Итак, разберем какие же инструменты есть у нас для автоматизации создания копии базы.

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

Резервная копия 1С в файловом режиме работы

Самый просто вариант — использовать встроенный  механизм резервного копирования и восстановления, которые предлагают нам современные конфигурации на управляемых формах. Настроить его, даже у не очень опытного пользователя, не составит усилий, внимательно читая наши рекомендации и советы. Для начала вам нужно найти подраздел (пункт меню) «Поддержка и администрирование», он располагается в разделе «Администрирование» либо в разделе «НСИ и администрирование» в зависимости от используемой конфигурации.

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

Второй вариант настройки автоматического архива 1С  — обеспечить сохранение и архивирование файла базы данных 1Cv8.1CD, который находится в каталоге расположение информационной базы. Посмотреть где находится каталог можно на форме списка информационных баз. Сразу скажем, что всю папку архивировать совсем не нужно. Достаточно один файл «1Cv8.1CD». Остальные каталоги содержать временные файлы, которые вам не пригодятся при восстановлении базы. Для этих целей можно использовать любые программы резервного копирования данных, которые, как правило, поддерживают настройку расписания. Вполне неплохой вариант в плане надежности, но для рядового пользователя может показаться сложным. Поэтому мы будем рекомендовать универсальный способ, описанный ниже. 

Третий вариант настройки автоматического архива 1С — использовать планировщик заданий Windows. В нём можно настроить расписание, по которому будет вызываться простой BAT — файл, следующего содержания:

«M:\Program Files\1cv8\8.3.9.1850\bin\1cv8.exe» DESIGNER /S»server1\DataBaseName» /N»ИмяПользователя» /P»ПарольПользователя» /DUMPIB»N:\DataBaseCopy.dt»

Где «M:\Program Files\1cv8\8.3.9.1850\bin\1cv8.exe» — путь к файлу запуска 1С, «server1\DataBaseName» — имя базы данных в кластере серверов, «ИмяПользователя» — имя пользователя с административными правами, «ПарольПользователя» — пароль пользователя, «N:\DataBaseCopy.dt» — путь и имя файла сохранения копии 1С.

Подробнее узнать про параметры командной строки 1С можно здесь. 

Резервная копия 1С в клиент-серверном режиме работы

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

Важным плюсом создания резервной копии базы средствами СУБД является то, что копирование можно производить «на лету» — на надо завершать работу всех пользователей в системе, можно забыть о монопольном режиме.

Пока, достаточно будет сказать, что процесс настройки зависит от используемой СУБД. Напомним, что 1С 8 поддерживает работу со следующими СУБД:

• MS SQL Server
• PostgreSQL
• IBM DB2
• Oracle Database

Наша практика показывает, что именно первые две являются самыми используемыми СУБД для 1С. PostgreSQL безусловно привлекает тем, что это полностью бесплатный продукт. MS SQL Server широко используется во многих организациях, при этом для небольших компаний вполне подойдет бесплатная версия Express. Oracle Database будет выбором для крупных организация, которые, скорей всего остановят свой выбор на конфигурации 1C ERP. 

Пару слов стоит сказать о MySql и 1С. MySql активно используется в web-технологиях, но нет, данная СУБД не поддерживается 1С. На ней невозможно развернуть базу. К сожалению, даже системные администраторы со стажем иногда путают MS SQL и MySql. 

Вернемся к настройке резервного копирования средствами СУБД.  В MS SQL необходимо будет настроить план обслуживания. Сделать это можно через MS SQL Managment Studio. Достаточно развернуть группу с сервером, далее управление (management), план обслуживания (maintenance plan) и создать новый план. Подробно рассматривать настройки здесь не будем. Специалист должен разобраться, а не специалисту делать это не рекомендуем. Если же вы используете версию MS SQL Express, то план обслуживания, увы, не входит в эту поставку. Поэтому придется писать скрипт и настраивать планировщик задач windows. 

Что касается СУБД PostgreSQL, настраивать вам автоматическое резервное копирование вам придется также вручную, обладая определенными знаниями и опытов в этом деле. Подробнее о настройке резервного копирования Postgre сервер для ОС win можно почитать здесь.

Универсальное средство для создания архива 1С для всех режимов работы

И напоследок, мы оставили самый удобный способ создания и настройки автоматического резервного копирования на взгляд do-1C — использование специального приложения Effector Saver. Эта статья не нацелена на рекламу данного ПО, мы подробно рассмотрели все варианты. Но в своей практике, мы, в том числе, используем именно этот инструмент. Давайте просто кратко перечислю плюсы:

• Есть рабочая и вполне функциональная БЕСПЛАТНАЯ версия
• Применяется для любого режима работы: файловый, клиент-серверный
  • Поддерживает СУБД MS SQL и PostgreSQL

• Запуск по расписанию —  ночная копия базы автоматически каждый день! 
• Работа с любой версией 1С: 7.7; 8.1-8.3
• Множество удобных настроек упрощающих жизнь пользователя

 Настройка Effector Saver для создания резервных копий 1С

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

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

После этого проверьте сервисные настойки. Для этого нажмите кнопку в крайнем верхнем углу «Сервис» —> «Параметры программы». Прежде всего проверьте закладку «Параметры запуска». Запустите агент как приложение или как сервис. Запустите монитор (монитор будет отображаться в системном трее, у часов, в правом-нижнем углу экрана). Также, рекомендуем установить пароль на вход в менеджер. Сделать это можно на закладке «Параметры менеджере» —> кнопка «Установить».

Подводя итог, хочется сказать еще раз одну простую мысль — бэкапов (копий) много не бывает. Хотя, в IT кругах, мы часто слышим одну перефразированную шутку: «тормоза и бэкапы придумали трусы», но не стоит забывать — это только шутка. Целостность  и безопасность баз 1С — в ваших руках! Если же данная статья показалась вам слишком слишком сложной и трудной для освоения — ничего страшного. Мы настроим архивирование баз 1С и выполним любые другие работы по 1С быстро и качественно, за разумную цену. Звоните! 

Настройка задачи резервного копирования базы 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 отсутствует.

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

Далее устанавливаем флаг «Автоматически удалять устаревшие резервные копии» и заполняем параметр «Хранить количество копий». Нажимаем «ОК».

Переходим во вкладку «Файл архива». Поле «Имя файла архива:» оставим незаполненным, чтобы оно формировалось из наименования задачи и окончания имени архива.
Далее, установим флаг «Шифровать файл архива» и заполним поля «Пароль:» и «Подтверждение:». Так, файлы будут защищены внутри архива и при попытке открыть его будет запрошен пароль.

Переходим во вкладку «Расписание автозапуска». Устанавливаем флаг «Запускать по расписанию». В поле «Периодичность:» из списка выбираем периодичность запуска задачи. В поле «Время начала:» указываем время запуска задачи. Нажимаем «Сохранить».

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

После завершения работы задачи во вкладке «Журнал задач» отобразятся дата и результат выполнения.
Для подробного просмотра результата выполнения задачи, выберем в меню «Журнал задач» — «Открыть запись», или клик мыши по записи выполнения задачи.

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

Резервное копирование

SQL Server — модели и типы

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

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

Модели восстановления базы данных SQL Server

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

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

Системные базы данных

SQL Server специфичны в отношении моделей восстановления. Например, базы данных master, msdb, и tempdb привязаны к модели простого восстановления, а база данных model может использовать любую из моделей восстановления. Обратите внимание, что модель восстановления, используемая для модели базы данных, определяет, какая модель восстановления будет использоваться для вновь созданных пользовательских баз данных по умолчанию.

Модель полного восстановления

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

Модель восстановления с неполным протоколированием

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

Следующие операции считаются массовыми и минимально регистрируются при использовании модели восстановления с неполным протоколированием: BULK INSERT, операции, выполняемые с помощью утилиты командной строки BCP, частичное обновление больших типов данных с использованием предложения .WRITE, CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX (в случае, если требуется перестройка кучи) и OPENROWSET с поставщиком набора строк BULK

Модель простого восстановления

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

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

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

Типы резервного копирования базы данных SQL

Существует несколько типов резервного копирования базы данных SQL Server.Резервная копия базы данных может, но не обязательно, содержать всю базу данных. Это зависит от типа резервного копирования и вашей стратегии резервного копирования, которая может включать различные типы резервного копирования. Любую стратегию резервного копирования рекомендуется начинать с создания полной резервной копии базы данных.

Полная резервная копия базы данных SQL

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

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

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

Обратите внимание, что SQL Server выполняет резервное копирование только активных / используемых страниц данных, что означает, что размер резервной копии может быть значительно меньше, чем фактическая оперативная база данных.

Дифференциальное резервное копирование базы данных SQL

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

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

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

Резервные копии журнала транзакций SQL Server

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

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

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

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

Иван — специалист по SQL Server и компьютерный фанат с многолетним опытом работы в сфере ИТ и SQL Server. Он начал с компьютерных игр, продолжил программированием и системным администрированием. Он специализируется в области аварийного восстановления, аудита и соответствия SQL Server.

Просмотреть все сообщения Ивана Станковича

Последние сообщения Ивана Станковича (просмотреть все)

.

Операции резервного копирования и восстановления базы данных SQL Server с использованием облака

В этой статье обсуждается концепция резервного копирования SQL Server и различные компоненты, необходимые для использования службы хранилища BLOB-объектов Microsoft Azure в качестве цели для резервного копирования. Как мы все знаем, диски и ленты были предпочтительным местом назначения по умолчанию до появления облачной платформы. В дополнение к этому, теперь мы можем расширить встроенные функции резервного копирования SQL Server в облачное хранилище; хранилище BLOB-объектов Windows Azure.Эта функция была впервые добавлена ​​в SQL Server 2012. В целом функции резервного копирования и восстановления в облако и из облака аналогичны использованию диска или ленты с очень небольшими отличиями.

Резервное копирование базы данных SQL Server в хранилище BLOB-объектов Azure — это процесс, который работает почти как устройство резервного копирования, такое как диск или лента. Во время процесса резервного копирования или восстановления URL-адрес выбирается в качестве «типа устройства», который, в свою очередь, запускает клиентский процесс VDI (интерфейс виртуального устройства резервного копирования). Процесс действует как промежуточный агент для отправки резервной копии базы данных в хранилище BLOB-объектов Azure.

В этой статье мы затрагиваем следующие темы:

1. Создание учетной записи хранения Azure
2. Настройка контейнера для хранения
3. Создание учетных данных для авторизации с использованием SSMS и T-SQL
4. Использование графического интерфейса для выполнения резервного копирования и восстановления базы данных
5. Использование сценария T-SQL для резервного копирования и восстановления базы данных
6. Реализация функции резервного копирования и восстановления с помощью PowerShell.
7. И более…

Прежде чем мы выполним резервное копирование базы данных, важно понять ключевые компоненты службы хранилища BLOB-объектов и SQL Server, а также их концепции.Для начала давайте сделаем небольшую подготовительную работу для настройки Microsoft Azure. Создайте учетную запись хранилища Azure. На первом этапе мы создаем учетную запись хранения на портале Azure. Используя службу хранилища BLOB-объектов, мы настраиваем контейнер хранилища BLOB-объектов Azure.

Затем давайте рассмотрим компоненты SQL Server.

• URL-адрес — это уникальный идентификатор, используемый для каждого файла резервной копии.
• Учетные данные SQL Server используются для аутентификации ресурсов.Процесс резервного копирования и восстановления должен использовать эти учетные данные для проверки подлинности службы хранилища больших двоичных объектов и связанных с ней контейнеров.
• На последнем этапе выполните резервное копирование в облачное хранилище. Шаги почти такие же, как и для всех других резервных копий, хотя и с несколькими дополнительными параметрами конфигурации.

Пошаговые инструкции по настройке хранилища BLOB-объектов Azure

1. Сначала войдите на портал Azure.
2. Найдите Учетные записи хранения на левой панели, нажмите Создать учетные записи хранения
   1. В этом разделе рассматривается создание учетной записи хранения, чтобы иметь возможность выбрать требуемую модель, которая напрямую влияет на стоимость в зависимости от использования.
   2. Назовите учетную запись; в нашем примере мы будем использовать sqlshackdemo . Следующим шагом является назначение этой учетной записи хранения группе ресурсов. У нас есть два варианта; либо используйте существующую группу ресурсов, либо создайте новую. Давайте создадим новый для демонстрации и назовем его sqlshack .
   3. Затем выберите расположение в зависимости от того, где вы хотите разместить хранилище. (Я выбрал Восток США.) Нажмите кнопку Create .Подождите минуту или две, пока не будет создана учетная запись хранения.
      Для создания учетной записи хранения требуется следующая информация:
      1. Имя: sqlshackdemo; уникальное имя, все строчные буквы
      2. В этом случае для Типа учетной записи

      используется настройка по умолчанию.

      3. Настройка производительности по умолчанию — стандарт
      4. Настройка по умолчанию — Шифрование службы хранения — Включено
      5. Группа ресурсов — создайте новую группу ресурсов с именем sqlshack
      6. Select Location — выбрано East-US
      7. Проверьте штырь на приборной панели опция
      8. Нажмите кнопку Создать
   4. После создания учетной записи хранения нам потребуется подготовить хранилище BLOB-объектов.Сделать это,
      1. просмотрите учетную запись хранения, в колонке Обзор выберите параметр для создания хранилища BLOB-объектов.
      2. Щелкните Blobs . Откроется новое окно.
      3. Щелкните значок + контейнер , чтобы создать новый контейнер.
      4. Назовите контейнер; Я выбрал sqlshackbackup . Помните, что имя должно состоять только из строчных букв.
      5. Выберите Private в качестве типа доступа
      6. , а затем нажмите кнопку Create .

Теперь мы можем перейти к SQL Server и начать работу над созданием учетных данных, которые будут использоваться для аутентификации в учетной записи Azure. В окне Новый запрос используйте CREATE CREDENTIAL для создания учетных данных.

Свойство Identity — это имя учетной записи хранения.В данном случае это sqlshackdemo .

Ключ доступа — это секретный ключ учетной записи хранения. Чтобы найти ключ доступа, щелкните Настройки и выберите Ключи доступа в колонке Учетная запись хранения . Справа вы должны указать key1 , которая является ключом доступа, выберите значок Copy to clipboard . Сохраните эту ключевую информацию в надежном месте. Синтаксис для создания учетных данных следующий:

Теперь подготовьте T-SQL для резервного копирования базы данных по URL-адресу с помощью службы учетной записи хранения больших двоичных объектов и ключа доступа.В следующем примере запускается полное резервное копирование базы данных SQLShackDemoATC в хранилище BLOB-объектов (URL + Storage + Container + filename).

Проверьте вывод, просмотрев хранилище BLOB-объектов.Мы видим, что файл SQLShackDemoATC.bak существует в хранилище. Мы можем просмотреть URL-адрес файла, и этот указатель будет использоваться в следующем разделе для восстановления базы данных.

Для демонстрации я буду восстанавливать SQLShackDemoATC с другим именем SQLShackDemoATC_Clone в тот же экземпляр SQL.

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

Выполнение задачи резервного копирования базы данных с помощью SSMS (SQL Server Management Studio)

1. В обозревателе объектов просмотрите базы данных , щелкните правой кнопкой мыши базу данных, перейдите к Задачи и затем щелкните Резервное копирование…

2. На странице Общие перейдите в раздел Назначение .В раскрывающемся списке Резервное копирование до: выберите URL-адрес , а затем щелкните Добавить . Откроется диалоговое окно Select Backup Destination .

3. Щелкните Новый контейнер . Откроется страница Connect to Microsoft Subscription .

4. В раскрывающемся списке Выберите учетную запись хранения выберите учетную запись хранения.В данном случае это sqlshackdemo .

5. Аналогичным образом перейдите к Выберите контейнер Blob и выберите sqlshackbackupdemo

6. Щелкните ОК.

7. Теперь вы находитесь в окне мастера Резервное копирование базы данных . В поле назначения мы можем увидеть URL-адрес файла резервной копии в хранилище.

8. На следующем экране отображается ход резервного копирования.

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

Мы видим, что файл резервной копии был записан в хранилище BLOB-объектов. Это показывает нам, что резервную копию также можно сделать с помощью SSMS.

Затем это позволяет нам продемонстрировать шаги для выполнения резервного копирования базы данных по URL-адресу с помощью PowerShell.

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

1. Backup-SqlDatabase — используется для резервного копирования базы данных.
2. Restore-SqlDatabase — используется для восстановления резервной копии базы данных.
3. New-SqlCredential — используется для создания учетных данных SQL для аутентификации в хранилище BLOB-объектов Azure.
4. Get-SqlCredential — используется для получения существующих учетных данных.

Сводка

Три различных способа резервного копирования базы данных в URL-адрес были объяснены на примерах с использованием SSMS, T-SQL и PowerShell.

Запоминание

1. Рекомендуется использовать уникальные имена файлов для каждой резервной копии, чтобы предотвратить случайную перезапись BLOB-объектов.
2. Во время создания контейнера рекомендуется установить уровень доступа как частный, чтобы только пользователи или учетные записи, которые могут предоставить требуемые учетные данные, могли читать или записывать в большие двоичные объекты в контейнере.
3. Для баз данных SQL Server на экземпляре SQL Server, работающем на виртуальной машине Windows Azure, используйте учетную запись хранения в том же регионе, что и сама виртуальная машина, чтобы избежать расходов, связанных с передачей данных между регионами.Использование одного и того же региона также обеспечивает оптимальную производительность операций резервного копирования и восстановления.
4. Ошибки резервного копирования могут привести к получению неверного файла резервной копии. Мы рекомендуем периодически выявлять неудачные резервные копии и удалять файлы больших двоичных объектов. Дополнительные сведения см. В разделе Удаление файлов резервных больших двоичных объектов с активной арендой.
5. Использование опции WITH COMPRESSION во время резервного копирования может минимизировать затраты на хранение и транзакционные издержки хранения. Это также может сократить время, необходимое для завершения процесса резервного копирования.

Содержание

Список литературы

Я технолог по базам данных, имеющий более 11 лет богатого практического опыта работы с технологиями баз данных. Я являюсь сертифицированным специалистом Microsoft и имею степень магистра компьютерных приложений.

Моя специальность заключается в разработке и внедрении решений высокой доступности и кроссплатформенной миграции БД. В настоящее время разрабатываются технологии SQL Server, PowerShell, Oracle и MongoDB.

Посмотреть все сообщения от Prashanth Jayaram

Последние сообщения от Prashanth Jayaram (посмотреть все)

.

tsql — Почему я не могу создать резервную копию базы данных с помощью t-sql?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

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

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Как запланировать резервное копирование базы данных SQL Server 2016

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

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

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.