Резервное копирование и восстановление

Введение

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

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

Вы научитесь:

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

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

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

Создание резервной копии

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

Проверьте текущие данные:

sudo mysql -e "SELECT * FROM app_db.users;"

Вы должны увидеть список пользователей: Alice, Bob и Charlie.

Теперь создадим логическую резервную копию с помощью инструмента mysqldump. Логическая резервная копия — это текстовый файл со всеми SQL-командами, например CREATE TABLE и INSERT, необходимыми для полного восстановления базы данных.

Таким образом, файл резервной копии — не неизвестный двоичный объект. Обычно это SQL-скрипт, который позднее можно выполнить на сервере базы данных, чтобы восстановить структуру и данные.

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

sudo mysqldump app_db > ~/project/backup.sql

Разберём команду:

• mysqldump — утилита для экспорта содержимого базы данных.
• app_db — база данных, резервную копию которой нужно создать.
• > — оператор перенаправления Linux, который записывает вывод команды в файл.
• ~/project/backup.sql — путь к целевому файлу.

Убедитесь, что файл резервной копии создан:

ls -l ~/project/backup.sql

Можно также просмотреть начало файла и увидеть SQL-команды:

head -n 20 ~/project/backup.sql

Имитация потери данных

Теперь наступает самая неприятная часть. Чтобы проверить план восстановления, нам понадобится авария. Мы имитируем случайное удаление рабочей базы данных.

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

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

Удалите базу данных app_db с помощью команды DROP:

sudo mysql -e "DROP DATABASE app_db;"

Убедитесь, что авария произошла, попытавшись обратиться к базе данных:

sudo mysql -e "USE app_db;"

Вы должны увидеть ошибку: ERROR 1049 (42000): Unknown database 'app_db'.

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

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

К счастью, у нас есть файл backup.sql. Мы можем использовать его для восстановления данных.

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

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

Создайте пустую базу данных:

sudo mysql -e "CREATE DATABASE app_db;"

Импортируйте данные из файла резервной копии:

sudo mysql app_db < ~/project/backup.sql

Разберём команду восстановления:

• sudo mysql — подключается к серверу базы данных.
• app_db — указывает MySQL базу данных, которая будет использоваться как целевая.
• < — оператор перенаправления ввода Linux. Он читает содержимое файла и передаёт его команде mysql так, как если бы вы вводили эти команды вручную.

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

По сути, процесс восстановления передаёт SQL-инструкции обратно серверу. Иными словами, восстановление часто представляет собой контролируемое повторное выполнение инструкций, сохранённых в логической резервной копии.

Проверка восстановления данных

Последний и самый важный этап любого плана резервного копирования — проверка. То, что команда восстановления завершилась без ошибки, ещё не означает, что данные восстановлены правильно. Это необходимо проверить.

Это одна из важнейших рабочих привычек при администрировании систем: успех — не в том, что «команда завершилась». Успех означает, что после её выполнения система находится в правильном состоянии.

Снова выполните запрос к таблице users:

sudo mysql -e "SELECT * FROM app_db.users;"

Критерии успешного выполнения:

Вы должны увидеть исходные данные:

+----+---------+---------------------+
| id | name    | email               |
+----+---------+---------------------+
|  1 | Alice   | alice@example.com   |
|  2 | Bob     | bob@example.com     |
|  3 | Charlie | charlie@example.com |
+----+---------+---------------------+

Если вы видите Alice, Bob и Charlie, значит, вы успешно восстановили базу данных после аварии.

Итоги

В этой лабораторной работе вы успешно выполнили полный цикл аварийного восстановления. Вы научились:

• создавать резервную копию — экспортировать базу данных в файл с помощью mysqldump;
• уничтожать данные — имитировать потерю данных с помощью DROP DATABASE;
• восстанавливать данные — импортировать SQL-файл дампа с помощью перенаправления ввода <;
• проверять результат — подтверждать целостность восстановленных данных.

Регулярное резервное копирование — ваша основная защита от потери данных. В реальной среде этот процесс следует автоматизировать и регулярно проверять восстановлением.