Часть 2. Настройка резервного копирования ms sql. Ошибки и заблуждения. Ms sql 2018 настройка резервного копирования
Настройка расписания и плана резервного копирования
Рекомендуем использовать Visual Studio 2017
Эта документация перемещена в архив и не поддерживается.
Visual Studio 2013
Если вы занимаетесь администрированием систем, вы уже знаете, почему наличие надежного набора резервных копий принципиально важно. Никто не хотел бы оказаться на месте администратора вышедшего из строя сервера, если нет полного набора резервных копий. К счастью, резервное копирование данных TFS можно выполнить с помощью средства «Плановые резервные копии» на консоли администрирования. Если регулярно создавать резервные копии этих баз данных, можно снизить риск потери данных или производительности из-за сбоя оборудования или других непредвиденных событий. В отличие от предыдущих методов, это средство также создает резервные копии баз данных SharePoint, используемых TFS, если TFS настроен для использования SharePoint.
Если используется выпуск SQL Server Enterprise или Datacenter и требуется восстановить базы данных конфигурации и коллекции до выпуска SQL Server Standard, перед выполнением резервного копирования необходимо отключить сжатие SQL Server, выполнив действия, описанные в следующей статье базы знаний Майкрософт. |
-
Если вы не являетесь администратором TFS, членом группы «Системный администратор SQL Server» и (если развертывание использует продукты SharePoint), членом группы «Администраторы фермы», получите соответствующие разрешения.
Кроме того, разрешение «Резервное копирование и создание планов обслуживания SQL Server» для учетной записи службы TFS (TFSService) должно иметь значение «Разрешить» на каждом экземпляре сервера SQL Server, где размещены копируемые базы данных, а также эта учетная запись должна иметь полный доступ к сетевой папке, папке или запоминающему устройству, где будут храниться резервные копии.
-
Откройте консоль администрирования TFS и на странице Плановые резервные копии запустите мастер для создания графика резервного копирования.
-
Резервные копии должны храниться в доступном по сети расположении, и учетная запись службы TFS должна иметь полный доступ к этому расположению, как и учетная запись, которая используется для настройки запланированного резервного копирования. Можно также выбрать, как долго будет храниться набор резервных копий и какие следует использовать расширения файлов для типов резервных копий.
-
Если на сервере настроена поддержка SMTP, можно получать оповещения об определенных событиях по электронной почте. В противном случае все варианты затемняются.
-
Можно выбрать один из двух графиков по умолчанию или создать собственный пользовательский график.
-
Выполните указания мастера. Если в развертывании используются отчеты, будет предложено ввести пароль, чтобы создать ключ шифрования для отчетов.
-
После настройки плановых резервных копий можно включить их выполнение по графику. Также можно выполнить резервное копирование немедленно. Будет создана резервная копия данных, а очередная копия будет создана по плану. Настоятельно рекомендуется воспользоваться этой возможностью, если запланированное резервное копирование произойдет нескоро или если у вас нет свежей резервной копии.
Примечание Если другой администратор решит выполнить немедленное резервное копирование, у него также должны быть права полного доступа для расположения, в которое сохранены резервные копии.
Ответ. Да. Можно вручную создавать планы резервного копирования. Узнать об этом подробнее можно здесь.
Ответ. Это делается с помощью средства «Восстановить», однако конкретные действия зависят от того, куда вам нужно восстановить данные: на новый сервер или на старый сервер.
technet.microsoft.com
Создание и восстановление резервной копии базы данных в Microsoft SQL Server – www.61bit.ru
Создание резервной копии
Восстановление резервной копии
В этой небольшой статье, мы разберем основные аспекты по созданию резервных копий в MS SQL. Статья будет полезна новичкам и людям которые сталкиваются с поддержкой 1с или MS SQL время от времени.
Создание резервной копии в Microsoft SQL server.
Для создания копии или восстановления базы, необходимо войти в оснастку «Microsoft SQL Server» SSMS. Для этого находим в Пуск-Все программы-SQL Server-Microsoft SQL Server либо Пуск-Выполнить-ssms.exe
Далее вводим данные для авторизации, они бывают двух типов.
Авторизация на основе проверки подлинности SQL. Данный тип использует внутреннюю базу пользователей SQL.
Авторизация на основе проверки подлинности Windows. Использует права предоставленные группе пользователей, например все Администраторы могут входить на основании своих прав в системе.
Далее в левой части находим пункт меню «Базы данных» и выбираем нужную нам базу.
Затем выберем пункт меню «Задачи-Создать резервную копию»
Далее выбираем «Тип резервной копии- Полная».
Назначение на «Диске» и добавляем месторасположение, куда необходимо сохранить созданную копию.
На вкладке «Параметры» указываем «Проверять резервную копию после завершения». Резервные копии можно сжимать для экономия места. Данная опция доступна не во всех версиях, и отсутствует к примеру в версии MS SQL Standart.
После нажимаем «Ок«, и ждем выполнения задачи. Если нет никаких помех для завершения задачи, то увидим сообщение о успешном создании копии.
Ошибки могут быть в случае, если произошло нарушение целостности базы либо из-за неверной рассчитанной контрольной суммы базы и свежесозданного файла. Этому могут способствовать ошибки системы или аппаратные неисправности. Эти случаи надо разбирать отдельно.
Восстановление базы из резервной копии
Для восстановления также необходим доступ в оснастку, все аналогично началу инструкции по созданию резервной копии. Этот шаг мы пропустим.
Выбираем нужную нам базу в списке слева.
Выбираем источником расположения набора «С устройства».
В открытом диалоговом окне выберем расположение файла резервной копии, в которую он был сохранен ранее или перемещен.
После нажатия «Ок». Попадем в диалоговое окно, там ставим флаг «Восстановить».
На вкладке параметры, указываем действия при восстановлении.
После завершения процесса, мы получим полностью рабочую базу.
Если остались вопросы, то Вы можете заказать настройку или консультацию по резервному копированию файлов базы данных, а также настройку более сложных регламентов для выполнения в MS SQL для нагруженных баз данных.
Часть 2. Настройка резервного копирования ms sql. Ошибки и заблуждения
Мы продолжаем цикл статей, посвященный типовым ошибкам и заблуждениям при настройке резервного копирования баз данных на Microsoft SQL Server. Начало см. Часть 1. Часть 1
Заблуждение: Зачем мне делать полный бэкап базы данных? достаточно просто скопировать файлы mdf и log!
У любой базы данных MS SQL есть как минимум два файла – данные, файл с расширением mdf, и журнал транзакций, файл с расширением log. Обрабатывая транзакции SQL Server постоянно синхронизирует информацию в этих файлах, поэтому они всегда находятся в заблокированном состоянии. Нет штатной возможности скопировать эти файлы у подключенной базы данных, даже если в ней никто не работает. Сторонние программы для бэкапирования файлов и образов также не могут скопировать эти файлы привычным образом, а фактически делают резервную копию инструкцией BACKUP DATABASE (обычно через VDI интерфейс). Часто это делается без ведома администратора, что нарушает цепочку резервных копий и является большим, неприятным, "сюрпризом" при попытке восстановления БД.
Ошибка: Резервные копии создаются на локальный диск, где находятся файлы с данными
Размещение резервных копий на одном диске вместе с файлами данных чревато тем, что при выходе жёсткого диска из строя у вас не будет ни файлов баз данных, ни их резервных копий. В независимости на сколько надежный у вас используется RAID, никогда не следует размещать резервные копии на одном физическом диске с файлами баз данных.
Заблуждение: для проверки созданной резервной копии достаточно выполнить команду RESTORE VERIFYONLY
Командой RESTORE VERIFYONLY можно проверить полноту резервной копии и возможность её считывания с диска. Обычно инструкция выполняется сразу после создания резервной копии. Однако необходимо знать, что команда RESTORE VERIFYONLY не проверяет структуру данных. Другими словами, успешное выполнение инструкции RESTORE VERIFYONLY не гарантирует, что реальное восстановление из резервной копии будет выполнено без ошибок. Есть только один 100% способ проверить резервные копии – попробовать восстановить из них. Поэтому рекомендуется периодически проверять резервные копии восстанавливая из них.
QMB позволяет автоматизировать процесс регулярной проверки резервных копий через восстановление. Причем такое восстановление может выполняться как на SQL Server источнике (во временную базу данных), так и на любом другом тестовом SQL Server.
Ошибка: Создание полного бэкапа, для передачи файла на сторону, и последующее его удаление
Довольно часто приходится сталкиваться с ситуацией, когда администратор создает свежую полную резервную копию (без параметра COPY_ONLY), чтобы передать её на сторону. При этом после передачи файл резервной копии удаляется, несмотря на то, что для базы данных используется полная модель восстановления и создаются резервные копии журнала транзакций. Таким образом, восстановление на актуальный момент времени становится не возможным. Необходимо помнить простое правило: Если у базы данных используется Полная модель восстановления, то создание полной резервной копии без параметра COPY_ONLY, начнет новую цепочку резервных копий. Этот файл нельзя удалять, до того момента пока не будет создана новая полная резервная копия. Если вы хотите создать полную резервную копию и удалить её после передачи, то создавайте её с параметром COPY_ONLY. В QMB для этого следует установить признак «Только для копирования» см. рис.
При создании XML плана восстановления QMB автоматически выполняет проверку физического наличия файлов резервных копий, необходимых для восстановления. Это позволяет превентивно выявлять подобные ошибки нехватки нужного файла.
qmbsql.ru
Управляемое резервное копирование SQL Server в Microsoft Azure
ОБЛАСТЬ ПРИМЕНЕНИЯ ЭТОЙ СТАТЬИ: SQL Server (начиная с 2016) База данных SQL Azure Хранилище данных SQL Azure Parallel Data Warehouse
Управляемое резервное копирование SQL Server в Microsoft Azure управляет резервным копированием SQL Server в хранилище BLOB-объектов Microsoft Azure и автоматизирует его. Серверу SQL Server можно разрешить определять расписание резервного копирования на основе рабочей нагрузки транзакций в базе данных. Кроме того, для настройки расписания можно воспользоваться дополнительными параметрами. Параметры хранения определяют продолжительность хранения резервных копий в хранилище BLOB-объектов Azure. Управляемое резервное копирование SQL Server в Microsoft Azure поддерживает восстановление на момент времени для указанного периода хранения.
Начиная с версии SQL Server 2016, процедуры и принцип действия Управляемое резервное копирование SQL Server в Microsoft Azure изменились. Дополнительные сведения см. в статье Migrate SQL Server 2014 Managed Backup Settings to SQL Server 2016.
Управляемое резервное копирование SQL Server в Microsoft Azure рекомендуется использовать для экземпляров SQL Server, работающих на виртуальных машинах Microsoft Azure. |
В настоящий момент автоматизация резервного копирования множества баз данных требует разработки стратегии резервного копирования, написания специального кода и планирования резервного копирования. С помощью Управляемое резервное копирование SQL Server в Microsoft Azureможно создать план резервного копирования, указав только период и место хранения. Хотя дополнительные параметры и доступны, они не требуются. Управляемое резервное копирование SQL Server в Microsoft Azure позволяет планировать резервное копирование, выполнять его и обслуживать резервные копии.
Управляемое резервное копирование SQL Server в Microsoft Azure можно настроить на уровне базы данных или экземпляра SQL Server. При настройке на уровне экземпляра также автоматически создаются резервные копии новых баз данных. С помощью параметров на уровне базы данных можно переопределить значения по умолчанию на уровне экземпляра в каждом конкретном случае.
Кроме того, резервные копии можно зашифровать, чтобы обеспечить дополнительную безопасность. Вы можете также настроить пользовательское расписание, чтобы управлять резервным копированием. Дополнительные сведения о преимуществах использования хранилища BLOB-объектов Windows Azure для резервных копий SQL Server см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.
Управляемое резервное копирование SQL Server в Microsoft Azure использует службу хранилища Microsoft Azure для хранения файлов резервных копий. Ниже приведены необходимые компоненты.
Учетная запись Microsoft Azure | Прежде чем просмотреть варианты приобретения , можно начать работу с Azure, используя бесплатную пробную версию. |
Учетная запись хранения Azure | Резервные копии хранятся в хранилище BLOB-объектов Azure, связанном с учетной записью хранения Azure. Чтобы создать учетную запись хранения, воспользуйтесь подробной пошаговой инструкцией в статье об учетных записях хранения Azure. |
Контейнер больших двоичных объектов | Для упорядочивания больших двоичных объектов используются контейнеры. Необходимо указать целевой контейнер для файлов резервных копий. Контейнер можно создать на портале управления Azureили с помощью команды New-AzureStorageContainer Azure PowerShell . |
Подписанный URL-адрес | Доступ к целевому контейнеру зависит от подписанного URL-адреса. Общие сведения о SAS см. в статье Подписанные URL-адреса. Часть 1: общие сведения о модели SAS. Маркер SAS можно создать в коде или с помощью команды PowerShell New-AzureStorageContainerSASToken . Скрипт PowerShell, упрощающий этот процесс, см. в статье Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with Powershell(Упрощение создания учетных данных SQL с использованием маркера подписанного URL-адреса в службе хранилища Azure с помощью Powershell). Маркер SAS можно хранить в SQL Credential и использовать с Управляемое резервное копирование SQL Server в Microsoft Azure. |
SQL Server, агент | Чтобы компонент Управляемое резервное копирование SQL Server в Microsoft Azure работал, должен быть запущен агент SQL Server. Рекомендуется установить автоматический запуск. |
Transact-SQL — это основной интерфейс для взаимодействия с Управляемое резервное копирование SQL Server в Microsoft Azure. Системные хранимые процедуры используются для активации, настройки и отслеживания Управляемое резервное копирование SQL Server в Microsoft Azure. Системные функции используются для получения существующих параметров конфигурации, значений параметров и данных файлов резервных копий. Расширенные события используются для отображения ошибок и предупреждений. Механизмы предупреждений включаются с помощью заданий агента SQL Server и управления на основе политик SQL Server. Далее представлен список объектов и описание их функций по отношению к Управляемое резервное копирование SQL Server в Microsoft Azure.
Можно также настроить Управляемое резервное копирование SQL Server в Microsoft Azureс помощью командлетов PowerShell. SQL Server Management Studio поддерживает восстановление резервных копий, созданных Управляемое резервное копирование SQL Server в Microsoft Azure , с помощью задачи Восстановление базы данных .
Системный объект | Описание |
MSDB | Хранит метаданные, журнал резервного копирования для всех резервных копий, созданных Управляемое резервное копирование SQL Server в Microsoft Azure. |
managed_backup.sp_backup_config_basic (Transact-SQL) | Запускает компонент Управляемое резервное копирование SQL Server в Microsoft Azure. |
managed_backup.sp_backup_config_advanced (Transact-SQL) | Настраивает дополнительные параметры для Управляемое резервное копирование SQL Server в Microsoft Azure, например шифрование. |
managed_backup.sp_backup_config_schedule (Transact-SQL) | Создает пользовательское расписание для Управляемое резервное копирование SQL Server в Microsoft Azure. |
managed_backup.sp_ backup_master_switch (Transact-SQL) | Приостанавливает и возобновляет работу Управляемое резервное копирование SQL Server в Microsoft Azure. |
managed_backup.sp_set_parameter (Transact-SQL) | Включает и настраивает мониторинг для Управляемое резервное копирование SQL Server в Microsoft Azure. Примеры: включение расширенных событий, настроек почты для уведомлений. |
managed_backup.sp_backup_on_demand (Transact-SQL) | Выполняет резервное копирование ad-hoc для базы данных, которая использует Управляемое резервное копирование SQL Server в Microsoft Azure без нарушения цепочки журналов. |
managed_backup.fn_backup_db_config (Transact-SQL) | Возвращает текущее состояние Управляемое резервное копирование SQL Server в Microsoft Azure и значения конфигурации для базы данных или всех баз данных в экземпляре. |
managed_backup.fn_is_master_switch_on (Transact-SQL) | Возвращает состояние основного переключателя. |
managed_backup.sp_get_backup_diagnostics (Transact-SQL) | Возвращает события, записанные в журнал подсистемой расширенных событий. |
managed_backup.fn_get_parameter (Transact-SQL) | Возвращает текущие значения системных параметров резервного копирования, например параметры мониторинга и почтовые параметры для оповещений. |
managed_backup.fn_available_backups (Transact-SQL) | Извлекает доступные резервные копии заданной базы данных или всех баз данных в экземпляре. |
managed_backup.fn_get_current_xevent_settings (Transact-SQL) | Возвращает текущие параметры расширенных событий. |
managed_backup.fn_get_health_status (Transact-SQL) | Возвращает объединенное число ошибок, зарегистрированных подсистемой расширенных событий за указанный период. |
Расписание резервного копирования
С помощью системной хранимой процедуры managed_backup.sp_backup_config_schedule (Transact-SQL). Если не указать пользовательское расписание, тип запланированных резервных копий и частота резервного копирования определяются на основе рабочей нагрузки в базе данных. Настройки срока хранения определяют длительность хранения файлов резервных копий в хранилище и для восстановления базы данных на момент времени в течение срока хранения.
Соглашения об именовании файлов резервных копий
Управляемое резервное копирование SQL Server в Microsoft Azure использует указанный контейнер. Таким образом, вы можете выбрать имя контейнера. Имя файла резервной копии для баз данных, не являющихся базами данных доступности, задается в соответствии со следующим соглашением об именовании. Имя создается с использованием первых 40 символов имени базы данных, GUID базы данных без "-" и метки времени. Между сегментами в качестве разделителей вставляется подчеркивание. Для полной резервной копии используется расширение BAK , а для резервной копии журналов — LOG . Для баз данных группы доступности в дополнении к схеме именования, описанной выше, после 40 символов имени базы данных добавляется GUID группы доступности. Значение GUID базы данных группы доступности — это значение для group_database_id в sys.databases.
Полная резервная копия базы данных
Управляемое резервное копирование SQL Server в Microsoft Azure планирует полную резервную копию базы данных, если выполняется одно из следующих условий.
Функция Управляемое резервное копирование SQL Server в Microsoft Azure включается для базы данных впервые, или функция Управляемое резервное копирование SQL Server в Microsoft Azure активируется с параметрами по умолчанию на уровне экземпляра.
Увеличение журнала после создания полной резервной копии не меньше 1 ГБ.
Максимальный интервал времени (1 неделя) прошел с момента последнего полного резервного копирования.
Цепочка журналов прервана. Управляемое резервное копирование SQL Server в Microsoft Azure периодически проверяет, сохранилась ли цепочка журналов, сравнивая первый и последний номера LSN файлов резервной копии. Если по какой-то причине цепочка журналов прервана, Управляемое резервное копирование SQL Server в Microsoft Azure планирует полное резервное копирование базы данных. Самая распространенная причина разрыва цепочки журналов — выполнение команды резервного копирования с помощью Transact-SQL или задачи резервного копирования в SQL Server Management Studio. К другим возможным причинам относится случайное удаление фалов журнала резервного копирования или случайная перезапись резервных копий.
Резервная копия журналов транзакций
Управляемое резервное копирование SQL Server в Microsoft Azure планирует резервную копию журналов, если выполняется одно из следующих условий.
Не удается обнаружить историю резервного копирования журналов. Это условие обычно выполняется, если Управляемое резервное копирование SQL Server в Microsoft Azure включается впервые.
Используемый объем журнала транзакций равен 5 МБ или больше.
Достигнут максимальный интервал времени (2 часа) с момента создания последней резервной копии журналов.
Каждый раз, когда резервная копия журнала транзакций отстает от полной резервной копии базы данных, целью является сохранение цепочки журналов до полной резервной копии.
При включении резервного копирования необходимо задать срок хранения в днях. Минимальное значение — 1 день, максимальное — 30 дней.
Управляемое резервное копирование SQL Server в Microsoft Azure оценивает возможность восстановления базы данных на момент времени в течение заданного периода, чтобы определить, какие файлы резервной копии необходимо сохранить, а какие — удалить. Параметр backup_finish_date резервной копии используется для определения и сопоставления времени, заданного настройками срока хранения.
Если для базы данных выполняется текущее задание полного резервного копирования базы данных, Управляемое резервное копирование SQL Server в Microsoft Azure ожидает завершения текущего задания до перехода к следующему заданию полного резервного копирования этой же базы данных. Аналогичным образом в заданный момент времени может выполняться только одно задание резервного копирования журнала транзакций. Однако операции полного резервного копирования базы данных и резервного копирования журнала транзакций могут выполняться одновременно. Ошибки записываются в журнал как расширенные события.
Если запланировано больше 10 параллельных операций полного резервного копирования базы данных, через канал отладки расширенных событий передается предупреждение. Управляемое резервное копирование SQL Server в Microsoft Azure хранит очередь приоритетов для оставшихся баз данных, для которых нужно создать резервные копии, пока все операции резервного копирования не будут запланированы и завершены.
Ниже приведены ограничения и рекомендации, связанные SQL Server 2016.
Поддерживается резервное копирование системных баз данных master, model и msdb. Резервное копирование tempdb не поддерживается.
SQL Server 2016поддерживает все модели восстановления (модель полного восстановления, модель восстановления с неполным протоколированием и простую модель восстановления).
Управляемое резервное копирование SQL Server в Microsoft Azure поддерживает только полные резервные копии базы данных и резервные копии журналов. Автоматическое резервное копирование файлов не поддерживается.
Хранилище BLOB-объектов Microsoft Azure — единственное поддерживаемое хранилище резервных копий. Резервные копии на диски или ленточные накопители не поддерживаются.
Управляемое резервное копирование SQL Server в Microsoft Azure использует функцию резервного копирования в блочные BLOB-объекты. Максимальный размер блочного BLOB-объекта составляет 200 ГБ. За счет чередования максимальный размер отдельной резервной копии можно увеличить до 12 ТБ. Если вам нужен больший размер, рекомендуется использовать сжатие и проверить размер файла резервной копии до настройки Управляемое резервное копирование SQL Server в Microsoft Azure. Проверку можно выполнить, создав резервную копию на локальном диске или создав ее вручную в службе хранилища Microsoft Azure с использованием инструкции Transact-SQL BACKUP TO URL . Дополнительные сведения см. в разделе SQL Server Backup to URL.
Управляемое резервное копирование SQL Server в Microsoft Azure может накладывать определенные ограничения, если она настроена с другими технологиями, поддерживающими резервное копирование, высокий уровень доступности и аварийное восстановление.
technet.microsoft.com
Настройка дополнительных параметров управляемого резервного копирования SQL Server в Microsoft Azure
Опубликовано: Август 2016
В этом руководстве описана настройка дополнительных параметров для Управляемое резервное копирование SQL Server в Microsoft Azure. Эти процедуры необходимы, только если вам нужны соответствующие функции. В противном случае вы можете включить Управляемое резервное копирование SQL Server в Microsoft Azure и использовать параметры по умолчанию.
В каждом сценарии резервное копирование настраивается с использованием параметра database_name . Если для database_name указать значение NUL или *, изменения затронут параметры по умолчанию на уровне экземпляра. Параметры на уровне экземпляра будут применены и к новым базам данных, созданным после такого изменения.
После настройки этих параметров вы сможете включить управляемое резервное копирование для базы данных или экземпляра с помощью системной хранимой процедуры managed_backup.sp_backup_config_basic (Transact-SQL). Дополнительные сведения см. в статье Enable SQL Server Managed Backup to Microsoft Azure.
Прежде чем включать Управляемое резервное копирование SQL Server в Microsoft Azure, нужно обязательно настроить дополнительные параметры и пользовательские параметры планирования, используя процедуру managed_backup.sp_backup_config_basic (Transact-SQL). В противном случае могут быть запущены нежелательные операции резервного копирования в период между активацией Управляемое резервное копирование SQL Server в Microsoft Azure и настройкой параметров. |
Следующие шаги описывают настройку параметров шифрования с помощью хранимой процедуры managed_backup.sp_backup_config_advanced (Transact-SQL).
Выберите алгоритм шифрования: прежде всего определитесь с алгоритмом шифрования, который вы будете использовать. Выберите один из следующих вариантов.
AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION
Создайте главный ключ базы данных: выберите пароль для шифрования копии главного ключа, которая будет храниться в базе данных.
USE Master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master key password>'; GOСоздайте резервную копию сертификата или асимметричного ключа: вы можете использовать для шифрования как сертификат, так и асимметричный ключ. Следующий пример демонстрирует создание сертификата, который будет использован для шифрования.
USE Master; GO CREATE CERTIFICATE MyTestDBBackupEncryptCert WITH SUBJECT = 'MyTestDBBackupEncryptCert'; GOНастройте шифрование управляемого резервного копирования: запустите хранимую процедуру managed_backup.sp_backup_config_advanced с соответствующими значениями. Следующий пример настраивает для базы данных MyDB шифрование с использованием сертификата с именем MyTestDBBackupEncryptCert и алгоритма шифрования AES_128 .
USE msdb; GO EXEC managed_backup.sp_backup_config_advanced @database_name = 'MyDB' ,@encryption_algorithm ='AES_128' ,@encryptor_type = 'CERTIFICATE' ,@encryptor_name = 'MyTestDBBackupEncryptCert'; GOПредупреждение Если в предыдущем примере указать для @database_name значение NULL, параметры будут применены к экземпляру SQL Server.
Следующие шаги описывают настройку параметров шифрования с помощью хранимой процедуры managed_backup.sp_backup_config_schedule (Transact-SQL).
Определите частоту полного резервного копирования: выберите, как часто будут создаваться полные резервные копии базы данных. Для полного резервного копирования доступны варианты "ежедневно" и "еженедельно".
Определите частоту резервного копирования журналов: выберите, как часто будут создаваться резервные копии журналов. Это значение задается в часах или минутах.
Определите день недели для еженедельного резервного копирования: если вы настроили "еженедельное" резервное копирование, выберите день недели для создания полной резервной копии.
Определите время начала резервного копирования: выберите время запуска резервного копирования в 24-часовом формате.
Определите продолжительность резервного копирования: здесь нужно указать время, необходимое для создания резервной копии.
Установите пользовательское расписание резервного копирования: следующая хранимая процедура позволяет задать пользовательское расписание для базы данных MyDB . Полные резервные копии создаются еженедельно в Monday в 17:30. Резервные копии журналов создаются каждые 5 минут. Резервное копирование выполняется не более двух часов.
USE msdb; GO EXEC managed_backup.sp_backup_config_schedule @database_name = 'MyDB' ,@scheduling_option = 'Custom' ,@full_backup_freq_type = 'Weekly' ,@days_of_week = 'Monday' ,@backup_begin_time = '17:30' ,@backup_duration = '02:00' ,@log_backup_freq = '00:05' GO
После настройки дополнительных параметров и пользовательского расписания следует включить Управляемое резервное копирование SQL Server в Microsoft Azure для целевой базы данных или экземпляра SQL Server. Дополнительные сведения см. в статье Enable SQL Server Managed Backup to Microsoft Azure.
Управляемое резервное копирование SQL Server в Microsoft Azure
technet.microsoft.com
Настройка резервного копирования в репликах доступности (SQL Server)
В этом разделе описывается настройка резервной копии вторичной реплики для группы доступности AlwaysOn с помощью среды SQL Server Management Studio, Transact-SQL или PowerShell в SQL Server 2016.
Перед началом работы выполните следующие действия.
Предварительные требования
Безопасность
Настройка резервного копирования во вторичных репликах с помощью:
Среда SQL Server Management Studio
Transact-SQL
PowerShell
Дальнейшие действия. После настройки резервного копирования во вторичных репликах
Получение сведений о параметрах настройки резервного копирования
См. также
Предварительные требования
Необходимо подключиться к экземпляру сервера, на котором размещена первичная реплика.
Безопасность
Разрешения
Настройка резервного копирования во вторичных репликах при создании группы доступности | Требуется членство в фиксированной роли сервера sysadmin и одно из разрешений: CREATE AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP или CONTROL SERVER. |
Изменение группы доступности или реплики доступности | Необходимо разрешение ALTER AVAILABILITY GROUP для группы доступности, разрешение CONTROL AVAILABILITY GROUP, разрешение ALTER ANY AVAILABILITY GROUP или разрешение CONTROL SERVER. |
Настройка резервного копирования во вторичных репликах
В обозревателе объектов подключитесь к экземпляру сервера, на котором размещена первичная реплика, и щелкните имя сервера, чтобы развернуть его дерево.
Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности.
Щелкните группу доступности, для которой нужно задать параметры резервного копирования, и выберите команду Свойства .
В диалоговом окне Свойства групп доступности перейдите на страницу Настройки резервного копирования .
На панели Где должно происходить резервное копирование? выберите один из способов автоматизированного резервного копирования для группы доступности:
Предпочтение вторичнойУказывает, что резервное копирование должно выполняться на вторичной реплике, за исключением тех случаев, когда в режиме «в сети» находится только первичная реплика. В этом случае резервное копирование будет выполняться на первичной реплике. Это параметр по умолчанию.
Только вторичнаяУказывает, что резервное копирование никогда не выполняется на первичной реплике. Если первичная реплика является единственной репликой, находящейся в режиме «в сети», резервное копирование не будет выполняться.
ПервичнаяУказывает, что резервное копирования должно всегда выполняться на первичной реплике. Данный параметр является полезным, если вам требуются такие функции резервного копирования, как создание разностных резервных копий, которые не поддерживаются при выполнении резервного копирования на вторичной реплике.
Важно Если планируется использовать доставку журналов для подготовки баз данных-получателей для группы доступности, задайте параметру автоматизированного резервного копирования значение Первичная до тех пор, пока все базы данных-получатели не будут подготовлены и присоединены к группе доступности.
Любая репликаУказывает, что вы предпочитаете, чтобы задания резервного копирования пропускали реплики доступности при выборе реплики для создания резервных копий. Примечание. Задания резервного копирования могут учитывать другие факторы, например приоритет резервного копирования каждой реплики доступности в сочетании с ее состоянием работоспособности и подключения.
Важно Принудительного применения параметра автоматического резервного копирования не существует. Интерпретация данного приоритета зависит от логики (при ее наличии), которая внесена в задания резервного копирования для баз данных в указанной группе доступности. Параметр автоматического резервного копирования не влияет на выполнение нерегламентированного резервного копирования. Дополнительные сведения см. в разделе Дальнейшие действия. После настройки резервного копирования во вторичных репликах ниже в этой статье.
Сетка Настройки резервного копирования реплики позволяет изменить приоритет резервного копирования для группы доступности. В этой сетке отображается текущий приоритет резервного копирования каждого экземпляра сервера, на котором размещена реплика, входящая в данную группу доступности. Сетка содержит следующие столбцы.
Экземпляр сервераИмя экземпляра SQL Server, в котором размещается группа доступности.
Приоритет резервного копирования (низкий = 1, высокий = 100)Указывает приоритет выполнения резервного копирования на данной реплике по отношению к другим репликам из той же группы доступности. Значение представляет собой целое число в диапазоне от 0 до 100. 1 указывает минимальный приоритет, 100 — наивысший приоритет. Если Backup Priority = 1, реплика доступности будет выбрана для создания резервных копий только в случае, если реплики доступности с более высоким приоритетом отсутствуют.
Исключить репликуУстановите этот параметр, чтобы реплика никогда не выбиралась для выполнения резервного копирования. Этот параметр может быть полезным, например, для исключения удаленной реплики доступности, создание резервных копий на которой нежелательно.
Для фиксации изменений нажмите кнопку ОК.
Альтернативные пути доступа к странице настройки резервного копирования
Настройка резервного копирования во вторичных репликах
Подключитесь к экземпляру сервера, на котором находится первичная реплика.
Для новой группы доступности используйте инструкцию CREATE AVAILABILITY GROUP (Transact-SQL). При добавлении или изменении существующей группы доступности воспользуйтесь инструкцией ALTER AVAILABILITY GROUP (Transact-SQL).
Настройка резервного копирования во вторичных репликах
Установите значение по умолчанию (cd) равным серверу экземпляра, на котором размещена первичная реплика.
При необходимости настройте приоритет каждой реплики доступности, которую необходимо добавить или изменить. Этот приоритет используется экземпляром сервера, на котором размещается первичная реплика, при принятии решения о том, какая реплика должна обработать запрос автоматического резервного копирования для базы данных в группе доступности (выбирается реплика с максимальным приоритетом). Значением приоритета может быть любое целое число от 0 до 100 включительно. Приоритет 0 указывает, что реплика не должна считаться кандидатом на обработку запросов резервного копирования. Значение по умолчанию — 50.
При добавлении реплики доступности в группу доступности воспользуйтесь командлетом New-SqlAvailabilityReplica. При изменении существующей реплики доступности воспользуйтесь командлетом Set-SqlAvailabilityReplica. В любом случае укажите параметр BackupPriorityn , где n представляет собой значение от 0 до 100.
Например, следующая команда присваивает приоритету резервного копирования реплики доступности MyReplica значение 60.
Set-SqlAvailabilityReplica -BackupPriority 60 ` -Path SQLSERVER:\Sql\Computer\Instance\AvailabilityGroups\MyAg\AvailabilityReplicas\MyReplicaТакже настройте приоритет автоматического резервного копирования для группы доступности, которая создается или изменяется. Этот параметр указывает, как задание резервного копирования вычисляет первичную реплику при выборе места для создания резервных копий. Значение по умолчанию предпочитают вторичные реплики.
При создании группы доступности используйте командлет New-SqlAvailabilityGroup. При изменении существующей группы доступности используйте командлет Set-SqlAvailabilityGroup. В любом случае укажите параметр AutomatedBackupPreference .
где
ПервичнаяУказывает, что резервное копирования должно всегда выполняться на первичной реплике. Данный параметр является полезным, если вам требуются такие функции резервного копирования, как создание разностных резервных копий, которые не поддерживаются при выполнении резервного копирования на вторичной реплике.
Важно Если планируется использовать доставку журналов для подготовки баз данных-получателей для группы доступности, задайте параметру автоматизированного резервного копирования значение Первичная до тех пор, пока все базы данных-получатели не будут подготовлены и присоединены к группе доступности.
SecondaryOnlyУказывает, что резервное копирование никогда не выполняется на первичной реплике. Если первичная реплика является единственной репликой, находящейся в режиме «в сети», резервное копирование не будет выполняться.
ВторичнаяУказывает, что резервное копирование должно выполняться на вторичной реплике, за исключением тех случаев, когда в режиме «в сети» находится только первичная реплика. В этом случае резервное копирование будет выполняться на первичной реплике. Это поведение по умолчанию.
NoneУказывает, что вы предпочитаете, чтобы задания резервного копирования пропускали реплики доступности при выборе реплики для создания резервных копий. Примечание. Задания резервного копирования могут учитывать другие факторы, например приоритет резервного копирования каждой реплики доступности в сочетании с ее состоянием работоспособности и соединения.
Важно Параметр AutomatedBackupPreferenceне вводится в действие принудительно. Интерпретация данного приоритета зависит от логики (при ее наличии), которая внесена в задания резервного копирования для баз данных в указанной группе доступности. Параметр автоматического резервного копирования не влияет на выполнение н
technet.microsoft.com
Настройка резервного копирования в репликах доступности (SQL Server)
В этом разделе описывается настройка резервной копии вторичной реплики для группы доступности AlwaysOn с помощью среды SQL Server Management Studio, Transact-SQL или PowerShell в SQL Server 2016.
Перед началом работы выполните следующие действия.
Предварительные требования
Безопасность
Настройка резервного копирования во вторичных репликах с помощью:
Среда SQL Server Management Studio
Transact-SQL
PowerShell
Дальнейшие действия. После настройки резервного копирования во вторичных репликах
Получение сведений о параметрах настройки резервного копирования
См. также
Предварительные требования
Необходимо подключиться к экземпляру сервера, на котором размещена первичная реплика.
Безопасность
Разрешения
Настройка резервного копирования во вторичных репликах при создании группы доступности | Требуется членство в фиксированной роли сервера sysadmin и одно из разрешений: CREATE AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP или CONTROL SERVER. |
Изменение группы доступности или реплики доступности | Необходимо разрешение ALTER AVAILABILITY GROUP для группы доступности, разрешение CONTROL AVAILABILITY GROUP, разрешение ALTER ANY AVAILABILITY GROUP или разрешение CONTROL SERVER. |
Настройка резервного копирования во вторичных репликах
В обозревателе объектов подключитесь к экземпляру сервера, на котором размещена первичная реплика, и щелкните имя сервера, чтобы развернуть его дерево.
Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности.
Щелкните группу доступности, для которой нужно задать параметры резервного копирования, и выберите команду Свойства .
В диалоговом окне Свойства групп доступности перейдите на страницу Настройки резервного копирования .
На панели Где должно происходить резервное копирование? выберите один из способов автоматизированного резервного копирования для группы доступности:
Предпочтение вторичнойУказывает, что резервное копирование должно выполняться на вторичной реплике, за исключением тех случаев, когда в режиме «в сети» находится только первичная реплика. В этом случае резервное копирование будет выполняться на первичной реплике. Это параметр по умолчанию.
Только вторичнаяУказывает, что резервное копирование никогда не выполняется на первичной реплике. Если первичная реплика является единственной репликой, находящейся в режиме «в сети», резервное копирование не будет выполняться.
ПервичнаяУказывает, что резервное копирования должно всегда выполняться на первичной реплике. Данный параметр является полезным, если вам требуются такие функции резервного копирования, как создание разностных резервных копий, которые не поддерживаются при выполнении резервного копирования на вторичной реплике.
Важно Если планируется использовать доставку журналов для подготовки баз данных-получателей для группы доступности, задайте параметру автоматизированного резервного копирования значение Первичная до тех пор, пока все базы данных-получатели не будут подготовлены и присоединены к группе доступности.
Любая репликаУказывает, что вы предпочитаете, чтобы задания резервного копирования пропускали реплики доступности при выборе реплики для создания резервных копий. Примечание. Задания резервного копирования могут учитывать другие факторы, например приоритет резервного копирования каждой реплики доступности в сочетании с ее состоянием работоспособности и подключения.
Важно Принудительного применения параметра автоматического резервного копирования не существует. Интерпретация данного приоритета зависит от логики (при ее наличии), которая внесена в задания резервного копирования для баз данных в указанной группе доступности. Параметр автоматического резервного копирования не влияет на выполнение нерегламентированного резервного копирования. Дополнительные сведения см. в разделе Дальнейшие действия. После настройки резервного копирования во вторичных репликах ниже в этой статье.
Сетка Настройки резервного копирования реплики позволяет изменить приоритет резервного копирования для группы доступности. В этой сетке отображается текущий приоритет резервного копирования каждого экземпляра сервера, на котором размещена реплика, входящая в данную группу доступности. Сетка содержит следующие столбцы.
Экземпляр сервераИмя экземпляра SQL Server, в котором размещается группа доступности.
Приоритет резервного копирования (низкий = 1, высокий = 100)Указывает приоритет выполнения резервного копирования на данной реплике по отношению к другим репликам из той же группы доступности. Значение представляет собой целое число в диапазоне от 0 до 100. 1 указывает минимальный приоритет, 100 — наивысший приоритет. Если Backup Priority = 1, реплика доступности будет выбрана для создания резервных копий только в случае, если реплики доступности с более высоким приоритетом отсутствуют.
Исключить репликуУстановите этот параметр, чтобы реплика никогда не выбиралась для выполнения резервного копирования. Этот параметр может быть полезным, например, для исключения удаленной реплики доступности, создание резервных копий на которой нежелательно.
Для фиксации изменений нажмите кнопку ОК.
Альтернативные пути доступа к странице настройки резервного копирования
Настройка резервного копирования во вторичных репликах
Подключитесь к экземпляру сервера, на котором находится первичная реплика.
Для новой группы доступности используйте инструкцию CREATE AVAILABILITY GROUP (Transact-SQL). При добавлении или изменении существующей группы доступности воспользуйтесь инструкцией ALTER AVAILABILITY GROUP (Transact-SQL).
Настройка резервного копирования во вторичных репликах
Установите значение по умолчанию (cd) равным серверу экземпляра, на котором размещена первичная реплика.
При необходимости настройте приоритет каждой реплики доступности, которую необходимо добавить или изменить. Этот приоритет используется экземпляром сервера, на котором размещается первичная реплика, при принятии решения о том, какая реплика должна обработать запрос автоматического резервного копирования для базы данных в группе доступности (выбирается реплика с максимальным приоритетом). Значением приоритета может быть любое целое число от 0 до 100 включительно. Приоритет 0 указывает, что реплика не должна считаться кандидатом на обработку запросов резервного копирования. Значение по умолчанию — 50.
При добавлении реплики доступности в группу доступности воспользуйтесь командлетом New-SqlAvailabilityReplica. При изменении существующей реплики доступности воспользуйтесь командлетом Set-SqlAvailabilityReplica. В любом случае укажите параметр BackupPriorityn , где n представляет собой значение от 0 до 100.
Например, следующая команда присваивает приоритету резервного копирования реплики доступности MyReplica значение 60.
Set-SqlAvailabilityReplica -BackupPriority 60 ` -Path SQLSERVER:\Sql\Computer\Instance\AvailabilityGroups\MyAg\AvailabilityReplicas\MyReplicaТакже настройте приоритет автоматического резервного копирования для группы доступности, которая создается или изменяется. Этот параметр указывает, как задание резервного копирования вычисляет первичную реплику при выборе места для создания резервных копий. Значение по умолчанию предпочитают вторичные реплики.
При создании группы доступности используйте командлет New-SqlAvailabilityGroup. При изменении существующей группы доступности используйте командлет Set-SqlAvailabilityGroup. В любом случае укажите параметр AutomatedBackupPreference .
где
ПервичнаяУказывает, что резервное копирования должно всегда выполняться на первичной реплике. Данный параметр является полезным, если вам требуются такие функции резервного копирования, как создание разностных резервных копий, которые не поддерживаются при выполнении резервного копирования на вторичной реплике.
Важно Если планируется использовать доставку журналов для подготовки баз данных-получателей для группы доступности, задайте параметру автоматизированного резервного копирования значение Первичная до тех пор, пока все базы данных-получатели не будут подготовлены и присоединены к группе доступности.
SecondaryOnlyУказывает, что резервное копирование никогда не выполняется на первичной реплике. Если первичная реплика является единственной репликой, находящейся в режиме «в сети», резервное копирование не будет выполняться.
ВторичнаяУказывает, что резервное копирование должно выполняться на вторичной реплике, за исключением тех случаев, когда в режиме «в сети» находится только первичная реплика. В этом случае резервное копирование будет выполняться на первичной реплике. Это поведение по умолчанию.
NoneУказывает, что вы предпочитаете, чтобы задания резервного копирования пропускали реплики доступности при выборе реплики для создания резервных копий. Примечание. Задания резервного копирования могут учитывать другие факторы, например приоритет резервного копирования каждой реплики доступности в сочетании с ее состоянием работоспособности и соединения.
Важно Параметр AutomatedBackupPreferenceне вводится в действие принудительно. Интерпретация данного приоритета зависит от логики (при ее наличии), которая внесена в задания резервного копирования для баз данных в указанной группе доступности. Параметр автоматического резервного копирования не влияет на выполнение нерегламентированного резервного копирования. Дополнительные сведения см. далее в разделе Дальнейшие действия. После настройки резервного копирования во вторичных репликах .
Например, следующая команда задает свойству AutomatedBackupPreference группы доступности MyAg значение SecondaryOnly. Автоматическое резервное копирование баз данных в этой группе доступности никогда не будет выполняться в первичной реплике, а будет перенаправляться на вторичную реплику с наивысшим приоритетом резервного копирования.
Set-SqlAvailabilityGroup ` -Path SQLSERVER:\Sql\PrimaryServer\InstanceName\AvailabilityGroups\MyAg ` -AutomatedBackupPreference SecondaryOnly
Чтобы просмотреть синтаксис командлета, воспользуйтесь командлетом Get-Help в среде PowerShell SQL Server. Дополнительные сведения см. в разделе Get Help SQL Server PowerShell. |
Настройка и использование поставщика SQL Server PowerShell
Чтобы настройка автоматического резервного копирования учитывалась для данной группы доступности на каждом экземпляре сервера, где размещена реплика доступности, приоритет резервного копирования которой больше нуля (>0), необходимо создать скрипты заданий резервного копирования для баз данных в группе доступности. Чтобы определить, является ли текущая реплика предпочитаемой репликой резервного копирования, выполните функцию sys.fn_hadr_backup_is_preferred_replica в скрипте резервного копирования. Если реплика доступности, размещенная на текущем экземпляре сервера, является предпочтительной для резервного копирования, эта функция возвращает значение 1. В противном случае функция возвращает значение 0. С помощью простого скрипта для каждой реплики доступности, который запрашивает эту функцию, можно определить, какая реплика должна выполнять данное задание резервного копирования. Например, типичный фрагмент скрипта задания резервного копирования выглядит следующим образом:
IF (NOT sys.fn_hadr_backup_is_preferred_replica(@DBNAME)) BEGIN Select ‘This is not the preferred replica, exiting with success’; RETURN 0 – This is a normal, expected condition, so the script returns success END BACKUP DATABASE @DBNAME TO DISK=<disk> WITH COPY_ONLY;Написание скрипта с подобной логикой для задания резервного копирования позволяет планировать запуск задания на каждой реплике доступности по одинаковому расписанию. Каждое из данных заданий обращается к одним и тем же данным для определения того, какие задания следует выполнить, поэтому для создания резервной копии фактически обрабатывается только одно запланированное задание. В случае отработки отказа не приходится изменять ни один из скриптов или заданий. Кроме того, если перенастроить группу доступности для добавления реплики доступности, то для управления заданиями резервного копирования потребуется просто скопировать или запланировать задание. В случае удаления реплики доступности просто удалите задание резервного копирования с экземпляра сервера, на котором размещалась эта реплика.
Если задание резервного копирования создается в мастере планов обслуживания, то в это задание автоматически включается логика скрипта, которая вызывает и проверяет функцию sys.fn_hadr_backup_is_preferred_replica. Однако задание резервного копирования не будет возвращать сообщение «Это не предпочтительная реплика». Необходимо создать задания для каждой базы данных доступности на каждом экземпляре сервера, на котором размещена реплика доступности этой группы доступности. |
Ниже приводятся способы получения информации, имеющей отношение к резервному копированию во вторичных репликах.
sys.fn_hadr_backup_is_preferred_replica | Является ли текущая реплика предпочитаемой репликой резервного копирования? | Неприменимо. |
sys.availability_groups | Параметр автоматизированного резервного копирования | automated_backup_preference automated_backup_preference_desc |
sys.availability_replicas | Приоритет резервного копирования данной реплики доступности | backup_priority |
sys.dm_hadr_availability_replica_states | Является реплика локальной по отношению к экземпляру сервера? Текущая роль. Состояние работы Состояние подключения Исправность синхронизации реплики доступности | is_local role, role_desc operational_state, operational_state_desc connected_state, connected_state_desc synchronization_health, synchronization_health_desc |
Обзор групп доступности AlwaysOn (SQL Server) Активные вторичные реплики: резервное копирование во вторичных репликах (группы доступности AlwaysOn)
technet.microsoft.com