완전히 준비된 상태이므로 데이터와 시스템을 쉽게 복원할 수 있는 방식으로 Ubuntu 시스템의 백업을 생성해야 합니다. 그래서 dd풀 HHD 이미지를 만들기로 결정했습니다.
제가 만든 이미지는 다음과 같습니다.
dd if=/dev/current_drive of=/dev/backup_drive/backup.img conv=sync status=progress
이미지가 오류 없이 완료되었습니다. 그 후 새 드라이브를 테스트하기 위해 이미지를 복원하기로 결정했습니다.
dd if=/backup_drive/backup.img of=/dev/new_drive conv=sync status=progress
여태까지는 그런대로 잘됐다. 이미지 복구에는 오류가 없습니다. 하지만 복구 이미지의 새 하드 드라이브에서 부팅하려고 하면 initramfs다음 오류가 발생합니다.
그래서 수동으로 수행한 후 fsck오류가 해결되었고 새 하드 드라이브에서 부팅할 수 있었습니다. 하지만 이미지를 드라이브에 복원하는 과정을 몇 번 시도했는데 매번 시작 문제가 발생했습니다. 내 원래 시스템 드라이브와 새 시스템 드라이브에 따르면 정확히 동일합니다.
sudo fdisk -l:
/dev/sda/새 하드 드라이브입니다.
/dev/sdb/이미지가 생성된 원본 이미지입니다.
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf11c2eb5
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 455024639 455022592 217G 83 Linux
/dev/sda2 455026686 488396799 33370114 15.9G 5 Extended
/dev/sda5 455026688 488396799 33370112 15.9G 82 Linux swap / Solaris
Disk /dev/sdb: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf11c2eb5
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 455024639 455022592 217G 83 Linux
/dev/sdb2 455026686 488396799 33370114 15.9G 5 Extended
/dev/sdb5 455026688 488396799 33370112 15.9G 82 Linux swap / Solaris
그렇다면 제가 뭘 잘못하고 있는지, 이미지 복원 후 부팅 오류가 발생하는 이유를 알고 계시나요? 원래 하드 드라이브에 오류가 발생하면 최종 새 하드 드라이브를 수리해야 하는 실제 상황을 겪고 싶지 않습니다.
그런데 원래 드라이브는 SSD였고 새 드라이브는 HDD였습니다(중요한 경우).
답변1
때를 dd,
- 소스 장치/파일 시스템을 변경/설치/기록해서는 안 됩니다.
- 및와
conv함께 사용 하지 마십시오 .noerrorsync손상된 데이터 bs=1M(또는bs=64K)을 다음과 같이 추가하세요 .성능상의 이유
기본적으로 성공적이고 일관된 직접 디스크 복사는 Live CD와 같은 독립 실행형 시스템을 통해서만 달성할 수 있습니다.그래도 조심해야지사용자가 모르는 사이에 파일 시스템이 자동으로 마운트되는 것과 관련됩니다.
sync또한 읽기 오류(따라서 및 noerror기타 옵션) 가 예상되는 경우 conv사용하는 것이 더 안정적입니다 ddrescue. 읽기 오류를 올바르게 처리하고 재시도 및 복구 기능도 갖추고 있습니다.
전체적으로 블록 수준 복사본은 오류가 발생하기 쉽기 때문에 신뢰할 수 없는 경향이 있습니다. 이렇게 하는 유일한 이유는 이것이 복사본을 생성할 수 있는 유일한 방법이기 때문입니다.완벽한 일관성(올바르게 수행된 경우에만).
다른 모든 방법은 단지충분하다실제로는 결코 완벽하지 않습니다. 데이터의 절반은 메모리에, 나머지 절반은 디스크에 유지하는 실행 중인 프로세스의 완벽한 복사본을 만들 수 있는 방법은 없습니다. 전체 이미지를 얻으려면 이 기능을 꺼야 합니다. (또는 모든 것을 가상화하고 동결합니다.)
다른 옵션도 있습니다:
- cp, rsync 또는 전용 백업 프로그램을 사용한 파일 기반 백업보그
- 파일 시스템별 도구(xfsdump, btrfs 전송/스냅샷...)
- 좌심실 용적스냅 사진(하지만btrfs를 사용하지 않음)
- 데이터베이스는 특별한 처리가 필요하며 자체 백업 도구를 제공합니다.
블록 수준 복사본이어야 하는 경우 mdadm 시스템을 남용하여 소스 드라이브에 RAID 1 레이어를 배치하고 이를 사용하여 대상 드라이브를 추가하여 실행 중인 시스템에서 일관된 복사본을 생성할 수도 있습니다. RAID는 두 당사자를 완벽한 동기화 상태로 유지하므로 불일치 문제를 크게 방지합니다(대상 드라이브를 삭제하기 전에 동기화가 완료되도록 허용한 경우).
# RAID creation (before installing Linux)
mdadm --create /dev/md0 --level=1 --raid-devices=1 --force /dev/source
# /proc/mdstat
md0 : active raid1 sda2[3]
134306472 blocks super 1.2 [1/1] [U]
# Add the target drive.
mdadm --grow /dev/md0 --raid-devices=2 --force
mdadm --manage /dev/md0 --add --write-mostly /dev/target
# Wait for RAID resilvering.
mdadm --wait /dev/md0
sync
# Remove the target drive.
mdadm /dev/md0 --fail /dev/target
mdadm /dev/md0 --remove /dev/target
mdadm --grow /dev/md0 --raid-devices=1 --force
그러나 이것은 해킹이며 복사본은 제대로 마운트 해제되지 않은 파일 시스템으로 계속 표시됩니다. sync예기치 않게 정전이 되면 이를 수행할 수 없기 때문에 이는 정전보다 약간 더 나쁩니다 . 그러나 dd이미지의 전반부의 상태가 후반부의 상태보다 몇 시간 뒤처지는 것보다 훨씬 더 낫습니다.
저는 매주 이 방법을 사용하여 HDD 대기를 차단하지 않고 단일 SSD 드라이브를 HDD에 미러링합니다. SSD에 장애가 발생하면 HDD가 쉽게 부팅될 수 있습니다.
물론 파일 기반 복사본을 사용해도 동일한 목적을 달성할 수 있습니다.
UUID를 언급했으므로 블록 수준에서 드라이브를 복제하면 UUID가 복제되어 결과적으로 재난이 발생할 수 있습니다. (위에서 설명한 RAID 공격의 경우 RAID 레이어 뒤에 편리하게 숨겨져 있습니다.)
새 파일 시스템으로의 파일 기반 복사에는 새로운 UUID가 있지만 해결 방법은 매우 간단합니다.
chroot, 편집/etc/fstab, initramfs 업데이트, 부트로더 재설치(chroot 방법은 기본적으로 모든 Linux 위키에서 찾을 수 있습니다)- 그렇지 않으면 Change Old UUID를 사용하여 이전 UUID를 복원하십시오
tune2fs -U <UUID>. 다른 파일 시스템에 대한 유사한 도구가 있습니다(문서가 필요합니다. 그렇지 않으면 필요한 UUID를 알 수 없습니다). 다시 말하지만, 중복되지 않도록 주의하고 이전 장치가 완전히 사라진 경우에만 이 작업을 수행하십시오.