데이터가 사라졌을 때: 단계별 대처 방법

데이터를 잃은 직후의 첫 행동이 그 이후의 모든 것보다 중요해요. 아래는 복구 가능성을 잃지 않는 절차예요.

즉시: 디스크에 쓰기 중단

삭제된 파일은 그 공간이 새로운 데이터로 채워질 때까지 디스크에 남아 있어요. 패키지 설치, 실행 중인 웹사이트, 커지는 로그 등 모든 쓰기 작업은 복구 가능성을 줄여요.

• 쓰기 작업을 멈추세요: 웹 서버, 데이터베이스, 큐 워커.
• 같은 디스크에 복구 소프트웨어를 설치하지 마세요.
• 시스템을 재설치하지 마세요: 재설치는 디스크를 완전히, 되돌릴 수 없이 파괴해요.

데이터가 중요하고 백업이 없다면, 어떤 실험도 하기 전에 머신을 멈추고 지원팀에 문의하세요.

정확히 무슨 일이 일어났는지 파악하기

백업이 있는 경우

가장 빠른 경로이고 거의 항상 유일하게 성공하는 경로예요. 자신의 방식대로 복원하세요 — rsync 또는 restic — 그리고 압축 해제가 성공했는지가 아니라 내용을 확인하세요: 크기, 줄 수, 데이터베이스가 열리는지 여부.

restic -r /path/to/repo snapshots
restic -r /path/to/repo restore latest --target /restore

먼저 별도의 디렉터리에 복원하고, 작업 중인 디렉터리 위에 덮어쓰지 마세요: 백업도 불완전할 수 있고, 남은 데이터를 백업으로 덮어쓰면 두 가지 가능성을 모두 잃게 돼요.

백업이 없는 경우

저희는 머신의 자동 백업을 보관하지 않으며 스냅샷도 없어요. 가상 머신의 디스크는 당신의 디스크예요: 그 위에서 일어난 일은 그대로 일어난 일이에요. 그래서 백업은 첫날부터 설정해요 — 무엇을 백업해야 하는지.

직접 시도해 볼 수 있는 것들:

• 파일이 아직 프로세스에 열려 있는 경우. 프로그램이 삭제된 파일을 붙잡고 있다면 /proc을 통해 접근할 수 있어요:

  lsof +L1
  cp /proc/<pid>/fd/<n> /root/recovered-file
  

  이 방법은 프로세스가 살아 있는 동안에만 동작해요 — 재시작하지 마세요.
• 데이터베이스 로그 속의 데이터. PostgreSQL과 MySQL에는 전문가가 장애 직전 상태를 재구성할 수 있는 선행 기록 로그(write-ahead log)가 있어요. 데이터베이스를 무작정 복구 모드로 시작하지 마세요 — 그러면 로그도 잃게 돼요.
• 구조 디스크로 부팅하고 extundelete나 photorec 같은 도구를 시도하기 전에 디스크를 다른 머신으로 이미징하세요. 작업은 실제 디스크가 아니라 이미지에서 해야 해요.

하지 말아야 할 것

• 데이터가 필요한지 결정하기도 전에 “처음부터 다시 시작하려고” 시스템을 재설치하는 것.
• 출력을 같은 디스크에 쓰는 복구 프로그램을 실행하는 것.
• 이미지 없이 실제 디스크에서 fsck가 “yes”에 자동 응답하도록 파일 시스템을 복구하는 것.
• 일주일을 기다린 뒤 복구를 요청하는 것: 머신이 오래 실행될수록 남는 것은 줄어들어요.

같은 일을 반복하지 않으려면

같은 대화는 항상 같은 결말로 끝나요: 백업이 있거나, 없거나. 오늘 설정하고 분기에 한 번 복원 훈련으로 테스트하세요 — 한 번도 복원해 본 적 없는 백업은 백업이 아니에요.