Как сделать резервную копию базы/таблицы в mysql

Введение

В качестве примера я рассмотрю серверы с установленными там продуктами bitrix, работающими в bitrixenv. Особенностью будет то, что bitrix до сих пор использует не самую свежую версию mysql от percona — Percona Server for MySQL 5.7. Тем не менее, проблем с этим нет никаких. Версия будет поддерживаться минимум до октября 2023 года.

Для полных и инкрементных бэкапов я рассмотрю утилиту Percona XtraBackup, которая позволяет делать архивы баз данных на лету без блокировок таблиц. В моей статье будет использоваться версия 2.4, так как именно она поддерживает mysql 5.7. Это максимально доступная версия в репозиториях, которые устанавливает окружение bitrixenv.

Примеры в этой статье будут актуальны практически для всех версий Mysql и XtraBackup, так как в подходах и командах отличий почти нет

Важно знать, что последняя версия XtraBackup на момент написания статьи была 8.0 и она поддерживает популярный форк mysql — MariaDB только до версии 10.2 включительно, да и то с оговорками. Для более поздних версий mariadb рекомендуется использовать mariabackup

Это форк XtraBackup, который в использовании практически ничем не отличается от оригинала.

Сегодня я рассмотрю инкрементные бэкапы mysql только с помощью XtraBackup, а так же полные бэкапы в том числе с помощью mysqldump. MariaDB и Mariabackup рассматривать не буду. Принципиальных отличий между ними нет. Там все то же самое.

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

Команда 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

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

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

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

Скриншот myaccount.google.com

Чтобы скачать всё, что о вас хранит Google, в несколько кликов, нужно пройти в меню экспорта. В нём можно выбрать нужные вам сервисы либо просто нажимайте далее, и тогда появится дополнительное меню. В нём можно выбрать формат архива (в том числе и разбить архив на несколько частей), а также сервис либо ссылку для скачивания. В старом аккаунте могут собираться десятки, а то и сотни гигабайтов данных. Поэтому для создания архива требуется от пары часов до нескольких дней. Когда он будет готов, система оповестит вас по почте.

Скриншот takeout.google.com

Меню удаления данных делится на удаление аккаунтов в сервисах YouTube, Google+, Play Игры и Gmail. Также у пользователя есть возможность тотального уничтожения в разделе «Настройки аккаунта», где у вас дважды попросят подтверждения, так как полная чистка повлияет на многие полезные сервисы, связанные с аккаунтом. Например, интернет-банкинг может быть привязан к почте Gmail. На всякий случай можно оставить путь для восстановления, добавив резервную почту и телефон в соответствующих графах.

Для экстренных случаев, если что-то случится и вы продолжительное время не будете пользоваться своим аккаунтом, выберите друга или родственника, который получит доступ к вашим данным. В меню нужно выбрать сроки бездействия (от 3 до 18 месяцев), список данных и человека, который их получит. По прошествии указанного срока аккаунт будет заблокирован, а доверительное лицо получит СМС-сообщение с доступом на почту. Также можно указать, чтобы всё было уничтожено автоматически через 3 месяца после деактивации.

myaccount.google.com

Чем грозит компании потеря базы данных 1С?

Потеря информационной базы бухгалтерии – это:

• утрата работоспособности всей системы управления бизнес-процессами, построенной на базе 1С;
• затраты, сопряженные с нарушением бизнес-процессов;
• риск претензий и штрафных санкций со стороны налоговых органов (если отчеты будут сданы не вовремя или с ошибками);
• дополнительная нагрузка на бухгалтерский персонал и IT-сектор;
• дополнительные затраты, связанные с восстановлением баз данных и возвращением функциональности интегрированной управленческой и бухгалтерской системы;
• утечка конфиденциальной информации: персональные данные клиентов, предмет коммерческой тайны и др.

Как случайная, так и преднамеренная потеря данных (Data Loss) – чрезвычайно неприятное событие для компании, которое проще предотвратить, чем устранить его последствия. К счастью, существуют современные решения, позволяющие минимизировать риск потери базы данных 1С.

Способы создания

В MS SQL Server резервные копии можно создавать несколькими способами. Рассмотрим используемые инструменты:

MS SQL Management Studio

Графический интерфейс SSMS прекрасно подходит для разовых операций. Он может применяться к различным базам данных.

Для этого необходимо:

1. Открыть MS SQL Management Studio. Выбрать БД, которая будет копироваться и кликнуть по ней правой кнопкой мыши. Выбрать Задачи, после чего – Создать резервную копию.
2. Откроется окошко, в котором необходимо оставить полный тип копий и прописать путь к резервному файлу. Если возникла необходимость – путь можно изменить, удалить, создать новый. Файл можно сохранить как на локальном диске, так и на сетевом.
3. После успешного окончания процесса появится уведомление об этом.

Командная строка (sqlcmd)

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

Для данного способа понадобится утилита sqlcmd:

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

PowerShell

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

Для бэкапа необходимо импортировать модуль import-module sqlps –DisableNameChecking.

Можно воспользоваться синтаксисом: Backup-SqlDatabase -ServerInstance <имя SQL сервера> -Database <имя базы> -BackupFile <путь к файлу с резервной копией>

Как и в предыдущем способе, для запуска скрипта по графику, его следует размещать в планировщике.

Резервное копирование базы данных MySQL с помощью Cron Jobs

Задание cron — это команда Linux, используемая для автоматического выполнения задания в указанное время. Мы объясним, как использовать эту команду для автоматизации резервного копирования баз данных MySQL.

Начните с входа в свою cPanel, прокрутите вниз до раздела Advanced и нажмите на Cron jobs.

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

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

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

Вы также можете настроить другие параметры, такие как время и день недели.

Теперь пришло время добавить команду следующим образом:

/usr/bin/mysqldump -u dbusername -p’dbpassword’ dbname > /home/username/path/backup.sql

Замените dbusername, dbpassword и dbname на имя пользователя базы данных, пароль базы данных и имя базы данных.

Путь относится к папке или серии папок, в которые вы хотите поместить файл резервной копии. Имя вашего файла резервной копии представлено в команде как backup.sql . Вы можете изменить это имя или оставить его как есть. Нажмите Добавить новое задание Cron .

Если вы прокрутите немного вниз, вы увидите список ваших текущих заданий Cron.

Если вы хотите изменить любое из ваших текущих заданий cron, нажмите Edit. Если вы больше не хотите запускать какую-либо работу или ошибаетесь, нажмите «Удалить».

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

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

gunzip /tmp/dump.sql.gz

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

export DBNAME=base

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

mysql -u root -p ${DBNAME} < /tmp/dump.sql

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

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

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

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

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

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

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

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

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

По умолчанию утилита будет выводить все в стандартный вывод, поэтому нам нужно перенаправить эти данные в файл, что мы и делаем с помощью оператора «>». Опции указывают параметры аутентификации и работы, а имя базы и таблицы — данные которые нужно экспортировать. Теперь рассмотрим кратко опции, которые будем использовать:

• -A — копировать все таблицы из всех баз данных;
• -i — записывать дополнительную информацию в комментариях;
• -c — использовать имена колонок для инструкции INSERT;
• -a — включать все возможные опции в инструкцию CREATE TABLE;
• -k — отключает первичные ключи на время копирования;
• -e — использовать многострочный вариант инструкции INSERT;
• -f — продолжить даже после ошибки;
• -h — имя хоста, на котором расположен сервер баз данных, по умолчанию localhost;
• -n — не писать инструкции для создания базы данных;
• -t — не писать инструкции для создания таблиц;
• -d — не записывать данные таблиц, а только их структуру;
• -p — пароль базы данных;
• -P — порт сервера баз данных;
• -Q — брать все имена таблиц, баз данных, полей в кавычки;
• -X — использовать синтаксис XML вместо SQL;
• -u — пользователь, от имени которого нужно подключаться к базе данных.

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

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

Но если во время создания копии возникнут какие-либо ошибки, они будут выведены на экран и вы сразу о них узнаете. Более сложный вариант, это выполнить резервное копирование MySQL с другого хоста, если у вас есть к нему доступ:

Копирование таблицы MySQL может быть выполнено простым добавлением имени таблицы в конец строки:

Также, чтобы выполнять автоматическое резервное копирование может понадобиться сразу задать пароль, для этого указывайте его сразу после опции -p, без пробела:

