☰

rsync를 사용하여 루트의 디렉터리에서 루트를 복원할 수 있습니까?

tag-icon • tag-icon rsync backup root
rsync를 사용하여 루트의 디렉터리에서 루트를 복원할 수 있습니까?

내가 예상하는 이벤트 순서는 다음과 같습니다.

대부분의 루트 디렉터리 백업

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} / /BACKUP

반전 과정

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} /BACKUP /

나는 먼저 온전한 확인을 하지 않고 파트 2를 시도하는 것에 대해 긴장했기 때문에 이 게시물을 작성했습니다. 출력은 --dry-run모두 좋아 보이지만 먼저 확인하고 싶습니다.

답변1

rsync를 사용한 전체 시스템 백업 복구를 위해 다음을 성공적으로 사용했습니다.

백업 명령:

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /* /backup

-H하드 링크 도 추가했습니다 . 나는 그것을 사용하는 것이 좋습니다. 그리고 -S파일이 드물다면. 가상 머신용으로 많이 가지고 있습니다.

복원하려면 라이브 CD/USB를 사용하고 새로 포맷된 빈 디스크를 마운트한 /mnt다음,

복구 명령:

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /backup/* /mnt

앞으로 일어날 일 /etc/fstab( /mnt/etc/fstab)을 잘 살펴보고 grub.cfg, 다시 시작하면 잘 될 것입니다.

제외와 관련하여 lost+foundXFS와 같은 일부 파일 시스템에서는 사용할 수 없으므로 이러한 파일 시스템을 사용하는 경우 포함해도 문제가 없습니다.

답변2

실제로 최고의 건전성 점검은백업에서 부팅.
실제 테스트를 통해 100% 확신할 수 있는 유일한 방법입니다!
내가 아는 한, 루트 디렉터리 내의 폴더에서는 이 작업을 수행할 수 없습니다. (실제로 제가 사용하고 있는 타겟은 "루트 트리 내의 폴더"이지만 /media/$USER/RootBackup 에서는 실제로는 또 다른 파일 시스템입니다.) 바로 사용하기 위해 백업을 복원할 필요도 없고 그냥 급한 경우나 나쁜 일이 발생하면 백업에서 부팅하고 거기에서 복원하세요!

를 사용하면 rsync필요할 때마다 매우 빠르게 루트 백업을 업데이트할 수 있습니다. 나는 우분투 20.04에서 커널과 기타 핵심 패키지를 업데이트하기 전에 매번 이 작업을 수행합니다.

관찰: LVM도 사용하는 경우 LVM 스냅샷을 매우 느린 옵션으로 폐기합니다.

나는 이 명령을 사용하고 있습니다.
sudo rsync -axHAXv --delete-excluded / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /media/$USER/RootBackup/
그런 다음 몇 번 실행하여 중요한 파일이 변경되지 않았는지 확인합니다.
--delete-excluded의 중요성은 실제로 동기화를 유지하는 것입니다(동일).

또한 /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-update이제 grub.cfg에서 /boot/grub/custom.cfg로 새 메뉴 항목을 복사합니다. (저는 여기서 gpt를 사용하고 있습니다. 이것이 필요하지 않을 수도 있습니다. 필요에 따라 생성된 메뉴 항목을 복사하고 수정하면 됩니다.)

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명령은 동일한 UUID를 사용합니다.linux
  • vmlinuz 및 initrd는 "/boot/"에서 검색되어야 하며 자동 심볼릭 링크를 사용하여 유지 관리할 필요가 없습니다.
  • root=UUID=.../dev/sdb4가 무작위로 sdc4로 변경되어 신뢰할 수 없기 때문에 linux 명령을 사용해야 합니다.
  • PARTUUID는 작동하지 않으므로 사용하지 마세요.

복원하려면 백업에서 부팅합니다. 그러면 원본 경로는 /가 되고 대상 경로는 설치해야 하는 다른 경로가 됩니다.

너무 오랫동안 기본 루트 백업 프로세스를 실행하지 않은 경우를 대비하여 다음을 수행하십시오.

  • 작업 중인 백업 루트에서 부팅
  • 만들다기본 루트 FS에서 두 번째 백업
  • 작업 중인 백업 루트를 기본 루트 FS로 복원
  • 기본 루트 FS에서 부팅
  • 누락되거나 잘못된 항목이 발견되면 방금 생성한 두 번째 백업에서 필요한 항목을 가져옵니다.

중단 없이 핵심 시스템 파일을 중요한 업데이트로 업데이트할 필요 없이 데스크탑 컴퓨터에서 지금처럼 마음의 평화를 누리시기를 바랍니다. :)

관련 정보