Доступные в данный момент возможности по резервированию данных в SQL Azure (ru-RU)

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

Для последней информации по резервированию и восстановлению в SQL Azure, а также по стратегии восстановления после сбоев см. SQL Azure MSDN: Business Continuity in SQL Azure.

Резервирование против ошибок оборудования

SQL Azure в один момент времени производит управление множеством копий ваших данных, хранящихся на различном независимом друг от друга оборудовании в датацентре. Мы называем эти копии репликами. В один момент времени хранится три реплики данных - одна primary и две secondary. Мы используем
схему подтверждения на основе кворума (quorum based commit scheme), когда данные записываются на primary и одну secondary реплику, и только после этого транзакция подтверждается. В это же время происходят периодически offsite-бэкапы данных на случай критических ошибок в датацентре. Эти механизмы защищают данные против ошибок оборудования.

Резервирование против пользовательских ошибок

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

Начало работы

Запрос Transact SQL:

CREATE DATABASE destination_database_name

AS COPY OF [source_server_name.]source_database_name

Для копирования БД на тот же самый сервер:

CREATE DATABASE [AdvetureWorksBackup] AS COPY OF [AdventureWorksLTAZ2008R2]

Запрос должен выполняться в условиях подключения к БД master сервера-приёмника.

Мониторинг выполнения

Вы можете следить за копированием БД, выполняя соответствующий запрос к DMV sys.dm_database_copies.

Например:

SELECT *

FROM sys.dm_database_copies

Вывод результата копирования БД:

Необходимые разрешения

Когда вы копируете БД на другой сервер SQL Azure, вы должны убедиться, что логин/пароль, используемые для копирования, идентичны на обоих серверах. Логин должен иметь разрешения db_owner на исходном сервере и dbmanager на сервере-приемнике. Больше про разрешения на MSDN: Copying Databases in SQL Azure.

Необходимо отметить, что сервер, на который вы копируете, не обязан быть в том же аккаунте. По факту вы можете совершать копию вашей БД в third party с использованием команды database copy. Для этого необходимо лишь иметь идентичные разрешения и логин/пароль.