ГлавнаяРазноеВосстановление базы из бэкапа sql

MySQL: восстановление базы данных из резервной копии (из backup). Восстановление базы из бэкапа sql


Как восстановить базу данных Microsoft SQL из бэкапа

  1. Как восстановить базу данных Microsoft SQL из бэкапа с помощью панели управления хостингом Plesk?
  2. Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической поддержки?

1. Как восстановить базу данных Microsoft SQL из бэкапа с помощью панели управления хостингом Plesk?

1.1. Убедитесь, что Вы предварительно создали базу данных Microsoft SQL, используя панель Plesk. Подробнее читайте в инструкции Как создать базу данных Microsoft SQL в Plesk.

1.2. Зайдите в панель Plesk, используя предоставленные Вам учетные данные (примечание: данные на доступ к панели управления и адрес для входа в панель управления высылались в письме о реализации заказа хостинга). После того, как у Вас отобразилась страница входа в панель управления Plesk, введите имя пользователя и пароль и нажмите кнопку [Войти]:

1.3. После успешного входа нажмите [Базы данных]: 1.4. Откроется страница управления базами данных. Для базы данных, которую Вы хотите восстановить из резервной копии (бэкапа), нажмите [Импортировать резервную копию]: 1.5. Откроется окно импорта (восстановления базы данных из бэкапа). Здесь возможны два варианта. Мы рекомендуем использовать вариант № 2 (см. п. 1.5.2 настоящей инструкции):

1.5.1. Загрузка файла бэкапа и восстановление данных:

1.5.1.1. Нажмите [Обзор...] (или [Choose File]), затем выберите файл бэкапа базы данных на локальном компьютере:

1.5.1.2. После этого нажмите [OK]: 1.5.1.3. Дождитесь загрузки файла бэкапа и восстановления данных. Мы не рекомендуем использовать этот вариант, т.к. если загрузка файла бэкапа будет прервана, то для восстановления данных из бэкапа придется загружать файл бэкапа повторно:
1.5.1.4. После того, как файл бэкапа будет загружен, и данные восстановлены, Вы увидите: 1.5.2. Восстановление данных из ранее загруженного по FTP файла бэкапа:

1.5.2.1. Предварительно загрузить файл бэкапа базы данных по FTP в папку [/private] на хостинге. Как загружать файлы по FTP читайте в инструкции Как загрузить файлы сайта на FTP-сервер.

1.5.2.2. В окне импорта (восстановления базы данных из бэкапа) нажмите [Импортировать], затем выберите файл бэкапа базы данных на сервере и нажмите [OK]:

1.5.2.3. Дождитесь восстановления данных: 1.5.2.4. После того, как данные будут восстановлены, Вы увидите: 1.6. На этом восстановление базы данных MSSQL из бэкапа завершено.

2. Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической поддержки?

2.1. Создайте базу данных в Plesk, как описано в инструкции Как создать базу данных Microsoft SQL в Plesk.

2.2. Создайте бэкап базы данных на локальном компьютере с помощью инструкции Как сделать бэкап локальной базы данных Microsoft SQL.

2.3. Загрузите полученный файл бэкапа базы данных Microsoft SQL по FTP в папку [/private] на хостинге. Как загружать файлы по FTP читайте в инструкции Как загрузить файлы сайта на FTP-сервер.

2.4. Обратитесь в службу технической поддержки с просьбой восстановить базу данных Microsoft SQL из бэкапа. При этом обязательно укажите следующую информацию:2.4.1. Имя сайта, для которого выполняется восстановление базы данных Microsoft SQL;2.4.2. Имя файла бэкапа, предварительно загруженного по FTP в папку [/private] на [шаге 2.3] настоящей инструкции;2.4.3. Имя базы данных (созданной в Plesk на [шаге 2.1] настоящей инструкции), которая будет восстановлена из бэкапа.

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

hb.by

Восстановление баз данных SQL Server 2005/2008

SQL Server поддерживает три различных вида резервных копий – полную (full backup), дифференциальную (differential backup) и резервную копию журнала транзакций (transaction log backup). Первые два вида резервных копий доступны для баз данных в любой модели восстановления, резервная копия журнала транзакций – для баз данных в модели восстановления FULL и BULK-LOGGED (про модели восстановления вкратце вы можете прочитать здесь, а лучше в BOL).

Если вы используете модель восстановления SIMPLE – вы сможете восстановить свою базу только из полного бэкапа (ну и накатить, дополнительно, дифференциальную копию). Вы никогда не восстановитесь на момент времени предшествующий сбою, только если вы не создали резервную копию непосредственно перед сбоем. Если ваша база данных находится в модели восстановления FULL и вы никогда не делаете бэкап журнала транзакций, но время от времени «обрезаете лог», прочитайте дальше – узнайте чего вы лишаетесь :).

