База знаний
Войти

Сценарии использования rv-backup

Этот раздел посвящен базовым сценариям использования rv-backup с пояснениями процесса.

Быстрый старт

Примечание — Ниже для примера приведены шаблоны идентификаторов ВМ и чек-пойнта:

  • 123-123-123-123-123 ‒ ID целевой ВМ, которая участвует в резервном копировании;
  • 555-555-555-555-555 ‒ ID последнего чек-пойнта.

Примечание — ID ВМ или диска можно узнать в веб-интерфейсе. Также ID ВМ можно посмотреть командой:

rv-backup list vms --remote

Примечание — ID чек-пойнта можно узнать следующими способами:

  • с помощью команды:
rv-backup vm <id ВМ> list checkpoints
  • посмотреть содержимое файла checkpoints.map (только локальные чек-пойнты).

Примечание — Для упрощения взаимодействия с rv-backup приложение предусматривает указание имени ВМ вместо ID, например:

rv-backup vm TestMachine list checkpoints

При этом следует учесть, что имена ВМ могут совпадать. В этом случае приложение выдаст ошибку и предложит ввести ID вместо имени ВМ. Подробнее для каждой команды можно узнать в разделе Интерфейс командной строки rv-backup.

Для быстрого старта необходимо выполнить следующие действия:

  1. запустить ВМ имеющуюся TestMachine c ID 123-123-123-123-123 с двумя дисками TestMachine_Disk и InfoDisk;
  2. подключиться через графическую консоль к ВМ;
  3. создать текстовые файлы на основном диске TestMachine_Disk и на InfoDisk;
  4. внести в эти файлы какую-либо информацию;
  5. создать и скачать полную резервную копию с помощью rv-backup на машине с доступом к интерфейсу СУСВ:
rv-backup vm 123-123-123-123-123 backup start -d -f
  1. изменить информацию в файлах, созданных на шаге 3;
  2. создать и скачать инкрементальную резервную копию:
rv-backup vm 123-123-123-123-123 backup start 555-555-555-555-555 -d -f

Примечание — Команда start поддерживает автоопределение типа резервного копирования. Можно не указывать UUID последнего чек-пойнта, тогда он будет выбран автоматически. Подробнее см. п. rv-backup vm backup.

  1. удалить файлы, созданные на шаге 3;
  2. восстанавить информацию с помощью rv-backup через создание новой ВМ:
rv-backup vm 123-123-123-123-123 backup upload vm new_vm1 Default hosted_storage
  1. ожидать, пока процесс восстановления будет завершен;
  2. убедиться, что файлы, удаленные на шаге 8 восстановлены и имеют содержимое, внесенное на шаге 4.

Ротация резервных копий

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

  • Автоматически при превышении указанных в конфигурации rv-backup лимитов;
  • Автоматически при превышении указанных в индивидуальной конфигурации лимитов;
  • Вручную с помощью команды.

Важно ‒ Источники условий для ротации имеют приоритеты (от наивысшего к низшему):

  • заданные в командной строке в качестве аргументов;
  • индивидуальные настройки, хранящиеся в директории с ВМ;
  • заданные в конфигурации rv-backup.

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

Для ротации rv-backup использует единственную стратегию: объединяется самый первый чек-пойнт (он же ‒ полная резервная копия) со следующим (со вторым), и так до тех пор, пока не станут проходить проверки по заданным условиям, например, до тех пор пока размер резервных копий не станет меньше 3.5 ГБ или до тех пор пока количество чек-пойнтов не станет равным 2.

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

Важно ‒ Ротация невозможна, если резервная копия ВМ содержит лишь один чек-пойнт.

Для ротации определяются целевые чек-пойнты согласно единственной стратегии (см. выше): x ‒ первый чек-пойнт, y ‒ второй чек-пойнт, z ‒ третий чек-пойнт (может не существовать).

Объединение чек-пойнтов ‒ это процесс, при котором осуществляются операции над каждым диском, имеющимся у целевых чек-пойнтов. Целевые чек-пойнты могут содержать разное количество дисков, отсюда следует, что есть сценарии действий при ротации для различных комбинаций этих дисков. Эти сценарии описаны в таблице 9. Каждый диск целевого чек-пойнта проверяется по таблице 9 (наличие цифры в чек-пойнте означает наличие диска; цифра равна номеру комбинации).

Примечание — Любой чек-пойнт содержит как минимум один диск.

По окончанию операций с дисками конфигурация ВМ из чек-пойнта y переносится в чек-пойнт x, затем чек-пойнт y удаляется из карты чек-пойнтов.

Пример 1

Например, имеется виртуальная машина TestVM с резервной копией с тремя чек-пойнтами. Чтобы сократить количество чек-пойнтов до одного и локально, и на виртуализации нужно выполнить команду:

rv-backup vm TestVM backup rotate --checks-count 1 --remote-too

Затем необходимо задать для TestVM условия, при которых ротация будет осуществляться автоматически, если размер резервной копии будет превышать 10 ГБ:

rv-backup vm TestVM backup rotate --backup-size 10GB --apply

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

Примечание — Ротация, которая запускается автоматически по условиям, всегда синхронизирует изменения в карте чек-пойнтов с картой чек-пойнтов на сервере виртуализации.

Пример 2

Например, имеется виртуальную машину IvanVM с двумя чек-пойнтами, каждый из которых содержит Диск1 и Диск2. Диск2 стал не нужен и был удален из IvanVM, но по-прежнему необходимо создавать новые чек-пойнты и совершать ротации. Следует инициировать резервное копирование, которое создаст три чек-пойнта. Теперь этот чек-пойнт содержит только Диск1.

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

rv-backup vm IvanVM backup rotate

Согласно стратегии ротации, о которой было сказано выше, будет выбрано три целевых чек-пойнта (в данном случае их всего 3), и каждый диск, который они содержат, будет проходить проверку по таблице 9:

  • Диск1 ‒ так как Диск1 присутствует во всех чек-пойнтах, будет выбран сценарий №1. Диск1 из второго чек-пойнта будет слит с Диск1 в первом чек-пойнте. Диск1 из третьего чек-пойнта будет перебазирован на Диск1 из первого чек-пойнта;
  • Диск2 ‒ так как Диск2 присутствует только в первых двух чек-пойнтах, но не присутствует в третьем, будет выбран сценарий №3. Диск2 из второго чек-пойнта будет слит с Диск2 в первом чек-пойнте.

После первой ротации второй чек-пойнт будет полностью слит с первым, а затем удален. Третий чек-пойнт станет вторым. Теперь IvanVM содержит два чек-пойнта, при этом первый чек-пойнт содержит Диск1 и Диск2, а второй содержит только Диск1.

Далее можно совершить еще одну ротацию:

rv-backup vm IvanVM backup rotate

Теперь проверка будет следующая:

  • Диск1 ‒ так как Диск1 присутствует только в первых двух чек-пойнтах, но не присутствует в третьем (так как третий не существует), будет выбран сценарий №3. Диск1 из второго чек-пойнта будет слит с Диск1 в первом чек-пойнте;
  • Диск2 ‒ так как Диск2 существует только в первом чек-пойнте, будет выбран сценарий №6. Диск2 будет удален из первого чек-пойнта, и это будет соответствовать состоянию IvanVM на момент создания второго чек-пойнта.

В результате имеется резервная копия ВМ IvanVM, содержащая единственный чек-пойнт с Диск1, что соответствует её актуальному состоянию.

Удаление чек-пойнта из середины цепочки чек-пойнтов

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

Примечание — Чек-пойнт считается находящимся в середине цепочки чек-пойнтов, если он не является первым в этой цепи и не является последним.

В ротации используется объединение первого (X) чек-пойнта со вторым (Y), и если есть третий (Z), то он перебазируется на первый (X). То есть для ротации точкой отсчета выбирается чек-пойнт X.

Для удаления чек-пойнта из середины точкой отсчета выбирается чек-пойнт Y. Он же указывается в команде:

remove —select-check

Важно ‒ Если чек-пойнт Y будет первым в цепи, то rv-backup выдаст ошибку:

Checkpoint[2c1f8c33-4df8-41c0-8912-51451686991a] does not have a parent, you might be trying to remove the last
checkpoint, if so, use other commands, for example "remove --last-check" or "remove [--local, --remote]".

Следует учитывать, что единственный чек-пойнт также является первым и последним.

В этом случае для удаления чек-пойнта нужно воспользоваться другими командами, например remove --last-check или remove [--local, --remote].

Для удаления чек-пойнта из середины нужно ввести команду:

TestVM‒ имя ВМ с которой производится работа
9751828f-9dc5-473f-93b3-b361edc26c74‒ UUID чек-пойнта который требуется удалить
--local‒ осуществлять действия с локальной картой чек-пойнтов
rv-backup vm TestVM backup remove --select-check 9751828f-9dc5-473f-93b3-b361edc26c74 --local

После этого директория, содержащая чек-пойнт 9751828f-9dc5-473f-93b3-b361edc26c74, будет удалена из хранилища резервных копий. Можно вместо --local указать параметр --remote-too, чтобы этот чек-пойнт был удален и из карты чек-пойнтов.

