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

Резервное копирование и восстановление СУБД MySQL

О необходимости выполнения резервного копирования для любых важных данных, будь то файлы, образ ОС или базы данных, написано множество статей. Поэтому убеждать читателя в необходимости бэкапить СУБД MySQL я не буду. Напомню лишь, что помимо бэкапа необходимо регулярно проверять резервные копии на возможность восстановления.

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

Сколько терять и за сколько восстанавливать

Итак, вспомним такие понятия как RPO и RTO.

Recovery Point Objective – максимально допустимый интервал за который мы можем позволить себе потерять данные. Например, если у нас RPO равно двум часам, то в случае сбоя мы потеряем данные максимум за последние два часа.

Recovery Time Objective — промежуток времени, в течение которого БД может оставаться недоступной в случае сбоя. То есть это то время, за которое мы обязуемся восстановить наши данные из бэкапа.

На картинке расстояние до сбоя это RPO (обычно измеряется в часах) а RTO это то расстояние-время, которое у нас останется на восстановление.

Однако, RTO и RPO нельзя назвать чисто техническим понятиями, в определенной степени это характеристики, позволяющие обеспечивать непрерывность бизнес процессов. Значения величин RTO и RPO должны указываться владельцами бизнес систем, а ИТ специалисты должны в ответ выдвинуть свои требования относительно оборудования и программного обеспечения для выполнения этих требований. Например, если бизнесу необходимо, чтобы в случае аварии данные были потеряны не более чем за час, а процесс восстановления должен занимать не более 30 минут, то админы в ответ должны сказать хранилища какого размера им необходимы, с какими характеристиками по скорости работы дисков и каналов передачи данных. То есть ИТ готовит спецификацию на необходимое оборудование и ПО с ценами, бизнес посмотрев на все это пони мает, что может быть два или даже три часа простоя это не так уж и страшно, да и восстанавливаться можно подольше. В результате согласовываются новые значения RTO и RPO и стоимость спецификации снижается. Такой подход позволяет разделить ответственность между всеми сторонами. Однако очень часто присутствует другой подход к политике резервного копирования, когда ИТ сами устанавливают значения RTO и RPO и сами пытаются их выполнять без согласования с бизнесом, что является в корне неверным.

Виды бэкапов в MySQL

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

Физический бэкап предполагает создание резервных копий на файловом уровне. В простейшем случае, мы просто останавливаем базу и копируем файлы из рабочей папки (/var/lib/mysql/db/). Просто и быстро. Но не стоит забывать, что при использовании для бэкапа команд операционной системы (например cp) возможны ситуации, когда полученные после копирования файлы окажутся поврежденными и база не будет работать корректно. Такое может произойти, например при копировании в моменты высокой загрузки сервера или при копировании по сети.

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

А кроме того, остановка базы даже на короткое время в продакшене – идея не слишком хорошая, поэтому лучше все-таки делать бэкапы на лету.

Логический бэкап лишен этих недостатков, но восстановление большой БД может занять значительное время, так как выполнение всех команд из бэкапа процесс долгий.

Альтернативным вариантом является использование сторонних средств резервного копирования, например Percona XtraBackup.

Логический бэкап

Для экспорта информации из базы данных в формате SQL можно использовать утилиту mysqldump. Вот ее синтаксис:

$ mysqldump опции имя_базы [имя_таблицы] > файл.sql

mysqldump —all-databases > dump-data.sql

То есть мы указываем имя базы или таблицы и перенаправляем вывод в файл. Но бэкап можно делать также удаленно. Как правило в сети имеется централизованный сервер резервного копирования с которого осуществляются подключения к узлам для выполнения бэкапов. В таком случае синтаксис команды будет следующий:

mysqldump -h хост -P порт -u имя_пользователя -p имя_базы > data-dump.sql

Процесс восстановления тоже достаточно прост. Необходимо создать новую базу и в ней выполнить перенаправление скрипта из файла бэкапа.

mysql> CREATE DATABASE new_database;

shell> mysql < dump-data.sql

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

В следующем примере мы делаем бэкап базы,заданной в переменной DBNAME и затем сжимаем полученный файл с помощью gzip.

mysqldump -uroot -p $ | gzip > /tmp/$.sql.gz

Когда нужно не все

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

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

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

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

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

Укажем значение параметров log-bin, expire_log_days, max_binlog_size.

Далее перезапустим сервис.

service mysql restart

