들어가며

내가 재직중이던 회사는 aws를 사용하기 이전에 linux ubuntu 서버를 직접 구축해서 사용하고 있었다.

그러던 중 어느날 동료 개발자 중 한명이 당시 웹 서비스 파일을 만지다가 실수로 mv 명령어로 백업용 파일을 서비스 파일에 덮어씌운 적이 있었다(!)

동료는 해당 파일을 새로 만들지 않고 시스템 단에서 복구하고자 노력했었다. 하지만 아쉽게도 계속 동작하고 있는 서버에서 그 파일을 복구시키는 건 불가능에 가까웠다.
(생각해보면 애초에 그런 작업이 가능하게끔 되어있는 시스템 자체가 잘못됐다고 생각한다...)

다행히 크게 중요한 파일은 아니었고 당시 기준 30분 정도면 다시 만들 수 있는 수준이었어서, 복구를 진행하지 말고 다른 업무를 진행하게 말씀드린 후 다시 만들었던 기억이 난다.

아직도 동료는 그 때 일이 가끔 생각나는지 얘기를 하곤 한다.

오늘은 오랜만에 그때의 기억을 회상하며 만약 그런 상황이라면 어떻게 할 수 있을지 이론적으로 알아보고자 한다.

---

시작하기 전에

❗❗❗❗ 가장 좋은 방법은 backup service를 사용하는 것입니다. 해당 방법은 실제 환경에서 도움이 되지 못할 확률이 매우 높다는 것을 알아주세요. ❗❗❗

이 게시글의 취지는 linux 단에서 어떻게 파일을 관리하여, 이를 이용해 복구가 될지 이론적으로 알아보고자 한다.

따라서 실제 동작하는 Server에서는 해당 방법이 어려울 확률이 굉장히 높으니(사실상 안됨), 그냥 이런 일이 발생하지 않도록 시스템을 잘 갖추고 백업 서비스를 사용하는게 정신건강에 좋다.
(안된다고 내 탓 하지 마셈)

---

파일의 저장, 삭제

파일을 저장한다?

방법을 알아보기 전에 파일을 저장 한다는 행위가 뭔지 알아보자.
깊게 들어가면(file system, inode 등) 한도끝도 없기 때문에 간단하게 설명해보고자 한다.

우리의 파일은 저장공간 (예:Hard Disk)에 저장되어 우리가 필요할 때 사용하게 된다.
쉽게말해 저장이란 Hard Disk에 우리의 파일을 써놓는다고 생각하면 된다.

Hard Disk 상의 어떤 위치에 우리의 파일을 써놓고, 주소값(저장된 위치)을 기억해 둔다음 필요할 때 거기서 가져와서 사용하는 것이다.

---

그럼 삭제는 뭐지?

아~ 저장이 써 놓는 거면 삭제는 지우는 거겠죠~ ㅋ 😋

아니다.

Hard Disk에게 지운다는 의미는 뭘까?
애초에 여기서 지워졌다는 행위는 뭘까?

만약 bit 상으로 0인 것이 지워졌다는 것으로 생각해보자.
그럼 운영체제에서 10GB의 용량을 가진 파일을 지우면 10GB의 0bit짜리 파일을 새로 쓰는 행위와 같지 않는가?

물론 이게 확실히 지워지는 건 맞지만, 그럼 모든 행위에 있어서 쓰는 행위가 너무 많아져 성능이 저하될 것이다.

때문에 대부분 실제로 지우지는 않고, 파일의 주소값만 삭제하거나 하는식으로 동작한다.
(비슷한 예로 Database의 Soft Delete와 Hard Delete를 생각해볼 수 있다)

---

어라?

엥? 그럼 실제로 파일이 삭제된 게 아니고 어딘가에 존재하긴 하는거네요? 운영체제는 그걸 모르는 것 뿐이구요 🙄

맞다.
그래서 뭔가 중요한 정보를 없앨 때 하드디스크를 전자레인지에 돌려서 아예 물리적으로 부셔지워버리는 것이다.

그렇지 않으면 Digital Forensic을 통해 로 저장되어 있는 데이터들을 꺼내볼 '수도' 있다.

엥? 그럼 우리도 저장공간을 확인하면 우리의 파일을 되찾을 수도 있겠네요?

오늘 알아볼 것이 바로 그거다. 한번 알아보자!

---

실습시간

현재 작성된 게시글은 Ubuntu 18.04.3, EXT4 FileSystem 환경을 기준해서 작성했습니다.

사전구성

처음에 말했던 예시 상황을 한번 재현해보고자 한다.
original.html 파일과 backup.html파일을 생성해보자.

original.html

backup.html

그리고 mv명령어로 original.html 파일을 backup.html 파일로 덮어씌우자.

mv backup.html original.html

보다시피 original.html파일이 backup.html파일로 덮어씌어진 모습이다.

---

복구시작

디스크 확인

