Linux восстановить базу данных

Резервное копирование и восстановление баз данных SQL Server в Linux

Вы можете создавать файлы резервных копий баз данных из SQL Server на Linux различными способами. На сервере Linux можно использовать sqlcmd для подключения к SQL Server и создания резервных копий. Из Windows можно подключиться к SQL Server в Linux и создать резервные копии с помощью пользовательского интерфейса. Функция резервного копирования одинакова для разных платформ. Например, можно выполнять резервное копирование баз данных локально, на удаленные диски или в Microsoft Хранилище BLOB-объектов Azure.

SQL Server на Linux поддерживает резервное копирование в Хранилище BLOB-объектов Azure только с использованием блочных BLOB-объектов. Использование ключа хранилища для резервного копирования и восстановления приведет к использованию страничного BLOB-объекта, что не поддерживается. Используйте вместо этого подписанный URL-адрес. Сравнение блочных и страничных BLOB-объектов см. в разделе Резервное копирование в блочные и страничные BLOB-объекты.

Резервное копирование базы данных

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

sqlcmd -S localhost -U SA -Q "BACKUP DATABASE [demodb] TO DISK = N'/var/opt/mssql/data/demodb.bak' WITH NOFORMAT, NOINIT, NAME = 'demodb-full', SKIP, NOREWIND, NOUNLOAD, STATS = 10" 

При выполнении команды SQL Server запросит пароль. После ввода пароля оболочка возвратит результаты выполнения резервного копирования. Пример:

Password: 10 percent processed. 21 percent processed. 32 percent processed. 40 percent processed. 51 percent processed. 61 percent processed. 72 percent processed. 80 percent processed. 91 percent processed. Processed 296 pages for database 'demodb', file 'demodb' on file 1. 100 percent processed. Processed 2 pages for database 'demodb', file 'demodb_log' on file 1. BACKUP DATABASE successfully processed 298 pages in 0.064 seconds (36.376 MB/sec). 

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

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

sqlcmd -S localhost -U SA -Q "BACKUP LOG [demodb] TO DISK = N'/var/opt/mssql/data/demodb_LogBackup.bak' WITH NOFORMAT, NOINIT, NAME = N'demodb_LogBackup', NOSKIP, NOREWIND, NOUNLOAD, STATS = 5" 

Восстановление базы данных

В следующем примере sqlcmd подключается к локальному экземпляру SQL Server и восстанавливает базу данных demodb. Вариант NORECOVERY используется для обеспечения дополнительного восстановления резервных копий файлов журнала. Если вы не планируете восстанавливать дополнительные файлы журналов, удалите NORECOVERY .

sqlcmd -S localhost -U SA -Q "RESTORE DATABASE [demodb] FROM DISK = N'/var/opt/mssql/data/demodb.bak' WITH FILE = 1, NOUNLOAD, REPLACE, NORECOVERY, STATS = 5" 

Если вы случайно используете параметр NORECOVERY, но у вас нет дополнительных резервных копий файлов журнала, выполните команду RESTORE DATABASE demodb без дополнительных параметров. При этом восстановление завершается, а база данных остается в рабочем состоянии.

Восстановление журнала транзакций

Следующая команда восстанавливает предыдущую резервную копию журнала транзакций.

sqlcmd -S localhost -U SA -Q "RESTORE LOG demodb FROM DISK = N'/var/opt/mssql/data/demodb_LogBackup.bak'" 

Резервное копирование и восстановление с помощью SQL Server Management Studio (SSMS)

Среду SSMS можно использовать с компьютера Windows для подключения к базе данных Linux и резервного копирования через пользовательский интерфейс.

Используйте последнюю версию SSMS для подключения к SQL Server. Чтобы скачать и установить последнюю версию, см. статью Скачивание SSMS. Дополнительные сведения об использовании SSMS см. в статье Управление SQL Server на Linux с помощью SSMS.

Ниже приведены пошаговые инструкции по резервному копированию с помощью SSMS.

1. Запустите SSMS и подключитесь к экземпляру SQL Server на Linux.
2. В обозревателе объектов щелкните правой кнопкой мыши базу данных, выберите пункт Задачи, а затем — Архивировать. .
3. В диалоговом окне Backup Up Database (Создание резервной копии базы данных) проверьте параметры и варианты и выберите ОК.

SQL Server завершает резервное копирование базы данных.

Восстановление с помощью SQL Server Management Studio (SSMS)

Ниже приведены пошаговые инструкции по восстановлению базы данных с помощью SSMS.

1. В SSMS щелкните правой кнопкой мыши пункт Базы данных и выберите Restore Databases. (Восстановить базы данных. ).
2. В разделе Источник выберите Устройство: и затем выберите многоточие (. ).
3. Найдите файл резервной копии базы данных и выберите ОК.
4. В разделе План восстановления проверьте параметры и файл резервной копии. Щелкните ОК.
5. SQL Server восстанавливает базу данных.

См. также

Примите участие в разработке документации по SQL

Знаете ли вы, что содержимое SQL можно изменить самостоятельно? Это не только улучшит нашу документацию, но и даст вам статус участника в создании этой страницы.