Каждая инкрементальная копия содержит изменения, которые были созданы с момента последней резервной копии, но самая первая резервная копия должна быть полной копией. Вам необходимо создать полную резервную копию через mysqldump, используя параметры —flush-log и —delete-master-logs, ––delete-master-logs удалит старые двоичные файлы журнала, а —flush-log инициализирует запись нового двоичного файла журнала. Результаты заархивируем.

mysqldump —flush-logs —delete-master-logs —single-transaction —all-databases | gzip > /var/backups/mysql/$(date +%d-%m-%Y_%H-%M-%S)-inc.gz

Мы не можем просто воспользоваться командой cp потому файлы журналов сейчас используются БД. Поэтому вам необходимо выполнить команду FLUSH BINARY LOGS , которая начнет запись в новый двоичный файл журнала. В этом случае все накопленные двоичные файлы журнала могут быть безопасно скопированы. После копирования двоичных файлов журнала они должны быть удалены, чтобы при следующем копировании они не дублировали уже созданные резервные копии данных. Для этого воспользуемся PURGE BINARY LOGS . Для автоматизации этих задач ниже приведен небольшой скрипт, который выполняет эти действия, а также помещает двоичные файлы журнала в архив.

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

0 0 * * * sudo mysqldump —flush-logs —delete-master-logs —single-transaction —all-databases | gzip > /var/backups/mysql/full_$(date +%d-%m-%Y_%H-%M-%S).gz

*/60 * * * * sudo bash

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

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

unzip \*.zip -d logs

В отличие от полной резервной копии, созданной с помощью mysqldump, двоичные файлы журнала содержат двоичные данные. Перед их восстановлением их необходимо преобразовать в sql-выражения, и за это отвечает утилита mysqlbinlog. Эта утилита получает двоичные файлы журнала в качестве входных данных и возвращает инструкции sql. Несколько файлов можно перечислить через пробел. Не забываем о том, что порядок перечисления файлов очень важен, именно в таком порядке SQL операторы и будут выполнены.

mysqlbinlog mysql-bin.000040 mysql-bin.000059 mysql-bin.000123 | sudo mysql -u root

А вообще можно не перечислять файлы вручную, а просто воспользоваться командой:

mysqlbinlog $(ls) | sudo mysql -u root

Таким образом можно снизить время, необходимое на создание бэкапов и сэкономить место для их хранения.

Заключение

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

Также напоминаю о том, что уже скоро в OTUS пройдет открытое занятие, посвященное погружению в PostgreSQL. Урок будет включать в себя:

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

Способы развертывания и установки, сама установка.

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

Как восстановить поврежденную базу данных Microsoft Access (один из рабочих вариантов)

Здравствуйте!

Как вы считаете, какой именно актив является одним из важнейших для любого бизнеса? Деньги, люди, хорошее лобби в правительстве? Это всё, конечно, важно, но многие забывают об еще одном — информации!

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

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

Что делать если нет резервной копии базы данных Microsoft Access?

Причины проблем с базами данных

Сейчас я говорю, разумеется, о базах данных в формате Microsoft Access. Чаще всего они перестают открываться по следующим причинам:

1. Прерванный процесс изменения базы данных Microsoft Access. Например, пользователь пытался внести какие-то изменения в удаленную базу данных, но из-за сбоев сети он не смог закончить операцию. В этом случае, приложение Microsoft Access помечает базу как поврежденную. Ее легко восстановить, но некоторые данные могут быть утеряны безвозвратно;
2. Вирусы. До боли знакомая проблема. Без комментариев;
3. Проблемы с «железом» (компьютеры, блоки питания, сетевые устройства, диски и так далее). Что угодно: потеря пакетов на сетевых картах, поврежденные сектора на диске и многое другое также могут вызывать порчу базы данных;
4. Некорректная работа плагинов для Microsoft Access, либо их неверная установка;
5. Попытка одновременного доступа к одной базе данных и ее изменение;
6. Сбои электропитания при работе с базой данных, вызывающие самопроизвольное выключение системы.

С сайта анектодов.нет (а вы думаете куда подевался свет?).

👉 Кстати!

Самый легкий способ предотвратить почти все проблемы с базой данных — регулярно делать резервную копию!

👉 Вообще, если база вдруг перестала открываться, в окне приложения вы видите кучу странных ошибок, другой копии файла нет — для начала успокойтесь и не предпринимайте поспешных мер!

Если нам немного повезет, то, возможно, всё обойдется легким испугом! И даже «существенных затрат» не потребуется.

ШАГ 1: пробуем встроенный бесплатный инструмент восстановления

Проблемы с базами Microsoft Access могут быть поначалу незаметны. Дело в том, что Microsoft Access способен сам исправлять мелкие ошибки целостности базы данных.

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

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

👉 Для начала, обратите внимание, что Microsoft Access имеет собственные средства восстановления поврежденных баз данных. Чтобы воспользоваться ими, нужно сделать следующее:

1. Открыть приложение Microsoft Access (просто приложение, а не поврежденную базу данных);
2. Перейти в меню «File (Файл) / Info (Информация) / Compact & Repair Database» (Сжать и восстановить базу данных 👇);
3. Выбрать поврежденную базу данных и нажать ОК;
4. Дождаться успешного восстановления базы данных.

Microsoft Access — восстановление файла

👉 Также попробуйте импортировать поврежденную базу данных в новый файл формата Microsoft Access. Для этого нужно сделать следующее:

1. Открыть приложение Microsoft Access и создать новый файл базы данных;
2. Выбрать вкладку «External data» (Внешние данные 👇);
3. Указать, что требуется импорт файла Access;
4. Установить нужные параметры для импорта файла и нажать OK.

External data (внешние данные)

ШАГ 2: используем спец. сервис и утилиту для восстановления

Если предыдущие шаги не увенчались успехом, рекомендую попробовать спец. инструменты для решения подобных «проблем». Речь идет об использовании сервиса: Recovery Toolbox for Access .

Как с ним работать:

1. сначала необходимо открыть следующий URL-адрес: https://access.recoverytoolbox.com/online/ru/;
2. далее нажать по кнопке «Select file» (Выбрать файл 👇);
3. указать поврежденную базу данных Microsoft Access для закачки на сервер;
4. ввести правильно свой адрес электронной почты;
5. ввести код CAPTCHA;
6. перейти к следующему этапу, нажав на клавишу «Next step»;
7. если сервис «справился» с файлом — оплатить услугу и скачать восстановленную базу.

Скриншот с сайта Recovery Toolbox for Access

Есть один недостаток : как вы уже заметили, мы загружаем базу на удаленный сервер. А вдруг в базе данных имеется конфиденциальная информация? В этом случае, есть простое решение – использовать оффлайн версию (👇) сервиса Recovery Toolbox for Access.

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

Оффлайн версия Recovery Toolbox for Access не использует подключение к удаленным сервисам, все этапы выполняются в автономном режиме! Отмечу, что Recovery Toolbox for Access работает только под ОС Windows, программа совместима со всеми поддерживаемыми версиями Microsoft Access.

👉 Для работы с Recovery Toolbox for Access нужно сделать следующее:

1. Скачать программу с офиц. сайта: https://access.recoverytoolbox.com/ru/;
2. Установить Recovery Toolbox for Access на ваш компьютер (процесс стандартный, как и у любой др. программы) ;
3. Запустить программу и выбрать файл Microsoft Access для восстановления (👇);
4. Дождаться окончания анализа поврежденной базы данных;
5. Сохранить восстановленный файл;
6. Продолжить работу с восстановленной базой данных.

Указываем куда сохранить восстановленные данные

👉 Кстати, при использовании оффлайн версии Recovery Toolbox for Access, пользователь получает возможность восстанавливать неограниченное количество файлов Microsoft Access. Можете помогать коллегам, которые столкнулись с похожей проблемой.

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

Как вы считаете, какой именно актив является одним из важнейших для любого бизнеса? Деньги, люди, хорошее лобби в правительстве? Нет, это информация. А все данные зачастую хранятся в базах данных, даже если компания не ведет бизнес в Сети. Как ни странно, но потеря любой из баз данных может привести к серьезным проблемам для бизнеса, обычно это связано с убытками, реже — с закрытием компании.

Что делать если нет резервной копии базы данных Microsoft Access?

Сейчас мы говорим о базах данных в формате Microsoft Access. Что делать, если база вдруг перестала открываться, в окне приложения вы видите кучу странных ошибок, а другой копии файла нет (разве бывает иначе?). Чтобы решить это проблему, многие проходят через несколько этапов (о них ниже), но проблему можно решить проще — с помощью онлайн сервиса восстановления данных Recovery Toolbox for Access.

Но не будем забегать вперед. Да, многие регулярно используют Microsoft Access, да и вообще это один из самых популярных инструментов создания и ведения баз данных, если не нужно решать какие-то совсем масштабные задачи. Самое главное: он прост в использовании. Но простота часто выходит боком, увеличивает уязвимость и риски. Почему такие проблемы могут возникать:

1. Прерванный процесс изменения базы данных Microsoft Access. Например, пользователь пытался внести какие-то изменения в удаленную базу данных, но из-за проблем с сетью он не смог закончить операцию. В этом случае, приложение Microsoft Access помечает базу как поврежденную. Ее легко восстановить, но некоторые данные могут быть утеряны безвозвратно.
2. Вирусы. До боли знакомая проблема. Без комментариев.
3. Проблемы с «железом». Что угодно: потеря пакетов на сетевых картах, поврежденные сектора на диске и многое другое может вызывать порчу базы данных.
4. Некорректная работа плагинов для Microsoft Access либо их неверная установка.
5. Попытка одновременного доступа к одной базе данных и ее изменение.
6. Сбои электропитания при работе с базой данных, вызывающие самопроизвольное выключение системы.

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

Бесплатно и, может быть, эффективно

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

Есть, правда, следующая возможность. Microsoft Access имеет собственные средства восстановления поврежденных баз данных, они работают таким образом:

1. Откройте приложение Microsoft Access (просто приложение, а не поврежденную базу данных);
2. Перейдите в меню File (Файл) — Info (Информация) — Compact & Repair Database (Сжать и восстановить базу данных);
3. Выберите поврежденную базу данных и нажмите ОК;
4. Дождитесь успешного восстановления базы данных;

Попробуйте импортировать поврежденную базу данных в новый файл формата Microsoft Access. Для этого нужно сделать следующее:

1. Откройте приложение Microsoft Access и создайте новый файл базы данных;
2. Выберите вкладку External data (Внешние данные);
3. Выберите импорт файла Access;
4. Укажите нужные параметры для импорта файла и нажмите ОК;

Что скажут профессионалы?

Есть шанс, что вам помогут данные манипуляции, и вы сможете успешно решить проблему. Если это не сработало, то есть другое решение. Оно предполагает использование стороннего средства восстановления информации — Recovery Toolbox for Access. Итак, как же он работает?

Тут все просто: есть онлайн сервис восстановления баз данных Microsoft Access, он находится тут: https://access.recoverytoolbox.com/online/ru/. Сервис подразумевает следующий алгоритм действий:

1. Нажмите кнопку Selectfile (Выбрать файл);
2. Выберите поврежденную базу данных Microsoft Access для закачки на сервер;
3. Введите свой адрес электронной почты;
4. Введите код CAPTCHA;
5. Перейдите к следующему этапу, нажав на клавишу Nextstep (Далее) и следуйте инструкциям;
6. Оплатите сервис восстановления и скачайте восстановленный файл.

Вообще, это самый лучший и дешевый способ восстановления данных, но есть один недостаток. Для параноиков – как вы уже заметили, он предполагает закачку файлов на удаленный сервер. А вдруг в той базе данных имеется конфиденциальная информация и вам противна сама мысль поделиться данными с кем-то? В этом случае, есть простое решение – использовать оффлайн версию сервиса Recovery Toolbox for Access.

При этом ничего закачивать на удаленный сервер не нужно. Программа устанавливается на компьютер пользователя, который сам выполняет процесс восстановления всего за несколько шагов. Офлайн-версия Recovery Toolbox for Access не использует подключение к удаленным сервисам, все этапы выполняются в автономном режиме. Отсутствие сторонних подключений легко проконтролировать с помощью файерволла. Recovery Toolbox for Access работает только под ОС Windows, программа совместима со всеми поддерживаемыми версиями Microsoft Access.

Для работы с Recovery Toolbox for Access нужно сделать следующее:

1. Скачать программу отсюда https://access.recoverytoolbox.com/ru/
2. Установить RecoveryToolboxforAccess на ваш компьютер
3. Запустить программу и выбрать файл Microsoft Access для восстановления
4. Дождаться окончания анализа поврежденной базы данных
5. Сохранить восстановленный файл
6. Продолжить работу с восстановленной базой данных

При использовании оффлайн версии Recovery Toolbox for Access, пользователь получает возможность восстанавливать неограниченное количество файлов Microsoft Access. Можете помогать коллегам, которые столкнулись с похожей проблемой. Воздержимся от слов типа «можете и дальше портить базы данных», так как делать этого все-таки не стоит. Вообще, все зависит от того, насколько серьезно база данных повреждена. В некоторых случаях, восстановление вообще невозможно, и Recovery Toolbox for Access — это все-таки не магия. Однако в большинстве случаев оно помогает.