Как сделать снапшот бд

Обновлено: 06.07.2024

Однако существуют опасности другого рода, от которых эти всевозможные аппаратные ухищрения не спасут: вирусы, сбои программ, да и просто человеческие ошибки, приводящие к потере данных. Наконец, не исключены стихийные бедствия, грозящие физическим уничтожением систем вместе со всей информацией. Единственная защита от таких ситуаций – резервное копирование данных (часто называемое бэкап – от английского backup). При этом резервные копии есть смысл сохранять исключительно на иных, чем источник копии, аппаратных устройствах. В идеале копия должна быть максимально удалена географически от оригинала, во избежание ее утери в случае серьезной техногенной катастрофы. Несмотря на простую, на первый взгляд, задачу – скопировать данные для их сохранности, решить ее технически грамотно позволит не всякое оборудование/программное обеспечение.

Конечно, это упрощенное и утрированное описание идеи снапшота. В реальности это организовано несколько иначе. Поскольку команда на создание снапшота может поступить в любой момент, и снапшот сразу же должен быть готов к копированию, то на дублирующем диске хранятся не сами данные, а только ссылки на них с основного диска. В таком варианте снапшот рассматривается как копия неких мета-данных в специально отведенной (резервной) области. Это означает, что сами данные никуда не копируются, копируются только ссылки на данные (или, для простоты понимания - каталог). Этот вариант также называется PIT (point-in-time) копией исходных данных.
Далее, если приложение пытается перезаписать исходные данные, то соответствующая программа сначала копирует блок подлежащих изменению оригинальных (исходных) данных на новое место (в специальную область, выделенную для операций копирования), и только потом выполняет собственно операцию записи. Значения ссылок соответственным образом обновляются. Такая технология называется COW (copy-on-write) и ее идея иллюстрируется на рисунке ниже.

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

Во-вторых, копируется весь каталог, включая ссылки на открытые файлы. Напомним, что файлы, открытые и заблокированные различными приложениями, скопировать стандартными средствами нельзя. Разумеется, далеко не факт, что при восстановлении данных удастся использовать заблокированные (незакрытые) файлы, но пусть лучше они будут, чем нет.

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

После того, как виртуальным томам или snapshot-томам назначены ID/LUNs (Logical Unit Number), компьютер видит каждый снапшот (если их несколько) как физический диск. Тем самым со снапшотами могут производиться те же действия, которые могут производиться и с обычными дисками.

Поддержка снапшотов в системах хранения данных от компании Maxtronic

Сама по себе реализация snapshot в системах хранения от Maxtronic International выполнена по вышеописанной схеме – снапшот создается как каталог ссылок на исходные данные, а все перезаписываемые данные сбрасываются с помощью COW на диск со снапшотом.
Единственное существенное отличие в том, что вы можете дополнительно создать специальный COW-том, который не виден никому, но который может быть использован в том случае, если не хватает места на любом из снапшот-томов.

Перед созданием snapshot-копий для рабочего тома необходимо создать другой том (вторичный), связанный с рабочим томом (первичным), т.е. сформировать пару для Snapshot. Сами же snapshot-копии создаются на вторичном томе.

После того, как первоначальная snapshot копия создана, команды записи данных на первичный том вызовут выполнение операции “copy-on-write” (COW), т.е. копирование старых данных с первичного тома на вторичный перед записью новых данных на первичный том.

Snapshot-том (диск) – это виртуальный объект, который, как уже упоминалось выше, представляет собой ссылки на исходные данные. Когда необходимо чтение данных с Snapshot-тома, то данные берутся с первичного тома, если они не обновлялись, или с вторичного тома, если данные были изменены. Поскольку вторичный том хранит только отличающиеся данные, при начальной настройке Вы можете задавать размер вторичного тома в разы меньше, чем размер первичного тома. Однако не рекомендуется задавать размер вторичного тома менее 10 процентов от размера первичного тома, поскольку ссылки тоже занимают место, да и перезаписываемые данные требуют места для своего размещения. Пользователь может настроить службу оповещения системы хранения, потребовав сообщить ему об угрозе нехватки места под снапшоты. Конечно, учитывая дешевизну дисковой емкости, правильнее всего не экономить и создавать пары равного объема.

Первичному тому может соответствовать множество Snapshot-томов (копий), каждая для своего момента времени. При этом они будут храниться на единственном вторичном томе. На рисунке показаны соотношения первичного, вторичного томов, и Snapshot-томов. Заметим, что при наличии нескольких snapshot операция COW будет приводить к уменьшению быстродействия системы хранения. Поскольку снапшотов может быть много, то выполнение COW для разных снапшотов будет отнимать ресурсы системы хранения из-за разбросанности снапшотов по диску. Чем к большему количеству исходных данных для snapshot-томов будут запрашиваться обращения по записи в одно и то же время, тем больше будет снижаться быстродействие системы хранения от применения COW процедуры.

Процесс создания snapshot можно условно разделить на три этапа:

Этап 1: Проектирование (Планирование)

Задать LUN’ы на снапшот-тома и сделать эти LUN видимыми для тех компьютеров, которым это требуется (например, для архивирования снапшотов). При этом надо учесть, что snapshot том будет иметь с точки зрения операционной системы компьютера те же параметры, что и исходный том, поэтому во избежание противоречий snapshot том не должен быть виден компьютеру, который работает с исходным томом.

Наглядно эти этапы можно видеть на иллюстрациях ниже.
В данном примере мы использовали 3 диска. На 2 дисках по 750 GB будет создан RAID 0, а отдельный диск (JBOD) так таковым и останется. Для получения любой картинки в исходном разрешении просто щелкните на изображении.

Начало большого пути – исходное состояние

Создаем дисковую группу dg0 из двух дисков по 750 GB

Создаем логический диск dg0ld0

Назначаем lun0 ранее созданному dg0ld0 и мапируем lun0 на первый FC порт.

Этап 2: Конфигурация

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

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

Мы готовы к созданию пары томов – исходного в паре с томом под снапшот. Просто нажимаем кнопку S.VOL Pair

Создаем пару томов в связке из dg0ld0 и jbod0

Этап 3: Создание и использование Snapshot (Вручную или по сценарию)
При создании Snapshot для исходного тома, требуется:

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

И снова немного иллюстраций процесса:

Мы готовы к созданию снапшота

Нажимаем кнопку Create и создаем снапшот с именем svol0

Назначаем lun1 ранее созданному снапшоту svol0 и мапируем lun1 на первый FC порт.

Теперь с точки зрения внешнего мира у нас два диска – один оригинальный и один снапшот

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

Все процедуры, описанные нами на этапе 3, выполнялись вручную. Разумеется, в реальной работе создание снапшота таким образом вряд ли будет нужно кому-либо. Поэтому правильнее всего применять процедуру создания снапшота по расписанию.
Достаточно скачать специальную программу для управления снапшотами и настроить планировщик задач Windows для запуска программы и тем самым создания/удаления снапшот в нужное время.
Например, для бэкапа данных Microsoft SQL Server можно применить такую последовательность действий:

rcmd \\192.168.0.1 C:\snapshot\acs_snap flush D: ; На компьютере с адресом 192.168.0.1 запускается программа acs_snap (о которой шла речь выше), по команде flush очищается кэш системы хранения.

Net start mssqlserver; Работа SQL Server возобновлена.
Далее, с помощью скрипта, используя интерфейс командной строки (CLI) системы хранения и режим командной строки Windows:

Одной из задач системного администрирования является борьба с неприятным явлением под названием " потеря данных ". Причины потери данных могут быть разными:

Сбой программного обеспечения.
Выход из строя оборудования.
Человеческий фактор.
Действие злоумышленников, вирусы, шифровальщики.
Пренебрежение резервным копированием, ошибки при организации безнес-процессов.
Форс-мажор. Пожары, наводнения, стихийные бедствия.
Нашествие инопланетян, война, рейдерский захват, политические баталии, действия правоохранительных органов.
Статическое электричество, космическая радиация.

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

Так что среди системных администраторов есть две основные группы: те кто не делает резервные копии и те кто уже делает. Есть ещё третья подгруппа: те, кто проверяет, что резервная копия восстанавливается, но это уже отклонение от нашей темы.

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

Backup

Backup (бэкап) — автономная копия данных системы, которая может храниться на отдельных носителях, в том числе геораспределённых.

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

Бэкап рекомендуется хранить на геораспределённом носителе, чтобы обеспечить возможность восстановления данных в случае выхода из строя ЦОД. Если канал передачи данных медленный, то рекомендуется хранить дополнительный бэкап рядом с основной системой, это позволит быстрее восстановить данные в случае сбоя.

Работоспособность бэкапа следует периодически проверять.

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

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

Snapshot

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

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

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

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

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

Резюме

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

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

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

Кроме бэкапа и снапшота есть и другие инструменты для предотвращения потери данных:

Репликация.
Зеркалирование.
Теневые копии.
Обновление ПО, шифрование, информационная безопасность, антивирусы, распределение прав доступа.
Профилактика оборудования.

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

Некоторое время назад озаботился решением вопроса бэкапа виртуальных машин 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. Но все же это решение конкретного коллектива разработчиков со своими возможностями и ошибками. В проксмокс реализован живой бэкап виртуальных машин из коробки. К сожалению, я не смог быстро найти техническую реализацию их решения. Возможно, все было бы еще проще. Но так тоже ничего получилось.

Онлайн курс "DevOps практики и инструменты"

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

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

Что такое снэпшот

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

Стоимость хранения снэпшота — 3 рубля за 1 ГБ в месяц. Скорость создания снэпшота напрямую зависит от объема данных.

Доступно 2 способа создания снэпшотов:

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

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

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

Как сделать снэпшот

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

Как создать снапшот виртуальной машины

Готово, созданный снэпшот появится в разделе Снэпшоты:

Как развернуть снэпшот

Развернуть снэпшот можно только на таком сервере, на котором доступно не меньше дискового пространства, чем на сервере, с которого делался снэпшот. Например, снэпшот сервера с тарифом Cloud-2 (20Gb) можно развернуть на Cloud-2 и выше. Cloud-1 (10Gb) не подойдет.

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

Как развернуть снапшот диска

Готово, снэпшот будет распакован на сервере.

Как удалить снэпшот

Напротив снэпшота, который нужно удалить, нажмите на корзину:

Как удалить снапшот системы

Готово, снэпшот будет удалён и исчезнет из списка.

Облачные серверы нового поколения

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 8 доступных ОС на выбор!

Читайте также: