백업 파일이 만들어졌다는 사실은 복구가 가능하다는 증거의 시작일 뿐이다. Temporal 실행을 다시 진행하려면 DB 내용뿐 아니라 그 내용을 읽는 Server, 업무 코드를 실행하는 Worker, 외부 예약과 결과 데이터가 함께 맞아야 한다. 이번 초안은 백업을 원래 환경에 덮어쓰지 않고 별도 시험 환경에 복원해 확인하는 설계를 다룬다.
가상 업무는 허용량 예약, 문서 변환, 결과 저장, 예약 확정이다. 실제 백업이나 복원을 수행한 보고가 아니며, DB 벤더의 일관된 백업 방식과 선택 Temporal 릴리스의 조건을 확인한 뒤 실험해야 한다. 운영 DB의 단순 파일 복사나 내부 테이블 수정 방법을 제시하는 글도 아니다.
복구할 상태가 어디에 있는지 찾는다
Temporal persistence에는 실행 상태와 History, Task, Namespace 정보 등이 있다. Visibility는 목록 검색을 위한 역할을 맡는다. 애플리케이션의 예약 원장과 변환 결과는 별도 저장소에 있다. 이 가운데 하나만 과거로 돌아가면 나머지와 시간이 어긋날 수 있다.
예를 들어 백업 시점에는 결과 저장 전이었지만 실제 외부 저장소에는 그 뒤 생성한 결과가 남아 있을 수 있다. 복원한 Workflow가 저장 Activity를 다시 실행하면 이미 존재하는 결과를 다시 만들려고 한다. 같은 업무 키로 중복을 방지하는 설계가 복구에서도 필요한 이유다.
백업 범위를 정할 때는 데이터만 보지 않는다. Server와 Worker 버전, schema 버전, Namespace 설정, 인증서와 암호화 payload를 읽는 데 필요한 키 관리도 확인한다. 여기서 키의 원문을 백업 보고서에 복사하라는 뜻은 아니다. 필요한 자산이 승인된 보관·복구 절차 안에 있는지 확인해야 한다.
복원 환경이 실제 외부 효과를 만들지 않게 한다
복원된 Worker가 원래 예약 API와 결과 저장소를 호출하면 시험이 실제 업무에 영향을 줄 수 있다. 별도 환경을 만드는 이유는 복원 자체를 확인하면서 원래 환경의 상태를 바꾸지 않기 위해서다. 생성 문서와 가상 원장을 복제하고, 시험 endpoint와 자격만 연결한다.
네트워크와 설정에서 이 경계를 확인한 다음 Worker를 시작한다. DB만 별도로 만들고 Worker의 접속 설정은 원래 환경을 쓰면 충분히 분리한 것이 아니다. 공개 실험에는 개인 데이터, 내부 주소, 운영 인증서를 넣을 필요가 없다.
동일한 Workflow ID가 별도 Service에 존재할 수 있으므로 로그에는 환경 구분도 필요하다. 다만 환경 이름을 바꿨다는 사실만으로 모든 외부 연결이 바뀌었다고 가정하지 않는다. 실제 실행 전에 연결 대상과 쓰기 경로를 검토한다.
어떤 시점을 복원할 것인가
첫 실험은 예약을 마치고 가상 변환을 기다리는 실행 하나로 시작한다. 백업이 어느 시점의 일관된 데이터를 제공하는지는 DB의 방식으로 확인한다. 백업 시작 버튼을 누른 순간과 실제 복원 가능한 시점이 같다고 단정하지 않는다.
- 정상 실행을 만들고 현재 업무 상태와 실행 ID를 기록한다.
- DB가 지원하는 방식으로 시험 백업을 만든다.
- 분리된 DB와 호환되는 Server 환경을 준비한다.
- 백업을 복원하고 schema와 Namespace를 확인한다.
- 시험 외부 API를 가리키는 Worker를 시작한다.
- 기존 실행의 진행과 결과, 예약 원장의 일관성을 대조한다.
- 복원 착수부터 업무 확인까지 걸린 시간을 단계별로 기록한다.
예상 결과는 필요한 데이터와 코드, 설정이 맞으면 복원한 실행을 계속 처리할 수 있다는 것이다. 실제 성공 여부는 실험 후에 판단한다. UI가 열렸다는 시점과 가상 문서가 올바르게 끝난 시점을 구분해 기록해야 복구 시간을 과장하지 않는다.
외부 저장은 성공했지만 History는 과거인 실패
대표 실패는 백업 이후 결과 저장이 성공한 상태를 만드는 것이다. 원래 환경의 가상 저장소에는 결과가 하나 있다. Temporal DB만 이전 시점으로 복원하면 실행은 저장을 다시 요청할 수 있다.
시험 저장소에 같은 업무 키의 결과를 미리 두고 복원 Worker를 실행해 보자. 멱등성이 없다면 중복 결과나 중복 예약 확정이 생길 수 있다. 멱등성이 있다면 같은 요청을 기존 결과로 처리하는지 확인한다. 어느 경우든 Temporal의 복원 성공과 외부 업무의 정합성 확인을 따로 기록한다.
예약 API의 상태도 중요하다. 이미 만료되거나 해제된 예약을 복원한 실행이 확정하려 할 수 있다. 이런 경우 단순 재시도만으로 해결되지 않는다. 현재 예약 상태를 조회하고 새 예약, 실패 종료, 수동 확인 중 무엇을 할지 업무 정책이 필요하다. 과거 실행 상태를 복원한다고 외부 시간과 업무 조건까지 되돌아가지는 않는다.
복구 목표를 측정 가능한 말로 적는다
복구 시간 목표는 서비스를 어느 정도까지 회복하는 데 허용할 시간인지 정해야 한다. API를 받을 수 있는 상태와 밀린 문서를 모두 처리한 상태는 다르다. 데이터 손실 목표도 마지막 백업 이후 어느 실행이나 이벤트까지 보존할 수 있는지를 기준으로 삼는다.
시험 결과에는 백업 시점, 복원 기준 시점, 데이터 복원 시간, Service 기동 시간, Worker 재개 시간, 업무 검증 시간을 나눠 적는다. 아직 재해 상황에서 반복 시험하지 않았다면 단일 시험의 수치를 운영 보장으로 내세우지 않는다.
복원 후 검색 목록과 실행 ID 조회가 다른 모습을 보이면 저장 역할과 복구 범위를 확인한다. 특정 저장소를 어떻게 복구하거나 다시 구성할지는 선택 릴리스와 DB 절차의 문제다. 검색 결과가 보이지 않는다고 내부 데이터를 임의로 수정해 맞추지 않는다.
검증 질문은 “Temporal DB 복원이 성공했는데 예약 원장이 틀릴 수 있는 이유는 무엇일까?”다. 또 “복구 시간을 API 응답 재개까지만 재면 어떤 업무 지연을 놓칠까?”를 생각해 보자. 백업은 저장 작업이고 복구는 업무를 다시 성립시키는 검증이라는 차이가 드러난다.