Резервное копирование и восстановление баз данных sql server

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

Используйте команду mysqldump, чтобы создать дамп текстового файла вашей базы данных, который будет управляться MySQL. Дамп текстового файла — это текстовый файл, содержащий команды SQL, необходимые для воссоздания базы данных с нуля.

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

mysqldump database_name> database_name.sql

Эта команда создаст резервную копию и отправит ее в файл .sql. Он только сделает копию вашей базы данных и не повлияет на нее.

Используйте следующую команду для резервного копирования нескольких баз данных одновременно.

mysqldump –database database_one database_two> two_databases.sql

Database_one — это имя первой базы данных, а database_two — имя второй базы данных, для которой вы хотите создать резервную копию. Оба будут сохранены в одной базе данных.

Если вы хотите сделать резервную копию всех ваших баз данных MySQL на сервере, используйте следующую команду, чтобы создать один файл резервной копии .sql, который будет содержать все ваши базы данных.

mysqldump –all-database> all_databases.sql

Использование phpMyAdmin для резервного копирования или восстановления MySQL

Если вы используете phpMyAdmin, резервное копирование и восстановление базы данных MySQL очень просто.

Функция экспорта используется для резервного копирования, а функция импорта — для восстановления.

Шаг 1: Создание резервной копии базы данных MySQL

1. Откройте phpMyAdmin. В дереве каталогов слева щелкните базу данных, резервную копию которой вы хотите создать.

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

2. Нажмите «Экспорт» в меню в верхней части окна.

Вы увидите раздел «Метод экспорта». Используйте «Быстро», чтобы сохранить копию всей базы данных. Выберите «Пользовательский», чтобы выбрать отдельные таблицы или другие специальные параметры.

Оставьте для поля «Формат» значение SQL, если у вас нет веских причин его изменить.

3. Нажмите кнопку Перейти. Если вы выбрали Быстрый, ваш веб-браузер загрузит копию базы данных в указанную вами папку загрузок. Вы можете скопировать ее в безопасное место.

Шаг 2: Очистите старую информацию базы данных

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

Это может привести к созданию дубликатов таблиц, что вызовет ошибки и конфликты.

1. Откройте phpMyAdmin, на панели навигации слева выберите базу данных, которую вы хотите восстановить.

2. Нажмите на флажок «Отметить все» в нижней части. Затем в выпадающем меню с надписью With selected выберите Drop.

3. Инструмент должен предложить вам подтвердить, что вы хотите продолжить. Нажмите «Да».

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

Шаг 3: Восстановите резервную копию базы данных MySQL

В phpMyAdmin для восстановления базы данных используется инструмент Импорт.

1. В меню сверху нажмите Импорт.

2. Первый раздел называется «Файл для импорта». Парой строк ниже есть строка, начинающаяся со слов «Browse your computer», и кнопка с надписью Choose File. Нажмите эту кнопку.

3. С помощью диалогового окна перейдите к месту, где вы сохранили файл экспорта, который хотите восстановить. Оставьте все параметры по умолчанию. (Если вы создали резервную копию с другими параметрами, вы можете выбрать их здесь).

4. Нажмите кнопку Go.

Заключение

Теперь вы знаете, как создавать резервные копии и восстанавливать базы данных MySQL с помощью phpMyAdmin или mysqldump.

Надеюсь, эта статья понадобилась вам только для того, чтобы показать, как экспортировать базу данных в phpMyAdmin. Но даже если вам не так повезло, резервное копирование или восстановление — довольно простая задача.

Использование Transact-SQL

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

• имя базы данных для создания резервной копии;
• устройство резервного копирования, на которое записывается полная резервная копия базы данных.

Базовая структура синтаксиса Transact-SQL для полного резервного копирования базы данных:

BACKUP DATABASE database TO backup_device ] ;

