홈페이지의 글은 파일처럼 보이지만 데이터베이스의 최근 내용이 주 파일 안에만 있는 것은 아니었다. K-POP PULSE의 9월 운영 문서는 SQLite의 WAL을 고려해 백업 API로 사본을 만들도록 적었다. 파일 하나를 복사하는 작업과 보존할 내용을 읽는 작업을 구별해야 했다.
나는 이번 이야기를 실제 원본 사이트에서 최근 글을 잃었다는 사고로 만들지 않는다. 기록에는 두 DB의 압축 백업이 만들어진 출력이 있고, 이번에는 별도의 새 합성 DB로 주 파일 복사와 백업 API 결과를 직접 비교했다. 당시 운영과 현재 재현의 경계를 함께 남긴다.
파일이 있다는 결과보다 안에 무엇이 있는지 묻는다
WAL에서는 커밋된 변경이 보조 로그에 남을 수 있다. 그 상태의 주 파일만 가져오면 내가 기대한 최신 행을 읽지 못할 수 있다. 그래서 백업의 이름이나 크기, 파일 생성 성공만으로 최근 원고까지 보존됐다고 판단하지 않는다.
중요한 질문은 어느 시점의 어떤 내용을 보존하려 했는가다. 글의 식별자와 본문, 연결 관계를 사본에서 읽을 수 있는지 확인해야 한다. 같은 행수라도 다른 문장이 들어 있으면 기대한 결과가 아니므로, 행의 존재와 필요한 내용은 따로 대조한다.
기록에 있는 백업 생성과 복원 검수를 구별한다
9월 26일 작업 출력에는 게시물 DB와 통계 DB의 압축 파일 생성, 보존 기간 정리가 남아 있다. 이는 당시 백업 절차가 실행되어 결과를 만든 기록이다. 그 출력만으로 실제 서비스를 사본에서 복원하고 모든 글을 확인했다고 말할 수는 없다.
나는 운영자가 다음에 무엇을 확인해야 하는지 알려 주는 방식으로 기록을 읽는다. 별도 DB 둘을 백업했다고 같은 순간의 한 사본이 되는 것도 아니다. 서로 연결된 데이터에 어느 시점이 필요한지 정하고, 실제 복구 흐름에서 그 관계를 확인할 범위를 남긴다.
새 작은 DB에서 차이를 직접 재현했다
현재 재현은 기준 행을 커밋하고 체크포인트를 마친 뒤 연결을 열어 둔 채 두 번째 행을 커밋하는 순서다. WAL 파일이 실제로 있는 상태에서 주 파일만 복사한 사본은 첫 행만 읽혔다. 백업 API로 만든 새 사본에서는 두 행과 두 번째 본문을 다시 읽었다.
이 결과는 내가 만든 합성 입력에서 두 방식의 차이를 확인한 것이다. 당시 K-POP DB의 누락된 글이나 원본 백업 파일을 복원한 자료가 아니다. 작은 재현에 실제 저장 상태와 읽기 결과를 남기면 원리를 설명하면서도 실제 사건을 만들어 내지 않을 수 있다.
코드와 구현 살펴보기
새 합성 재현의 순서. 원본 운영 DB 복원 절차가 아니다.
New synthetic database, not an operating project:
1. Commit a baseline row and complete its checkpoint.
2. Keep the connection open; commit another row into WAL.
3. Copy only the main file -> inspect which rows remain.
4. Use the backup API -> close and reopen the new copy.
5. Compare expected row IDs and text, not only file size.
# This map describes the new checked example; it does not restore the original site.사본을 만드는 프로그램에도 보존 조건을 둔다
이번 공유 CLI는 원본을 읽기 전용 연결로 열고 아직 없는 새 출력 파일을 만든다. 기존 목적지나 같은 파일은 거부하며, 새 사본을 단독 파일로 읽을 수 있도록 그 대상만 저널 모드를 바꾼다. 원본 데이터 행과 저널 모드를 바꾸는 프로그램은 아니다.
읽기 전용 연결도 환경에 따라 보조 파일에 접근하거나 생성할 수 있다. 이를 모든 파일시스템 변화가 없다는 뜻으로 소개하지 않는다. 무결성 검사와 테이블 행수, 파일 해시를 결과에 남기지만 업무 데이터의 정확성까지 자동으로 인증하지 않는다. 적용 환경의 조건을 읽고 확인해야 한다.
전체 홈페이지에 필요한 것은 DB 밖에도 있다
글이 이미지와 영상, 첨부 파일을 가리킨다면 DB 사본만으로 그 자산이 돌아오지는 않는다. 프로그램과 설정, 실행 환경과 필요한 연결도 별도 보존 대상이다. 비밀 설정은 공개 콘텐츠와 섞지 않으면서 복구할 수 있는 방식으로 관리해야 한다.
나는 복원 사본에서 실제 조회와 공개 주소, 자산을 읽는 확인을 그 사이트에 맞게 정한다. 백업 진행 뒤의 새 커밋과 미커밋 변경, 다른 DB의 시점을 모두 포함했다고 가정하지 않는다. 파일 생성 성공을 전체 서비스 복구 완료로 부르면 다음 작업자가 필요한 확인을 놓친다.
검사와 적용 범위를 같이 넘긴다
공유 ZIP에는 새 Python CLI와 사용 설명, 검사 코드가 있다. 합성 WAL 재현, 단독 사본 재열기, 기존 파일 보호와 오류 처리, 실제 CLI를 포함한 17개 검사를 통과했다. 테스트 사본을 먼저 만들고 자기 환경의 권한과 데이터 형태에 맞는 확인을 덧붙여 사용한다.
네트워크 파일시스템이나 특수 확장 테이블, 모든 SQLite 버전을 검수한 결과는 아니다. 원본 운영 사이트의 복원 시험도 이번 작업 범위가 아니다. 나는 백업을 켜 두었다는 설명보다 필요한 내용을 실제로 읽었다는 근거를 남겨 다른 제작자가 복구할 때 출발점을 찾을 수 있게 하고 싶다.