백업 파일이 손상됐을 때 어떻게 해야 할까

Sheet happens. 지난 강의에서 우리는 장애 발생 후 데이터베이스를 완전히 복구하는 단계별 과정을 배웠었지. 근데 현실은 늘 예상치 못한 상황을 던져줘. 만약 네 백업 파일이 손상됐다면? 이제 이 문제를 파헤쳐보자.

이력서는 어디에 두는 게 좋을까?

농담이야. 지금부터는 기술적인 얘기를 할 거야. 하지만 농담에도 진심이 조금은 들어있다는 거 잊지 마 :)

백업 파일 손상 분석하기

손상된 백업 파일 — 이건 마치 졸업 논문 파일이 제출 직전에 안 열리는 거랑 똑같아. 증상도 비슷하지:

• 복구 시 에러 발생: pg_restore를 실행하면 이런 에러가 뜰 수 있어:

  pg_restore: [archiver] input file does not appear to be a valid archive

• 일부 데이터가 없거나 파일 크기가 이상하게 작거나 0이야.
• 압축 해제한 SQL 파일에 데이터가 끊기거나, 이상한 문자들이 있거나, 빈 섹션이 있어.

백업 손상은 여러 가지 이유로 생길 수 있어:

• 백업 중에 프로세스가 중단됨 (예: 전원 꺼짐, 시스템 다운 등).
• 파일 전송이 잘못됨 (USB나 네트워크로 복사할 때 에러).
• 하드웨어 장애 (디스크, RAM, RAID 장애 등).
• 백업 도구나 시스템 설정 오류.
• 바이러스, 악성코드, 그리고 물론 실수로 "클릭 잘못함".

손상된 백업에서 데이터 복구하기

파일이 손상됐다고 끝난 건 아니야. 가끔은 뭔가라도 복구할 수 있거든. 몇 가지 방법을 알아보자.

pg_restore로 복구 시도하기

pg_dump로 custom이나 directory 포맷으로 만든 파일이라면, pg_restore 명령어에 --ignore-errors 플래그를 붙여서 복구를 시도해봐. 예시:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

이 플래그는 에러가 나도 무시하고 계속 복구를 진행하라는 뜻이야. 손상된 부분의 데이터는 잃겠지만, 일부 정보라도 건질 수 있을 거야.

이게 먹힌다면, 복구가 끝난 후에 데이터가 제대로 들어왔는지 꼼꼼히 확인하고, 빠진 게 뭔지 체크해둬.

부분 데이터 활용하기

만약 SQL 텍스트 포맷 백업이 있다면, 텍스트 에디터(가능하면 Visual Studio Code나 Notepad++ 같은 고급 에디터)로 열어서 어디서 끊겼는지 확인해봐. 파일이 읽히고 대부분의 SQL 쿼리가 살아있다면:

1. 손상된 부분을 잘라내.
2. 남은 SQL 쿼리를 직접 실행하거나 psql 명령어로 돌려봐:

psql -U username -d database_name -f partial_backup.sql

custom 포맷 파일 읽기

백업이 custom 포맷이라면, 내용을 부분적으로 추출해볼 수 있어:

pg_restore --list backup_file.dump > file_list.txt

이 명령어는 백업에 들어있는 모든 오브젝트 목록을 만들어줘. 그 다음엔, 아래 명령어로 특정 요소(테이블, 스키마 등)만 복구할 수 있어:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

file_list.txt를 편집해서 손상된 요소를 빼고 복구할 수도 있어.

아카이브 로그(WAL)로 복구 시도하기

증분 또는 차등 백업(pg_basebackup 등)을 썼다면, 아마 아카이브 로그(WAL 파일)가 있을 거야. 이 파일들은 이전 백업 이후의 모든 변경사항을 저장해. 복구하려면:

1. 가장 최근의 정상 백업을 찾아.
2. PostgreSQL에 WAL 파일 위치를 알려줘:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. 복구를 실행해.

외부 복구 도구 사용하기

가끔 파일 복구 유틸리티로 백업 손상을 최소화할 수 있어. 유명한 도구로는 ddrescue가 있어. 예시:

ddrescue --force backup_file.dump recovered_dump.file

이 도구는 최대한 많은 데이터를 복구해서 새 파일로 만들어줘.

백업 손상 예방하기

손상된 파일 다루는 건 진짜 스트레스야. 이런 상황을 피하려면 어떻게 해야 할지 생각해보자.

여러 장소에 백업 보관하기

프로젝트에서 백업은 항상 "계란을 한 바구니에 담지 마라"는 원칙이 있어. 백업을 여러 군데에 두는 게 좋아:

• 로컬 서버.
• 클라우드(Amazon S3, Google Cloud Storage, 아니면 Dropbox 같은 간단한 서비스).
• 외장 저장장치(진짜 안전하게 가고 싶으면).

정기적으로 백업 무결성 검사하기

IT 업계에선 이런 말이 있어: "테스트 안 한 백업은 백업이 아니다." 정기적으로 테스트 복구를 해봐야 해. 방법은:

1. 테스트 서버에 백업을 올려.
2. 거기서 데이터를 복구해.
3. 정상적으로 복구됐는지 확인해.

체크섬 사용하기

백업 만들 때 파일 체크섬(MD5나 SHA256 등)도 같이 생성해두자:

md5sum backup_file.dump > backup_file.md5

복구할 때는 현재 체크섬이 원본과 같은지 비교해봐:

md5sum -c backup_file.md5

이렇게 하면 파일이 손상됐는지 미리 알 수 있어.

손상된 백업에서 복구한 사례

실제 사례 몇 개를 살펴보자.

케이스 1. 파일 전송 에러

FTP로 백업을 옮기다가 파일 크기가 예상보다 작다는 걸 알게 됐어. pg_dump로 텍스트 포맷 백업을 썼으니까:

1. 에디터로 파일을 열었어.
2. 손상된 부분을 잘라냈어.
3. 남은 부분을 psql로 복구했어.

케이스 2. WAL에서 일부 데이터 손실

서버가 증분 백업과 아카이브 WAL 파일을 쓰고 있었는데, 갑자기 일부 파일이 사라졌어. 그래도 pg_basebackup과 남아있는 WAL 파일로, 복구 설정에서 경로를 지정해서 데이터를 살릴 수 있었어.

백업은 단순히 복사만 하는 게 아니라, 그걸 제대로 쓸 수 있는지도 꼭 확인해야 해. 세상이 망하기 전에 네 백업이 쓸모없는 걸 알게 되면 진짜 곤란하니까. 만약 백업이 손상됐다면, 당황하지 말고: PostgreSQL은 데이터를 복구할 수 있는 다양한 방법을 제공해. 중요한 건 빠르고 신중하게 움직이는 거야!

그리고 아무것도 안 통하면 — 이 강의의 첫 번째 항목을 다시 읽어봐.