Резервное копирование и восстановление
Как в крупных, так и в небольших организациях случаются аварии и инциденты. В связи с этим у вас всегда должен быть план восстановления на случай, если работа систем будет прервана. SQL Server позволяет выполнять восстановление базы данных до определенной точки во времени, но только при работе в модели полного восстановления. В модели восстановления с неполным протоколированием базу данных, скорее всего, нужно будет восстанавливать до конца резервной копии журнала транзакций.
Одно из преимуществ SQL Azure состоит в том, что Azure может взять всю эту работу на себя. Так как SQL Azure управляет резервными копиями и выполняется в модели полного восстановления, он может восстановить базу данных до любой точки во времени. Вы можете даже восстановить удаленную базу данных, используя настроенную политику хранения. А если на логическом сервере или экземпляре включено прозрачное шифрование данных (TDE), то Майкрософт применяет шифрование резервных копий автоматически.
По умолчанию полная резервная копия базы данных создается раз в неделю. Резервные копии журналов создаются каждые 5–10 минут, а разностные резервные копии — каждые 12–24 часов. Файлы резервных копий по умолчанию хранятся в Службе хранилища Azure в геоизбыточном хранилище с доступом на чтение (RA-GRS). Однако вы можете также использовать резервные копии в хранилище, избыточном между зонами (ZRS) или локально избыточном хранилище (LRS). Группа инженеров SQL Azure на постоянной основе проводит автоматические проверки восстановления из автоматических резервных копий баз данных, размещенных на логических серверах и в эластичных пулах. Для перехода в управляемый экземпляр SQL Azure проводится автоматическое начальное резервное копирование с контрольной суммой баз данных, восстановленных с помощью собственной команды RESTORE или с помощью Azure Database Migration Service. Также в Управляемом экземпляре SQL Azure можно при необходимости создать собственную резервную копию только для копирования и сохранить ее в хранилище BLOB-объектов Azure.
Создание стратегии резервного копирования с использованием управляемого экземпляра SQL Azure и базы данных SQL Azure
Sql Azure заботится о тяжелом подъеме, но по-прежнему важно понять, как хранятся и обрабатываются резервные копии, а также какие варианты хранения и восстановления. В конечном счете, вы по-прежнему отвечаете за общую стратегию восстановления на определенный момент времени, долгосрочного хранения и геовосстановление.
Восстановление до точки во времени (PITR)
В базе данных SQL Azure и в управляемом экземпляре SQL Azure можно использовать самостоятельное восстановление. Можно выбрать точную точку во времени, до которой необходимо восстановить базу данных, и запустить процесс с помощью портал Azure, PowerShell, Azure CLI или REST API. Восстановление на определенный момент времени (PITR) создаст новую базу данных (с другим именем) на одном логическом сервере. Если исходную базу данных нужно будет заменить на базу данных PITR, для возврата к рабочему состоянию придется переименовать и исходную, и новую базы данных. Обновлять строки подключения не требуется.
Срок хранения PITR может составлять от 1 до 35 дней. Срок хранения по умолчанию (для всех уровней служб и вариантов развертывания) составляет семь дней. Большинство вариантов развертывания и уровней служб позволяет выбрать для политики значение от 1 до 35 дней в зависимости от сценария. Например, для тестовой базы данных может потребоваться только один день, но вы можете выбрать не более 35 дней для критически важной базы данных.
Долгосрочное хранение (LTR)
Если 35 дней недостаточно для удовлетворения потребностей организации или соблюдения требований, можно выбрать долгосрочное хранение (LTR). Этот параметр позволяет автоматически создавать полные резервные копии базы данных, хранящиеся в хранилище RA-GRS, ZRS или LRS до 10 лет. Для базы данных SQL Azure LTR является общедоступным. Для Управляемого экземпляра Azure SQL LTR доступен в ограниченной общедоступной предварительной версии.
Геовосстановление
В случае катастрофического события вашей организации потребуется возможность восстановления. Резервные копии автоматически сохраняются в RA-GRS (если только вы не выберете ZRS или LRS), и это означает, что они будут храниться в парном регионе. Поэтому, если весь регион выходит из строя, а базы данных или управляемые экземпляры находятся в этом регионе, вы будете защищены. Вы можете выполнить геовосстановление в любой другой регион из последней геореплицированной резервной копии. Эта резервная копия может несколько отставать от первичной, поскольку репликация BLOB-объекта Azure в другой регион требует времени. Геовосстановление легко выполняется с помощью портала Azure, PowerShell, Azure CLI или REST API.