기술 · 실용 가이드
SQLite “database disk image is malformed”? 복구 전에 원본부터 보존하세요
SQLITE_CORRUPT를 preservation incident로 다루세요. writers를 중지하고 journal/WAL과 DB를 함께 보존해 read-only copy를 hash한 뒤 새 파일로만 recover하고 검증합니다.
SQLITE_CORRUPT를 preservation incident로 다루세요. writers를 중지하고 journal/WAL과 DB를 함께 보존해 read-only copy를 hash한 뒤 새 파일로만 recover하고 검증합니다.
import 성공은 SQL 실행 증거일 뿐 모든 recovered value의 정확성을 증명하지 않습니다.
1. 변경 중지와 정확한 files 확인
application과 모든 writers를 중지하고 resolved path, SQLite library/CLI version, size, timestamp, 첫 전체 error를 기록합니다. 유일한 copy에 VACUUM, REINDEX, write pragma를 실행하지 마세요.
rollback journal/WAL 사용 시 matching -journal, -wal, -shm을 DB와 함께 보존합니다. hot journal/WAL 분리는 automatic recovery를 방해합니다.
2. evidence와 working copies 생성
original set을 hash하고 read-only로 두며 recovery는 별도 working copy에서만 합니다. 일반 file copy는 writers 중지 후에만 안전하고 live healthy DB에는 backup API, VACUUM INTO, sqlite3_rsync를 씁니다.
untouched evidence를 남기고 command, tool version, output filename을 기록합니다. partial success로 original을 덮지 말고 storage failure 의심 시 device evidence를 먼저 보존합니다.
3. copy 진단, repair 약속 금지
working copy에서 PRAGMA integrity_check를 실행해 모든 rows를 저장합니다. structure, missing/duplicate pages, 여러 constraints를 검사하지만 foreign keys는 foreign_key_check가 필요합니다.
다른 copy의 ok가 original 정상 증명은 아닙니다. 실제 file, schema, page count, critical tables를 확인하고 I/O error와 SQLITE_CORRUPT를 분리합니다.
4. backup restore 우선, 그다음 salvage
known-good backup을 먼저 검증합니다. 없다면 working copy에 .recover를 실행해 SQL을 새 file로 저장하고 또 다른 새 DB에 import합니다. original을 덮지 마세요.
Recovery는 salvage입니다. deleted rows가 되살아나거나 values가 바뀌고 constraints가 깨지며 lost_and_found가 생길 수 있습니다. .recover가 더 많이 구해도 정확성을 보장하지 않습니다.
5. service 복귀 전 검증
recovered DB에서 integrity_check, foreign_key_check, UNIQUE/CHECK, row counts, relationships, balances, critical totals, lost_and_found를 검토합니다.
application test 뒤 새 backup과 rollback plan으로 전환합니다. original evidence를 유지하고 data loss를 기록하며 unsafe copy, journal separation, filesystem, rogue write를 조사합니다.
