Для полного резервного копирования системы -восстановление с использованием rsync, которое я успешно использовал:

команда резервного копирования:
sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /* /backup

Я также добавил -Hдля жестких ссылок. Я настоятельно рекомендую вам использовать его. И -S, если у вас разреженные файлы. У меня их было много, для виртуальных машин.

Для восстановления я использовал live cd/usb, смонтировал пустой, только что отформатированный вскоре -на -be -/ диск на /mnt, а затем

команда восстановления:
sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /backup/* /mnt

Позаботился о том, чтобы вскоре -по -стать /etc/fstab(/mnt/etc/fstab), также взгляните на grub.cfg, перезагрузился, и все прошло гладко.

Что касается исключения, lost+foundнедоступно в некоторых файловых системах, например в XFS, поэтому его можно опустить, если используется такая fs; никакого вреда, хотя, если он включен.

Лучшей проверкой работоспособности является загрузка из резервной копии .
Это единственный способ быть уверенным на 100%, проверив это на деле!
Насколько я знаю, вы не сможете сделать это из папки внутри корня. (На самом деле я использую в качестве места назначения «папку внутри корневого дерева», но в /media/$USER/RootBackup это фактически другая файловая система. )Вам даже не нужно будет восстанавливать резервную копию, чтобы оперативно ею воспользоваться, в случае, если вы спешите и случится что-то плохое, просто загрузитесь с резервной копии, а затем восстановите ее!

С rsyncдостаточно быстро просто обновить резервную копию корня в любое время. Я делаю это каждый раз перед обновлением ядра и других основных пакетов в Ubuntu 20.04.

Обс. :Если вы тоже используете LVM, я отказался от моментального снимка LVM как вариант из-за очень медленной работы.

Я использую эту команду:
sudo rsync -axHAXv --delete-excluded / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /media/$USER/RootBackup/
Я запускаю его несколько раз, чтобы важные файлы не изменились.
Важность --delete -exclude заключается в том, чтобы действительно синхронизировать (идентичный ).

Я также делаю резервную копию /boot отдельно, потому что там смонтирован другой раздел с:
sudo rsync -axHAXv --delete-excluded /boot/ --exclude=/lost+found /media/$USER/RootBackup/boot/

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

mount |grep RootBackup #copy the device name, ex.: sdb4
ls /dev/disk/by-uuid/ -l |grep sdb4 # copy the UUID ex.: 4e97fe69-93ae-4e6a-a2cc-3406cb21176c

теперь скопируйте новую запись меню из grub.cfg в /boot/grub/custom.cfg (Здесь я использую gpt, вам это может не понадобиться, просто скопируйте и измените запись меню, сгенерированную grub-updateпо мере необходимости):

menuentry 'RootBackup by UUID' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osproberfailed-manualadjustment-gnulinux-simple-4e97fe69-93ae-4e6a-a2cc-3406cb21176c' {
    insmod part_gpt
    insmod ext2
    set root='hd3,gpt13'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd3,gpt13 --hint-efi=hd3,gpt13 --hint-baremetal=ahci3,gpt13  4e97fe69-93ae-4e6a-a2cc-3406cb21176c
    else
      search --no-floppy --fs-uuid --set=root 4e97fe69-93ae-4e6a-a2cc-3406cb21176c
    fi
    linux /boot/vmlinuz root=UUID=4e97fe69-93ae-4e6a-a2cc-3406cb21176c ro quiet splash $vt_handoff debug --verbose
    initrd /boot/initrd.img
}

обс. :важные изменения, необходимые после grub-updateавтоматически созданного пункта меню, были:

• предоставить правильный UUID. Обратите внимание, что команды searchи linuxиспользуют один и тот же UUID, поскольку вся резервная копия оказалась в одном разделе.
• vmlinuz и initrd нужно было искать в «/boot/», и они используют автоматическую символическую ссылку, чтобы не требовать обслуживания
• Команде linux пришлось использовать root=UUID=..., потому что /dev/sdb4 случайно изменился на sdc4 и был ненадежным
• не используйте PARTUUID, так как он не будет работать.

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

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

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

Я надеюсь, что вы можете быть так же спокойны, как я сейчас, на настольном ПК, без -перерыва и необходимости обновлять основные системные файлы критическими обновлениями!:)