备份与恢复确认

하루 한 번 pg_dump 만 뜬다면 RPO 는?

• 24시간
• 0
• 1시간
• 덤프 시간에 따라 다르다

PITR 에 필요한 세 조각이 아닌 것은?

• 논리 덤프
• 베이스 백업
• 아카이브된 WAL
• 복구 대상 시각 설정

archive_command 가 실패했는데 0(성공)을 반환하면?

• 실패를 알아채고 다음 주기에 자동으로 재시도한다
• 로그에 경고만 남고 넘어간다
• 아카이빙이 그 자리에서 멈춘다
• PostgreSQL 이 그 WAL 을 지워서 그 구간은 영원히 복구 불가가 된다

archive_command 가 계속 실패하면 결국 무슨 일이 생기나?

• 아무 일 없다
• 서버가 읽기 전용이 된다
• pg_wal 이 계속 불어나 디스크가 찬다
• 백업이 자동으로 꺼진다

archive_command 에 test ! -f 를 앞에 붙이는 이유는?

• 아카이빙 속도를 높이려고
• 아카이브 디렉터리 쓰기 권한을 미리 확인하려고
• 같은 이름의 다른 내용을 덮어써서 복구가 조용히 깨지는 것을 막는다
• 압축 여부를 판단하기 위해

복구 후 recovery_target_action 을 pause 로 두는 이점은?

• 복구가 더 빨리 끝난다
• 멈춘 상태로 확인한 뒤 승격 여부를 결정할 수 있다
• WAL 저장 공간을 아낀다
• 타임라인 번호가 바뀌지 않는다

복구 후 승격하면 타임라인 번호가 증가하는 이유는?

• 구현상의 버그 때문이다
• 그 시점부터 원본과 다른 역사가 시작되기 때문
• 내부 버전이 올라가기 때문
• WAL 공간이 꽉 차기 때문

가장 흔하고 가장 비싼 백업 실수는?

• 압축을 안 한다
• 덤프 포맷을 잘못 고른다
• 너무 자주 뜬다
• 복원 연습을 안 한다