Если вы это читаете, я полагаю, что ваша база находится в модели восстановления FULL, вы регулярно делаете полные резервные копии и копии журналов транзакций. Кроме того, ваша «цепочка восстановления» из резервных копий журнала транзакций должна быть неповрежденной.

Что такое «цепочка восстановления»? Это непрерывная последовательность резервных копий, состоящая из полного бэкапа и непрерывной последовательности резервных копий журнала транзакций. Например, в 12.30 вы создали полный бэкап (назовем его full1), а в 12.45, 13.00 и 13.15 создавали резервные копии журнала транзакций (trlog1, trlog2, trlog3, соответственно). До тех пор пока у вас есть все эти резервные копии, вы сможете восстановить свою базу данных на любой момент времени между 12.30 и 13.15, на 12.48, например.

Если вы удалите копию trlog2, созданную в 13.00, то резервная копия trlog3 (и все копии сделанные в дальнейшем) станет абсолютно бесполезной – восстановиться вы сможете на любой момент времени между 12.30 и 12.45. То же самое произойдет в случае, если кто-то создаст копию в 12.31 и удалит ее – все последующие копии станут бесполезны. Чтобы начать новую цепочку восстановления вам нужно будет сделать полную резервную копию и, затем, резервную копию журнала транзакций.

Во всем этом есть один не очень очевидный (по крайней мере, так было для меня) момент. Полная резервная копия всегда начинает, но никогда не прерывает цепочку восстановления (это справедливо для SQL Server 2005 и старше). Разберем это на примере. Вдобавок к уже имеющимся копиям (full1, trlog1, trlog2, trlog3 – непрерывная цепочка восстановления) сделаем в 13.30 полную резервную копию full2 и резервные копии журнала транзакций trlog3, trlog4, trlog5 в 13.45, 14.00 и 14.15, соответственно.

Теперь, если нам нужно восстановить базу данных на 14.15, проще всего использовать «новую» цепочку восстановления, т.е. восстановить full2 и «накатить» на нее последовательно trlog3, trlog4, trlog5. Но, если окажется, что из копии full2 мы не можем восстановиться (например, посыпался диск, содержащий эту копию), то мы можем воспользоваться нашей «первой» цепочкой восстановления – восстановить резервную копию full1 и последовательно накатить на нее копии журнала транзакций trlog1, trlog2, trlog3, trlog4, trlog5, trlog6. Точно также, мы можем использовать первую цепочку восстановления, для восстановления базы данных на 13.29 – восстанавливаем full1 и накатываем trlog1, trlog2, trlog3 и trlog4.

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

Дальше я расскажу несколько способов использования резервных копий SQL Server. Первый вариант (он работает для всех моделей восстановления) – необходимо восстановить базу данных из полной резервной копии. Здесь все просто – необходимо выполнить T-SQL скрипт:

RESOTRE DATABASE [имя_базы_данных]FROM DISK = 'путь к полной резервной копии'WITH REPLACE, RECOVERY, STATS = 10

Параметр REPLACE указывает на то, что если база данных с именем [имя_базы_данных] существует, то мы заменяем ее содержимое содержимым резервной копии. Если вы восстанавливаете базу данных с помощью GUI – нужно указать «Overwrite the existing database» на вкладке «Options».

RECOVERY говорит о том, что базу данных необходимо перевести в согласованное состояние и разрешить соединения пользователей. В GUI это соответствует опции «Leave the database ready to use by rolling back uncommitted transactions. Additional transaction logs cannot be restored.». Т.е., SQL Server откатывает все незафиксированные транзакции и позволяет пользователям работать с данными. После того как вы восстановили резервную копию с параметром RECOVERY, к ней нельзя применять дополнительно копии журналов транзакций и дифференциальные копии. Будьте внимательны, этот параметр устанавливается по умолчанию и если вы захотите «накатить» еще одну копию – процесс восстановления придется начать заново.

STATS = 10 отвечает за вывод информации о процессе восстановления. В данном случае, при восстановлении каждых 10 % резервной копии, на вкладке Messages в SSMS будет появляться сообщение. При восстановлении с помощью GUI вы не можете управлять этим параметром – за изменениями можно следить на «графике» в нижнем левом углу.

По умолчанию копия восстанавливается в то же самое место откуда она была сделана. Т.е. если изначально все файлы базы данных лежали в каталоге C:\Database, а вы хотите восстановить копию в другое место, то необходимо использовать параметр MOVE. Для использования MOVE вам необходимо знать логические имена файлов – их можно посмотреть с помощью представления sys.database_files. На рисунке показан пример использования этого представления.Таким образом, чтобы восстановить базу данных AdventureWorks из резервной копии и одновременно перенести ее в другое место, можно воспользоваться следующим скриптом:

