리눅스 루트 파티션 마이그레이션으로 새 디스크 안전하게 이전하기

리눅스 파티션 마이그레이션 작업은 평소엔 미루기 쉽지만, 디스크 용량이 부족해지거나 오래된 SSD를 교체해야 할 때는 결국 한 번은 하게 되더라고요. 특히 루트 디스크 이전은 운영체제 자체가 올라가 있는 영역을 옮기는 일이라서, 잘못 건드리면 부팅이 안 되거나 데이터가 꼬일 수 있습니다. 저도 홈랩에서 우분투 서버를 돌리다가 리눅스 디스크 업그레이드를 해야 했던 적이 있었는데, 처음엔 단순히 복사만 하면 끝날 줄 알았습니다. 근데 실제로 해보니까 파티션 구조, 부트로더, UUID, fstab(파일시스템 마운트 설정)까지 확인할 게 정말 많더라고요.

이번 글에서는 제가 실제로 자주 쓰는 방식 기준으로, 리눅스 루트 파티션을 새 디스크로 안전하게 마이그레이션하는 방법을 정리해보겠습니다. 핵심은 무작정 dd(블록 단위 복제)만 믿지 않고, 상황에 따라 rsync(파일 단위 동기화), gparted(파티션 편집 도구), 그리고 부트 복구 절차를 적절히 조합하는 겁니다. 여기서 중요한 포인트! 빠르게 끝내는 것보다 데이터 손실 방지가 우선입니다.

기존 디스크에서 새 디스크로 루트 파티션, EFI 또는 /boot, UUID 확인, 부트 복구까지 이어지는 전체 흐름을 보여주는 개요 이미지입니다.

1. 왜 리눅스 루트 파티션 마이그레이션이 까다로운가

쉽게 말해, 일반 데이터 디렉터리를 옮기는 것과 루트 파일시스템 root filesystem(운영체제 핵심 파일이 있는 영역)을 옮기는 건 난이도가 완전 다릅니다. 루트 파티션에는 /etc, /boot, /var, 라이브러리, 서비스 설정, 커널 이미지까지 엮여 있거든요. 여기에 BIOS 부팅인지 UEFI 부팅인지에 따라서 준비할 것도 달라집니다.

• 데이터만 복사하면 끝나지 않습니다. 부팅 정보도 맞아야 합니다.
• 파티션 UUID(고유 식별자)가 바뀌면 /etc/fstab 수정이 필요할 수 있습니다.
• GRUB(그럽, 리눅스 부트로더) 재설치가 필요한 경우가 꽤 많습니다.
• 실행 중인 시스템을 그대로 옮기면 로그나 캐시 파일이 바뀌어서 복제 일관성이 흔들릴 수 있습니다.

그래서 저는 가능하면 라이브 환경 Live Environment(USB로 부팅한 임시 OS)에서 작업하는 편입니다. 처음엔 번거로워 보여도, 결과적으로 사고가 덜 납니다.

2. 리눅스 파티션 마이그레이션 방식 비교: rsync vs dd vs gparted

많이들 고민하는 게 이겁니다. rsync와 dd 중 뭐가 낫냐는 질문이죠. 결론부터 말하면, 정답은 환경 따라 다릅니다. 저는 아래 기준으로 선택합니다.

제가 직접 해보니, 같거나 더 큰 디스크로 통째 복제면 dd가 편할 때도 있습니다. 반대로 더 큰 새 SSD로 옮기면서 파티션 구조를 정리하려면 rsync가 훨씬 낫더라고요. 이 글에서는 가장 범용적인 rsync 기반 리눅스 파티션 마이그레이션을 중심으로 설명하고, 중간에 dd가 맞는 경우도 같이 짚어보겠습니다.

3. 작업 전 체크리스트: 데이터 손실 방지부터 준비합니다

이 단계는 정말 중요합니다. 솔직히 말하면, 여기서 대충 하면 나중에 몇 시간 날립니다. 저도 예전에 디스크 이름을 잘못 보고 /dev/sda 대신 /dev/sdb를 건드릴 뻔해서 식은땀 났었거든요 ㅎㅎ

