Снимок LVM создается в грязном состоянии и не может быть смонтирован в XEN

У меня есть сервер, на котором работает Xen 4.9.2 с Linux Ubuntu 18.04.2, установленным в Dom0. Существует одна виртуальная машина (DomU) с Linux Ubuntu 12.04.5, которая использует логический том LVM в качестве корневой файловой системы. Этот логический том LVM настроен в Dom0, и на нем создается файловая система ext4. Затем он подвергается DomU следующим образом:

disk = [ '/dev/GuestVg/RootLv0,raw,xvda1,rw' ]

и DomU монтирует его таким образом (/ etc / fstab):

# file system  mount point  type  options                              dump    pass
/dev/xvda1     /            ext4  noatime,nodiratime,errors=remount-ro 0       1

Я пытаюсь использовать моментальный снимок LVM для резервного копирования логического тома из Dom0 пока файловая система смонтирована в DomU. Проблема с этим подходом заключается в том, что когда я создаю моментальный снимок этого логического тома только для чтения, он создается с файловой системой в «грязном» состоянии (need_recovery установлен флаг) и мой инструмент резервного копирования fsarchiver не могу его смонтировать.

# Creating read-only snapshot
sudo lvcreate -s -p r -n rootfs_snapshot -L 512M /dev/GuestVg/RootLv0
  Using default stripesize 64.00 KiB.
  Logical volume "rootfs_snapshot" created.

# Checking needs_recovery flag on the filesystem
sudo tune2fs -l /dev/GuestVg/RootLv0 | grep 'needs_recovery'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file

# Checking needs_recovery flag on the snapshot
sudo tune2fs -l /dev/GuestVg/rootfs_snapshot | grep 'needs_recovery'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file

# Running backup
sudo fsarchiver -v savefs rootfs_2019-02-15.fsa /dev/GuestVg/rootfs_snapshot
filesys.c#318,generic_mount(): partition [/dev/GuestVg/rootfs_snapshot] cannot be mounted on [/tmp/fsa/20190215-205030-00061846-00] as [ext4] with options [user_xattr,acl]
oper_save.c#1032,filesystem_mount_partition(): cannot mount partition [/dev/GuestVg/rootfs_snapshot]: filesystem may not be supported by either fsarchiver or the kernel.
removed rootfs_2019-02-15.fsa

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

Когда файловая система размонтирована или когда она монтируется в Dom0 (вместо DomU), моментальный снимок создается без need_recovery флаг, и его можно успешно смонтировать и создать резервную копию.

Я провел небольшое исследование и нашел объяснение того, что происходит, когда файловая система монтируется в Dom0. Ссылка: https://yarchive.net/comp/linux/disk_snapshot.html

Когда монтируется файловая система ext4, устанавливается флаг needs_recovery. Этот флаг очищается при чистом размонтировании файловой системы. Если система выйдет из строя без чистого umount, этот флаг позволяет программе e2fsck знать, что для ее восстановления необходимо выполнить проверку файловой системы. Когда снимок LVM создается логического тома с смонтированной файловой системой ext4, команда lvcreate делает снимок файловой системы в неактивном состоянии; то есть он принудительно закрывает транзакцию журнала, приостанавливает все действия файловой системы, делает снимок диска, как если бы он был отключен, а затем разрешает продолжить работу файловой системы. Итак, если вы посмотрите на снимок файловой системы ext4, сделанный таким образом, вы увидите, что флаг needs_recovery не установлен, поскольку журнал ext4 в снимке пуст.

Моя проблема в том, что файловая система монтируется ядром, работающим в DomU, а не в Dom0 (где делается снимок), и поэтому все описанные шаги, которые выполняет lvcreate, похоже, не имеют никакого эффекта. Моментальный снимок файловой системы создается в "грязном" состоянии (флаг needs_recovery все еще установлен), и такие инструменты, как fsarchiver, отказываются монтировать такой моментальный снимок для создания резервной копии. Я могу внести некоторые изменения в файловую систему через tune2fs из Dom0, чтобы очистить флаг needs_recovery (пока он все еще смонтирован в DomU), а затем сделать снимок, но это похоже на взлом, который может привести к повреждению данных, потому что ядро ​​в DomU не будет знать, что файловая система была изменена с Dom0.

Итак, мой вопрос: как правильно сделать снимок LVM в чистом состоянии в Dom0 логического тома с файловой системой, смонтированной в запущенном DomU? Это вообще возможно?

Я не хотел бы выключать DomU для создания резервной копии, но мне интересно, является ли это единственным способом сделать согласованный моментальный снимок.