백업과 복구

가장 좋은 경로는 별도 인스턴스에 복원한 뒤 테이블만 옮기는 것입니다. 운영 DB 전체를 되돌리면 그동안 들어온 정상 데이터까지 사라집니다.

복제본에서 가져오려 해도 대개 안 됩니다. DROP 은 복제에 그대로 전파되므로 복제본에서도 사라집니다.

흔한 실수: 복제본이 있으니 백업이 필요 없다고 보는 것. 복제는 서버 장애에 대비하고, 잘못된 명령에는 대비하지 못합니다. 두 가지는 다른 위험에 대한 대비입니다.

예를 들어 이렇게 갈립니다.

두 지표를 함께 정해야 비용이 나옵니다. RPO 0 과 RTO 1분을 요구하면 동기 복제와 자동 승격이 필요하고, 인프라 비용이 배로 듭니다.

그리고 서비스 안에서도 데이터별로 다릅니다. 결제 기록은 RPO 0 에 가까워야 하고, 접속 로그는 하루를 잃어도 됩니다.

흔한 실수: 두 지표를 정하지 않고 백업만 돌리는 것. 장애가 났을 때 "얼마나 잃었고 얼마나 걸리는지" 아무도 모르는 상태가 됩니다.

백업이 성공했다는 것과 복구가 된다는 것은 다른 사실입니다.

첫 번째가 근본입니다. 그래서 정기적으로 실제 복원을 해보고 시간을 재는 것이 백업 운영의 일부입니다.

흔한 실수: 백업 성공 알림만 보고 안심하는 것. 알림은 "파일이 만들어졌다"를 말하고 "그 파일로 서비스를 되살릴 수 있다"를 말하지 않습니다.

복제를 일부러 몇 시간 늦춰 두고, 실수를 그 시간 안에 발견하면 그것으로 복구합니다.

DROP TABLE 이나 잘못된 UPDATE 는 일반 복제본에 즉시 전파되어 그곳에서도 사라집니다. 지연 복제본은 아직 그 변경을 적용하지 않았으므로 원래 데이터가 남아 있습니다.

발견 시간이 관건입니다. 1시간 지연이면 1시간 안에 알아채야 하므로, 이상 감지와 알림이 함께 있어야 의미가 있습니다.

흔한 실수: 지연 복제본을 백업 대신으로 삼는 것. 지연 시간이 지나면 같은 상태가 되므로, 오래된 실수나 장기 보관 요구에는 답이 되지 않습니다. 백업과 함께 두는 장치입니다.