1. 전체 백업을 먼저 확보합니다. 가능하면 별도 외장 디스크나 NAS에 보관합니다.
2. 현재 부팅 방식이 UEFI인지 Legacy BIOS인지 확인합니다.
3. 원본 디스크와 대상 디스크의 장치명을 정확히 확인합니다.
4. LVM, RAID, LUKS 암호화 사용 여부를 먼저 파악합니다.
5. 가능하면 라이브 USB로 부팅해 오프라인 상태에서 진행합니다.

현재 디스크 구조 확인

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,UUID
sudo fdisk -l
findmnt /
cat /etc/fstab
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

이 명령으로 현재 루트 파티션, EFI System Partition(UEFI 부팅용 파티션), 스왑, UUID를 한 번에 대강 파악할 수 있습니다. 여기서 메모를 꼭 남겨두세요. 나중에 UUID 맞추거나 fstab 수정할 때 정말 도움 됩니다.

4. 실전 구현: 새 디스크에 루트 파티션 마이그레이션하는 단계

이제 본격적으로 들어가보겠습니다. 예시는 기존 디스크가 /dev/sda, 새 디스크가 /dev/sdb인 상황으로 가정하겠습니다. 실제 장치명은 환경마다 다르니 꼭 확인하고 바꾸셔야 합니다.

4-1. 새 디스크 파티션 준비

UEFI 시스템이라면 보통 아래처럼 구성하면 무난합니다.

• EFI 파티션: FAT32, 약간의 여유 공간
• 루트 파티션: ext4
• 필요 시 swap 파티션 또는 swap 파일

sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart ESP fat32 1MiB 513MiB
sudo parted /dev/sdb --script set 1 esp on
sudo parted /dev/sdb --script mkpart primary ext4 513MiB 100%

sudo mkfs.vfat -F32 /dev/sdb1
sudo mkfs.ext4 /dev/sdb2

BIOS 환경이라면 EFI 파티션 없이 루트 중심으로 잡는 경우가 많습니다. 다만 기존 구조를 최대한 비슷하게 가져가는 게 삽질을 줄입니다.

새 SSD에 EFI 파티션과 루트 파티션을 만드는 과정, 그리고 임시 마운트 지점을 연결하는 흐름을 보여주는 이미지입니다.

4-2. 대상 파티션 마운트

sudo mount /dev/sdb2 /mnt
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/sdb1 /mnt/boot/efi

만약 원본 시스템에 별도 /boot 파티션이 있다면 그것도 따로 만들어서 마운트해야 합니다. 여기서 구조가 틀어지면 복사 후 부팅이 안 될 수 있습니다.

4-3. rsync로 루트 파일시스템 복사

제가 가장 많이 쓰는 구간입니다. rsync는 파일 권한, 심볼릭 링크, ACL, 하드링크 등을 꽤 안정적으로 가져갈 수 있어서 좋습니다. 다만 제외 대상은 신중하게 잡아야 합니다.

sudo rsync -aAXHv \
  --exclude='/dev/*' \
  --exclude='/proc/*' \
  --exclude='/sys/*' \
  --exclude='/tmp/*' \
  --exclude='/run/*' \
  --exclude='/mnt/*' \
  --exclude='/media/*' \
  --exclude='/lost+found' \
  / /mnt

여기서 -aAXH 옵션이 중요합니다. archive, ACL, xattr, hardlink 보존을 의미하거든요. 처음엔 이게 뭔가 싶었는데, 권한과 메타데이터가 미묘하게 틀어지면 서비스가 이상하게 동작하는 경우가 있어서 저는 거의 습관처럼 넣습니다.

운영 중 시스템에서 바로 복사했다면, 마지막에 한 번 더 rsync를 돌려 변경분만 맞춰주는 것도 좋습니다. 다운타임을 줄일 때 꽤 유용하더라고요.