RESTORE DATABASE [AdventureWorks]FROM DISK = 'D:\backup\awfull.bak'WITH REPLACE, RECOVERY, STATS = 10,MOVE 'AdventureWorks_Data' TO 'D:\database\AW_data.mdf',MOVE 'AdventureWorks_Log' TO 'D:\database\AW_log.ldf'

Если восстановление производится с помощью GUI, необходимо задать новые имена файлов на вкладке «Options» (таблица «Restore the database files as:», колонка «Restore As»).

Второй вариант – восстановление из полной резервной копии и всех резервных копий журнала транзакций (или дифференциальных копий).

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

RESTORE DATABASE [AdventureWorks]FROM DISK = 'D:\backup\awfull.bak'WITH REPLACE, NORECOVERY, STATS = 10,MOVE 'AdventureWorks_Data' TO 'D:\database\AW_data.mdf',MOVE 'AdventureWorks_Log' TO 'D:\database\AW_log.ldf'

Если после выполнения восстановления вы попробуете обратиться к базе – получите ошибку:Database 'AdventureWorks' cannot be opened. It is in the middle of a restore.После восстановления полной резервной копии восстанавливаем последнюю дифференциальную копию (если есть):

RESTORE DATABASE [AdventureWorks]FROM DISK = 'D:\backup\awDIFF.bak'WITH NORECOVERY, STATS = 10

На этом, если у вас модель SIMPLE, вы можете остановиться – больше вы ничего не сделаете. Если у вас модель FULL, вы можете дополнительно накатить резервные копии журнала транзакций:

RESTORE LOG [AdventureWorks]FROM DISK = 'D:\backup\awlog1.trn'WITH NORECOVERY….RESTORE LOG [AdventureWorks]FROM DISK = 'D:\backup\awlog12.trn'WITH RECOVERY

Обратите внимание, последняя копия должна быть восстановлена с параметром RECOVERY. Если база данных осталась в состоянии RESTORING, ее можно привести в работоспособное состояние и без резервных копий:

RESTORE DATABASE [AdventureWorks]WITH RECOVERY

После этого база данных «вернется к жизни».Третий вариант – восстановление на момент времени. У меня есть база данных AdventureWorks, ее полная резервная копия и резервная копия журнала транзакций, сделанная ранее. Результат выполнения запроса

SELECT *FROM Person.AddressType

представлен на рисунке:

В 13.46 эта таблица была удалена. Тот же самый запрос теперь возвращает:Invalid object name 'Person.AddressType'Чтобы вернуть все на свои места, в первую очередь делаем резервную копию журнала транзакций:

BACKUP LOG [AdventureWorks]TO DISK = 'D:\backup\awlog2.trn'

После того как копия создана, восстанавливаем полную резервную копию и первую резервную копию журнала транзакций (обе с параметром NORECOVERY).Теперь восстановим последнюю резервную копию, созданную ПОСЛЕ удаления таблицы:

RESTORE LOG [AdventureWorks]WITH RECOVERY, STOPAT = '09/10/2010 13:45' (дата здесь задается в формате "ММ/ДД/ГГГГ ЧЧ:ММ")После этого исходный запрос возвращает нормальный результат, таблица восстановилась.

Еще один вариант восстановления данных. История из жизни :). Несколько месяцев назад попали в не очень приятную ситуацию – записи в одном из регистров сведений (периодическом, не подчиненном регистратору) были «испорчены». То есть они как бы остались, но свой смысл потеряли. Регистр был большим и нужным. Ошибка произошла несколько часов назад, так что полностью восстанавливать базу данных было нельзя. Собирались переносить данные с помощью обработки ВыгрузкаЗагрузкаДанныхXML, но программисты попросили попробовать перенести данные средствами SQL, в надежде, что это будет быстрее.

Мы восстановили из бэкапов копию базы на момент времени предшествующий порче данных. С помощью функции «ПолучитьСтруктуруХраненияБазыДанных» узнали имя регистра сведений в базе данных - _InfoReg4452 (например, точно я уже не помню). Очистили в основной базе этот «испорченный» регистр с помощью TRUNCATE TABLE _InfoReg4452.На копии базы выбрали TASKS -> ExportData, в качестве источника указали копию с нормальным регистром, в качестве приемника рабочий сервер и рабочую базу (с очищенным регистром). На странице выбора объектов выбрали только одну – нужную нам таблицу:Еще два клика мышью и все. Таблица перенеслась, люди продолжили работу. Хочу обратить внимание на несколько нюансов. Во-первых, если не очищать таблицу-приемник, все данные в ней останутся, а новые могут и не появиться. Во-вторых, такой метод может подойти для некоторых регистров сведений и справочников, но для таблиц по которым делаются движения, или объектов, совершающих движения, придется восстанавливать множество дополнительных таблиц – 100 раз подумайте, прежде чем применять этот метод. Ну и вообще этот метод идет в разрез с лицензионным соглашением, но он быстр и удобен в некоторых случаях.Надеюсь эта информация была хоть кому-нибудь полезной.

P.S. Не верьте мне на слово - попробуйте все это сделать на своих копиях!

sp-who.livejournal.com

MySQL: восстановление базы данных из резервной копии (из backup)

Случилось - необходимо восстановить базу данных из резервной копии, предварительно сделанной. Что-ж, бывает.

Существует два метода:

  • из дампа базы - если бекап выполнялся через mysqldump
  • из архива базы - если бекап делали просто архивированием каталога с базой данных

Метод 1: из дампа

Этот метод предполагает наличие файла резервной копии, сделанного утилитой mysqldump. Этот файл имеет ни много не мало формат SQL - т.е. в нем банально прописаны команды для пересоздания базы данных с использованием обычных MySQL команд.

1) Если Вы делали бекап всех баз MySQL сервера - открывайте файл бекапа и удаляйте все данные, которые не касаются восстанавливаемой базы. Если бекап у Вас конкретной базы - т.е. той, которую бедете восстанавливать, и кроме нее ничего внутри нет - идем дальше.

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

CREATE DATABASE IF NOT EXISTS `mydatabase`;USE mydatabase;

-- MySQL dump 10.13  Distrib 5.1.56, for debian-linux-gnu (i486)---- Host: localhost    Database: mydatabase-- -------------------------------------------------------- Server version       5.1.56-0.dotdeb.0

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;/*!40101 SET NAMES utf8 */;/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;/*!40103 SET TIME_ZONE='+00:00' */;/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

---- Table structure for table `mytable`--

DROP TABLE IF EXISTS `mytable`;/*!40101 SET @saved_cs_client     = @@character_set_client */;/*!40101 SET character_set_client = utf8 */;CREATE TABLE `mytable` (.........

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

CREATE DATABASE IF NOT EXISTS `mydatabase`;

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

Видите второй строчкой "USE mydatabase;"? Вот убедитесь, что такая команда есть (а ее нет, полюбому, т.ч. дописывайте) и вместо "mydatabase" указывайте название восстанавливаемой базы.

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

3) Восстанавливаем:

$ mysql -u root -p < mydatabase.bak

где вместо "mydatabase.bak" указывайте имя файла бекапа (который Вы только что правили).

В общем-то, все.

Метод 2: из архива

Работает в случае, если базу данных Вы бекапили простым копированием ее каталога и его архивации в tar (или не архивации).

1) Останавливаем MySQL сервер.

для Debian/ubuntu:

$ sudo /etc/init.d/mysql stop

для CentOS/redhat:

$ sudo /etc/init.d/mysqld stop

для FreeBSD:

$ sudo /usr/local/etc/rc.d/mysql-server stop

2) Распаковываем базу из tar (если она запакована в tar-архив)

$ tar -xf mydatabase.bak.tar

3) Копируем извлеченный архив (вместе со всеми файлами внутри) по пути, где размещаются все базы данных MySQL. Лучше при этом старый каталог удалить (каталог базы данных, а не весь каталог MySQL, конечно).

4) Проверяем атрибуты - дабы владельцем базы был MySQL. Лучше просто выполнить команду применения атрибутов:

$ sudo chown -R mysql:mysql mydatabase

где mydatabase - это имя каталога базы данных (при этом предполагается, что Вы находитесь в каталоге баз данных MySQL).

5) Запускаем MySQL сервер обратно.

для Debian/ubuntu:

$ sudo /etc/init.d/mysql start

для CentOS/redhat:

$ sudo /etc/init.d/mysqld start

для FreeBSD:

$ sudo /usr/local/etc/rc.d/mysql-server start

На этом все - база восстановлена.

 

Актуально для: MySQL 5.x+

my-biz.com.ua

Ошибка восстановления из резервной копии Базы данных SQL

