56. Резервное копирование и восстановление данных в Proxmox.

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

Для начала сразу определимся что будем говорить о возможностях резервного копирования (бэкап - англ. backup) и восстановления предлагаемых средой PVE - Proxmox Virtual Environment. Не смотря на то, что есть отдельный продукт для этих целей: PBS - Proxmox Backup Server. Это полноценная система "заточенная" под выполнение определённых задач и ставится она на отдельное "железо".

Для первичного ознакомления с основами резервного копирования рекомендуется ознакомиться со следующими материалами:

1. Резервное копирование в Home Assistant

2. Резервное копирование Home Assistant с помощью VMware.

1. Теория.

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

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

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

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

В данной статье рассмотрим подход именно к сохранению основных файлов хранящихся непосредственно на железе.

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

1.1 Что являет собой процедура резервного копирования, если виртуальные машины это просто файлы? Почему бы их просто не скопировать и всё?

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

1.2 "Золотое" правило резервного копирования.

 Оно называется 3, 2, 1. Это означает что нужно иметь минимум 3 копии данных, минимум на 2 разных физических носителях, и минимум 1 копия должна храниться не там же где физически и географически находятся другие носители. Т.е. например в каком либо "облаке".

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

- Если допустить что система работает на стандартном мини-пк, то значит есть возможность подключить как минимум 2 физических диска.

- На первом диске находится только система с виртуальными машинами/контейнерами.

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

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

Основные причины потери данных.

1.3 Как часто нужно делать резервные копии?

Ответ очень простой: чем чаще - тем лучше. Если вы часто вносите изменения в систему (имеется в виду виртуальную машину или контейнер), и при этом пренебрегаете правилом создания снимков (снэпшотов - англ. snapshot), то рекомендация будет хотя бы 2 раза в сутки.

Для рабочей системы рекомендуется ежедневный бэкап.

1.4 Как долго хранить резервные копии?

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

1.5 Не стоит забывать и про математику.

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

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

1.6 В чём разница между снэпшотом и бэкапом?

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

в то время как

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

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

Однако из снэпшота нельзя создать новую такую же виртуальную машину, и его нельзя ни скопировать ни переместить. Хранится он на том же диске, где и оригинальная машина.

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

Перейдём к практике.

2. Резервное копирование.

2.1 Снэпшоты.

Чтобы сделать снимок системы, выбираем её, переходим на соответствующий раздел и нажимаем кнопку "сфотографировать". Главное обращать внимание на предлагаемые объяснения относительно некоторых ошибок, которые может допустить пользователь.

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

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

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

2.2 Резервные копии.

Управление ими разделено на 2 части. Глобальное на весь датацентр, или точечно на виртуальную машину/контейнер.
Будем "идти" по нарастанию, от малого к большому.

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

Какие опции здесь есть?

Создать бэкап сейчас.

Если есть бэкап и он выбран, то:

Восстановить из бэкапа (если таковой имеется).

Отображение информации с техническими характеристиками машины.

Возможность редактиривать заметки.

Возможность включить/выключить защиту от удаления этого бэкапа.

Удалить его (если выключена защита от удаления).

2.2.1 Возможности создания резервной копии.

При нажатии на кнопку создания бэкапа есть следующие опции:

Выбрать на какой том/раздел (т.е. в итоге физический диск) он будет сохранён.

Выбрать режим создания копии.

Будет ли этот бэкап защищён от удаления (как ручного, так и автоматического).

Заметка с возможностью использования шаблонных значений.

Какой уровень сжатия включить для этой копии.

Отправить ли мэйл по окончании процесса.

Очищать ли старые копии согласно политике хранения копий.

Выбор места хранения:

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

Выбор режима создания копии:

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

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

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

Сжатие итогового файла резервной копии:

• No compression: Итоговый файл резервной копии не сжимается. Т.е. файл будет иметь исходный размер, занимая столько же места на диске, сколько и исходные данные виртуальной машины или контейнера. Если не требуется сжатие или планируется сжимать файлы с помощью внешних инструментов, то можно выбрать этот режим.

• LZO compression: LZO (Lempel-Ziv-Oberhumer) Итоговый файл будет сжат с использованием алгоритма LZO. Он обеспечивает хороший баланс между скоростью сжатия и объемом итогового файла.

• GZIP compression: Итоговый файл будет сжат с использованием алгоритма GZIP. Он обеспечивает более высокий уровень сжатия по сравнению с LZO, но требует больше времени на сжатие и распаковку.

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

2.3 Восстановление из резервной копии.

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

Место хранения: На каком томе из имеющихся в системе будет развёрнута восстановленная система.

Номер идентификатор будет тот же что и у оригинальной машины.

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

Использовать ли уникальные настройки для новой машины, например такие как МАК адрес.

Запустить ли новую машину после восстановления.

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

ВАЖНО ПОМНИТЬ!!!!

Восстановление машины из бэкапа удаляет (перезаписывает) оригинальную машину.

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

Теперь можно ближе узнать как как работают

3. Глобальные настройки резервного копирования.

Как уже было сказано, находятся они на уровня всего датацентра.

• На главной закладке прежде всего выбираем хост (ноду), ОТКУДА будет производиться копирование.
• В качестве объекта КУДА будет производиться копирование, выбираем желаемый том (например рэйд массив).
• В расписании указываем как часто будет происходить бэкап.
• В режиме выбора отмечаем к каким виртуалкам будут применены все выбранные опции:

Включая отмеченные.
Все имеющиеся.
Исключая отмеченные.
На основании пула машин.

• Можно отправить мэйл по окончании процедуры.
• При этом указать чтобы он отправлялся всегда или только если были ошибки во время процесса:

• Выбрать необходимую степень сжатия данных.
• И режим создания копии.

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

Если необходимо по каким-то причинам временно отключить этот набор, то просто убираем соответствующую отметку.

Осталось настроить политику хранения резервных копий.

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

Поэтому используется другой способ. Можно хранить:

• Последние Х штук бэкапов (не важно как часто они делаются).
• Х штук ежедневных.
• Х штук ежемесячных.
• Х штук ежечасных.
• Х штук еженедельных.
• Х штук ежегодных.

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

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

4. Синхронизация.

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

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

Далее понадобится программа синхронизации. Идеально для этой цели подойдёт RSync. Для её установки необходимо сделать следующие шаги:

Для начала убедиться что система полностью обновлена, выполнив команду apt update.

После чего запустить непосредственно установку самой программы: apt install rsync.

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

rsync -av /путь_к_исходной_директории/ /путь_к_целевой_директории/ &

Символ & в конце строки означает что процесс будет происходить в фоновом режиме. Если есть необходимость следить за процессом, то убираем этот знак и пробел перед ним.

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

-a (или --archive): Это опция для режима архива, которая позволяет сохранить все атрибуты файлов и директорий в процессе синхронизации. Включает в себя опции -r (рекурсивная передача файлов), -l (сохранение символических ссылок), -p (сохранение прав доступа), -t (сохранение временных меток) и др. Это обычно рекомендуемый режим для общего использования rsync.

-v (или --verbose): Эта опция включает подробный вывод о процессе синхронизации. rsync будет выводить информацию о передаваемых файлах, прогрессе и другие детали. Это может быть полезно для отслеживания процесса и получения дополнительной информации при выполнении команды.

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

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

И запускаем следующую команду:

rsync -av --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ &

Она должна скопировать в целевую папку только новый файл из исходной.

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

rsync -av --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ &

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

Если всё работает, то итоговая команда будет выглядеть следующим образом:
rsync -a --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ &

Теперь создадим умное оповещение о работе этой команды.

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

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

rsync -av --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ > /tmp/rsync.log

Файл лога /tmp/rsync.log будет перезаписываться каждый раз, когда эта команда выполняется. Перенаправление > используется для создания нового файла или перезаписи существующего файла.

Теперь добавим проверку: [ -s /tmp/rsync.log ]

Она проверяет, не пуст ли файл лога. Если файл лога пуст (то есть, rsync не выполнил никаких операций копирования), то команда вернет значение FALSE.

rsync -av --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ > /tmp/rsync.log && [ -s /tmp/rsync.log ]

Отправка по электронной почте.

За это отвечает последняя добавляемая часть: && mail -s "Rsync job report" address@example.com < /tmp/rsync.log

&& говорит о том, что можно продолжать выполнение если предыдущая часть вернула значение TRUE (т.е. лог файл не пуст).

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

Полученная итоговая команда будет выглядеть как-то так:

rsync -av --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ > /tmp/rsync.log && [ -s /tmp/rsync.log ] && mail -s "Rsync job report" address@example.com < /tmp/rsync.log

Отлично, разобрались с тем, что и как будет происходить. Осталось решить когда это будет.

Для этого можно воспользоваться встроенным планировщиком Cron.

Открываем его командой crontab -e

Укажем параметры запуска нашей команды. Чтобы их определить, нужно знать когда заканчивается заранее настроенная процедура резервного копирования, или хотя бы сколько времени она занимает. Плюс сверху накинуть ещё минут 10-15 на случай непредвиденных задержек. Например, если бэкап назначен на 01:00 ночи каждый день, и занимает он полчаса, то запуск синхронизации можно смело настраивать на 01:45. Для простоты, округлим до двух часов ночи.

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

0 2 * * * rsync -av --delete --update /путь_к_исходной_директории/ /путь_к_целевой_директории/ > /tmp/rsync.log && [ -s /tmp/rsync.log ] && mail -s "Rsync job report" address@example.com < /tmp/rsync.log 

Формат записей crontab выглядит следующим образом:

"минуты" "часы" "день месяца" "месяц" "день недели" "команда"

Поэтому, разбирая указанный пример, получаем:

0: Указывает на минуты. Команда будет выполнена в 0 минут каждого часа.

2: Указывает на часы. Команда будет выполнена в 2 часа ночи (используется 24 часовой формат.

*: Звёздочка в позициях "день месяца", "месяц" и "день недели" означает "любое значение". 

Таким образом, команда будет выполняться в 2 часа ночи в любой день месяца, в любом месяце, в любой день недели.

Выходим из режима редактирования, не забыв сохранить изменения.

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

Если же есть желание заливать во внешнее облако, то можно самостоятельно изучить использование таких программ как Rclone, Duplicati или Grive2.

Кстати, резервное копирование конфигурации Home Assistant в облако уже было рассмотрено ранее в этой статье.

5. Восстановление данных.

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

5.1 Восстановление с заменой.

Допустим необходимо вернуть определённую виртуалку к состоянию до бэкапа.

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

5.2 Создание новой из бэкапа.

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

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

Чтобы выполнить эту операцию, необходимо зайти на то хранилище, которое выделено под резервные копии, и зайти в одноимённый раздел.

5.3 Клонирование и шаблон.

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

Клонирование же, по сути, это аналог действия рассмотренного в пункте 5.2. Только с быстрым доступом, по правому клику на выбранной машине.

Клонирование (Cloning):

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

Шаблоны (Templates):

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

Основные отличия между клонированием и шаблонами:

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

На этом обзор по стандартным функциям резервного копирования средствами Proxmox PVE можно считать оконченным.