Мы можем делать бэкап вручную время от времени, но это не совсем удобно, поскольку есть другие важные дела. Поэтому используем планировщик cron, чтобы автоматизировать процесс. Тут есть два способа более простой, и более сложный, но точный. Допустим, нам нужно создавать резервную копию каждый день, тогда просто создайте скрипт в папке /etc/cron.daily/ со следующим содержимым:

Папку /backups/mysql-dump.sql нужно заменить на свою папку для резервных копий. Осталось дать скрипту права на выполнение:

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

Добавьте в открывшейся файл такую строку и сохраните изменения:

Команда будет выполняться каждый день, в 2:30, это удобно, поскольку ночью обычно меньше нагрузка на сервер. Как вы поняли, первое число — это минуты, второе — часы, третье день, дальше неделя и месяц. Звездочка значит, что этот параметр не имеет значения.

Отслеживание хода выполнения с помощью xEvent

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

Предупреждение

С помощью расширенных событий backup_restore_progress_trace можно повысить производительность и существенно сэкономить дисковое пространство

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

Права доступа, разрешения и привилегии

XtraBackup должна иметь возможность:

• Подключиться к вашему серверу MySQL.

• Обладать правами доступа к каталогу datadir. 

• Во время создания резервной копии иметь права на запись в указанный через параметр target-dir каталог.

Что такое datadir?

datadir — это каталог, в котором сервер баз данных MySQL хранит данные. Все базы данных, все таблицы находятся там. В большинстве дистрибутивов Linux по умолчанию таким каталогом является /var/lib/mysql.

Что такое target-dir каталог?

target-dir — это каталог, в который будет сохранена резервная копия.

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

• RELOAD и LOCK TABLES

• REPLICATION CLIENT

• CREATE TABLESPACE

• PROCESS

• SUPER

• CREATE

• INSERT

• SELECT

Конфигурация 

Конфигурация XtraBackup выполняется с помощью опций, которые ведут себя так же, как и стандартные параметры MySQL.

Что это значит?

Конфигурационные параметры могут быть указаны либо в командной строке, либо в файле конфигурации СУБД, например в /etc/my.cnf.

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

Например, значение datadir и некоторые параметры InnoDB XtraBackup получаем из конфигурации вашей СУБД.

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

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

Пример указания пути к каталогу с резервной копией в my.cnf:

Типы резервного копирования SQL Server

Полное (Full Backup)

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

Полную резервную копию вы можете восстановить за 1 шаг, так как она не требует других дифференциальных/инкрементальных копий.

Если модель восстановления базы SQL данных установлена как “Полная”, то при восстановлении бекапа вы можете указать параметр “STOPAT”, где указывается время (до секунды) на котором нужно остановить восстановление данных. Например, сотрудник внёс некорректные данные в 14:46:07, с помощью параметра STOPAT вы можете восстановить данные на момент 14:46:06

Дифференциальное

Дифференциальное или разностное резервное копирование — это копирование только тех данных, которые появились с момента последней полной резервной копии.

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

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

Например, если полная резервная копия весит 300 GB, а дифференциальная спустя час работы 5 GB, то спустя сутки это будет 120 GB, что делает использование данного типа копий нерациональным.

Журнал транзакций

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

Восстанавливая журнал транзакций, вы также можете указать параметр STOPAT, как и в восстановлении полной резервной копии.

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

Tail-Log

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

Tail-Log бекап рекомендуется делать перед восстановлением копий журнала транзакций, чтобы не потерять транзакции между последним бекапом и текущим моментом времени.

Copy-only

Этот вид бекапа не может служить “базой” для дифференциальных резервных копий и для копий журнала транзакций. Copy-only бекап не нарушает текущую цепочку резервных копий (полный-> дифференциальный или полный -> копии журналов транзакций) и используется только в том случае, если вам нужно снять полную резервную копию, не задевая текущую цепочку бекапов.

За исключением этих нюансов – ничем не отличается от обычной полной копии.

Частичная резервная копия

Partial backup этот тип резервной копии используется для того, чтобы снять копии с read-only файловых групп. На практике используется редко.

С помощью Powershell

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

Для выполнения команды, сначала импортируем модуль:

import-module sqlps -DisableNameChecking

Синтаксис:

