장애 이후 데이터 복구

장애는 여러 가지가 있어: 하드웨어 고장, 정전, 코드 에러, 그리고 꽤 자주 일어나는 게, 게으른 관리자가 "뭔가 오래된 거" 지운다고 하다가 실수로 데이터베이스를 삭제하는 경우. 이런 상황에서는 백업이랑 잘 짜여진 복구 프로세스가 진짜 "마법 지팡이"가 돼줄 거야.

이제 IKEA 가구 조립하듯이, 당황하지 말고 차근차근 복구 과정을 살펴보자.

1단계. 장애 원인 분석

무작정 데이터 복구부터 달려들기 전에, 무슨 일이 일어났는지 파악하는 게 중요해.

1. 애플리케이션이나 데이터베이스 에러?
   네 애플리케이션 로그랑 PostgreSQL 로그를 확인해봐 (보통 /var/log/postgresql/나 네 OS에 따라 비슷한 디렉토리에 있어). 에러 인디케이터를 찾아봐.

2. 하드웨어 고장?
   서버가 물리적으로 망가졌다면 (예: 하드디스크 문제), 먼저 장비가 정상인지 확인해. 디스크가 망가졌으면, 다른 디스크를 연결해서 거기서 복구해.

3. 네트워크나 접근 문제?
   네트워크 문제라면 — 서버는 당장 복구 작업이 필요 없을 수도 있어.

4. 사람 실수:
   솔직히 말해봐... 누가 DROP DATABASE 쳤어? 만약 그렇다면, 아직 백업에서 복구할 기회가 있어.

장애 원인을 정확히 이해하면 다음에 이런 일 피할 수 있어.

2단계. 백업 파일 확인

이제 제대로 된 백업이 있는지 확인할 차례야. pg_dump나 pg_basebackup으로 만든 최신 데이터베이스 백업을 찾아봐. 무결성도 체크해야 해. 아직 방법을 모른다면, 간단히 설명해줄게:

• ls -l 명령어로 파일 크기를 확인해봐. 파일이 너무 작으면 뭔가 문제일 수 있어.
• file 명령어로 파일을 체크해봐. 예시:

  file backup_file.sql
  

  SQL 덤프 파일이라는 정보가 나와야 해.

tar 아카이브라면, 압축 해제가 잘 되는지 확인해봐:

tar -tf backup.tar

에러 없으면? 굿! 다음 단계로 가자.

3단계. PostgreSQL 중지

복구 시작 전에 PostgreSQL 서버를 멈추는 게 안전해. 아래 명령어로 (서버 관리자 권한 필요):

sudo systemctl stop postgresql

데이터베이스를 멈추면, 복구에 방해되는 프로세스가 없어져.

4단계. 복구용 새 데이터베이스 준비

데이터베이스가 완전히 삭제됐거나 망가졌으면, 먼저 새로 만들어야 해. 예시 명령어:

createdb -U postgres new_database

new_database를 네 데이터베이스 이름으로 바꿔줘.

5단계. 백업 복구

복구에는 두 가지 주요 시나리오가 있어:

1. SQL 백업 (pg_dump)을 썼다면: 복구는 이렇게 해

   psql -U username -d new_database -f backup_file.sql
   

• username — PostgreSQL 사용자명.
• new_database — 데이터를 가져올 데이터베이스.
• backup_file.sql — 백업 파일.

2. 바이너리 백업 (pg_basebackup 또는 pg_dump의 custom)을 썼다면:
   복구는 이렇게:
   

   pg_restore -U username -d new_database backup_file.dump
   

   이 백업들은 텍스트가 아니라 "압축된" 데이터야.

추가 팁:

• 백업에 데이터만 있으면 --data-only 옵션 써.
• 구조만 복구하려면 --schema-only 추가해.

6단계. PostgreSQL 시작 & 테스트

복구 명령어 실행 후 서버를 시작해:

sudo systemctl start postgresql

이제 테스트를 해보자. psql이나 pgAdmin으로 복구된 데이터베이스에 접속해봐. 데이터가 잘 들어갔는지 쿼리 몇 개 날려봐:

SELECT * FROM your_table_name LIMIT 10;

문제 없어 보이면, 축하해: 데이터 복구 성공!

7단계. 데이터 무결성 체크

복구 후에는 데이터가 제대로 복구됐는지 꼭 확인해야 해. 예시:

1. 테이블 행 수를 백업과 비교해봐:

   SELECT COUNT(*) FROM your_table_name;
   

   결과를 백업 기록이랑 비교해봐 (있다면).

2. 체크섬 사용: 전에 테이블 체크섬을 만들어뒀다면, 지금 비교해봐:

   md5sum backup_file.sql
   

3. 테이블 간 관계 체크: 복구된 FOREIGN KEY 관계가 잘 동작하는지 확인해봐.

8단계. 애플리케이션 테스트

이제 이 데이터베이스를 쓰는 네 애플리케이션이 잘 동작하는지 확인해봐. 주요 시나리오를 쭉 테스트해봐. 에러가 있나? 화면에 잘 나오나?

실제 복구 에러 예시

이제 몇 가지 케이스를 보면서, 어떻게 문제를 피할 수 있는지 알아보자:

1. PostgreSQL 버전 불일치.
   예를 들어, 백업은 12버전에서 했는데 서버는 15버전으로 업그레이드 됐다면, 복구할 때 에러가 날 거야.
   해결법: 백업할 때 썼던 PostgreSQL 버전이랑 똑같은 버전을 쓰거나, 호환성 문서를 참고해: PostgreSQL Documentation.

2. 손상된 백업 . 백업이 망가졌으면, 일부 데이터가 날아갈 수 있어.
   해결법: 백업 여러 버전을 복제해서 보관해 (예: 여러 버전 저장).

3. 특정 테이블 복구 에러.
   특정 테이블만 복구하는데, 다른 의존성(예: 외래키)이 없으면 에러가 날 수 있어.
   해결법: 항상 부모 테이블부터 순서대로 복구해.