rm -rf로 삭제된 파일 복구 방법

첫 60초 동안 해야 할 일

rm -rf로 삭제된 파일을 복구할 수 있을지는 두 가지 요소에 의해 결정되며, 이 두 가지 모두 검색 엔진을 열기 전에 수행해야 합니다. 해당 파일시스템에 대한 쓰기 작업을 즉시 중단하십시오. 그 후 언마운트하거나 읽기 전용으로 다시 마운트하여 사용을 중단하십시오.

rm은 아무것도 삭제하지 않습니다. 디렉터리 항목을 제거하고 inode와 파일의 데이터 블록을 사용 가능 상태로 표시할 뿐입니다. 바이트는 여전히 장치에 남아 있습니다. 블록 할당자가 해당 블록을 다른 프로세스에 할당하고 그 프로세스가 데이터를 덮어쓰기 전까지는 데이터가 유지됩니다. 파일시스템이 마운트된 상태로 계속 사용되면 데몬이 로그를 기록하거나 데이터베이스가 페이지를 플러시할 때마다 복구하려는 블록에 데이터가 덮어씌워질 수 있습니다.

따라서 가장 먼저 실행해야 할 명령어는 파일 복구 명령어가 아니라 쓰기를 중단시키는 명령어입니다.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

umount이 umount: /mnt/data: target is busy.를 반환한다면, 무엇이 해당 파일시스템을 점유하고 있는지 확인하십시오.

sudo fuser -vm /mnt/data
sudo lsof +D /mnt/data

파일시스템을 해제할 수 없다면 대신 읽기 전용으로 다시 마운트하십시오. 읽기 전용 마운트는 새로운 할당을 방지하며, 이는 필요한 조치의 대부분을 충족합니다.

sudo mount -o remount,ro /mnt/data

삭제된 경로가 루트 파일시스템에 있다면 상황은 더 복잡해집니다. 실행 중인 프로세스가 파일을 쓰기 모드로 열고 있고 커널이 이를 강제로 닫지 않기 때문에 sudo mount -o remount,ro /은 보통 mount: /: cannot remount /dev/vda1 read-only. 오류와 함께 실패합니다. VPS 환경에서의 현실적인 해결책은 제공업체의 구조(rescue) 또는 복구(recovery) 모드를 사용하는 것입니다. 이 모드는 디스크를 마운트하지 않은 상태로 별도의 라이브 시스템을 부팅합니다. 아래의 모든 명령어는 아무도 쓰기 작업을 하지 않는 장치를 대상으로 실행해야 합니다.

이 가이드 전체에 적용되는 하나의 규칙이 있습니다. 복구된 파일, 디스크 이미지, 새로 설치한 도구를 복구 대상 파일시스템에 절대 저장하지 마십시오. 두 번째 볼륨을 연결하거나 SSH를 통해 다른 장비로 출력 결과를 전송하십시오.

ext4에서 rm -rf 복구가 거의 불가능한 이유

무언가를 설치하기 전에 기대치를 조정하십시오. 현재 사용 중인 파일 시스템을 먼저 확인하십시오.

lsblk -f

거의 모든 VPS 이미지의 기본값인 ext4에서 파일의 데이터 위치는 inode 내에 익스텐트 트리(extent tree) 형태로 저장됩니다. 익스텐트는 파일의 논리적 블록 N이 물리적 블록 M에서 시작하여 L개의 블록만큼 이어진다는 기록입니다. 작은 파일은 이러한 기록을 최대 4개까지 inode 내부에 보관합니다. 더 큰 파일은 트리의 나머지 부분을 담고 있는 추가 블록을 가리킵니다.

파일에 대한 마지막 링크가 사라지면, ext4는 해당 트리를 따라가며 모든 익스텐트를 블록 할당자에게 반환하고 inode에서 트리를 삭제합니다. 이후 inode는 비어 있는 것으로 표시되며 삭제 시간이 기록됩니다. 데이터 자체는 그대로 남아 있지만, 데이터가 어디에 있었는지에 대한 유일한 기록은 지워진 상태입니다.

이는 삭제된 inode에 ext3grep와 같은 도구가 추적할 수 있는 정보를 충분히 남겨두었던 ext3와 다른 점입니다. ext4에서도 삭제된 inode를 나열할 수는 있습니다.