Источник

Как восстановить базу MySQL

Обновлено: 13.04.2023 Опубликовано: 25.10.2016

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

Подготовка базы

Подключаемся к командной оболочке mysql:

* данной командой мы подключимся к СУБД под пользователем root. Опция -p потребует ввода пароля.

Для восстановления базы сначала необходимо ее создать:

> CREATE DATABASE db DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* подробнее про создание баз читайте на странице Создание и удаление баз в MySQL/MariaDB.

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

> CREATE USER ‘dbuser’@’localhost’ IDENTIFIED BY ‘password’;

> GRANT ALL PRIVILEGES ON db.* TO ‘dbuser’@’localhost’;

Из файла через командную строку

Если при создании дампа использовалась gzip, сначала распаковываем архив:

Для удобства, создадим переменную с именем базы:

Команда выполняется из UNIX-shell:

* где root — учетная запись, от которой идет подключение к серверу баз данных; DNBAME — имя базы, которую необходимо восстановить (переменная, которую мы задали ранее); /tmp/recovery.sql — файл дампа, из которого восстанавливаем базу.
* можно также добавить опцию -v — она позволит показать на экране ход процесса, однако, она очень сильно снижает скорость восстановления — не рекомендуется ее использовать для больших баз.

На самом деле, если внутри дампа есть указание на переход к конкретной таблице (USE table), то восстановление будет выполняться в нее, а не ту таблицу, которую мы указали в переменной DBNAME. Как это проверить и изменить сказано ниже.

Если у нас много файлов, которые нужно импортировать, можно выполнить следующую команду:

cat /tmp/*.sql | mysql -u root -p db

* в данном случае мы прочитаем из каталога /tmp все файлы, заканчивающиеся на .sql и импортируем их содержимое в базу.

С помощью phpMyAdmin

Выбираем базу, которую нужно восстановить. Переходим на вкладку Импорт — кликаем по кнопке Выберите файл:

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

Нажимаем по OK и ждем восстановления данных.

Пропускать ошибки

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

Суть сводится к простому добавлению ключа —force или -f:

Восстановление в другую базу

По умолчанию, восстановление происходит в ту базу, для которой указан переход в самом дампе с помощью инструкции:

* где database_name — имя конкретной базы.

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

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

Если файл дампа большой, открывать его на редактирование может оказаться непростой задачей. Поменять название базы можно с помощью sed:

sed ‘s/USE `database_name`;/USE `new_database_name`;/’ -i /tmp/dump.sql

* в данном примере мы заменим имя базы database_name на new_database_name в файле /tmp/dump.sql.

Восстановление в другую таблицу

Команда mysql не предусматривает возможности восстановить дамп только для одной таблицы. Есть два варианта это обыграть.

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

Чтобы выполнить развертывание конкретной таблицы, нам нужно сначала сделать восстановление в отдельную базу, после чего скопировать таблицу в нужную базу командой на подобие этой (должна выполняться в среде SQL):

> INSERT INTO database_name.table_name SELECT * FROM new_database_name.table_name;

* в данном примере выполняется копирование содержимого таблицы table_name из базы данных new_database_name в базу database_name.

2. Резервирование только одной таблицы.

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

mysqldump -uroot -p database_name table_name > /tmp/dump_base_table.sql

После чего уже выполняем восстановление из дампа.

Возможные ошибки

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

MySQL server has gone away

Во время восстановления базы может выскочить ошибка:

ERROR 2006 (HY000) at line xxx: MySQL server has gone away.

Как правило, ее причина в низком значении параметра max_allowed_packet, который отвечает за ограничение выполнения команд из файла. Посмотреть текущее значение можно командой в mysql:

> SHOW VARIABLES LIKE ‘max_allowed_packet’;

Чтобы увеличить значение параметра, открываем конфигурационный файл my.cnf:

* в некоторых версиях СУБД конфиг может находится по пути /etc/my.cnf.d/server.cnf.

В разделе [mysqldump] редактируем или добавляем:

[mysqldump]
.
max_allowed_packet = 512M

* значение для данного параметра не обязательно должно быть таким большим.

Перезапускаем mysql одной из команд:

systemctl restart mariadb

Row size too large

Ошибка выскакивает после небольшого времени работы восстановления. Более полный текст выглядит, примерно, так:

ERROR 1118 (42000) at line 608: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

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

Для решения проблемы мы можем добавить опцию innodb_strict_mode со значением 0. Данная опция регламентирует более строгий режим работы СУБД. Это грубое решение, которое позволит нам добиться результата, но мы можем выполнить настройку тонко — об этом можно прочитать на соответствующей странице блога mithrandir.ru.

Мы же сделаем все по-быстрому. Открываем конфигурационный файл СУБД — его местоположение зависит от версии и реализации, например:

* это пример расположения для базы MariaDB 10. Более точное расположение можно найти в файле /etc/my.cnf.

Приводим опцию innodb_strict_mode к виду:

[mysqld]
.
innodb_strict_mode = 0

systemctl restart mariadb

* в данном примере мы перезапустили сервис для mariadb.

Источник