Параметр	Описание
database	База данных для резервного копирования.
backup_device	Указывает список от 1 до 64 устройств резервного копирования, используемых для создания резервной копии. Можно указать как физическое устройство резервного копирования, так и соответствующее логическое устройство, если оно уже определено. Для указания физического устройства резервного копирования используйте параметр DISK или TAPE. { DISK | TAPE } = physical_backup_device_name Дополнительные сведения см. в разделе Устройства резервного копирования (SQL Server).
WITH with_options	Используется для указания одного или нескольких параметров, o. Сведения о некоторых основных параметрах см. в пункте 2.

При необходимости укажите один параметр WITH или несколько. Здесь описываются некоторые основные параметры WITH. Сведения о всех параметрах WITH см. в разделе BACKUP (Transact-SQL).

Основные параметры WITH резервного набора данных:

• { COMPRESSION | NO_COMPRESSION } : Только в версии SQL Server 2008 Enterprise и выше указано, выполняется ли команда backup compression для этой резервной копии, переопределяя значение по умолчанию на уровне сервера.
• ENCRYPTION (ALGORITHM, SERVER CERTIFICATE | ASYMMETRIC KEY) : Только для SQL Server 2014 и выше укажите используемый алгоритм шифрования, а также сертификат или асимметричный ключ для шифрования.
• DESCRIPTION = { ‘ text ‘ | @ text_variable }: Задает произвольное текстовое описание резервного набора данных. В этой строке может содержаться до 255 символов.
• NAME = { имя_резервного_набора_данных | @ переменная_резервного_набора_данных } : Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если имя не указано, оно остается пустым.

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

Чтобы отформатировать носитель резервной копии, используйте параметр FORMAT:

FORMAT

Используйте предложение FORMAT при первом обращении к носителю или при необходимости перезаписать все существующие данные. При необходимости назначьте новому носителю имя и описание.

Важно!

Будьте предельно осторожны, используя предложение FORMAT инструкции , так как оно удаляет все резервные копии, сохраненные ранее на носителе резервных копий.

A. Резервное копирование на дисковое устройство

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

Б. Резервное копирование на ленточное устройство

В следующем примере создается полная резервная копия базы данных на ленте в дополнение к предыдущим резервными копиям.

В. Резервное копирование на логическое ленточное устройство

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

Как сделать резервную копию БД MySQL и MariaDB в Windows

Резервную копию можно создать в графическом веб-интерфейсе в phpMyAdmin. Если вы хотите сделать бэкап сразу всех баз данных, то перейдите на главную страницу phpMyAdmin, оттуда перейдите во вкладку Экспорт. Далее всё достаточно просто.

Аналогично при бэкапе отдельных баз данных: перейдите на страницу интересующей БД, а далее во вкладку Экспорт.

phpMyAdmin — это прослойка на PHP между СУБД и пользователем, по этой причине скорость создания дампа очень большой базы займёт больше времени, чем если создавать его напрямую через специальную программу от MySQL или MariaDB.

Если вы решили сделать бэкап базы данных MySQL из командной строки в Windows, то для этого понадобиться утилита mysqldump.exe, она поставляется вместе с MySQL и расположена в каталоге с установленной MySQL/MariaDB в папке bin. Например, если СУБД установлена в C:\Server\bin\mysql-8.0, то программа mysqldump.exe будет находиться в папке C:\Server\bin\mysql-8.0\bin\.

Для её использования откройте командную строку и перетащите туда программу. Программу можно использовать с разнообразными опциями.

Если вы хотите сделать резервную копию всех баз данных в один файл, то выполните:

mysqldump.exe -u root -p --all-databases > all-databases.sql

Кстати, файл нужно искать в той папке, которую вы видите в приглашении командной строки.

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

mysqldump.exe -u root -p rsyslog > rsyslog.sql

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

mysqldump.exe -u root -p --databases rsyslog syslog > rsyslog_syslog.sql

Чтобы сделать резервную копию только одной таблицы (wp_posts) из базы данных (wordpress):

