rm으로 삭제한 파일 복구 가능한가? (extundelete 실험기)

조회수: 0

리눅스에서 실수로 rm 명령을 한 번 잘못 치면 심장이 덜컥 내려앉는다. 특히 중요한 설정 파일이나 로그, 심지어 소스 코드 디렉터리를 통째로 날렸다면 “이거 복구 가능한가?”라는 생각이 가장 먼저 든다.
많은 문서에서 “rm으로 삭제하면 복구 불가능하다”라고들 이야기하지만, ext3/ext4 파일 시스템에서는 extundelete 같은 전용 도구로 어느 정도 복구를 시도해볼 수 있다. 완벽한 만능열쇠는 아니지만, 조건만 맞는다면 “완전 포맷” 수준의 절망적인 상황은 피할 수 있다.

이 글에서는 테스트용 환경을 만들고, rm 으로 파일을 삭제한 뒤 extundelete 로 실제 복구를 시도해본 과정을 단계별로 정리한다. 그리고 실무에서 어떤 경우에 복구 가능성이 높은지, 반대로 어떤 경우엔 깨끗이 포기해야 하는지도 함께 정리해본다.

rm이 하는 일: 파일을 “당장” 지우는 건 아니다

먼저 rm 이 내부적으로 어떤 일을 하는지 짚고 넘어가야 extundelete가 왜 필요한지 이해가 된다.

리눅스에서 파일은 크게 두 가지로 생각할 수 있다.

  • 디렉터리 엔트리(이름, 위치)
  • 실제 데이터 블록(디스크에 저장된 내용)

rm 명령은 보통 “파일 내용을 싹 지운다”라기보다는, 파일의 디렉터리 엔트리와 inode 참조를 해제해서 파일 시스템 입장에서 “이 파일은 더 이상 필요 없는 데이터”라고 표시하는 역할에 가깝다. ext 계열 파일 시스템에서는 이때 데이터 블록 자체는 당장 덮어쓰지 않고, 나중에 필요한 다른 파일이 들어올 때 재사용할 수 있는 “여유 공간” 정도로 인식한다.

바로 이 틈을 파고드는 도구가 extundelete다. 파일 시스템 메타데이터와 아직 덮어쓰이지 않은 데이터 블록을 분석해서, 지워진 파일을 다시 복원하는 방식으로 작동한다.

extundelete로 복구할 수 있는 전제 조건

extundelete에는 전제가 몇 가지 있다. 이 조건을 만족하지 않으면 시도 자체가 의미가 없는 경우도 있다.

  1. 파일 시스템 유형이 ext3 또는 ext4일 것
  2. 삭제 이후 디스크에 큰 쓰기 작업이 거의 없었을 것
  3. 해당 파티션을 read-only로 마운트하거나, 최소한 추가 쓰기를 최대한 막았을 것
  4. 루트 권한으로 작업할 수 있을 것

XFS, Btrfs처럼 다른 파일 시스템에서는 extundelete를 사용할 수 없다. 또 ext4에서도 저널 옵션이나 내부 구조에 따라 복구 성공률이 달라지는데, 이는 파일이 삭제된 시점 이후로 얼마나 많은 블록이 덮어쓰였는지에 크게 좌우된다.

실무에서는 삭제 사실을 인지하는 즉시 해당 파티션 쓰기를 중단하고, 가능하면 언마운트 후 복제본을 떠서 그 복제본에서 작업하는 것이 가장 이상적인 접근이다.

테스트 환경 구성: 일부러 파일을 날려보자

실험을 위해 로컬 가상머신에 다음과 같이 환경을 구성했다는 가정으로 설명해보자.

  • 테스트용 디스크 /dev/sdb
  • 여기에 ext4 파일 시스템 생성 후 /test 에 마운트
  • 그 안에 data/ 디렉터리를 만들고 여러 파일 생성

예시 명령은 대략 다음과 같다.

sudo mkfs.ext4 /dev/sdb
sudo mkdir -p /test
sudo mount /dev/sdb /test

cd /test
mkdir data
for i in {1..5}; do
  echo "테스트 파일 $i 입니다" > data/file$i.txt
done

ls data 를 해 보면 file1.txt 부터 file5.txt 까지 잘 생성된 것을 확인할 수 있다. 이제 정말 하기 싫지만, 실험을 위해 일부러 삭제를 해본다.

rm data/file3.txt
rm -rf data

실수로 디렉터리를 통째로 날린 상황을 연출한 셈이다.

파티션 언마운트와 readonly 마운트

이제부터는 최대한 해당 파일 시스템에 쓰기를 막아야 한다. 테스트이므로 과감하게 언마운트하고, extundelete가 작업할 수 있도록 디바이스를 그대로 두자.

cd /
sudo umount /test

운영 환경이라면 이 과정이 쉽지 않을 수 있다. 해당 파티션 위에 서비스가 올라가 있다면 중단이 필요하기 때문이다. extundelete 특성상 마운트된 상태에서도 어느 정도 조회는 가능하지만, 확실한 복구를 위해서는 언마운트 후 작업하는 편이 훨씬 안전하다.

extundelete 설치와 기본 사용법

이제 extundelete를 설치한다. 배포판에 따라 패키지 이름이 조금씩 다르다.

  • Debian/Ubuntu 계열 sudo apt-get install extundelete
  • RHEL/CentOS/Rocky 계열 sudo yum install extundelete

설치가 끝났다면, 어떤 파일을 복구할 수 있는지 먼저 확인해본다.

sudo extundelete /dev/sdb --inode 2

또는 삭제된 파일 목록을 한 번에 보고 싶다면 다음과 같이 사용할 수 있다.

sudo extundelete /dev/sdb --restore-all

이 명령을 실행하면 현재 디렉터리(보통 extundelete를 실행한 위치)에 RECOVERED_FILES 라는 디렉터리가 생기고, 그 안에 복구 가능한 파일들이 저장된다.

특정 경로만 복구하고 싶다면 다음과 같이 쓸 수 있다.

sudo extundelete /dev/sdb --restore-directory /data

혹은 특정 파일만 알고 있다면,

sudo extundelete /dev/sdb --restore-file data/file3.txt

처럼 지정할 수도 있다.

실험 결과: 무엇이 살고, 무엇이 죽는가

실제 테스트에서는 다음과 같은 패턴이 나타난다.

  1. 삭제 직후, 아무 작업도 하지 않고 바로 extundelete를 돌린 경우
    • 디렉터리 구조와 파일 이름이 상당 부분 그대로 복구되는 경우가 많다
    • 삭제된 지 얼마 지나지 않아 쓰기가 거의 없었다면 내용도 온전히 복구되는 편이다
  2. 삭제 후, 같은 파티션에 여러 차례 큰 파일을 생성하거나 패키지 설치 등으로 디스크를 많이 사용한 경우
    • 파일 이름은 복구되지만 내용이 깨져 있거나 0바이트로 되돌아오는 경우가 늘어난다
    • 일부 파일은 아예 리스트에도 나타나지 않거나, 손상된 상태로만 복원된다

이유는 간단하다. extundelete는 결국 “아직 덮어쓰이지 않은 블록”을 찾는 방식으로 동작하기 때문이다. 삭제 후 시간이 많이 흐르고, 해당 파티션에 계속 쓰기가 발생하면, 복구 가능한 여지는 급격히 줄어든다.

실무에서 쓸 때의 현실적인 한계

실무에서 rm -rf 로 중요한 디렉터리를 날렸다고 할 때, extundelete로 모든 걸 되살릴 수 있을까? 경험적으로는 다음 정도의 기대치를 갖는 편이 현실적이다.

  • 긴급 상황에서 “일부라도 건질 수 있는 마지막 수단”에 가깝다
  • 로그, 텍스트 파일처럼 구조가 단순한 파일은 복구됐는지 육안으로 확인하기가 비교적 쉽다
  • 데이터베이스 파일, VM 디스크 이미지처럼 구조가 복잡하거나 내부 일관성이 중요한 파일은, 설령 내용이 어느 정도 복구되어도 애플리케이션 수준에서 이미 손상된 경우가 많다
  • 실제 서비스에서는 extundelete 이전에, 스냅샷/백업 정책이 잘 잡혀 있는지가 훨씬 더 중요하다

특히 DB 서버에서 extundelete로 데이터 파일을 복구하는 것은 거의 “도박”에 가깝다. 애초에 DB는 자체 백업/복구 메커니즘을 제공하므로, 이를 따르는 쪽이 훨씬 안전하다.

extundelete 실험에서 얻은 교훈

테스트를 여러 번 반복해보면 몇 가지 분명한 교훈이 나온다.

  1. 삭제 사실을 깨닫는 즉시 쓰기를 멈출 것
    • 로그를 남기려고 여기저기 명령을 치는 것도 결국 쓰기를 유발한다
    • 가능하다면 해당 파티션을 바로 언마운트하고, 다른 디스크에 상황을 기록하는 편이 좋다
  2. extundelete는 “마지막 보루”일 뿐, 전략이 아니라 전술이다
    • 평소에 백업과 스냅샷을 잘 설계해두면 extundelete를 쓸 일 자체가 거의 없다
    • 중요 시스템일수록 복구 도구에 기대기보다 사전 예방에 집중하는 편이 맞다
  3. 테스트 환경에서 미리 연습해 두면 실제 상황에서 대응력이 크게 올라간다
    • 가상머신 하나 만들어서 일부러 파일을 지우고 복구해보면 명령과 동작 원리를 몸으로 익힐 수 있다
    • extundelete뿐 아니라 다른 파일 시스템(XFS의 xfs_undelete류 도구 등)에 대해서도 한 번쯤 실험해보는 것이 좋다

백업 전략과 안전한 삭제 습관

rm 복구 실험을 해보면 자연스럽게 “애초에 이런 일을 만들지 않는 게 최선”이라는 결론에 도달하게 된다. 일상적인 리스크를 줄이는 방법은 크게 두 가지다.

  1. 백업과 스냅샷
    • 정기적인 전체 백업
    • 중요한 서비스 디렉터리에 대한 파일 단위 백업 또는 스냅샷
    • 클라우드 환경이라면 블록 스토리지 스냅샷을 활용
  2. 안전한 삭제 습관
    • rm 대신 rm -i 또는 alias rm='rm -i' 설정으로 한 번 더 확인
    • 실무에서는 바로 삭제 대신 “휴지통 디렉터리”로 옮기는 스크립트를 만들어 두는 것도 방법
    • rm -rf 를 칠 때는 경로를 다시 한 번 소리 내서 읽어보는 습관

이런 습관만 자리 잡아도 extundelete를 직접 써야 할 일은 상당 부분 줄어든다.

정리: rm으로 삭제한 파일, 완전한 복구를 기대하기보다는

결론을 정리하면 다음과 같다.

  • ext3/ext4 파일 시스템에서 rm 으로 삭제한 파일은, 조건이 맞을 때 extundelete 를 통해 어느 정도 복구가 가능하다.
  • 다만 삭제 이후 디스크 쓰기가 많았거나, 데이터 특성상 약간의 손상도 감당할 수 없는 경우라면 실질적인 복구 성공률은 떨어진다.
  • 운영 환경에서는 extundelete를 “혹시나 하는 마음에 시도해보는 응급 처치” 정도로 바라보는 편이 좋다.
  • 진짜 중요한 것은 평소의 백업/스냅샷 전략과, 실수 자체를 줄이는 작업 습관이다.

실험을 직접 해보면, 생각보다 많은 경우에 일부 파일이 살아 돌아오기도 하지만, 동시에 “언제든 실패할 수 있다”는 사실도 함께 체감하게 된다. 결국 rm 복구의 세계에서 가장 강력한 도구는 extundelete가 아니라, 미리 준비해 둔 백업이라는 점을 잊지 않는 게 좋다.

정보 추천글 더보기