Восстановление резервной копии виртуальной машины
Непосредственное восстановление виртуальных машин в KVM при помощи RuBackup возможно для таких виртуальных машин, диски которых располагаются в файловой системе и используют формат qcow2.
Если для дисков виртуальной машины используются блочные устройства или устройства Ceph, то резервная копия будет восстановлена в каталоге в виде набора файлов виртуальной машины (конфигурационный xml-файл и образы дисков виртуальной машины), которые можно импортировать в среду виртуализации вручную.
Клиент может осуществить восстановление данных резервной копии в оконном Менеджере Клиента RuBackup (RBC), либо при помощи утилиты командной строки rb_archives.
В случае восстановления инкрементальной резервной копии будет сформирована цепочка восстановления: вначале будет восстановлена полная резервная копия, на которую будут наложены изменения из инкрементальных резервных копий.
1. Восстановление резервной копии в RBC
Для восстановления данных резервной копии в оконном Менеджере Клиента RuBackup (RBC) необходимо выполнить следующие действия:
-
Выделить нужную резервную копию и в контекстном меню выбрать «Восстановить» (рисунок 1):
-
Ввести пароль клиента и далее RBC выведет информационное сообщение о дальнейших действиях (рисунок 2):
-
Указать место восстановления резервной копии (рисунок 3):
-
Далее появится информационное сообщение о создании задачи на восстановление (рисунок 4):
-
Проконтролировать результат процесса восстановления можно после автоматического переключения RBC на вкладку «Задачи» (рисунок 5):
После выполнения восстановления в KVM появится новая виртуальная машина, полностью идентичная той, которая была в системе в момент резервного копирования.
2. Централизованное восстановление резервных копий с помощью RBM
Система резервного копирования RuBackup предусматривает возможность восстановления резервных копий как со стороны клиента системы, так и со стороны администратора СРК.
В тех случаях, когда централизованное восстановление резервных копий не желательно, например когда восстановление данных является зоной ответственности владельца клиентской системы, эта функциональность может быть отключена на клиенте (см. RuBackup Manager (RBM)).
В тех случаях, когда централизованное восстановление на клиенте доступно, то его можно инициировать, перейдя в раздел «Репозиторий». Найдите в списке требуемую резервную копию, нажмите на нее правой кнопкой мыши и выберите в контекстном меню «Восстановить» (рисунок 6):
В окне централизованного восстановления можно увидеть основные параметры резервной копии и, если это применимо, определить место восстановления резервной копии.
В случае восстановления виртуальной машины из резервной копии будет выполнена проверка наличия в среде виртуализации виртуальной машины с оригинальным именем.
Если такой виртуальной машины нет, то будет произведено восстановление с оригинальным именем.
Если виртуальная машина с таким именем уже есть, то к имени виртуальной машины будет добавлен цифровой постфикс. Также будут удалены из восстанавливаемой виртуальной машины специфичные параметры сетевых интерфейсов (например MAC-адрес), для избежания конфликтов с оригинальной виртуальной машиной (рисунок 7).
Проверить ход выполнения восстановления резервной копии можно в окне «Очередь задач» (рисунок 8).
При успешном завершении восстановления резервной копии или цепочки резервных копий, соответствующие задачи на восстановление перейдут в статус «Done» (рисунок 9).
3. Восстановление при помощи утилиты rb_archives
Для восстановления резервных копий клиент может использовать утилиту командной строки rb_archives.
Используйте следующую команду:
rb_archives
rb_archives -x 63Password:
----> Restore archive chain: 63 < ----
Record ID: 63 has status: Trusted
TASK WAS ADDED TO QUEUE:233Вы можете проконтролировать процесс восстановления в файле журнала при помощи команды:
tail -f /opt/rubackup/log/RuBackup.logTue 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