mysqldump.exe -u root -p wordpress wp_posts > wordpress_posts.sql

Для того, чтобы сделать резервную копию нескольких таблиц, перечислите их через пробел после названия БД:

mysqldump.exe -u root -p wordpress wp_posts wp_comments > wordpress_posts_comments.sql

7.4. Как сделать импорт или экспорт базы данных через SSH? Работа с БД по SSH

Для импорта сначала загружаете дамп на сервер. Дамп должен быть в формате .sql
Далее подключаетесь на сервер по ssh и выполняете команду:

mysql -u пользователь_БД -p имя_БД < файл_дампа_БД

В случае неудачи всегда будет указанна ошибка из за которой импорт не удался или прервался.

Для экспорта существует утилита, которая позволяет сделать бэкап базы данных в традиционном SQL-формате – mysqldump. Общий вид в командной строке:

mysqldump –u пользователь_БД -p имя-БД > файл_дампа_БД

Также утилита имеет много опций и ключей, рассмотрим несколько основных полезных примеров по использованию mysqldump.

mysqldump -–all-databases -uUSER -pPASSWORD > /path/mysql-db-server.sql

Команда с опцией -–all-databases сохраняет все базы данных пользователя USER на MySQL-сервере.

mysql -uUSER -pPASSWORD < /path/mysql-db-server.sql

Восстанавливает все БД mysql пользователя USER. Если USER — root — то все БД.

mysqldump -uUSER -pPASSWORD DATABASE table1 table2 table3 > /path/ DATABASE_t1-t2-t3.sql

Сохраняет таблицы table1, table2, table3, из базы DATABASE в файле DATABASE_t1-t2-t3.sql.

mysqldump —no-data -uUSER -pPASSWORD DATABASE > /path/DATABASE-schema.sql

Указав опцию —no-data команда сохранит структуру таблиц (без данных) в файле DATABASE_schema.sql.

mysqldump —add-drop-table -uUSER -pPASSWORD DATABASE > /path/DATABASE.sql

Опция —add-drop-table добавит команду DROP TABLE (удаление таблицы) перед созданием таблиц.

mysqldump —databases -uUSER -pPASSWORD DATABASE > /path/DATABASE.sql

Опция —databases добавит команду CREATE DATABASE перед созданием базы данных. Это позволяет не создавать и не задавать базу данных при восстановлении.

mysqldump -uUSER –pPASSWORD –h192.168.0.1 DATABASE > /path/DATABASE.sql

Команда сделает бэкап базы DATABASE с сервера с ip-адресом 192.168.0.1

mysqldump —max_allowed_packet=8M -uUSER –pPASSWORD DATABASE > /path/DATABASE.sql

Опция —max_allowed_packet=8M принудительно изменит размер пакета считываемых данных в оперативную память размером в 8 мегабайт.

mysqldump —quick -uUSER –pPASSWORD DATABASE > /path/DATABASE.sql

Опция —quick заставляет команду записывать данные непосредственно на диск.

mysqldump —default-character-set=cp1251 -uUSER –pPASSWORD DATABASE > /path/DATABASE.sql

Принудительно указываем кодировку cp1251.

mysqldump -uUSER –pPASSWORD DATABASE | gzip -c /path/DATABASE.sql.gz

Этой последовательностью получаем архивированный бэкап с помощью утилиты gzip (для последующего восстановления необходимо будет предварительно извлечь из архива).

Заливаем архив бекапа в базу
gunzip < /path/to/outputfile.sql.gz | mysql -u USER -pPASSWORD DATABASE
или так
zcat /path/to/outputfile.sql.gz | mysql -u USER -pPASSWORD DATABASE

Создаём новую базу данных
mysqladmin -u USER -pPASSWORD create NEWDATABASE

Для просмотра списка баз данных можно использовать команду:
mysqlshow -u USER -pPASSWORD

А так же можно посмотреть список таблиц базы:
mysqlshow -u USER -pPASSWORD DATABASE