sudo debugfs -R lsdel /dev/vdb1

debugfs은 -w 플래그를 전달하지 않는 한 장치를 읽기 전용으로 엽니다. 따라서 마운트 해제된 장치에서 실행하는 것은 안전하며 시도하는 데 비용이 들지 않습니다. inode 목록은 출력되겠지만, 해당 inode가 사용하던 블록 맵이 이미 지워졌기 때문에 dump이 추적할 수 있는 정보가 없어 덤프를 뜨는 단계에서 막히게 됩니다.

두 가지 도구가 저널을 읽어 이 문제를 우회하려고 시도합니다. 저널은 ext4가 시스템 충돌 시 메타데이터의 일관성을 유지하기 위해 사용하는 고정 크기의 링 버퍼이며, 삭제 전의 inode 사본이 남아 있을 수 있습니다. extundelete와 ext4magic은 모두 이 저널을 검색합니다. 작업 중인 저널의 크기를 확인하십시오.

sudo dumpe2fs -h /dev/vdb1 | grep -i journal

저널은 메타데이터만 보관하며 크기가 작기 때문에 일반적인 쓰기 작업이 발생하면 금방 덮어씌워집니다. 운영 중인 서버에서 삭제 전의 inode가 남아 있는 시간은 수 분 단위에 불과합니다. 두 도구 모두 활발히 유지보수되지 않으며 모든 배포판에 패키지로 포함되어 있지도 않습니다. 두 도구 모두 성공 확률이 매우 낮다고 간주하고, 마운트 해제된 장치나 디스크 이미지를 대상으로 실행하십시오. 아무런 결과가 나오지 않더라도 놀라지 마십시오.

만약 lsblk -f이 xfs를 보고한다면 상황은 더 나아지지 않습니다. XFS 역시 지원되는 복구 도구가 없기 때문입니다. 아래의 선택지 순서는 바뀌지 않습니다.

실행 중인 프로세스가 파일을 여전히 열고 있습니까?

이 방법은 이 페이지에서 성공 확률이 높은 유일한 복구 수단이며, 파일을 사용 중이던 서비스를 재시작하지 말아야 하는 이유이기도 합니다.

파일은 두 가지 카운트가 모두 0에 도달해야 완전히 삭제된 것으로 간주합니다. 하나는 해당 inode를 가리키는 디렉터리 엔트리의 수이고, 다른 하나는 열려 있는 파일 디스크립터의 수입니다. rm은 첫 번째 카운트를 0으로 만듭니다. 프로세스가 여전히 파일을 열고 있다면 두 번째 카운트는 0이 아니므로, inode와 해당 블록은 여전히 할당된 상태이며 데이터도 읽을 수 있습니다.

링크 카운트가 0으로 떨어진 열린 파일을 찾으십시오:

sudo lsof +L1

+L1는 링크 카운트가 1 미만인 열린 파일 목록을 출력합니다. 각 결과에는 프로세스, 파일 디스크립터 번호, 0의 NLINK, 그리고 (deleted)로 끝나는 경로가 표시됩니다. PID와 디스크립터 번호를 사용하여 /proc로 이동하십시오:

sudo ls -l /proc/1234/fd

엔트리는 3 -> /var/log/app/events.log (deleted)와 같은 형태입니다. 해당 링크는 여전히 데이터에 접근할 수 있습니다. 이를 다른 파일 시스템으로 복사하십시오:

sudo cp /proc/1234/fd/3 /mnt/rescue/events.log

mv이 아닌 cp을 사용하십시오. /proc/1234/fd/3를 열면 오프셋 0부터 시작하는 동일한 inode에 대한 새로운 핸들을 얻게 되므로, 작성자의 현재 위치 이후 부분만 가져오는 것이 아니라 파일 전체를 얻을 수 있습니다.

알아두어야 할 두 가지 제한 사항이 있습니다. 삭제된 디렉터리 트리는 이 방법으로 복구할 수 없습니다. 프로세스가 열어둔 개별 파일만 유지되기 때문입니다. 또한 데이터베이스 엔진이 쓰기 작업 중일 때 복사한 데이터베이스 파일은 크래시 일관성(crash-consistent) 상태이므로, 이를 깨끗한 파일로 취급하지 말고 엔진 자체의 복구 기능을 실행할 계획을 세워야 합니다. lsof 출력에서 디스크립터 번호 대신 mem가 표시되는 엔트리는 메모리 매핑된 파일이며, 이러한 파일은 복사할 /proc/<pid>/fd 엔트리가 없습니다.

btrfs, ZFS 또는 LVM 스냅샷이 있습니까?

파일 시스템이 스냅샷을 지원한다면, 삭제된 파일은 이미 스냅샷 내부에 그대로 남아 있습니다. 이는 삭제 이전에 스냅샷이 존재했을 때만 유효합니다. 지금 생성하는 스냅샷은 과거의 데이터를 복구할 수 없습니다.

btrfs는 스냅샷을 서브볼륨(subvolume)으로 유지합니다:

sudo btrfs subvolume list /

스냅샷을 탐색하고 필요한 경로를 cp -a 명령으로 복사하십시오. 전체 서브볼륨을 롤백하는 것보다 개별 경로를 복사하는 방식을 권장합니다. 롤백을 수행하면 스냅샷 생성 이후에 기록된 모든 데이터가 삭제되기 때문입니다.

ZFS는 모든 스냅샷을 읽기 전용 디렉터리로 노출합니다:

zfs list -t snapshot
ls /tank/data/.zfs/snapshot/

.zfs 디렉터리는 숨겨져 있어 데이터셋 루트에서 ls 명령을 실행해도 나타나지 않지만, 이름을 직접 입력하여 진입할 수 있습니다. 해당 위치에서 파일을 복사하십시오. zfs rollback 명령은 전체 데이터셋을 과거 시점으로 되돌리고 지정한 스냅샷보다 최신인 모든 스냅샷을 파괴하므로, 최후의 수단으로만 사용하십시오.

LVM 스냅샷은 고정 크기를 가진 copy-on-write 볼륨입니다:

sudo lvs
sudo mount -o ro /dev/vg0/data-snap /mnt/snap

읽기 전용으로 마운트한 뒤 파일을 복사하십시오. 신뢰하기 전에 lvs 명령으로 상태를 확인해야 합니다. LVM 스냅샷에 할당된 공간이 가득 차면 커널에 의해 무효화되며, 일단 무효화된 스냅샷의 내용은 복구할 수 없습니다.

스냅샷은 백업이 아닙니다. 스냅샷은 원본과 동일한 디스크나 풀에 존재하므로 원본이 겪는 모든 장애를 공유합니다. 스냅샷은 2분 전의 실수를 되돌리는 데 매우 유용하며, 지금 상황에 정확히 부합하는 해결책입니다.

PhotoRec을 이용한 카빙, 라이브 디스크가 아닌 이미지 파일 대상 작업

위의 방법들이 모두 적용되지 않는다면 남은 방법은 카빙입니다. 카빙은 원시 장치(raw device)를 스캔하여 알려진 파일 형식의 시작을 알리는 바이트 패턴을 찾은 뒤, 그 뒤에 오는 데이터를 모두 추출하는 방식입니다. 카빙은 파일 데이터만 읽어 들입니다. 파일 이름, 디렉터리 구조, 타임스탬프, 소유권 정보는 모두 파일 시스템 메타데이터이며, rm에 의해 파괴된 정보이므로 복구할 수 없습니다. 결과물은 번호가 매겨진 출력 디렉터리에 f0384512.jpg라는 이름으로 저장되며, 이를 직접 확인하며 분류해야 합니다.

이 작업의 성공 여부를 결정하는 두 가지 규칙이 있습니다.

첫째, 다른 도구를 사용하기 전에 반드시 장치의 이미지를 생성하십시오. Debian 및 Ubuntu에서는 gddrescue 패키지를 설치하며, 설치되는 바이너리는 ddrescue입니다.

sudo apt update && sudo apt install -y gddrescue testdisk
sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map

/mnt/rescue는 파티션 용량만큼의 여유 공간이 있는 다른 장치에 저장해야 합니다. lsblk -b은 정확한 크기를 바이트 단위로 출력합니다. 맵 파일을 사용하면 복사 작업이 중단되었을 때 처음부터 다시 시작하지 않고 이어서 진행할 수 있습니다. 이미지를 확보해 두면 첫 번째 도구가 디스크에 덮어쓰기를 수행하더라도, 나중에 동일한 바이트 데이터를 대상으로 다른 도구를 시도해 볼 수 있습니다.

둘째, 복구 도구를 이미지 파일로 지정하십시오.

sudo photorec /d /mnt/rescue/recup /mnt/rescue/vdb1.img

photorec은 텍스트 메뉴를 엽니다. 파티션, 파일 시스템 유형, 검색할 파일 서명, 대상 디렉터리를 차례로 선택하십시오. 기본 설정은 모든 파일을 찾으므로 수만 개의 조각을 일일이 확인해야 합니다. 작업을 시작하기 전에 실제로 손실된 파일 형식으로 서명 목록을 좁히는 것이 좋습니다.

같은 패키지에 포함된 testdisk은 자체적인 삭제 취소 기능을 갖추고 있으나, FAT, exFAT, NTFS, ext2만 지원합니다. ext4의 경우 photorec를 사용해야 합니다.

조각난 파일은 손상된 상태로 복구될 가능성이 높습니다. 카빙은 파일의 블록이 연속적이라고 가정하므로, 할당자가 디스크 전체에 분산시킨 파일은 잘못 재조합되거나 아예 누락될 수 있습니다. 미디어 파일은 강력한 헤더를 가지고 있어 비교적 잘 복구됩니다. 반면 일반 텍스트, 설정 파일, 소스 코드는 셸 스크립트의 시작을 알리는 바이트 서명이 없기 때문에 복구가 어렵습니다.

잘못된 공백: 경로가 삭제된 이유

거의 모든 rm -rf 사고는 셸 문제에서 비롯됩니다. rm은 경로 목록을 전달받아 순서대로 삭제합니다. 사용자의 의도는 고려하지 않습니다.

가장 흔한 실수는 공백 하나 때문입니다.

rm -rf /home/deploy/app /old
rm -rf /home/deploy/app/old

첫 번째 줄은 두 개의 인자로 인식됩니다. 먼저 애플리케이션을 삭제하고, 이어서 /old를 삭제합니다. 만약 /old이 존재하지 않는다면 rm는 아무것도 출력하지 않습니다. -f가 파일 누락 오류를 억제하기 때문입니다. 침묵이 곧 성공을 의미하지는 않습니다.

두 번째 형태는 공백을 포함한 변수에 따옴표를 씌우지 않은 경우입니다.

dir="/srv/my app"
rm -rf $dir

셸은 공백을 기준으로 값을 분리하므로, rm은 /srv/my과 app을 각각 별개의 경로로 전달받습니다. rm -rf "$dir"와 같이 작성해야 하나의 경로로 인식됩니다.

세 번째는 변수가 비어 있는 경우입니다. 보통 변수를 채워야 할 명령이 실패했을 때 발생합니다.

rm -rf "$TARGET"/*

TARGET이 설정되지 않으면 해당 부분은 rm -rf /*로 확장됩니다. GNU rm는 인자가 없는 형태를 거부합니다. rm -rf /은 rm: it is dangerous to operate recursively on '/'를 출력하고 중단됩니다. 하지만 glob 형태는 이러한 보호를 받지 못합니다. rm이 실행되기 전에 셸이 /*를 실제 최상위 경로 목록으로 대체하기 때문입니다. 이때 /은 목록에 포함되지 않으므로 보호 장치가 작동하지 않습니다.

다음 사고를 방지하는 습관

• 경로로 사용하는 모든 변수는 따옴표로 감쌉니다. 테스트와 루프 내부를 포함하여 매번 "$dir"을 사용하십시오.
• 값이 비어 있으면 작업을 중단합니다. TARGET이 설정되지 않았거나 비어 있을 때 rm이 시작되기 전 rm -rf "${TARGET:?TARGET is not set}"/*를 사용하여 셸을 중단하고 메시지를 출력하십시오. 삭제 작업을 수행하는 모든 스크립트 상단에는 set -euo pipefail를 추가하십시오.
• --one-file-system을 추가하십시오. 이는 rm가 인자로 전달된 경로와 다른 파일 시스템에 위치한 디렉터리를 건너뛰도록 지시하므로, 재귀적 삭제 작업이 마운트된 백업 볼륨이나 바인드 마운트 경로로 진입하는 것을 방지합니다.
• root 권한으로 삭제하지 마십시오. 서비스 계정은 자신이 소유한 파일만 삭제할 수 있으며, 이는 각 서비스를 별도의 비권한 사용자로 실행하는 것의 핵심 근거입니다. 특정 계정이 어디까지 접근할 수 있는지 확실하지 않다면 ls 목록의 권한 비트를 읽는 것만으로 한 번의 명령에 답을 얻을 수 있습니다.
• 작업을 수행하기 전에 목록을 먼저 출력하십시오. 스크립트에서는 경로를 구성하고 printf '%s\n'로 출력한 뒤, 내용을 확인하고 나서 두 번째 단계에서 삭제를 진행하십시오.
• 휴지통 명령어를 가까이 두십시오. sudo apt install trash-cli은 trash-put, trash-list, trash-restore, trash-empty 기능을 제공합니다. 삭제된 파일은 ~/.local/share/Trash로 이동하며, trash-empty 30는 30일이 지난 파일을 정리합니다.

rm을 trash-put로 별칭(alias) 지정하는 것이 당연한 다음 단계처럼 보이지만, 이는 함정입니다. 별칭은 해당 설정이 없는 다른 서버에서 실패하는 반사적인 습관을 만들며, 치명적인 실수가 발생하는 스크립트 내부에서는 별칭이 적용되지 않습니다. 대신 의도적으로 trash-put를 직접 입력하십시오.

항상 성공하는 유일한 복구 방법

위의 모든 내용은 가능성에 불과합니다. 백업은 가능성이 아닙니다.

백업을 실질적인 것으로 만드는 요소는 두 가지입니다. 사용자가 기억하지 않아도 일정에 따라 자동으로 실행되어야 하며, 최소 한 번 이상 복구를 수행해 보아야 합니다. 한 번도 복구해 본 적 없는 저장소는 그저 믿음일 뿐입니다. 백업을 무용지물로 만드는 요소(포함 목록의 잘못된 경로, 아무도 기록해 두지 않은 저장소 암호 등)는 정작 필요할 때가 되어서야 드러나기 때문입니다.

restic을 사용하면 복구는 두 개의 명령어로 완료됩니다.

restic -r /srv/restic-repo snapshots
restic -r /srv/restic-repo restore latest --target /mnt/rescue --include /srv/appdata

실제 경로를 덮어쓰지 말고 빈 디렉터리에 복구하십시오. 그래야 데이터가 이동하기 전에 두 경로를 비교할 수 있습니다. VPS에서 restic 백업 설정하기에서는 저장소 설정과 이를 실행하는 systemd 타이머를 다룹니다.

Borg를 사용하는 경우:

borg list /srv/borg-repo
borg extract /srv/borg-repo::daily-2026-08-08 srv/appdata

Borg 아카이브 내부의 경로는 선행 슬래시 없이 저장되므로 srv/appdata은 일치하지만 /srv/appdata은 아무것도 일치하지 않습니다. borg extract은 현재 작업 디렉터리에 쓰기를 수행하므로, 먼저 cd를 사용하여 임시 디렉터리로 복구하십시오.

아직 도구를 선택하지 않았다면 restic과 Borg 비교를 참고하십시오. 중복 제거와 추가 전용(append-only) 저장소에 대해 다루고 있으며, 이는 서버가 침해당했을 때 백업 기록이 삭제되는 것을 방지하는 속성입니다. 어떤 도구를 선택해도 좋습니다. 가장 나쁜 선택은 아무것도 실행하지 않는 것입니다.

새 서버를 설정할 때가 가장 비용이 적게 드는 시점입니다. 잃어버릴 만한 데이터가 생기기 전에 설정하십시오. 새 VPS에서의 첫 10분에서 SSH 및 방화벽 설정과 함께 이 작업을 수행해야 합니다.

그다음 달력에 반복 일정을 등록하십시오. 매달 저장소에서 한 디렉터리를 /tmp으로 복구하고 파일을 확인하십시오. 그 작은 습관 하나가 이 페이지에 나열된 모든 도구보다 더 가치가 있습니다.

FAQ

ext4에서 삭제된 파일을 복구할 수 있습니까?

일반적으로는 불가능합니다. 파일에 대한 마지막 링크가 사라지면 ext4는 inode에서 익스텐트 트리를 지워버리므로, 디스크 어디에도 데이터 위치를 기록한 정보가 남지 않습니다. extundelete과 ext4magic는 ext4 저널에서 해당 inode의 이전 복사본을 검색하지만, 이는 삭제가 발생한 지 몇 분 지나지 않았고 그동안 파일 시스템에 아무런 쓰기 작업이 없었을 때만 유효합니다. 두 프로젝트 모두 현재 활발히 유지보수되지 않습니다. 해당 도구들은 반드시 마운트 해제된 장치나 디스크 이미지에 대해서만 실행해야 하며, 마운트된 파일 시스템에 직접 실행해서는 안 됩니다. 작업 전 sudo dumpe2fs -h /dev/vdb1 | grep -i journal을 사용하여 대상 장치를 먼저 확인하십시오.

서비스가 삭제된 파일을 여전히 열고 있습니다. 복구할 수 있습니까?

네, 이 경우가 가장 좋은 상황입니다. 프로세스가 파일을 열고 있는 동안에는 inode와 데이터 블록이 할당된 상태로 유지되므로 데이터를 읽을 수 있습니다. 서비스를 재시작하지 마십시오. 마지막 파일 디스크립터가 닫히는 순간 삭제가 완료되기 때문입니다. sudo lsof +L1를 실행하여 링크 카운트가 0인 열린 파일 목록을 확인하고, PID와 파일 디스크립터 번호를 기록한 뒤 sudo cp /proc/1234/fd/3 /mnt/rescue/events.log을 사용하여 /proc를 통해 복사하십시오. 복사본은 반드시 다른 파일 시스템에 저장해야 합니다. 디스크립터 번호 대신 mem로 표시되는 항목은 메모리에 매핑된 상태이므로 복사할 수 있는 /proc/<pid>/fd 경로가 존재하지 않습니다.

왜 복구 도구를 직접 실행하지 않고 디스크를 이미지로 만들어야 합니까?

모든 도구는 결과를 어딘가에 기록해야 하는데, 복구 중인 파일 시스템에 쓰기 작업이 발생하면 아직 데이터가 남아 있는 빈 블록을 덮어쓸 수 있기 때문입니다. 먼저 sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map를 사용하여 파티션을 다른 장치로 복사한 다음, photorec을 해당 이미지 파일에 지정하십시오. 이미지를 사용하면 나중에 다른 도구를 사용하여 동일한 바이트를 대상으로 다시 시도할 수 있습니다. 원본 디스크에 직접 쓰기가 발생하면 이러한 재시도는 불가능합니다.

rm -rf / 명령은 여전히 Linux 시스템을 파괴합니까?

단순히 해당 명령만 입력해서는 파괴되지 않습니다. GNU rm은 이를 거부하고 rm: it is dangerous to operate recursively on '/'를 출력합니다. 위험한 형태는 다른 경로를 통해 전달되는 경우입니다. TARGET가 설정되지 않은 상태에서 rm -rf "$TARGET"/*을 실행하면 rm -rf /*로 확장됩니다. 셸은 rm에 실제 최상위 디렉터리 목록을 전달하는데, 이 목록에는 /이 포함되어 있지 않으므로 보호 기능이 작동하지 않습니다. 대신 "${TARGET:?TARGET is not set}"을 작성하면 rm가 실행되기 전에 셸이 작업을 중단합니다.

파일 시스템 스냅샷이 백업입니까?

아닙니다. btrfs나 ZFS 스냅샷은 보호 대상 데이터와 동일한 풀에 저장되므로, 디스크 장애나 풀 손상이 발생하면 데이터와 스냅샷이 모두 사라집니다. LVM 스냅샷은 고정된 크기라는 추가적인 문제가 있습니다. 스냅샷이 가득 차면 커널이 이를 무효화하며 내부 데이터도 모두 사라집니다. 스냅샷은 2분 전의 삭제 실수를 되돌리는 데는 매우 유용합니다. 그 외의 모든 경우에는 별도의 하드웨어에 저장소를 유지하십시오.