4-4. fstab 수정

새 디스크의 UUID를 확인한 뒤, 복사된 시스템의 /etc/fstab를 수정합니다.

sudo blkid /dev/sdb1 /dev/sdb2
sudo nano /mnt/etc/fstab

예를 들어 이런 식으로 바뀔 수 있습니다.

UUID=NEW-ROOT-UUID / ext4 defaults 0 1
UUID=NEW-EFI-UUID /boot/efi vfat umask=0077 0 1

이 단계에서 UUID를 잘못 넣으면 부팅 중 emergency mode(긴급 모드)로 떨어질 수 있습니다. 실제로 저는 swap UUID 하나 안 맞아서 부팅이 지연된 적이 있었네요.

4-5. chroot로 부트 환경 재구성

chroot(체루트, 임시로 새 루트 환경에 들어가는 방법)로 진입해서 부트로더와 initramfs를 재생성합니다.

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

grub-install /dev/sdb
grub-mkconfig -o /boot/grub/grub.cfg
update-initramfs -u
exit

배포판에 따라 grub2-mkconfig 또는 명령 경로가 다를 수 있습니다. UEFI 환경이라면 EFI 경로와 부트 엔트리 생성 여부도 확인해야 합니다. 우분투/데비안 계열은 위 절차가 익숙하고, RHEL 계열은 약간 다를 수 있습니다.

4-6. EFI 항목 확인

sudo efibootmgr -v

새 디스크 기준 부트 엔트리가 제대로 잡혔는지 확인합니다. BIOS/UEFI 설정에서 부팅 순서를 새 디스크로 올리는 작업도 잊지 마세요.

5. dd와 gparted는 언제 쓰면 좋을까

모든 상황에서 rsync가 정답은 아닙니다. 기존 디스크 상태가 깔끔하고, 구조를 그대로 복제하고 싶다면 dd가 단순할 때도 있습니다.

sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress

다만 이 명령은 정말 조심해야 합니다. if(입력), of(출력) 순서 뒤바뀌면 끝입니다. 그리고 원본보다 작은 대상 디스크에는 사실상 맞지 않습니다. 복제 후 남는 공간 확장은 gparted나 parted로 추가 작업이 필요하죠.

gparted는 GUI라서 파티션 확장이나 순서 확인에 좋습니다. 특히 복제 후 루트 파티션이 남는 공간을 못 쓰고 있을 때 시각적으로 확인하기 편하더라고요.

파일 단위 복사와 블록 단위 복제의 차이, 그리고 gparted로 파티션을 확장하는 보조 흐름을 비교한 이미지입니다.

6. ⚠️ 트러블슈팅: 제가 자주 겪었던 문제들

여기서는 이론보다 경험담이 더 중요합니다. 저도 처음엔 왜 안 되는지 몰라서 한참 헤맸던 구간들입니다.

문제 1. 부팅은 되는데 루트 파일시스템을 못 찾는 경우

• 원인: fstab UUID 불일치, initramfs 미갱신, 잘못된 루트 파라미터
• 해결: 라이브 USB로 들어가서 새 루트 마운트 후 blkid, /etc/fstab, update-initramfs 재확인

문제 2. GRUB 프롬프트만 뜨는 경우

• 원인: GRUB 설치 누락, EFI 엔트리 미등록, 잘못된 부팅 모드
• 해결: chroot로 들어가 grub-install과 grub-mkconfig 재실행, BIOS/UEFI 모드 일치 확인

문제 3. rsync 후 권한 문제로 서비스가 실패하는 경우

• 원인: ACL, xattr 누락 또는 SELinux 컨텍스트 이슈
• 해결: -A, -X 옵션 포함 여부 확인, 배포판 보안 정책도 점검

문제 4. 새 디스크로 부팅했는데 예전 디스크가 계속 잡히는 경우

• 원인: 부팅 순서 미변경, EFI 엔트리 우선순위 문제
• 해결: 펌웨어 설정에서 새 디스크를 우선 부팅 장치로 변경