где:

USER — это имя пользователя базы данных;

PASSWORD — пароль пользователя;

SERVER — это имя (или ip-адрес) сервера базы данных;

DataBase — наименование базы данных;

NameFile.sql — имя файла, в который будет помещен дамп базы данных.

Как восстановить базу данных MySQL в cPanel

Чтобы восстановить базу данных, откройте интерфейс Backup (Создать резервную копию), который вы найдете в разделе Files (Файлы) на главной странице cPanel.

Английский скриншот cPanel Backup:

Русский скриншот cPanel Создать резервную копию:

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

В разделе Restore a MySQL Database Backup (Восстановить резервную копию базы данных MySQL) нажмите Choose File (Выбрать файл) и выберите файл SQL с локальной машины. Нажмите кнопку Upload (Загрузить) и cPanel импортирует файл.

Для более сложного импорта SQL или для репликации, а не замены базы данных, вы можете использовать инструмент phpMyAdmin, описанный в предыдущем разделе. Однако для стандартного восстановления предпочтительнее использовать страницу Backup, поскольку cPanel обрабатывает префиксы баз данных и настраивает SQL-запросы.

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

2011: Dell EMC European Disaster Recovery Survey

Dell EMC опубликовала результаты исследования European Disaster Recovery Survey 2011, проведенного по заказу EMC. Исследование показало, что 74% европейских компании не уверены, что смогут полностью восстановить системы и данные после аварии и более половины компаний (54%) теряли данные или сталкивались с перебоями в работе ИТ в течение последних 12 месяцев. Результаты исследования указывают, что компаниям нужно сосредоточить усилия на резервном копировании и восстановлении после аварий, чтобы гарантировать непрерывность бизнес-процессов, как в случае природных катастроф, так и типичных сбоев в работе ИТ.

Подготовленный по заказу EMC независимым исследовательским агентством Vanson Bourne отчет анализирует состояние резервного копирования и аварийного восстановления данных в европейских компаниях и позволяет оценить, насколько хорошо компании защищены от потери данных и перебоев в работе ИТ. European Disaster Recovery Survey 2011: Data Today Gone Tomorrow: How Well Companies Are Poised For IT Recovery.

Выводы на основе исследования:

Риск сохраняется и сбои чаще происходят из-за проблем ИТ, а не природных катастроф.

Исследование показало, что самые серьезные проблемы не связаны с форсмажорными ситуациями. Три типичных причины потери данных и перебоев ИТ систем следующие:

• Неисправность оборудования: 61%
• Сбой в энергоснабжении: 42%
• Сбои в работе программного обеспечения: 35%

При этом только 7% случаев потеря данных или сбой ИТ систем были вызваны природными катастрофами, и 8% — злонамеренными действиями персонала компании. Независимо от причины потери данных или сбоя ИТ систем, 44% компаний после таких инцидентов пересмотрели свои процедуры резервного копирования и восстановления данных. Более того, 27% компаний после аварии увеличили свои затраты на технологии для резервного копирования и восстановления.

Экономические последствия: потери прибыли из-за перебоев в работе ИТ систем.

Исследование дало количественную оценку потерь бизнеса от простоев ИТ систем. Основной ущерб был вызван:

• Падением продуктивности сотрудников: 43%
• Упущенной прибылью: 28%
• Задержкой разработки новых продуктов: 27%

Из-за сбоя систем в среднем компании потеряли два рабочих дня, что соответствует потере 28 391 человеко-часов в компании, где работает около двух тысяч человек.

В среднем по Европе 49% компаний должны иметь план восстановления данных после аварий в соответствии с условиями страхования бизнеса или требованиями законодательства. Применяя правильный подход к резервному копированию и восстановлению данных после аварий, компании могут сократить расходы на страхование. Более четверти опрошенных компаний получили от своего страховщика предложение уменьшить взносы на страхование в зависимости от применяемой ими стратегии резервного копирования и восстановления ИТ систем после аварий.
Распутывая ленту: 40% компаний по-прежнему полагаются на ленту, но большинство из них хотят отказаться от нее.