Столкнулся с проблемой восстановления базы данных MS SQL средствами Veritas Netbackup SQL Client. Используя мастер восстановления базы данных, был автоматически сгенерирован скрипт восстановления:NBIMAGE "xxx.MSSQL7.XXXXXX.db.XX_xXX_X.~.7.001of004.20171204211155..C" SQLHOST "XXX.XXXXX.XX" NBSERVER "XXX.XXXXX.XX" STRIPES 004 BROWSECLIENT "XXXXXX.XXXXX.XX" MAXTRANSFERSIZE 6 BLOCKSIZE 7 RECOVEREDSTATE RECOVERED SQLCOMPRESSION TRUE NUMBUFS 2 ENDOPER TRUEЗапуск этого скрипта проходил успешно, однако спустя некоторое время задания прерывалось ошибкой 2850, а точнее:1/31/2018 01:50:58 - Info bpbrm (pid=18784) child done, status 41 01/31/2018 01:50:58 - Info bpbrm (pid=18784) sending message to media manager: STOP RESTORE xxx.xxxxx.xx_1512411259 01/31/2018 01:51:01 - Error bptm (pid=12412) The following files/folders were not restored: 01/31/2018 01:51:01 - Error bptm (pid=12412) UTF - /xxx.MSSQL7.XXXXXXXXXX.db.XXXXX_xxxx.~.7.001of004.20171204211155..C 01/31/2018 01:51:02 - Info bpbrm (pid=18784) media manager for backup id xxxx.xxxxx.xx_1512411259 exited with status 150: termination requested by administrator Поиск по коду ошибки 2850, подсказал, что задание автоматически завершается по причине истечении времени ожидание (TimeOut), а для исправления ситуации рекомендуется увеличить значение параметра Client read timeout в несколько раз, например, до 2 часов.Изменения параметра Client read timeout, привело лишь к эффекту, что аварийное время завершения задания также увеличилось в 2 раза, и все с тем же неудачным статусом восстановления.

Однако, в базе знаний компании veritas также отыскалась интересная статья, что ситуация с завершением заданий резервного копирования по timeout, может возникать из-за, ожидания завершения разных паралелельных потоков восстановления (https://www.veritas.com/support/en_US/article.000030813):

When the restore of the first stripe finishes, it will wait until the second stripe finishes too.During this time the drive and tape used by the first stripe are still reserved and not available to another job.If the second restore stripe needs more time than the "Media mount timeout" setting to complete,the restore operation will time out.This may be caused by throughput differences during the backup on each stripe causing the subsequent stripeimages to be greatly different in size.

Стандартное решение, рекомендуемое при появлении подобной ошибки:

Increase the “ Media Mount Timeout” (Netbackup Administration Console -> Host Properties -> Master Servers-> Timeouts)to a setting greater than the difference in restore times of each stripe.

Но в моем случае обе части резервной копии располагались на одной ленте. что по сути являлось смертельной блокировкой, обреченной на timeout, подошло только альтернативное решение:

modify the SQL restore script and set STRIPES to 1.

После изменения значение STRIPES до 1, операция восстановления сразу же запустила восстановление БД, без какого-либо долгого ожидания.

userman.ru

Восстановление резервной копии в Управляемый экземпляр Базы данных SQL Azure

  • 11/01/2018
  • Время чтения: 4 мин
  • Соавторы

In this article

В этом руководстве описано, как восстановить резервную копию базы данных, хранящейся в хранилище BLOB-объектов Azure, в Управляемый экземпляр с помощью стандартного файла резервной копии Wide World Importers.This quickstart demonstrates how to restore a backup of a database stored in Azure blob storage into the Managed Instance using the Wide World Importers - Standard backup file. Использование этого метода сопряжено с некоторым простоем.This method requires some downtime.

Сведения об использовании Azure Database Migration Service (DMS) для миграции см. в статье о миграции SQL Server в управляемый экземпляр базы данных SQL Azure.For a tutorial using the Azure Database Migration Service (DMS) for migration, see Managed Instance migration using DMS. Дополнительные сведения о методах миграции см. в разделе Перенос экземпляра SQL Server в Управляемый экземпляр Базы данных SQL Azure.For a discussion of the various migration methods, see SQL Server instance migration to Azure SQL Database Managed Instance.

Предварительные требованияPrerequisites

В этом кратком руководстве:This quickstart:

Восстановление базы данных Wide World Importers из файла резервной копииRestore the Wide World Importers database from a backup file

С помощью SSMS выполните следующие шаги для восстановления базы данных Wide World Importers в управляемый экземпляр из файла резервной копии.With SSMS, use the following steps to restore the Wide World Importers database to your Managed Instance from the backup file.

  1. Откройте SQL Server Management Studio (SSMS) и подключитесь к Управляемому экземпляру.Open SQL Server Management Studio (SSMS) and connect to your Managed Instance.
  2. Откройте в SSMS окно нового запроса.In SSMS, open a new query window.

  3. Воспользуйтесь следующим сценарием для создания учетных данных в Управляемом экземпляре с помощью предварительно настроенной учетной записи хранения и ключа SAS.Use the following script to create a credential in the Managed Instance using the preconfigured storage account and SAS key.

    CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] WITH IDENTITY = 'SHARED ACCESS SIGNATURE' , SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2028-09-06T02:52:55Z&st=2018-09-04T18:52:55Z&spr=https&sig=WOTiM%2FS4GVF%2FEEs9DGQR9Im0W%2BwndxW2CQ7%2B5fHd7Is%3D'

    Примечание

    Всегда удаляйте ? в началеAlways remove the leading ? созданного ключа SAS.from generated SAS key.

  4. Используйте следующий сценарий для проверки допустимости учетных данных и резервной копии SAS. Укажите URL-адрес контейнера, в котором находится файл резервной копии.Use the following script to check the SAS credential and backup validity - providing the URL for the container with the backup file:

    RESTORE FILELISTONLY FROM URL = 'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'

  5. Используйте приведенный ниже скрипт для восстановления базы данных Wide World Importers из файла резервной копии. Укажите URL-адрес контейнера, в котором находится этот файл.Use the following script to restore the Wide World Importers database from a backup file - providing the URL for the container with the backup file:

    RESTORE DATABASE [Wide World Importers] FROM URL = 'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'

  6. Чтобы отслеживать состояние восстановления, выполните следующий запрос в новом сеансе запроса:To track the status of your restore, run the following query in a new query session:

    SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete , dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')`

  7. По завершении восстановления просмотрите восстановленную базу данных в обозревателе объектов.When the restore completes, view it in Object Explorer.

