백업·복구와 데이터 검증

복구본의 무결성과 기준값을 SQL로 대조합니다.

개념 이해하기

백업은 실제 복구 후 검증을 통과해야 의미가 있습니다. 실습에서는 백업 시점에 기록한 manifest와 복구된 orders의 행 수·최대 id·결제 합계를 비교해 PASS 또는 FAIL을 판정합니다.

PRAGMA integrity_check로 SQLite 파일 구조를 확인하고 control total로 업무 데이터 누락을 검출합니다. 운영에서는 외래키 위반, 핵심 테이블 수, 기간별 금액과 애플리케이션 smoke test도 수행합니다.

복제본은 실수로 삭제한 데이터도 그대로 반영하므로 시점 복구 가능한 백업과 복구 훈련을 대체하지 않습니다.

백업 방식이 엔진마다 완전히 다릅니다 — SQLite는 파일 복사만으로 충분하지만 MariaDB는 mysqldump, PostgreSQL은 pg_dump 같은 전용 도구가 필요합니다.

이번 강좌에서

복구본의 무결성과 기준값을 SQL로 대조합니다.

결과 행 수와 경계값을 직접 검증합니다.

처음에 자주 헷갈리는 부분

합계만 같아도 서로 다른 행이 누락·중복될 수 있으므로 행 수, key 범위, 업무 집계와 표본 checksum을 함께 비교합니다.

직접 바꿔보세요복구본에서 주문 하나를 지운 뒤 validation_status가 FAIL로 바뀌는지 확인하세요.

CREATE TABLE backup_manifest (
  table_name TEXT PRIMARY KEY,
  expected_rows INTEGER,
  expected_max_id INTEGER,
  expected_paid_amount INTEGER
);

INSERT INTO
  backup_manifest
VALUES
  ('orders', 3, 3, 30000);

-- 별도 환경에 복구된 테이블이라고 가정합니다.
CREATE TABLE restored_orders (
  id INTEGER PRIMARY KEY,
  amount INTEGER,
  status TEXT
);

INSERT INTO
  restored_orders
VALUES
  (1, 10000, 'paid'),
  (2, 20000, 'paid'),
  (3, 5000, 'cancelled');

PRAGMA integrity_check;

WITH
  actual AS (
    SELECT
      COUNT(*) AS row_count,
      MAX(id) AS max_id,
      SUM(
        CASE
          WHEN status = 'paid' THEN amount
          ELSE 0
        END
      ) AS paid_amount
    FROM
      restored_orders
  )
SELECT
  manifest.table_name,
  manifest.expected_rows,
  actual.row_count AS restored_rows,
  manifest.expected_paid_amount,
  actual.paid_amount AS restored_paid_amount,
  CASE
    WHEN manifest.expected_rows = actual.row_count
    AND manifest.expected_max_id = actual.max_id
    AND manifest.expected_paid_amount = actual.paid_amount THEN 'PASS'
    ELSE 'FAIL'
  END AS validation_status
FROM
  backup_manifest manifest
  CROSS JOIN actual;

실행 결과브라우저 SQLite WebAssembly

실행 버튼을 누르면 결과가 여기에 표시됩니다.