Как показывают результаты исследования, в среднем компании тратят 10% своего ИТ-бюджета на резервное копирование и восстановление данных. Причем 29% компаний считают, что эти расходы недостаточны. 40% компаний по-прежнему используют ленту для резервного копирования и восстановления данных и ежегодно в среднем тратят €74 000 на транспортировку, хранение, проверку и замену кассет с лентой. В 10% компаний, где лента используется для восстановления данных после аварий, сотрудники хранят дома ленты с резервными копиями.

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

• Низкая скорость восстановления данных с ленты — 39%
• Требуется более быстрое резервное копирование и восстановление 33%
• Низкая надежность ленты 26%

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

Как создать резервную копию базы данных MySQL в cPanel

Наша цель — сделать дамп базы данных и загрузить полученный SQL-файл на наш компьютер, где мы можем сохранить его или переместить в более безопасное место. Это можно сделать из командной строки с помощью клиента «mysql», но cPanel MySQL backup and restore предлагает простой в использовании интерфейс.

Любой из этих методов может быть использован для резервного копирования баз данных на вашем сервере. Для этого примера мы будем использовать установку WordPress и базу данных WordPress. Небольшое предупреждение, прежде чем мы продолжим: сайт WordPress состоит из базы данных и файлов, и полная резервная копия WordPress должна включать и то, и другое.

Английский скриншот cPanel Backup:

Русский скриншот cPanel Backup:

1. Сначала выберите пункт Backup (Создать резервную копию) в разделе Files (Файлы) на главной странице. Эта страница представляет собой удобный унифицированный интерфейс для резервного копирования файлов и баз данных, связанных с вашей учетной записью cPanel.
2. Далее найдите раздел Download a MySQL Database Backup (Загрузить резервную копию базы данных MySQL), где вы увидите список баз данных, которые вы можете загрузить.
3. Наконец, нажмите на выбранную вами базу данных, чтобы инициировать резервное копирование, и cPanel создаст SQL-файл и сохранит его в место загрузки по умолчанию на вашем компьютере.

Это самый простой способ резервного копирования MySQL в cPanel, но вы также можете использовать встроенный инструмент администрирования phpMyAdmin для настройки параметров экспорта или резервного копирования нескольких баз данных одновременно.

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

Процесс прерывается из-за ограничений на хостинге

На тарифах виртуального хостинга Year+, Optimo+, Century+, Millennium+ установлены ограничения на использование процессами процессоров сервера, в связи с чем распаковка тяжелых архивов может завершаться принудительно. В таких случаях (за исключением дампов с расширением .sql.zip) вы можете использовать команду pv, например:

cat имя_дампа.sql | pv -L 2M | mysql -u'база_данных' база_данных -p'пароль_базы_данных'

ERROR #1273: Unknown collation

При импорте может наблюдаться подобная ошибка:

cat имя_дампа.sql | mysql -u'база_данных' база_данных -p'пароль_базы_данных'
ERROR 1273 (HY000) at line 29: Unknown collation: 'utf8mb4_unicode_520_ci'

В этом случае, оставив исходный файл без изменений, создайте копию дампа, заменив в ней строки, отвечающие за Collation и кодировку:

cat имя_дампа.sql | sed 's/utf8mb4_unicode_520_ci/utf8_unicode_ci/g' | sed 's/utf8mb4/utf8/g' > имя_дампа_new.sql

После чего осуществите импорт измененного дампа стандартным способом.

ERROR #1062: Duplicate entry

Может встречаться ошибка:

ERROR 1062 (23000) at line 53: Duplicate entry '1' for key 'PRIMARY'

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

cat имя_дампа.sql | sed 's/INSERT/REPLACE/' > имя_дампа_new.sql

После импортируйте измененный дамп как обычно.