Centos lvm снапшот как полный бэкап
Обновлено: 04.07.2024
Дошли руки до своего нетбука, который знакомый попросил одолжить на время. Перед тем как отдать нетбук я решил сделать полный бэкап системы, но потом не смог найти достаточно свободного места на домашнем компе, чтобы забэкапить весь диск целиком. Поскольку знакомому вполне подходил ноут без жесткого диска, то я просто снял винт и таким образов временно решил проблему полного бэкапа.
Однако близится день заморозки кодовой базы Debian в предверии нового релиза Debian Wheezy. Основные черты нового дистрибутива уже видны и по возвращении нетбука я хочу пробно обновить систему на нем, чтобы иметь представление, что меня ожидает при обновлении домашнего компа.
Чтобы не было неприятных сюрпризов перед обновлением, мне нужно сделать бэкап, причем желательно таким образом, чтобы была возможность возиться с "последствиями" обновления и иметь возможность быстро переключиться на стабильный Squeeze. Если делать это по-старинке, то мне придется делать зеркало системных файлов на домашний комп, причем в двух вариантах (стабильный squeeze и обновление на wheezy). Понятное дело, что восстановиться из такого бэкапа в полевых условиях не получится (если вдруг всплывет косяк, связанный с обновлением). Нужна возможность держать всю информацию на самом нетбуке, но проблема в том, что там просто нету столько свободного места, чтобы держать две полные копии системы. Потому я начал искать новое решение.
В общих чертах меня могла бы спасти BTRFS у которой есть поддержка снапшотов на уровне файловой системы (т.е. в снапшотах хранится только разница относительно базы, с которой они были созданы). Но btrfs еще в стадии разработки и спотыкаться об ее недоработки нет желания.
Далее вспомнилось, что в самом начале освоения LVM я пробовал делать снапшоты перед обновлением системы. Если обновление нужно было отменить, то приходилось монтировать снапшот и затем rsync'ом приводить систему в чувство. Но хочется чего-то проще. Что-то вроде сделал снапшот и если результат обновления не нравится - просто возвращаем исходное состояние нужному LVM тому, используя для этого соответствующий снапшот.
Пока искал выход нагуглил новость о том, что начиная с ядра 2.6.33 появилась возможность объединять LVM том и его снапшот - BINGO! - как раз то, что нужно мне и без лишних телодвижений.
Разбивка диска на нетбуке у меня не слишком мудреная:
Посколько /boot находится вне LVM, то я сделал его копию:
Смотрим, сколько у меня места в группе томов (VG), еще не размеченного под логические тома (LV):
Далее делаем снапшоты всех разделов:
После этого можно смело обновлять систему. Если потребуется откатить обновление, то создаем новый снапшот (чтобы разобраться, когда появится свободное время) и мержим старый снапшот и соответствующий логический том:
Теперь можно перезагрузиться, чтобы тома начали слияние (слияние начинается только при последующей активации тома).
Если в процессе обновления поменялось содержимое /boot, то после перезагрузки или при помощи LiveCD/LiveUSB его можно восстановить так:
После завершения слияния, пространство, занятое под laptop/rootfs-before и laptop/home-before освободится. Аналочично поступаем, если нужно вернуться в играм с обновлением.
Главное меню » Операционная система Linux » Как сделать резервную копию снимка LVM в Linux
При создании снимка LVM объем резервного копирования метаданных файловой системы копируется в только что созданный снимок тома. Блоки файлов остаются на исходном томе, однако, до тех пор, пока ничего не изменилось в метаданных снимка, все указатели в блоках по исходному объему остаются правильными. Когда файл изменяется на исходном томе, оригинальные блоки копируются в снимок тома перед изменением в файловой системе.
Итак, давайте начнем с операции резервного копирования снимка LVM:
Шаг 1: Проверьте обзор всей группы томов в системе с помощью команды vgs. Для нашего demo 50mb пространства более чем достаточно.
В приведенной выше команде:
Шаг 3: Вы можете проверить логический том с помощью нижеследующей команды, вы можете видеть, что в приведенном ниже примере указан наш вновь созданный снимок тома.
Теперь выполните шаг для объединения снимков обратно к первоначальному объему, который вернет все данные.
Шаг 6: Слияние снимка тома с помощью следующей команды.
Шаг 8: Теперь деактивируйте и активируйте первоначальный объем. Этот шаг необходим для объединения снимков обратно в первоначальный объем.
Вы можете увидеть в приведенном выше выводе, что все наше исходное содержимое на месте, что означает, что мы успешно провели операцию снимка LVM резервного копирования.
Примечание: Вам не нужно удалять резервную копию LVM снимка. Путем преобразования снимка обратно на первоначальный том, вы автоматически удаляете том снимка.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Некоторое время назад озаботился решением вопроса бэкапа виртуальных машин kvm. Когда стал разбираться в теме, с удивлением обнаружил, что каких-то удобных, устоявшихся решений для горячего бэкапа виртуальных машин без остановки работы в kvm нет. Ни коммерческих решений не увидел, ни бесплатных. Пришлось самому вникать в суть и разбираться в теме.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
С гипервизором kvm лично мне приходилось мало работать. Еще в первое мое знакомство с гипервизорами, когда я выбирал, какой использовать в своей работе, kvm мне не понравился вообще по следующим причинам:
- Нет удобного инструмента для управления гипервизором под Windows. Для меня это критично, так как моя основная рабочая система ОС Windows.
- Не увидел готового образа, который бы позволил быстро и без лишних движений развернуть гипервизор на новом железе.
В итоге я остановился на Xen там, где нужно поставить систему на программный рейд mdadm, и Hyper-V в тех случаях, где рейд либо не нужен совсем, либо он аппаратный. В своей работе так или иначе приходится сталкиваться с различными системами, поэтому разбираться приходится во всем, в том числе и в kvm.
Есть 2 различных способа сделать бэкап виртуальной машины kvm:
- С остановкой или заморозкой системы на короткий промежуток времени.
- Без остановки системы вообще.
Для первого случая все относительно просто, каких-то нюансов нет. Во втором случае возникают нюансы и вопросы. Просто взять и сделать горячий бэкап виртуальной машины в kvm не получится. Вопрос рассмотрения архивных копий виртуальных машин нужно начинать с выбора типа жесткого диска, который будет использоваться. В зависимости от этого будет разная стратегия бэкапа. С этого мы и начнем.
Сразу хочу пояснить, что не имею большого опыта в работе с kvm и возможно что-то делаю неправильно. Данная статья мой опыт самостоятельного поиска решения и закрепление его для себя и всех, кому это будет интересным.Какой диск выбрать в kvm - lvm, raw (img) или qcow2
В kvm есть несколько типов дисков, которые вы можете использовать в своей работе. Они имеют принципиальные отличия как по своей работе, так и по способам бэкапа. Выбирать тот или иной тип нужно в зависимости от ваших задач. Рассмотрим эти типы подробнее.
LVM. Тут все понятно. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы.
- Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
- Максимальное быстродействие.
- Легко изменить размер диска.
- Более сложное управление по сравнению с дисками в виде отдельных файлов.
- Менее гибкое управление пространством диска. Если весь диск разбить на lvm разделы для виртуалок, то места на нем не останется, даже если вируталки будут пустые.
- Более сложный перенос на другой сервер.
RAW. Это обычный формат сырых данных. Среди дисков в виде файлов это будет самый простой и быстрый вариант. Все данные пишутся как есть без дополнительных обработок и служебной информации. Формат является универсальным для большинства популярных гипервизоров.
- Максимальная простота и производительность среди образов в виде файла.
- Универсальный формат с поддержкой в большинстве гипервизоров.
- Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
- Не поддерживает снепшоты ни в каком виде.
- Занимает сразу все выделенное пространство на диске, даже если внутри виртуальной машины место будет свободно. Из-за отсутствия фрагментации в некоторых случаях это может оказаться плюсом.
QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как QEMU Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы должна хоть и не сильно, но уступать RAW. Как обстоит дело на практике, я не знаю, не замерял и подробно эту информацию не проверял.
- Поддержка снепшотов и динамических дисков. Как следствие - более удобное управление дисковым пространством.
- Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
- Более низкая производительность, по сравнению с другими типами образов.
У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат вообще не рассматриваю. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее приемлемым вариантом. Собственно, ниже и пойдет рассказ, как совместить удобство управления QCOW2 и простоту бэкапов и снэпшотов lvm. Я покажу, как сделать живой бэкап виртуальной машины kvm в формате qcow2 без остановки виртуальной машины.
Бэкап виртуальной машины kvm без остановки
Перед практической реализацией живого бэкапа виртуальной машины, снова немного поговорим о теории. Для бэкапа виртуальной машины kvm достаточно просто скопировать ее диски в виде файлов. Это можно сделать даже при работающей машине. Но если в этот момент на виртуалке идет какая-то дисковая активность, вы скорее всего получите неработающий образ. И это логично. Значит нам, чтобы гарантированно скопировать диск, виртуальную машину нужно выключить, либо придумать что-то еще.
Это "что-то еще" является снепшот. Мы можем сделать во время бэкапа снепшот виртуальной машины, зафиксировав ее состояние и сделать копию с этого снепшота. После завершения копирования снепшот объединяется с основным файлом и машина продолжает работать в штатном режиме. Завершать работу или замораживать виртуальную машину в данном случае нет необходимости.
С самими снепшотами тоже есть нюансы. Есть 2 разных типа снепшота. Например, если вы сделаете снепшот qcow2 средствами virt-manager, то удивитесь, не увидев новый файл снепшота. Оказывается, снепшот будет создан внутри qcow2, а файл как был один, так и останется. Это очень неудобно, так как если у вас будет занят весь доступный для файла объем, вы гарантированно получите ошибку при старте вашей виртуалки. А контролировать объем диска, в котором находятся снепшоты трудно и неудобно. И бэкапы в таком случае делать тоже не получится. Хотя получится, но все равно не удобно. Нужно будет отдельными командами конвертировать состояние виртуальной машины до снепшота в отдельный файл и его уже забирать для бэкапа. Плюс ко всему машину в этом случае нужно будет заморозить на момент создания снимка. Заморозка будет кратковременной, но все равно без нее не обойтись. Я приведу для примера команды, которыми это можно делать, но сам я не стал использовать такой способ, потому что, во-первых, не смог найти команды на объединения снепшота и основного файла, во-вторых, меня не устраивает даже кратковременная заморозка системы.
Конвертируем снепшот в отдельный образ:
Преобразовываем raw обратно в qcow2:
После этого надо объединить снимок с остальным файлом. Я не стал искать, как это сделать, так как тут используется заморозка виртуальной машины, хоть и кратковременная, но я хочу обойтись без нее. Поэтому я стал дальше искать варианты.
Установка qemu-guest-agent
Мы будем делать снепшот средствами virsh. При этом остановки или заморозки системы не будет вообще. Чтобы этот вариант корректно работал, вам необходимо установить на виртуальную машину qemu-guest-agent. Для этого вам сначала нужно добавить Channel Device по имени org.qemu.guest_agent.0. Проще всего это сделать через virt-manager.
Затем в систему надо установить пакет qemu-guest-agent. Для debian и centos все просто:
Для windows надо с диска virtio-win установить пакет qemu-ga из папки guest-agent, которая находится в корне диска.
Подробнее об установке qemu-guest-agent можно прочитать в документации redhat. Теперь у нас все готово для выполнения живого бэкапа виртуальной машины в kvm без остановки этой виртуалки.
Выполняем снепшот виртуальной машины:
| vm-name | имя виртуальной машины |
| backup-snapshot | название снэпшота, может быть любым |
| vda | имя диска, для которого указываем адрес снепшота |
| /snapshot/vm-name-backup.qcow2 | путь и имя файла для снепшота |
Для того, чтобы узнать имена дисков виртуальной машины, воспользуйтесь командой:
Обращаю внимание на важный момент, который я сначала упустил и долго не мог разобраться в логике создания снепшота. Параметр diskspec не указывает для какого диска создается снепшот, а просто обозначает путь до снепшота. Если у вас несколько дисков, а в diskspec вы указали только один диск, то снепшоты все равно будут созданы для всех дисков. При этом для тех дисков, где вы указали путь, будет использоваться указанный, а для остальных будет по-умолчанию в той же папке, где лежит исходный файл ВМ. Этот нюанс серьезно меняет логику работы скриптов для автоматизации бэкапа в том случае, если у машин несколько дисков. Написав скрипт для бэкапа машин с одним диском, у меня не получилось его быстро оптимизировать для нескольких.После того, как сделали снимок, скопируйте куда вам нужно основной файл виртуальной машины. Я предпочитаю его сразу сжимать всеми ядрами процессора с помощью архиватора pigz:
Когда выполнение бэкапа завершено, объединим снапшот с основным файлом:
После этого файл снэпшота можно удалить:
Для полноты картины забэкапим еще и настройки виртуалки:
И на этом все. Мы сделали полный бэкап работающей виртуальной машины kvm без ее остановки. Сама она даже не поняла, что с ней что-то сделали. Работающие БД на ней не испытывают никаких проблем. Проверял на postgresql. Терминальные сессии в windows server тоже чувствуют себя отлично.
Скрипт для автоматического бэкапа виртуальных машин KVM
По мотивам всего написанного выше я набросал простенький скрипт для автоматического живого бэкапа всех дисков всех работающих в момент выполнения скрипта виртуальных машин. Обращаю внимание, что бэкапятся все диски. Скрипт привожу просто для примера, не используйте его, если вам не нужны полные бэкапы всех дисков. Лично я бэкаплю только небольшие системные диски. Все, что много весит, предпочитаю архивировать другими способами уже изнутри виртуальной машины. Если это базы данных, то делаю бэкапы нужных баз postgresql, если это файловый сервер, то использую rsync для создания инкрементных бэкапов. Ну и так далее. Каждый выбирает средства на свой вкус.
Обращаю внимание на несколько моментов:
vm_list может либо автоматически заполняться списком работающих виртуальных машин, либо можно вручную указать список только тех машин, которые нужно бэкапить. Для этого нужно раскомментировать соответствующую строку в начале скрипта при объявлении переменной. Затем выбрать подходящую строку для цикла for. Он будет немного разным, в зависимости от списка.
Снепшоты будут создаваться в той же папке, где хранится основной файл данных. На время отладки советую для начала закомментировать строку с удалением снепшота, на всякий случай. Рекомендую этот крипт прогнать сначала на тестовом сервере. Я его написал на примере одного гипервизора, больше нигде не проверял. Но работает он однозначно, я проверил несколько раз с разными списками VM. В итоге оставил его у себя на сервере в работе.
Для регулярной очистки бэкапов, если они у вас будут храниться где-то в доступном с этого сервера месте, можно добавить в самый конец условие очистки. Для полного бэкапа VM мне видится нормальной схема хранения бэкапов в несколько месяцев, с созданием архивов раз в неделю. Чаще бэкапить системные диски не вижу смысла, там редко бывают ежедневные изменения.
Данная команда удалит все файлы старше 90 дней в папках с названиями виртуальных машин, расположенных в /backup-vm.
Заключение
В начале статьи я сказал, что не встретил готового решения по живому бэкапу kvm. (upd. Уже после публикации статьи мне подсказали готовое решение kvmBackup.) На самом деле это не совсем верно. Есть хорошая готовая сборка на основе kvm - proxmox. Я подробно рассматривал ее в отдельном материале - Установка и настройка proxmox. Но все же это решение конкретного коллектива разработчиков со своими возможностями и ошибками. В проксмокс реализован живой бэкап виртуальных машин из коробки. К сожалению, я не смог быстро найти техническую реализацию их решения. Возможно, все было бы еще проще. Но так тоже ничего получилось.
Регулярное резервное копирование – важный этап в защите данных. Разработка эффективной стратегии резервного копирования и восстановления почти всегда включает в себя поиск баланса между влиянием на производительность, затратами на внедрение и хранение данных, скоростью восстановления и целостностью данных. Оптимальное решение будет зависеть от точек восстановления, масштаба и архитектуры базы данных.
Данный мануал научит вас выполнять горячее резервное копирование рабочей БД MySQL с помощью снапшотов LVM и сохранять данные в удаленном хранилище.
Процедура, представленная в этом мануале, хорошо подходит для больших баз данных MySQL, баз данных, использующих смесь систем хранения (таких как InnoDB, TokuDB и MyISAM) и серверов баз данных с несколькими блочными хранилищами, управляемыми через LVM.
Требования
- Сервер Ubuntu 16.04, настроенный по этому мануалу.
- Рабочая установка MySQL 5.7+ (читайте Установка MySQL в Ubuntu 16.04).
- Логический том LVM для хранения данных MySQL. Больше полезной информации вы найдете в мануале Введение в LVM: основные понятия и операции. Чтобы научиться перемещать каталог данных MySQL, читайте Перемещение каталога данных MySQL в Ubuntu 16.04.
- s3-совместимое хранилище и учетные данные API.
- Клиент передачи файлов s3cmd (2.X), его установка описана в разделе 1 мануала Архивирование логов в удаленном хранилище объектов с помощью Logrotate и S3cmd в Ubuntu 16.04.
- s3cmd, настроенный на доступ к вашему хранилищу (как описано в мануале Настройка s3cmd 2.x для управления хранилищами).
1: Изучение конфигурации MySQL и LVM
Для начала нужно найти каталог данных MySQL и собрать данные о настройках LVM.
Поиск datadir
Чтобы найти расположение каталога данных MySQL, введите:
mysqladmin -u root -p variables | grep datadir
Введите root-пароль MySQL, после чего вы увидите вывод:
Каталог данных текущей установки MySQL располагается в /data/mysql.
Теперь нужно убедиться, что /data/mysql живет в логическом томе LVM. Чтобы подтвердить это, запустите lsblk:
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 600G 0 disk
└─vg1-mysql_data 252:0 0 475G 0 lvm /data
vda 253:0 0 160G 0 disk
├─vda1 253:1 0 159.9G 0 part /
├─vda14 253:14 0 4M 0 part
└─vda15 253:15 0 106M 0 part /boot/efi
Как видите, каталог /data на самом деле является точкой монтирования для логического тома LVM по имени mysql_data. Он является членом группы томов vg1.
Теперь нужно убедиться, что у вас достаточно свободного места в группе томов vg1 для создания снапшота LVM.
Изучение конфигурации LVM
Важно отметить, что вывод команд, описанных в этом разделе, будет зависеть от аппаратного обеспечения вашего сервера и конфигурации LVM. Для начала мы быстро рассмотрим конфигурацию оборудования и LVM для сервера Ubuntu 16.04, используемого в этом руководстве.
Сначала выясним, сколько физических томов используется:
sudo pvscan
PV /dev/sda VG vg1 lvm2 [500.00 GiB / 25.00 GiB free] Total: 1 [500.00 GiB] / in use: 1 [500.00 GiB] / in no VG: 0 [0 ]
Как видите, в данном случае есть один физический том объемом 500 ГБ (/dev/sda), который находится в группе томов vg1. 475 ГБ этого физического объема выделено на логические тома, а 25 ГБ остается свободным для использования группой томов.
Чтобы подтвердить это, запросите подробные данные о группе томов vg1, используя команду vgdisplay:
sudo vgdisplay
--- Volume group ---
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 500.00 GiB
PE Size 4.00 MiB
Total PE 127999
Alloc PE / Size 121600 / 475.00 GiB
Free PE / Size 6399 / 25.00 GiB
VG UUID KEsoDE-zON7-NdyO-ioxb-6FSl-CB4m-S3QCRj
Из строк Alloc PE / Size и Free PE / Size можно отметить, что в данном случае логическим томам выделено 475 ГБ, а группе томов vg1 – 25 ГБ. Строка Cur PV показывает, что в этой группе томов есть 1 физический том. Строка Cur LV указывает, что пул пространства в этой группе томов был использован для создания 1 логического тома.
Чтобы посмотреть на этот логический том, используйте lvdisplay:
LV Size сообщает, что у нас есть один логический том объемом 475 ГБ, mysql_data, расположенный в /dev/vg1/mysql_data (напомним, что vg1 – имя группы томов mysql_data).
Подводя итог, следует сказать, что на сервере Ubuntu 16.04, используемом в этом мануале, есть один физический том объемом 500 ГБ (/dev/sda), используемый для поддержки одной группы томов (vg1), из которой был создан единый логический том объемом 475 ГБ (mysql_data). Это оставляет 25 ГБ свободного места группе томов, которое может использоваться для создания дополнительных логических томов (и снапшотов).
Вероятно, ваша конфигурация оборудования и LVM будет отличаться; вы можете подключить несколько блочных устройств хранения, объединив их в одну или несколько групп томов. Однако процедура создания снапшота логического тома от этого не зависит и будет одинакова.
Используя серию команд, представленных в этом разделе, вы получили общее представление о настойке LVM и конфигурации оборудования.
Теперь нужно подготовить сервер базы данных к созданию снапшота LVM.
2: Подготовка сервера к созданию снапшота LVM
Чтобы создать корректный снапшот LVM, необходимо обеспечить достаточное дисковое пространство для любых записей или изменений, которые могут возникнуть во время резервного копирования и передачи файлов в хранилище. В зависимости от размера вашей базы данных резервное копирование может занять несколько часов, поэтому лучше не забывать про осторожность. Если в процессе выполнения резервного копирования в томе заканчивается пространство, то том снапшота станет недействительным, и вы не получите последовательную резервную копию.
В предыдущем разделе вы узнали, что группа томов (vg1), содержащая основной логический том (mysql_data), имеет только 25 ГБ. Может быть, во время резервного копирования базы данных 25 ГБ изменений не будет записано на диск, но на всякий случай лучше иметь запас пространства – не менее 100 ГБ. В производственной настройке лучше всего измерить средний объем данных, записываемых на диск во время запланированного резервного копирования, и соответственно масштабировать размер тома снапшота.
Чтобы добавить дополнительные 75 ГБ пространства в группу томов vg1, можно либо добавить блочное устройство хранения, либо увеличить размер тома, который в настоящий момент подключен к серверу. В этом мануале мы расширим уже прикрепленный том хранилища.
Увеличить текущий том можно с помощью панели управления хранилищем.
В панели отображаются все существующие тома и данные о них. Увеличьте объем тома до 100 Гб.
Чтобы это изменение отобразилось в LVM, нужно использовать pvresize.
Войдите на сервер, а затем запустите pvscan, чтоб найти физические тома.
Вы получите такой же вывод, как ранее для /dev/sda:
PV /dev/sda VG vg1 lvm2 [500.00 GiB / 25.00 GiB free] Total: 1 [500.00 GiB] / in use: 1 [500.00 GiB] / in no VG: 0 [0 ]
Теперь запустите на том pvresize, чтобы добавить новое пространство:
sudo pvresize /dev/sda
Physical volume "/dev/sda" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
Убедитесь, что объем тома изменился:
Теперь физический том /dev/sda имеет 600 Гб.
PV /dev/sda VG vg1 lvm2 [600.00 GiB / 125.00 GiB free] Total: 1 [600.00 GiB] / in use: 1 [600.00 GiB] / in no VG: 0 [0 ]
Теперь убедитесь, что свободное пространство группы томов также увеличилось на 100 ГБ:
sudo vgdisplay
--- Volume group ---
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 600.00 GiB
PE Size 4.00 MiB
Total PE 153599
Alloc PE / Size 121600 / 475.00 GiB
Free PE / Size 31999 / 125.00 GiB
VG UUID KEsoDE-zON7-NdyO-ioxb-6FSl-CB4m-S3QCRj
Это указывает на то, что теперь у вас есть 125 ГБ свободного пространства, из которого можно создать том снапшотов.
Для целей этого руководства 125 Гб будет достаточно для обработки операций и изменений во время процедуры резервного копирования и загрузки, но в производственной среде размер тома снапшота должен масштабироваться пропорционально ожидаемому использованию диска в окне резервного копирования.
Теперь у вас достаточно пространства для проведения успешной процедуры создания снапшота.
3: Создание и монтирование снапшота LVM
Важно! Во время создания снапшота LVM при записи на диск будет некоторое ухудшение производительности. Вы должны сначала протестировать эту процедуру на тестовой базе данных с симулированной нагрузкой, чтобы убедиться, что этот метод будет работать в производственной среде.
Теперь нужно создать снапшот логического тома mysql_data, используя lvcreate. Прежде чем мы это сделаем, нужно заморозить записи в базу данных с помощью FLUSH TABLES WITH READ LOCK, чтобы гарантировать согласованность данных. Таблицы должны быть заблокированными, пока работает lvcreate, после чего их можно разблокировать. Общее время блокировки с помощью этих команд должно быть очень маленьким в зависимости от выполняемых в настоящее время запросов на запись.
Блокирование операций чтения в БД MySQL
Войдите в MySQL:
Из оболочки MySQL запустите команду FLUSH TABLES для блокировки вашей базы данных.
Важно! После выполнения следующей команды все открытые таблицы будут закрыты, все таблицы всех баз данных будут заблокированы с помощью глобальной блокировки чтения. Если это выполняется в производственной базе данных, лучше всего выполнить эту команду на реплике или как часть скрипта, чтобы свести к минимуму время блокировки базы данных.
FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
Это означает, что ваша база данных заблокирована. Не выходите из командной строки MySQL.
Теперь можно создать и смонтировать логический том для размещения данных MySQL.
Создание и монтирование тома снапшота
Сохраняя это соединение клиента MySQL, войдите в систему на своем сервере базы данных из нового окна терминала.
Важно! Если вы закроете это соединение, блокировка будет сброшена, и запись возобновится, что сделает снимок несогласованным.
Теперь мы можем сделать снимок логического тома mysql_data. Выделите 100 ГБ буферного пространства для обработки записей и других изменений при выполнении физической резервной копии. Чтобы создать снимок LVM, выполните следующую команду lvcreate:
sudo lvcreate -L 100G -s -n mysql_data_snap /dev/vg1/mysql_data
Флаг -L указывает размер логического тома, в данном случае это 100 ГБ. Флаг -s указывает, что логическим томом будет снапшот, в этом случае это снапшот тома /dev/vg1/mysql_data. Назовем этот том mysql_data_snap.
Вы увидите такой вывод:
Logical volume "mysql_data_snap" created.
Это указывает на то, что теперь у вас есть копия логического тома mysql_data, из которой можно выполнить резервное копирование.
Теперь, когда мы по существу «заморозили» наши файлы данных MySQL в определенный момент времени, мы можем разблокировать таблицы базы данных и возобновить операции записи. Из ранее открытого соединения MySQL запустите следующую команду:
UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
Таблицы разблокированы, и теперь вы можете безопасно закрыть это соединение.
На данный момент ваша БД все еще работает и принимает входящие соединения и записи. Также у вас есть последовательный снапшот данных в тот момент, когда вы запускали FLUSH TABLES WITH READ LOCK (точнее, данных в момент времени, когда был обработан последний запрос записи после FLUSH).
На этом этапе нужно смонтировать снапшот, чтобы у вас был доступ к замороженным данным.
Создайте точку монтирования /backup_src:
sudo mkdir /backup_src
Смонтируйте том снапшота в /backup_src:
sudo mount /dev/vg1/mysql_data_snap /backup_src
Теперь у вас есть доступ к замороженным данным. Проверьте это:
cd /backup_src
ls
Вы увидите каталог данных MySQL:
Теперь можно скопировать снимок в хранилище объектов.
4: Сжатие и загрузка файлов в хранилище объектов
Чтобы загрузить эту резервную копию в хранилище объектов, используйте инструмент s3cmd.
Сначала проверьте конфигурацию s3cmd и попытайтесь получить доступ к хранилищу резервных копий (в этом мануале оно называется mysql-backup-demo):
s3cmd info s3://mysql-backup-demo/
s3://mysql-backup-demo/ (bucket):
Location: nyc3
Payer: BucketOwner
Expiration Rule: none
Policy: none
CORS: none
ACL: 3587522: FULL_CONTROL
Этот вывод указывает, что соединение было успешным, и s3cmd может передавать объекты в хранилище.
Теперь сожмите и загрузите каталог данных MySQL в mysql-backup-demo:
sudo tar -czvf - /backup_src/mysql | s3cmd put - s3://mysql-backup-demo/mysql_backup_180423.tar.gz
Здесь tar используется для сжатия и архивирования каталога данных MySQL,ю после чего вывод передается s3cmd, который перемещает сжатый архив в хранилище. Сжатый архив называется mysql_backup_180423.tar.gz.
Поскольку мы использовали tar в режиме расширенного вывода, вы увидите список сжатых файлов (чтобы скрыть этот вывод, опустите флаг -v в приведенной выше команде).
.
upload: '<stdin>' -> 's3://mysql-backup-demo/mysql_backup_180423.tar.gz' [part 1, 1417kB] 1451996 of 1451996 100% in 0s 1993.41 kB/s done
Когда передача закончится, убедитесь, что все файлы были успешно перемещены в хранилище:
Физическое резервное копирование данных MySQL в хранилище объектов успешно завершено.
Теперь размонтируйте и сбросьте том снапшота, восстановив используемое пространство в группе томов vg1.
5: Демонтаж и сброс тома снапшота
Теперь, когда данные были скопированы в хранилище, том снапшота, который мы создали ранее в этом учебнике, больше не используется, и его можно безопасно размонтировать.
Для этого введите:
sudo umount /backup_src
Вместо /backup_src укажите имя вашей точки монтирования.
Чтобы сбросить том, введите:
sudo lvremove vg1/mysql_data_snap
Здесь vg1 – это имя вашей группы томов, а mysql_data_snap – имя вашего снапшота.
Вам будет предложено подтвердить удаление, для этого нужно ответить Y.
Вы должны увидеть следующий результат:
Logical volume "mysql_data_snap" successfully removed
Том снапшота успешно удален. Теперь вы завершили полное физическое резервное копирование MySQL и загрузили его в свое удаленное хранилище.
Давайте рассмотрим сценарий восстановления.
6: Тестовое восстановление физической резервной копии
Чтобы восстановить базу данных MySQL из физической резервной копии, которую мы предварительно загрузили в хранилище, нужно переместить резервную копию на сервер базы данных, а затем извлечь файлы в качестве восстановленного каталога данных MySQL.
Сначала перенесите резервную копию из хранилища обратно в домашний каталог пользователя на сервере базы данных:
s3cmd get s3://mysql-backup-demo/mysql_backup_180423.tar.gz
/mysql_backup_180423.tar.gz
download: 's3://mysql-backup-demo/mysql_backup_180423.tar.gz' -> '
/mysql_backup_180423.tar.gz' [1 of 1] 1451889 of 1451889 100% in 0s 38.49 MB/s done
Теперь нужно остановить работу сервера базы данных и очистить существующий каталог данных, чтобы протестировать чистое восстановление из файлов физической резервной копии.
Во-первых, остановите сервер MySQL:
sudo service mysql stop
Теперь очистите каталог данных MySQL:
sudo rm -rf /data/*
Напоминаем, что в мануале используется нестандартное расположение каталога /data.
Теперь извлеките физическую копию в каталог данных:
/mysql_backup_180423.tar.gz -C /data
Теперь, когда файлы данных были восстановлены, можно перезапустить базу данных MySQL и позволить ей восстановиться:
sudo service mysql start
Наконец, можно войти на сервер базы данных, чтобы убедиться, что восстановление выполнено успешно:
Введя пароль, вы увидите такой вывод:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.21-0ubuntu0.16.04.1 (Ubuntu)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Чтобы убедиться в целостности данных, просмотрите свои таблицы.
Заключение
В производственной настройке эта процедура в идеале должна быть записана в виде сценария и запланирована с надлежащим логированием, мониторингом и оповещениями. Кроме того, команду FLUSH TABLES WITH READ LOCK (даже ненадолго) не следует запускать на главном сервере, только на минимально загруженной реплике. Обратите внимание, что с небольшими изменениями вы также можете адаптировать описанную выше процедуру, чтобы быстро развернуть реплики из основной физической резервной копии.
Если ваш экземпляр MySQL использует исключительно InnoDB в качестве механизма хранения, вы можете также использовать Percona XtraBackup для физического резервного копирования базы данных подобным образом.
Читайте также: