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

Непосредственное восстановление виртуальных машин в KVM при помощи RuBackup возможно для таких виртуальных машин, диски которых располагаются в файловой системе и используют формат qcow2.

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

Клиент может осуществить восстановление данных резервной копии в оконном Менеджере Клиента RuBackup (RBC), либо при помощи утилиты командной строки rb_archives.

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

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

Для восстановления данных резервной копии в оконном Менеджере Клиента RuBackup (RBC) необходимо выполнить следующие действия:

  • Выделить нужную резервную копию и в контекстном меню выбрать Восстановить (Рисунок 1):

20
Рисунок 1.

  • Ввести пароль клиента и далее RBC выведет информационное сообщение о дальнейших действиях (Рисунок 2):

21
Рисунок 2.

  • Указать место восстановления резервной копии (Рисунок 3):

22
Рисунок 3.

  • Далее появится информационное сообщение о создании задачи на восстановление (Рисунок 4):

23
Рисунок 4.

  • Проконтролировать результат процесса восстановления можно после автоматического переключения RBC на вкладку Задачи (Рисунок 5):

24
Рисунок 5.

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

2. Централизованное восстановление резервных копий с помощью RBM

Система резервного копирования RuBackup предусматривает возможность восстановления резервных копий как со стороны клиента системы, так и со стороны администратора СРК.

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

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

25
Рисунок 6.

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

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

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

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

26
Рисунок 7.

Проверить ход выполнения восстановления резервной копии можно в разделе Tasks Задачи (Рисунок 8).

27
Рисунок 8.

При успешном завершении восстановления резервной копии или цепочки резервных копий, соответствующие задачи на восстановление перейдут в статус Done (Рисунок 9).

28
Рисунок 9.

3. Восстановление при помощи утилиты rb_archives

Для восстановления резервных копий клиент может использовать утилиту командной строки rb_archives. Используйте следующую команду:

rb_archives
29 
rb_archives -x 63
Password:
----> Restore archive chain: 63  < ----
Record ID: 63 has status: Trusted
TASK WAS ADDED TO QUEUE:233

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

tail -f /opt/rubackup/log/RuBackup.log
Tue Mar  2 17:58:29 2021: Try new name: ubuntu18.04-test-kvm-0
Tue Mar  2 17:58:29 2021: The name: ubuntu18.04-test-kvm-0 is free. Use it
Tue Mar  2 17:58:29 2021: Found disk in XML file. Type: file device: disk
Tue Mar  2 17:58:29 2021: Source file: /var/lib/libvirt/images/ubuntu18.04_clean-clone-3-clone-clone-1.qcow2
Tue Mar  2 17:58:29 2021: File is exists: /var/lib/libvirt/images/ubuntu18.04_clean-clone-3-clone-clone-1.qcow2
Tue Mar  2 17:58:29 2021: Try new filename: /var/lib/libvirt/images/ubuntu18.04_clean-clone-3-clone-clone-1-0.qcow2
Tue Mar  2 17:58:29 2021: ------------>> Direct restore <<------------
Tue Mar  2 17:58:37 2021: New domain was defined from XML file: /rubackup-tmp/cbc208da-ee42-40ec-a111-778cb456853c/cbc208da-ee42-40ec-a111-778cb456853c.xml
Tue Mar  2 17:58:37 2021: Task was done. ID: 234
Tue Mar  2 17:58:37 2021: Task ID: 234. New status: Done

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

В том случае, если виртуальная машина с оригинальным именем уже присутствует в KVM, то новая виртуальная машина будет восстановлена с определенным постфиксом в ее имени, например -0;

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

rb_archives -X 63
Password:
----> Restore archive chain: 63  < ----
Record ID: 63 has status: Trusted
TASK WAS ADDED TO QUEUE:235

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

sudo ls -l cbc208da-ee42-40ec-a111-778cb456853c/
итого 5913168
-rw------- 1 root root       5475 мар  2 17:36 cbc208da-ee42-40ec-a111-778cb456853c.xml
-rw------- 1 root root        116 мар  2 17:36 target_list
-rw------- 1 root root 6055067648 мар  2 17:36 ubuntu18.04_clean-clone-3-clone-clone-1.qcow2