Дополнительная информацияNext steps

docs.microsoft.com

Автоматизированное восстановление баз данных MS SQL из бэкапов / Блог компании СофтЛаб / Хабрахабр

В этой статье я хотел бы рассказать о том, как с помощью утилиты Quick Maintenance & Backup for MS SQL настроить автоматическое восстановление баз данных из бэкапов на тестовом экземпляре SQL Server в сети. При этом создавать бэкапы будет штатный План обслуживания. Потребность в автоматизированном восстановлении может возникнуть в следующих случаях:
  1. Если требуется регулярно актуализировать базы данных на тестовых серверах.
  2. Если требуется периодически проверять через восстановление созданные бэкапы: полный, разностный и журналы транзакций.
В сети можно найти примеры скриптов позволяющие в той или иной мере автоматизировать эти задачи. Но большинство решений требуют хорошего понимания T-SQL, предметной области и скорее всего потребуют изменения ваших Планов обслуживания. Я покажу как это сделать за 15-20 минут с помощью утилиты Quick Maintenance & Backup for MS SQL (QMB). Мы задействуем механизм XML планов восстановления — это XML файл с последовательностью бэкапов, который умеет создавать утилита. По информации в XML файле программа получит последовательность бэкапов, сформирует T-SQL скрипт для восстановления и запустит его на выполнение. Подробнее об этой возможности можно почитать здесь. Подробнее о других возможностях утилиты читайте на официальном сайте, а также в этой статье.

Задача

Итак, допустим имеется рабочий SQL Server (Srv01) на котором развернуты несколько баз данных с Полной моделью восстановления. На сервере создан План обслуживания с произвольной стратегией резервного копирования. В моем случае это: Полный бэкап – каждую неделю 24.00 в воскресенье Разностный бэкап – каждую ночь в 24.00 кроме воскресенья Бэкап лога – каждый день с 9.00 до 23.59 через каждые 1 час Бэкапы создаются в папке F:\MS SQL\Backup. При этом для каждой базы агент SQL Server создает отдельные подпапки.

Задача: каждый день в 23:00 на резервном SQL Server (London) выполнять восстановление баз данных на последнее возможное состояние из бэкапов созданных на Srv01. Оба сервера находятся в единой локальной сети. После восстановления каждой базы данных необходимо проверить её целостность (DBCC CHECKDB). Таким образом, каждый вечер кроме воскресенья, будет выполняться восстановление из Полного бэкапа, разностного и журналов транзакций, созданных в течении дня. В понедельник восстановление будет проводится из Полного бэкапа и журналов транзакций, созданных в течении понедельника. Если по каким-то причинам восстановление не выполнится администратору должно прийти email-уведомление.

Понятно, что для того чтобы тестовый SQL Server (London) смог выполнить восстановление он должен иметь доступ к файлам бэкапов. Тут возможны два варианта:

  1. Расшарить папку F:\MS SQL\Backup  на Srv01 так чтобы она была доступна на London.
  2. С помощью QMB копировать бэкапы в общую сетевую папку, которая доступна на London.
По причине дополнительной надежности и простоты настройки мы реализуем второй вариант, т.е. утилита будет дополнительно копировать файлы в сетевую папку.