Также можно применить такое удаление и к последнему (не единственному) чек-пойнту, если по какой-то причине необходимо удалить чек-пойнт, но сохранить при этом последнее состояние ВМ. В этом случае последний чек-пойнт будет объединен с предыдущим.

Проверка логов

Для проверки логов можно воспользоваться командой:

journalctl | grep rv-backup

Примечание — Подробность логирования можно настроить в конфигурации.

Пример вывода:

[rv-backup] [INF]‒ rv-backup 0.1 started!
[rv-backup] [INF]‒ CA certificate already exists!
[rv-backup] [INF]‒ ┌──────────────┬─────────────────┐
[rv-backup] [INF]‒ │ API Name:       │ РОСА Виртуализация │
[rv-backup] [INF]‒ │ API Vendor:     │                     │
[rv-backup] [INF]‒ │ API Version:    │ 4.4.3.12-1.0.5.rv3c │
[rv-backup] [INF]‒ │ Hosts:          │ 1/1 (active/total)  │
[rv-backup] [INF]‒ │ StorageDomains: │         2/3         │
[rv-backup] [INF]‒ │ Users:          │         1/1         │
[rv-backup] [INF]‒ │ VMs:            │         2/2         │
[rv-backup] [INF]‒ └──────────────┴─────────────────┘
[rv-backup] [INF]‒ Incremental backup from checkpoint[be995f8e-6b36-4937-a8ea-8dbad2a84a11] started!
[rv-backup] [INF]‒ Checkpoint[bb5a2c18-7c34-4a4b-874d-0fb4a1117769] created.
[rv-backup] [INF]‒ Transfer[42006272-c072-49c7-950a-8a78714e160c] initialization started!
[rv-backup] [INF]‒ Transfer[42006272-c072-49c7-950a-8a78714e160c] initialized.
[rv-backup] [INF]‒ Finalizing transfer[42006272-c072-49c7-950a-8a78714e160c] with disk[16b20599-b0ef-471b-b108-f3c567ac7e53].
[rv-backup] [INF]‒ Transfer[42006272-c072-49c7-950a-8a78714e160c] finalized in 1.011 seconds.
[rv-backup] [INF]‒ Download disk[16b20599-b0ef-471b-b108-f3c567ac7e53] completed successfully.
[rv-backup] [INF]‒ Transfer[cd91a114-975e-4b9f-a256-dfc2b1acf89b] initialization started!
[rv-backup] [INF]‒ Transfer[cd91a114-975e-4b9f-a256-dfc2b1acf89b] initialized.
[rv-backup] [INF]‒ Finalizing transfer[cd91a114-975e-4b9f-a256-dfc2b1acf89b] with disk[59189b1a-7c11-4725-8c4e-8fda35339a47].
[rv-backup] [INF]‒ Transfer[cd91a114-975e-4b9f-a256-dfc2b1acf89b] finalized in 1.010 seconds.
[rv-backup] [INF]‒ Download disk[59189b1a-7c11-4725-8c4e-8fda35339a47] completed successfully.
[rv-backup] [INF]‒ VM[a8a53919-c5ea-4199-846c-1f532d73e6a0] configuration saved to: backups/vm_a8a53919-c5ea-4199-846c-1f532d73e6a0/cp_bb5a2c18-7c34-4a4b-874d-0fb4a1117769/config.ovf
[rv-backup] [INF]‒ Backup[efe599d7-f674-4169-97cf-77b94c7928df] download completed.
[rv-backup] [INF]‒ Connection closed!

Использование функционала emergency

Администратор может столкнуться с последствиями сбоев, такими как блокировка диска, трансфера. Для такой ситуации rv-backup имеет дополнительный набор экстренных функций.

Важно ‒ Следует внимательно изучить последствия неправильного использования экстренного функционала.

Алгоритм действий:

  1. убедиться, что экстренный функционал правильно настроен, и конфигурация содержит нужный раздел;
  2. осуществить развертывание ключей для доступа rv-backup к СУСВ, для чего также потребуется ввести пароль пользователя root СУСВ:
rv-backup emergency deploy_ssh_keys
  1. проверить доступность SSH-соединения с engine для rv-backup командой:
rv-backup emergency test_ssh_to_he

При наличии возможности соединения с engine будет выведено сообщение:

Connection successful!
  1. после успешной проверки ввести одну из команд, в зависимости от ситуации:

Примечание — Команды экстренного функционала являются интерактивными и требуют участия пользователя.