Backup-SqlDatabase -ServerInstance <имя SQL сервера> -Database <имя базы> -BackupFile <путь к файлу с резервной копией>

Пример скрипта на powershell

$server = «SQL01» $curdate = Get-Date -Format yyyyMMdd

import-module sqlps -DisableNameChecking

$db = work1 Backup-SqlDatabase -ServerInstance $server -Database $db -BackupFile $db_$curdate.bak

* где выполняется резервное копирования базы work1 на сервере SQL01

Также как и для cmd, данный скрипт можно поместить в планировщик для запуска по расписанию.

Инкрементный бэкап Mysql

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

# xtrabackup --backup --target-dir=/root/backupdb/inc1 --incremental-basedir=/root/backupdb/full

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

backup_type = full-backuped
from_lsn = 0
to_lsn = 17687056
last_lsn = 17687065
compact = 0
recover_binlog_info = 1
flushed_lsn = 17687065

LSN — log sequence number. Это регистрационные номера транзакций. В данном случае полный бэкап начинается с нулевой транзакции и заканчивается 17687056. Теперь смотрим этот же файл в директории inc1.

backup_type = incremental
from_lsn = 17687056
to_lsn = 17710039
last_lsn = 17710048
compact = 0
recover_binlog_info = 1
flushed_lsn = 17710048

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

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/full

либо так:

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/inc1

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

Предлагаю вот такой скрипт для инкрементных бэкапов — mysql-inc-backup.sh.

#!/bin/bash

DATA1=`date +%Y-%m-%d`
DATA2=`date +%H-%M-%S`

xtrabackup --backup --target-dir=/root/backupdb/$DATA1/inc-$DATA2 --incremental-basedir=/root/backupdb/$DATA1/full

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

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

Примеры создания дампа MySQL

1. С последующим архивированием

export DBNAME=base

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

* в данном примере мы сначала создали переменную DBNAME, в которую внесли значение с именем базы, которую необходимо забэкапить. После выполняем команду mysqldump, результат выполнения которой по конвееру отдаем архиватору gzip. В результате мы получит дамп по пути /tmp/<имя базы>.sql.gz

Или с подробным выводом информации на экран (дольше по времени):

mysqldump -v -uroot -p ${DBNAME} | gzip > /tmp/${DBNAME}.sql.gz

2. Для одновременно нескольких баз

Просто перечисляем имена баз через пробел и добавляем параметр -B

mysqldump -v -uroot -p -B base1 base2 base3 > /tmp/dump_multiply_bases.sql

3. Для всех баз одной командой

Для этого ставим —all-databases, вместо имен баз

mysqldump -v -uroot -p —all-databases > /tmp/dump_all_bases.sql

4. Резервирование только структуры базы

Для уточнения, это создание копии только самих таблиц без данных. Делается добавлением параметра —no-data

mysqldump -v -uroot -p —no-data base1 > /tmp/dump_base1_nodata.sql

5. Создание копии определенной таблицы

Для этого после базы через пробел перечисляем названия таблиц

mysqldump -v -uroot -p base1 table1 table2 > /tmp/dump_base1_tables.sql

6. Резервирование прав доступа на СУБД

Позволяет выгрузить все учетные записи с паролями. Удобно для переноса СУБД на новый сервер без потери доступа к нему.

mysqldump -v -uroot -p mysql user > /tmp/mysql_user.sql

* после восстановления этого дампа, необходимо в sql shell выполнить команду flush privileges;

Резервное копирование базы данных 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

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

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

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

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

• Задачи организации, относящиеся к рабочей базе данных, особенно требования к доступности данных и их защите от потери или повреждения.

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

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

Установка

Установка XtraBackup из репозитория apt Percona.

Выполните последовательно следующие команды:

2. После установки выполните команду 

Так как, важно убедиться, что утилита корректно работает на сервере. В результате на экране отобразится что-то подобное:

xtrabackup: recognized server arguments: — datadir=/var/lib/mysql — tmpdir=/tmp — server-id=1 — logbin=/var/log/mysql/mysql-bin.log — innodbbufferpoolsize=16384M — innodbfilepertable=1 — innodbflushmethod=Odirect — innodbflushlogattrxcommit=0xtrabackup version 2.4.20 based on MySQL server 5.7.26 Linux (x8664) (revision id: c8b4056)