Общий порядок действий

Итак, нам потребуется проделать следующие шаги:
  1. Настроить общую сетевую папку
  2. Установить утилиту QMB
  3. Настроить уведомления и зарегистрировать в программе два SQL Server: Srv01 и London.
  4. Создать в программе две новых задачи:
    • Создание XML плана восстановления на сетевом диске
    • Восстановление по XML плану с сетевого диска
  5. Создать в программе два сценария:
    • Сценарий, на рабочем сервере Srv01, выполняющий создание XML плана восстановления в общей папке с копированием в неё файлов бэкапов. Старт каждый 1 час.
    • Сценарий, на тестовом сервере London, выполняющий восстановление по XML плану из бэкапов, размещенных в общей папке.  Старт каждый день в 23.00.
Ниже рассмотрим каждый шаг подробнее.

Установка QMB

Утилиту можно скачать тут. Пробный период — 30 дней.

Я поставил утилиту на тестовом сервере London. В общем случае программу можно установить на любом компьютере, работающем круглосуточно т.е. установка именно на SQL Server не обязательна. При установке программы оставляем все параметры по умолчанию. Инсталлятор установит службу QmbService и клиента.

Регистрация SQL Server и настройка уведомлений

При первом старте программы откроется мастер. Перейдем на следующий шаг и установим галку «Включить email-оповещения» и введем адрес электронной почты для получения уведомлений.

Для отправки уведомлений рекомендуется настраивать собственную учетную запись SMTP, но для простоты мы будем использовать встроенную. Далее введем имя SQL Server и учетную запись для подключения к SQL Server. Необходимо указать учетную запись имеющую привилегии sysadmin (по умолчанию sa).

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

В следующем окне можно настроить слежение за свободным местом на дисках. Если в этом нет необходимости, то снимите все чекбоксы с дисков.

Жмем кнопку «Вперед».

Нам не требуется обслуживать базы данных поэтому на последней странице мы выберем «Создать пустой автономный сценарий». Затем снимем галку «Создать автономный сценарий для обслуживания системных баз данных» и нажмем кнопку «Завершить».

Программа зарегистрирует SQL Server и откроет форму нового пустого сценария.

Создание XML-плана восстановления

Любые задачи в программе исполняются в рамках сценариев. В окне нового автономного сценария ведем его имя Создание XML плана восстановления.   Добавим в сценарий задачу, которая будет создавать XML файл плана восстановления. Нажмем кнопку «Добавить». Откроется форма выбора задачи. Кликнем кнопку «Добавить новую задачу». Откроется форма новой задачи. На форме нужно:
  1. Изменить тип задачи на «Создание XML плана восстановления»
  2. Создать новое подключение к общей папке. В моем случае это папка \\Server\Backup на файловом сервере. Примечание: Для сети без домена имя пользователя необходимо указывать в формате: Компьютер\Пользователь
  3. Выбрать базы данных которые войдут в XML план восстановления. В моем случае это три базы — Account2013, Account2014, Account2015.
  4. Указать имя задачи — Создание XML плана для Account2013, Account2014, Account2015.
После выполнения всех действий, форма задачи будет выглядеть как на рисунке ниже. Обратите внимание на признак «Копировать недостающие файлы архивных копий в общую папку». Благодаря этой опции программа автоматически скопирует недостающие файлы бэкапов с локального диска SQL Server в сетевую папку. При этом, путь к файлу источнику программа определит самостоятельно по информации о созданных резервных копиях, которую SQL Server хранит в системной базе msdb.

Нажмем кнопку Принять и выберем созданную задачу в сценарий. На форме сценария установим флаг «Запуск сценария по расписанию» и укажем расписание: Каждый день, через 1 час начиная с 9:30 до 22:30. Напомню, что План обслуживания создает бэкап лога каждый час с 9:00 до 23:59. Таким образом QMB будет обновлять XML план восстановления со сдвигом в 30 минут (9:30, 10:30, 11:30 и т.д). Нужно отметить, что если бы бэкапы создавались Политикой обслуживания QMB, то XML файл плана восстановления обновлялся бы автоматически.

Сценарий должен выглядеть как на рисунке ниже.

Теперь проверим сценарий. Для этого нажмем кнопку «Выполнить». Если все настроено верно, то в сетевую папку будут скопированы файлы резервных копий и создан файл RestorationPlan.xml. Если в ходе работы программа не найдет нужных файлов резервных копий, то задача завершится ошибкой. Таким образом мы заранее узнаем о потенциальных проблемах. Например, довольно часто, администраторы для передачи базы данных создают её полный бэкап (без параметра COPY_ONLY), а после передачи сразу удаляют его чтобы он не занимал место. Однако при этом рвется цепочка резервных копий и восстановление на актуальный момент времени становится невозможно. Программа выявит эту проблему ещё на этапе создания XML плана восстановления. Сохраним сценарий. Теперь QMB через каждый час будет пересоздавать XML файл плана восстановления и копировать новые файлы бэкапов, которые создает штатный агент SQL Server. Нужно отметить, что задача по созданию XML плана копирует файлы, необходимые только для восстановления на последний возможный момент времени. При этом файлы копируются без папок т.е. все файлы будут размещены в указанной сетевой папке. В программе существует возможность настроить копирование подпапок, а даже удаление устаревших файлов в сетевой папке. Это можно сделать через пользовательскую задачу, содержащую CMD скрипт или используя Политику обслуживания QMB.

Восстановление на тестовом сервере

Восстановление по XML плану выполняется аналогично, с помощью специальной задачи, размещенной в сценарии. Однако восстановление должно выполняться на тестовом SQL Server (London), поэтому этот сервер тоже необходимо зарегистрировать в программе. Для этого в древовидном списке слева нажмем кнопку «Зарегистрировать сервер». Процедура регистрации сервера полностью аналогична описанной ранее.

После регистрации сервера откроется окно автономного сценария. Введем наименование Восстановление по XML плану с Srv01 и укажем его расписание: Каждый день в 23:00.

Теперь из формы сценария добавим новую задачу, аналогично тому как мы создавали задачу для создания XML плана. Однако, теперь в поле тип укажем Восстановление по XML плану, выберем ранее созданное подключение к сетевой папке и укажем имя XML файла. Переключатель База источник определяет какие именно базы данных XML плана восстановления необходимо восстанавливать.База данных в которую будет выполнено восстановление определяется одноименным переключателем. В нашем случае я буду восстанавливать в одноименные базы данных. Это значит, что на SQL Server будут созданы/перезаписаны базы данных имеющие аналогичные имена (в моем случае это три базы: Account2013, Account2014, Account2015). Таким образом эти базы будут актуализироваться до последнего состояния.

Режим Восстанавливать во временную базу данных следует выбирать, если восстановление выполняется с целью проверки файлов резервных копий и процедуры восстановления. В этом режиме QMB создаст временную базу с наименованием qmbTempRestoreDb[Случайный индекс], которая будет удалена после восстановления и проверки её целостности.

Сохраняем задачу и выбираем её в нашем сценарии.

Чтобы убедиться, что восстановление пройдет успешно выполним сценарий в ручном режиме. Программа последовательно восстановит каждую базу данных и выполнит тестирование её целостности.  В зависимости от размеров баз данных процедура может занимать значительное время. Сохраним сценарий. Теперь каждый день в 23:00 программа будет автоматически восстанавливать базы данных и в случае сбоя отправлять уведомления на Email. Кроме этого, используя XML файл плана восстановления, администратор с помощью программы может вручную, в несколько кликов, восстанавливать базы данных на других SQL Server.

С удовольствием отвечу на ваши вопросы в комментариях или по электронной почте [email protected] Спасибо за внимание!

habr.com

Как восстановить mysql базу из бэкапа

Импорт базы данных из файла дампа или бэкапа чаще всего осуществляется инструментами администрирования mysql или резервного копирования данных. Но что делать, если содержимое базы данных повреждено и его нужно восстановить из копии, а под рукой только сервер и файл с данными для импорта?

Вариант первый

Рассмотрим простейший случай, когда сервер mysql расположен на этой же системе:

mysql -u username -p database < /home/mydump.sql

mysql -u username -p database < /home/mydump.sql

Теперь подробнее:

  • Команда mysql — вызов утилиты управления сервером mysql;
  • Параметр -u username — указываем имя пользователя mysql, имеющего полномочия на добавление/обновление данных;
  • Параметр -p — указывает необходимость запроса пароля;
  • Параметр database — задает имя базы данных, в которую нужно импортировать данные;
  • И последняя часть: < /home/mydump.sql — передача данных для импорта.

После нажатия Enter, будет запрошен пароль пользователя username и, в случае его корректного ввода, выполнен импорт.

Вариант второй, немного сложнее

Как быть, если целевой сервер mysql находится за семью морями или просто в соседнем здании, но идти до него не хочется?

mysql -h remote.mysql.host -u username -p database < /home/mydump.sql

mysql -h remote.mysql.host -u username -p database < /home/mydump.sql

Все отличие от первого варианта только в явном указании удаленного сервера mysql для подключения: -h remote.mysql.host. указывать можно как имя хоста, так и его ip-адрес.

Разумеется, у пользователя username должны быть полномочия для удаленного подключения к серверу mysql.

p0vidl0.info