для разблокировки трансферов
rv-backup emergency unlock_transfers
для разблокировки дисков
rv-backup emergency unlock_disks

и следовать дальнейшим инструкциям rv-backup.

Перенос хранилища резервных копий

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

Существуют два метода перемещения хранилища бэкапов:

  • с помощью команды rv-backup storage move (рекомендуется);
  • вручную.

Ручной метод

Проще всего переносить директории, содержащие чек-пойнты (начинаются с префикса cp_) ВМ, целиком. Имя таких директорий начинается c префикса vm_, например vm_d9ce6db5-fd2b-446d-bc69-c2b825790cfb. Важно соблюдать структуру резервных копий. Директория, указанная в конфигурации Paths::storage_dir, должна содержать директории с ВМ.

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

Примечание — Исключение составляет лишь корневой чек-пойнт, который по сути является полной резервной копией ВМ. Только из него можно восстановить ВМ, даже если другие чек-пойнты отсутствуют.

После переноса резервных копий из другого места следует подкорректировать пути, хранящиеся в чек-пойнтах, которые указывают на место предыдущего чек-пойнта (эти пути хранятся в метаданных qcow). Для этого нужно запустить автоматическую процедуру проверки:

rv-backup storage check

Эта проверка скорректирует пути нужным образом.

Остаточные ВМ и очистка хранилища

Остаточные ВМ (residual VM) ‒ это виртуальные машины, находящиеся в хранилище резервных копий и не имеющие карту чек-пойнтов ни на сервере виртуализации (СУСВ), ни в хранилище резервных копий.

Остаточные ВМ могут получиться в результате удаления чек-пойнтов командой backup remove --local, если предварительно не сделать очистку командой backup clean --local, например:

rv-backup vm TestVm backup remove --local
команда очистки не выполнена
rv-backup vm TestVm backup clean --local

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

rv-backup list vms --residual

Пример вывода:

[root@host1 src]# rv-backup list vms --residual
13:43:07 Check of backup storage for remaining metafiles completed.
13:43:07 Checkpoint map for VM[a55d1159-3c41-481f-bf1c-ae311c1a817d] not found. The search for the latest configuration will be performed by modification date!
┌───────────────────┬─────────────────────────────────────┐
│                    VM │ a55d1159-3c41-481f-bf1c-ae311c1a817d        │
╞═══════════════════╪═════════════════════════════════════╡
│                  Name │ TestVm                                      │
│                  Path │ /storage/vm_a55d1159-3c41-481f-bf1c-ae311c1a817d   │
│                   OVF │ /storage/vm_a55d1159-3c41-481f-bf1c-ae311c1a817d/cp_519b44e4-fc66-40f3-ad0e-2db3e7719e16/config.ovf      │
│         1. Checkpoint │ 519b44e4-fc66-40f3-ad0e-2db3e7719e16        │
│             Timestamp │ 2023-10-02T18:31:35                         │
│                  Size │ Disks: 2, 384.23KB                          │
│         2. Checkpoint │ e82af539-0e07-42f6-b994-64f80fa04301        │
│             Timestamp │ 2023-10-02T18:32:32                         │
│                  Size │ Disks: 2, 4.47GB                            │
└──────────────────┴──────────────────────────────────────┘

Важно:

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

Основной сценарий Disaster Recovery

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

Примечание — Disaster Recovery использует механизм инкрементальных резервных копий rv-backup для получения дисков ВМ.

Каждые 15 минут (или сколько указано в конфигурации) производится проверка актуальности состояния ВМ в РВ. Если состояние неактуально (не соответствует состоянию ВМ на ОВ), то начинается итерация Disaster Recovery.

В рамках итерации Disaster Recovery производится оценка, что именно устарело из следующих компонентов: диски ВМ: метаданные дисков (файлы .lease и .meta) или инкремент базы данных (sql-дамп с метаданными), а также производится доставка устаревших компонентов в хранилище РВ. Этот процесс можно понимать как синхронизацию ВМ с ВМ на РВ.

Когда возникает необходимость воспользоваться резервной ВМ, запускается хост с резервным ЦУ. На этом хосте установлен необходимый компонент Disaster Recovery ‒ утилита rv-dr-sync, которая подключается к резервному хранилищу, забирает оттуда инкременты базы данных и применяет их по очереди к базе данных РЦУ перед его непосредственным запуском. Таким образом, резервная ВМ готова к запуску сразу после запуска РЦУ.