Ubuntu에서 Disk는 대부분 /dev아래에 sda1~ 또는 vda1~등과 같은 네이밍으로 되어있다.
현재 시스템의 Disk는 무엇일지 fdisk로 찾아보자.

현재 시스템은 /dev/vda~의 네이밍을 사용하고있다.
여기서 /dev/vda4를 확인해보겠다.

---

복구 명령어 실행

자 한번 떠올려보자.
우리가 원래 작성했던 파일엔 뭐가 있었을까?

himprover, hello I'm original이라는 문구가 있었던 것 같다.

여기서 grep 명령어로 해당 문구가 /dev/vda4 내부에 남아있는지 찾아보자.

grep -i -a -B150 -A150 'himprover' /dev/vda4 > new.html

명령어가 복잡해 보이는데 간단하게 정리하자면

/dev/vda4 파일에서 himprover문자열을 대소문자 구분없이 찾아서, 앞150 뒤150를 같이 new.html 파일에 저장해라.

라는 의미를 가진다.

한번 결과물을 확인해보자.

?????????????

당황하지 말고, vim의 검색 기능으로 himprover 글자를 찾아보자.
결국 여기 내용이 있다는 건, himprover라는 문자열을 찾았다는 의미이기 때문이다.

!!!!!!!!!!!!!!!!!!!!!!!!!

지워진 줄만 알았던 원본 파일이 정말로 아직 /dev/vda4에 존재했다!
분명 ls 나 ls -a명령어로는 확인이 안되지만, 저장공간 내에는 아직 우리의 파일이 남아있었다.

만약 우리의 파일이 더 컸다면 -A150, -B150 옵션을 적절히 조절해서 전체 파일을 알아낼 수 있을 것이다.

---

근데 왜?

아니 이렇게 쉽고 간편한데 왜 복구가 안된다고 하세요? 🤨🤔

그건 몇 가지 이유가 존재한다.

---

1. 격리된 환경

아까 저장을 하는 과정을 떠올려보자.

우리는 저장공간 내에 어떠한 위치에 파일을 쓰고, 그 주소값을 기억해 사용한다.
이때 어떠한 위치 는 실제로 사용되고 있지 않은 (삭제된 경우 포함) 위치 일 것이다.

그럼 만약 다른 파일이 생성, 수정 된다면, 우리가 삭제한 파일(데이터)이 덮어씌어질 수도 있는 것이다.

우리가 조금 전 진행한 실습 환경은 굉장히 정적이고 격리된 환경이었다.
어떤 새로운 파일이 크게 생기지도 않고, 변경 또한 적다는 말이다.

하지만 실제 서버는 그렇지 않다.
많은 작업들이 실시간으로 진행되고 있기 때문에 삭제처리된 파일이 덮어씌어지는 것은 시간문제이다.

그래서 실제 동작중인 서버에서 삭제처리한 파일을 다시 찾기 어려운 것이다.

때문에 실제로 이런 내용을 검색해보면 당장 컴퓨터부터 끄고 하드디스크부터 빼라고 한다. (ㅋㅋㅋ)

---

2. 매우 오래 걸리는 시간

실습으로 진행해본 파일은 굉장히 크기가 작은 파일이다. 하지만 실제 파일은 이렇게 작지 않다. -A1000000 -B1000000 을 해도 모자를 수 있다.

또한, 파일 딱 한개만 사라지는 경우도 있겠지만 디렉토리 전체가 날아가는 경우도 존재한다.
그럼 모든 파일에 각각의 복구를 해주어야 한다는 말이다.

---

그외 ETC

이 외에도 디스크의 크기, 어떤 데이터를grep할 지 등 수 많은 이유로 이는 거의 불가능하다. 그러니 평소에 백업 잘하고 이런 일이 발생하지 않도록 사전에 시스템을 구성해두어야 한다.

---

정리

이번에는 mv로 파일이 덮어씌어졌을 때 어떻게 하면 파일을 복구할 수 있을지 알아보았다.

반복적으로 말하고 있듯이, 이 게시글은 mv 혹은 rm으로 삭제한 데이터를 복구하는 방법을 담은 게시글이 아니다.

파일이 대략 어떤식으로 저장되어 어떻게 복구 할 수 있을지 이론적으로 알아보는 게시글이다.

그러니 꼭!!! 백업은 필수고, 휴먼에러가 최대한 발생하지 않도록 시스템적으로 대비해두자.

• rm이나 mv로 파일을 잘못삭제하면 저장공간 내에 남아있을'수'도 있다.
• 그런 경우 grep 명령어 등을 사용해 해당 저장공간에서 원본 데이터를 찾을 '수'도 있다.
• 그냥 serverless 쓰자.

+ 읽어주셔서 감사합니다.
+ 오타, 내용 지적, 피드백을 환영합니다. 많이 해주실 수록 제 성장의 밑거름이 됩니다.