복구 후 데이터 무결성 검사

데이터베이스 복구는 항상 쉬운 게 아니야. 겉으론 잘 된 것 같아도, 나중에 로그에서 에러가 튀어나오거나, 어떤 테이블이 사라지거나, 데이터가 수상해 보일 때가 있지. 그래서 복구 후에 꼭 모든 게 제대로 됐는지 확인하는 게 진짜 중요해.

가끔 데이터 일부가 아예 복구되지 않을 수도 있어 — 예를 들어 백업 파일이 손상됐을 때. 테이블 구조가 꼬일 수도 있고: foreign key가 사라지거나, 인덱스가 없어지거나, 이상한 값이 생길 수도 있지. 겉보기엔 멀쩡해 보여도, 로그가 "이 DB 뭔가 이상하다"라고 힌트를 줄 때도 있어.

무결성 검사는 마치 수리 후 차량 점검 같은 거야. 조금만 시간 들여서 다 잘 돌아가는지 확인하는 게, 나중에 프로덕션에서 갑자기 문제 터지는 것보다 훨씬 낫지.

복구 로그 분석하기

pg_restore로 데이터를 복구할 때 PostgreSQL은 무조건 로그를 만들어. 이 로그에는 복구 과정에서의 유용한 정보, 경고, 에러가 다 들어있어. 로그 파일을 지정해서 명령어를 이렇게 쓸 수 있어:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

> restore_log.txt 2>&1 이 부분이 표준 출력이랑 에러를 한 파일로 모아주는 거야.

로그에서 뭘 봐야 할까?

1. 에러. "ERROR"나 "FATAL" 같은 키워드에 집중해. 예시:

   ERROR:  relation "students" does not exist
   

2. 경고. 가끔 "WARNING" 경고도 보여. 치명적이진 않지만, 꼭 읽어보는 게 좋아 — 뭔가 문제의 신호일 수도 있으니까:

   WARNING:  no privileges could be granted for table "grades"
   

3. 데이터 불일치. 주요 객체들 — 테이블, 인덱스, foreign key — 다 복구됐는지 확인해봐.

grep으로 빠르게 검사하기

로그 파일이 너무 길면(진짜 "전쟁과 평화"만큼 길 때도 있음), grep으로 키워드만 뽑아볼 수 있어:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

로그 에러 분석하기

실제 로그에서 나온 예시를 보자:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

이 에러가 뭘 의미할까? PostgreSQL이 enrollments 테이블에 행을 복구하려고 하는데, 해당 course_id가 courses 테이블에 없다는 뜻이야.

어떻게 해결하지? 아마 courses 테이블 데이터가 손상됐거나 복구가 안 된 거야. 직접 누락된 행을 추가하거나, 복구를 다시 해야 해.

무결성 체크를 위한 체크섬 사용

백업 파일이 복구 전후로 손상되지 않았는지 확실히 하고 싶으면 체크섬을 써봐.

체크섬은 파일 데이터를 대표하는 작은 숫자야. 파일이 한 비트라도 바뀌면 체크섬도 바뀌지. 이걸로 파일이 손상됐는지 알 수 있어.

md5sum 유틸리티로 체크섬을 만들 수 있어. 예시:

md5sum backup_file.dump

결과는 이렇게 나와:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

체크섬 비교하기

미리 체크섬을 기록해뒀다면, 지금 체크섬이랑 비교해볼 수 있어:

md5sum -c checksum.md5

checksum.md5 파일에는 체크섬 값과 파일 이름이 들어있어야 해:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

체크섬이 일치하면 OK 메시지가 뜨고, 아니면 파일이 손상된 거야.

DB 레벨에서 데이터 검사하기

체크섬이나 로그도 좋지만, 실제 데이터가 제대로 복구됐는지 어떻게 확인할까? 표준적인 방법 몇 가지를 소개할게:

1. 행 개수 비교

복구 전후로 테이블의 행 개수를 비교해봐. 예시:

-- students 테이블 행 개수 세기
SELECT COUNT(*) FROM students;

행 개수가 다르면 복구가 완벽하지 않은 거야.

2. 키 무결성 검사

테이블 간 관계를 복구해서 foreign key가 다 정상인지 확인해봐:

-- 수강 신청한 학생들 검사
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

이 쿼리 결과가 나오면, enrollments 테이블에 없는 course가 있다는 뜻이야.

3. 원본과 데이터 비교

만약 데이터 복사본(예: 다른 DB의 dump)이 있다면, 쿼리로 비교해볼 수 있어:

-- courses 테이블 데이터 검사
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

실제 복구 사례

실전에서 있었던 일: 어느 날 DBA Bob이 서버 장애 후 백업에서 데이터를 복구하려고 했어. 명령어는 이렇게 썼지:

pg_restore -U admin -d my_database my_backup.dump

근데 로그를 보니 복구가 에러로 끝났어:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

이건 디스크 공간이 부족하다는 뜻이야. 공간을 확보하고 복구를 다시 했더니, 일부 테이블이 여전히 복구되지 않았더라고. 다행히 Bob은 미리 체크섬을 만들어두고 WAL 아카이브도 설정해놔서, 결국 DB를 완전히 복구할 수 있었어.

무결성 검사 요약

복구 후 데이터 무결성 검사를 마무리할 때는 이렇게 해봐:

1. 로그에서 에러와 경고를 확인해.
2. 체크섬으로 파일 손상 여부를 확인해.
3. DB 데이터를 행 개수와 관계 무결성 기준으로 비교해.
4. 뭔가 이상하면 에러를 분석하고 복구 과정을 다시 반복해.

이제 꼼꼼하게 검사해서 데이터가 네가 기대한 대로 복구됐는지 확실히 확인할 수 있을 거야. 데이터베이스 관리에서 제일 중요한 건, 백업에 대한 자신감이지!