Для работы Disaster Recovery требуется:

  • Развёрнутая и настроенная основная виртуализация и резервная виртуализация.
  • Настроенное инкрементальное резервное копирование rv-backup.
  • Настройка:
    • проведена настройка Disaster Recovery;
    • заполненные разделы конфигурации Options.DisasterRecovery и Options.DisasterRecovery.vm.uuid;
    • на хосте РЦУ установлена и настроена утилита rv-dr-sync;
    • доступ к хосту ОЦУ;
    • доступ к хосту с смонтированным хранилищем РВ, в том числе с хоста РЦУ.

Как только все требования будут соблюдены, достаточно создать первую резервную копию ВМ:

rv-backup vm MyVM1 backup start -d -f -c 'first backup'

и запустить итерацию Disaster Recovery:

rv-backup vm MyVM1 disaster run

После завершения выполнения команды итерацию Disaster Recovery можно считать завершенной. Теперь можно запускать ЦУ (СУСВ) РВ и запускать ВМ.

Дополнительная информация

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

Важно ‒ Механизм Disaster Recovery на данном этапе реализации не отличает, какое из состояний ВМ было изменено позже (более актуально) при сравнении состояний ВМ из ОВ и ВМ из РВ. Это значит, что если ВМ в РВ производила изменения на диске, то эти изменения могут быть перезаписаны следующим циклом Disaster Recovery.

Чем чаще проходит цикл Disaster Recovery, тем актуальнее состояние ВМ в РВ. При запуске итерации Disaster Recovery сработает проверка параметра конфигурации check_interval, и если время проверки еще не пришло, то проверка актуальности пропускается, экономя время для остальных операций. Если время проверки настало, будут произведены все действия с устаревшими компонентами Disaster Recovery, описанные выше, за исключением ситуации, когда все компоненты по-прежнему актуальны, в таком случае итерация Disaster Recovery завершается сразу.

Возможные ошибки

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

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

Необходимо выполнить следующие действия:

удаление карты чек-пойнтов на сервере виртуализации
rv-backup vm <vm_name> backup remove --remote
удаление карты чек-пойнтов в хранилище
rv-backup vm <vm_name> backup remove --local
очистка хранилища от файлов несуществующих(теперь) чек-пойнтов
--remote означает, что сверка будет происходить с картой чек-пойнтов на сервере виртуализации
rv-backup vm <vm_name> backup clean --remote

После этого можно начать новую цепочку резервных копий:

rv-backup vm <vm_name> backup start -d -f -c "first checkpoint‒ full backup"

Сбор информации для отладки

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

rv-backup --collect-logs </путь/к/архиву>

Команда собирает вывод различных консольных команд, а также копирует структуру хранилища резервных копий, за исключением дисков (qcow2). Вся информация собирается во временной директории c префиксом rv-backup-collector-. После сбора информации rv-backup предложит проследовать в эту директорию и проверить файлы на содержание "чувствительной" информации. Если пользователь решит, что все файлы этой директории не содержат такой информации, то rv-backup сложит их в архив (.tar.gz) с именем, указанным при вызове команды. Этот архив можно передать разработчикам для отладки.

Важно ‒ Все решения о передаче какой-либо информации принимает исключительно пользователь. rv-backup не собирает и не отправляет какую-либо информацию без его ведома и намерения. rv-backup использует передачу информации исключительно для взаимодействии с ЦУ виртуализации при выполнении задач резервного копирования.

Примерная структура временной директории, где сохраняется собранная информация перед архивацией:

/tmp/rv-backup-collector_psu14g8c
├── data
│   └── backups
│       ├── vm_d9ce6db5-fd2b-446d-bc69-c2b825790cfb
│       │   ├── checkpoints.map
│       │   ├── cp_408c967c-3d17-412c-973b-21761a5bcaa6
│       │   │   └── config.ovf
│       │   └── cp_f40bd94a-2cd8-49c4-968f-ebc0e78b73b2
│       │       └── config.ovf
│       └── vm_f13addca-0482-4ffa-b4b6-68900ac4ffe5
│           ├── checkpoints.map
│           ├── cp_03c602ec-24c1-4926-9d0d-359e53cb1974
│           │   └── config.ovf
│           └── cp_19279145-d80e-41d7-a5b5-098c6526a4c8
│               └── config.ovf
├── journalctl
├── ls
├── tree
└── meta.json

Пример содержания meta.json:

{
"version": "0.7.6",
"datatime": "09.02.2023 10:46:43 ",
"used_commands": {
"tree": "tree -a --dirsfirst --sort=mtime /data/backups",
"ls": "ls -lARh /data/backups",
"journalctl": "journalctl --no-pager | grep rv-backup"
}
}