백업은 비 오는 날 우산 같은 거라고 생각하기 쉽지: 모든 문제에서 널 지켜줄 거라고 믿잖아. 근데 우산에 구멍이 나 있으면 결국 젖게 돼. 백업이랑 복구도 똑같아: 뭔가 잘못되면 데이터를 잃거나, 더 최악으로는 깨진 데이터베이스를 얻게 될 수도 있어. 그래서 오류를 이해하고 미리 막는 게 진짜 중요해.
데이터 복구 시 문제
- PostgreSQL 버전 호환성 문제
가장 흔하고 짜증나는 문제 중 하나는, 한 버전의 PostgreSQL에서 만든 데이터를 다른 버전(예: 11에서 만든 백업을 15에서 복구하려고 할 때)에 복구하려는 거야. PostgreSQL은 버전 간의 하위 호환성을 보장하지 않아.
왜 이런 일이 생길까?
- 버전마다 데이터 포맷이 바뀔 수 있어.
- 어떤 함수나 파라미터가 삭제되거나 바뀔 수도 있어.
어떻게 피할 수 있을까?
- 항상
pg_dump로 백업을 만들어. PostgreSQL 데이터 디렉토리를 그냥 복사하지 말고!pg_dump는 어느 호환 버전에서도 복구할 수 있는 범용 SQL 스크립트를 만들어줘. - 복구 시작 전에 버전 호환성을 꼭 확인해. PostgreSQL 공식 문서에서 정보를 찾을 수 있어.
예시를 들어볼게. PostgreSQL 14에서 백업을 만들었어:
pg_dump -U user -d my_database -f backup.sql
이제 PostgreSQL 15에서 복구하려고 해:
psql -U user -d my_database -f backup.sql
그리고 이런 오류가 나와:
ERROR: 인식할 수 없는 설정 파라미터 "old_function"
해결법: 서버의 PostgreSQL 버전을 업그레이드하거나 pg_upgrade 유틸리티로 옮겨봐.
- 필요한 WAL 파일 없음
가끔 증분 또는 차등 백업에서 복구할 때 갑자기 멈추는 경우가 있어 — 대부분 WAL(Write-Ahead Logging) 파일이 없어서 그래. PostgreSQL은 마지막 전체 백업 이후의 변경사항을 적용하려면 WAL 파일이 꼭 필요해. 파일이 없거나 깨졌으면 복구를 끝낼 수 없어.
예를 들어 WAL 파일 아카이빙을 안 켰거나, 누가 공간 확보하려고 폴더를 실수로 지웠을 때 이런 일이 생겨. 그래서 불완전한 백업을 쓸 거면 postgresql.conf에서 아카이빙을 꼭 켜야 해:
archive_mode = on
archive_command = 'cp %p /path/to/wal_archive/%f'
그리고 아카이브가 진짜 잘 되고 있는지, 파일이 제대로 있는지 자주 확인해. 이 정도 수고로 복구 실패 걱정 안 해도 돼.
- 백업 파일 손상
백업 파일이 깨지면 복구에 쓸 수 없어, 그냥 쓸모없어져.
왜 이런 일이 생길까?
- 파일 전송이나 저장 중에 무결성이 깨졌을 때.
- 백업 만드는 도중에 예기치 않은 장애가 났을 때.
어떻게 피할 수 있을까?
압축이랑 체크섬을 써서 백업 파일 무결성을 확인해. 예를 들어 파일 만든 뒤에 MD5 해시를 만들어봐:
md5sum backup.sql > backup.sql.md5
복구 전에 항상 백업 파일을 체크해:
md5sum -c backup.sql.md5
문제와 해결
깨진 파일을 복구하려고 해:
pg_restore -U user -d my_database backup.dump
그리고 이런 메시지가 떠:
pg_restore: 치명적 오류: 입력 파일이 텍스트 파일로 보이는데, 'pg_restore' 커맨드라인 툴을 쓰고 있어; 대신 psql을 써봐
해결법: 텍스트 에디터로 파일을 열어서 내용이 괜찮은지 확인해. 손상이 심하지 않으면 SQL 파일을 직접 고칠 수도 있어.
- 사용자 권한 부족.
가끔 복구할 때 권한 부족 때문에 오류가 날 수 있어, 특히 제한된 사용자로 복구하려고 할 때.
왜 이런 일이 생길까?
사용자에게 테이블, 스키마, 데이터베이스 오브젝트를 만들 권한이 부족해서 그래.
어떻게 피할 수 있을까?
필요한 권한이 있는 사용자로 복구를 실행해:
pg_restore -U postgres -d my_database backup.dump
- 기존 데이터베이스 덮어쓰기
또 자주 하는 실수는, 이미 데이터가 있는 데이터베이스에 백업을 복구해서 기존 데이터를 덮어써버리는 거야. 실수로 기존 레코드를 덮으면 복구 못 해.
왜 이런 일이 생길까?
--clean 플래그를 안 써서, 새 백업이 기존 데이터 위에 그냥 추가돼서 그래.
어떻게 피할 수 있을까?
복구할 때 --clean 플래그를 써서 기존 구조를 지워:
pg_restore --clean -U user -d my_database backup.dump
- 미완료 트랜잭션 오류
복구할 때 미완료 트랜잭션에 걸린 데이터 때문에 문제가 생길 수 있어. 특히 큰 데이터베이스에서 자주 나와.
왜 이런 일이 생길까?
트랜잭션이 서버 장애로 "깨져서" 그래.
어떻게 피할 수 있을까?
PostgreSQL 서버가 모든 트랜잭션을 깔끔하게 끝내고 복구를 하도록 해. 문제가 생기면 서버를 이렇게 재시작해봐:
sudo service postgresql restart
복구 오류 예방 방법
각 문제를 피하는 방법을 얘기했지만, 대부분의 문제를 막을 수 있는 일반적인 전략도 있어:
복구 테스트를 자주 해봐. 별도의 테스트 데이터베이스를 만들어서 거기에 복구해봐.
여러 개의 백업 복사본을 보관해. 클라우드 서비스, 로컬 저장소, 원격 서버를 같이 써.
백업 자동화해. cron이나 비슷한 툴로 스케줄을 짜.
파일 무결성 체크해. 체크섬을 써서 백업이 깨지지 않았는지 확인해.
PostgreSQL 버전 동기화 유지해. PostgreSQL 업데이트를 미루지 마. 나중에 버전 불일치로 골치 아플 수 있어.
실제 케이스와 해결법
케이스 1: WAL 파일 분실. 서버가 갑자기 꺼졌는데 필요한 WAL 파일이 없어. 이럴 땐 전체 백업 없이는 복구 불가능해. 제일 쉬운 해결법은 WAL 아카이브 설정을 자주 확인하는 거야.
케이스 2: 깨진 백업. 서버에 백업을 올렸는데 파일이 비어있는 걸 발견했어. 이런 경우 다른 저장소의 백업을 쓰거나, 일부만 손상된 백업에서 복구할 수 있는지 확인해봐.
케이스 3: 버전 호환성 문제. PostgreSQL 12에서 14로 데이터 옮기다가 오류가 났어. pg_dump로 데이터를 내보내고, 새 버전에서 복구해봐.
GO TO FULL VERSION