중요 포인트는 문제를 한 번에 다 보려 하지 않는 겁니다. 저는 보통 디스크 인식 → 파티션 UUID → fstab → GRUB → 커널/initramfs 순서로 좁혀갑니다. 이렇게 보면 생각보다 금방 원인이 보입니다.

7. 검증: 리눅스 디스크 업그레이드 후 꼭 확인할 것

마이그레이션이 끝났다고 바로 안심하면 안 됩니다. 진짜 완료는 새 디스크 단독 부팅 확인까지 해야 합니다. 저는 아래 순서로 검증합니다.

1. 기존 디스크를 잠시 분리하거나 BIOS에서 비활성화합니다.
2. 새 디스크만으로 부팅되는지 확인합니다.
3. findmnt /, lsblk로 실제 루트가 새 디스크인지 확인합니다.
4. 서비스가 정상 기동되는지 봅니다. 웹서버, 데이터베이스, 컨테이너 런타임 순으로요.
5. 로그에 에러가 없는지 확인합니다.

findmnt /
lsblk -o NAME,SIZE,MOUNTPOINT,UUID
systemctl --failed
journalctl -p err -b

여기서 systemctl –failed 결과가 비어 있으면 꽤 안심이 됩니다. 저는 홈랩에서는 재부팅도 2~3번 해봅니다. 한 번 성공했다고 끝이 아니더라고요.

새 디스크에서 정상 부팅된 뒤 lsblk, findmnt, systemctl 결과를 확인하는 검증 장면을 표현한 이미지입니다.

8. 정리와 FAQ: 리눅스 파티션 마이그레이션에서 기억할 것

이번 작업의 핵심을 한 줄로 줄이면 이겁니다. 복사보다 검증이 더 중요합니다. 리눅스 파티션 마이그레이션은 명령어 몇 줄로 끝나는 것처럼 보여도, 실제로는 부팅 구조와 파일시스템 이해가 같이 따라와야 안전합니다. 그래도 한 번 제대로 해보면 다음부터는 훨씬 덜 무섭습니다. 저도 처음엔 긴장 많이 했는데, 몇 번 해보니까 체크리스트만 잘 지키면 생각보다 안정적으로 옮겨지더라고요.

혹시 지금 루트 디스크 이전이나 리눅스 디스크 업그레이드를 준비 중이시라면, 오늘 정리한 순서대로만 가셔도 큰 사고는 피할 가능성이 높습니다. 다음 글에서는 LVM 기반 마이그레이션이나 암호화 디스크 이전도 따로 다뤄보려고 합니다. 이전 글에서 백업 전략을 정리한 내용과도 같이 보면 더 도움이 될 겁니다.

자주 묻는 질문

• Q. 온라인 상태에서 옮겨도 되나요?
  가능은 하지만, 일관성 문제가 생길 수 있어서 가능하면 라이브 환경에서 작업하는 편이 안전합니다.
• Q. rsync와 dd 중 뭐가 더 안전한가요?
  무조건 한쪽이 안전하다고 보긴 어렵습니다. 구조 변경이 있으면 rsync, 동일 복제가 목표면 dd가 맞는 경우가 많습니다.
• Q. gparted만으로 끝낼 수 있나요?
  파티션 조정엔 좋지만, 루트 디스크 이전 전체를 완성하려면 부트로더와 fstab 확인이 필요합니다.
• Q. 데이터 손실 방지를 위해 가장 중요한 한 가지는?
  백업입니다. 이건 아무리 강조해도 부족하지 않습니다.

백업, UUID, fstab, GRUB, 단독 부팅 테스트까지 핵심 점검 항목을 한눈에 정리한 요약 이미지입니다.

🎉 여기까지 마무리하면 기본적인 리눅스 파티션 마이그레이션은 끝입니다. 드디어 됐다! 싶어도 마지막 재부팅 검증은 꼭 해보세요. 그 한 번이 진짜 차이를 만듭니다.