JSONL 的格式是每行一個 JSON 物件。作為匯出格式，核心優勢是工具鏈成熟 — grep 過濾、jq 結構化查詢、tail -f 即時監控，不需要 database client。

一天一檔

事件按日期分檔：events-2026-06-19.jsonl、events-2026-06-20.jsonl。每天零點（或 UTC 日期變更時）切換到新檔案。

一天一檔的好處：

時間範圍查詢直接對應到檔案。查「昨天的 error」只需要讀一個檔案，不需要掃描整個資料集。

保留策略按檔案操作。保留 30 天的資料 = 刪除 30 天前的檔案。不需要 database 的 TTL 機制或 partition pruning。

備份和搬移按檔案操作。rsync 一個目錄就完成備份；搬移特定日期的資料 = 搬移對應檔案。

一天一檔的風險是單日資料量過大時，單一檔案的 grep 查詢會變慢。自用工具場景下，單日事件量通常在數千到數萬筆，檔案大小在 MB 級，grep 查詢在秒級完成。當單日事件量超過百萬筆時，需要考慮演進到更適合的儲存方案（見 規模演進）。

Append-only 寫入

JSONL 的寫入模式是 append-only — 新事件追加到檔案尾端，已寫入的事件不修改。

Append-only 的操作特性：

寫入不需要鎖。os.OpenFile 用 O_APPEND flag 開啟，OS 保證每次 write 是 atomic 的（在 write size 不超過 PIPE_BUF 的前提下，Linux 上是 4096 bytes）。單一事件的 JSON 通常在這個限制內。

不會損壞既有資料。寫入失敗（磁碟滿、程序崩潰）最多造成最後一行不完整，不影響前面的行。恢復時刪除最後一行的不完整片段即可。

支援 tail -f 即時監控。tail -f events-2026-06-19.jsonl | jq . 即時顯示新寫入的事件，不需要額外的 streaming 機制。

Gzip 壓縮

歷史檔案（非當天的）用 gzip 壓縮。JSON 文字的壓縮率通常在 80-90%（10MB 壓縮到 1-2MB）。

壓縮策略：

當天的檔案不壓縮。保持 append-only 和 tail -f 的能力。

日期切換時壓縮前一天的檔案。用 cron job 或 collector 啟動時檢查，把 events-2026-06-18.jsonl 壓縮為 events-2026-06-18.jsonl.gz。

查詢壓縮檔用 zgrep / zcat。zgrep "error" events-2026-06-18.jsonl.gz 不需要先解壓。

JSONL 備份的保留

JSONL 備份檔的保留策略和 SQLite 主要儲存的分層保留獨立 — JSONL 是最後的重建來源，保留期限可以比 SQLite 中的原始事件更長。

典型配置：JSONL 備份保留 30 天（即使 SQLite 中的原始事件只保留 7 天），提供 SQLite 損壞時的 30 天重建窗口。超過 30 天的 JSONL 壓縮檔用 cron job 清理：

1find /var/lib/collector/events/ -name "events-*.jsonl.gz" -mtime +30 -delete

主要儲存的查詢驅動分層保留策略見 規模演進。

匯出的實作注意

匯出使用 streaming — 從 storage 逐筆讀取、逐行寫出，記憶體使用和事件總量無關。300 萬筆事件（約 900MB JSONL）不需要整批載入記憶體。

匯出的 JSONL 檔案包含事件明文（已 redaction 的欄位除外）。匯出後的檔案不受 collector 的存取控制保護，注意存放位置和存取權限。

下一步路由

• Collector 的完整架構 → Collector 架構
• 查詢設計 → 查詢 API 設計
• 儲存撐不住時的演進 → 規模演進

本篇是無 SSH 的 FTP / 面板管理環境接管的延伸，聚焦在資料庫層面。程式碼與部署紀律見主文。

phpMyAdmin 的限制與對策

phpMyAdmin 是多數無 SSH 環境預裝的資料庫管理介面，匯出功能涵蓋完整 SQL dump，但它跑在 PHP 執行環境裡，受限於 max_execution_time 和記憶體上限。資料庫超過 50MB 時，匯出經常在執行到一半就因 timeout 中斷，產出不完整的 SQL 檔案——而不完整的 dump 在還原時只會匯入前半段的表、後面的表靜靜消失。

大資料庫的匯出對策

第一個選項是分表匯出。phpMyAdmin 的匯出頁面允許選擇要匯出的資料表，把一次完整匯出拆成 3-5 批，每批在 timeout 之前完成。缺點是匯出不是原子操作——不同批次之間如果有寫入，表之間的參照關係可能不一致（例如訂單表引用的商品 ID 在商品表的那一批裡還沒匯出）。對多數讀取為主的站台，這個不一致窗口可接受；對交易密集的站台，需要在低流量時段操作。

第二個選項是調整 phpMyAdmin 的 timeout。部分主機允許在 phpMyAdmin 的設定目錄放自訂的 config.inc.php：

1$cfg['ExecTimeLimit'] = 600; // 從預設 300 秒增加到 600 秒

cPanel 主機通常在「軟體」區塊的 phpMyAdmin 設定裡有對應的 UI 選項。Plesk 的路徑是「資料庫」→「phpMyAdmin 設定」。能不能改取決於主機商的權限政策，改之前先確認。

第三個選項是繞過 phpMyAdmin。如果主機允許遠端 MySQL 連線（在 cPanel 的「遠端 MySQL」頁面加白名單 IP），就能用桌面工具直連資料庫匯出：

桌面工具直連 MySQL 比 phpMyAdmin 穩定，因為匯出跑在本機、不受主機的 PHP timeout 限制。mysqldump 是最可靠的選項：

1mysqldump -h db-host.example.com -u dbuser -p \
2  --single-transaction --routines --triggers \
3  dbname > backup_$(date +%Y%m%d_%H%M).sql

--single-transaction 對 InnoDB 表做一致性快照，不需要鎖表。--routines 和 --triggers 確保 stored procedure 和觸發器也被包含在 dump 裡——phpMyAdmin 匯出預設也包含，但容易在手動選項時漏勾。

匯出後的驗證

匯出完成後檢查 SQL 檔案的結尾。完整的 mysqldump 結尾會有 -- Dump completed on YYYY-MM-DD HH:MM:SS。phpMyAdmin 匯出的結尾會有 -- phpMyAdmin SQL Dump 的對應結尾標記。如果檔案在某個 INSERT INTO 語句中間斷掉，這份 dump 就是不完整的，還原時會靜靜丟失後面的資料。

1tail -5 backup_20260626_1430.sql
2# 預期看到 "Dump completed" 或完整的結尾註解

備份策略：頻率與保留

備份頻率由資料的變更速率決定。一個每天只有幾筆訂單的小型電商，每週備份加上每次變更前備份就夠用。一個每天有數百筆交易的服務，需要每日備份。判斷依據是：如果最新的備份丟了、要用上一份還原，能接受丟失多少資料？這個時間差就是實際的 RPO（Recovery Point Objective）。

保留策略

命名用時間戳避免覆蓋：dbname_20260626_1430.sql.gz。壓縮用 gzip（gzip backup.sql），50MB 的 SQL dump 通常壓到 5-10MB。

儲存位置

本機是第一份副本，但本機磁碟故障時備份也跟著消失。至少再推一份到雲端儲存：

1# rclone 同步到 Google Drive（事先用 rclone config 設定 remote）
2rclone copy /local/backups/db/ gdrive:project-backups/db/ --max-age 7d
3
4# 或推到 S3
5aws s3 sync /local/backups/db/ s3://my-project-backups/db/ --storage-class STANDARD_IA

備份驗證

備份存在不等於備份可用。每月至少做一次驗證：把最新的 dump 匯入本地 MySQL，檢查關鍵表的 row count 跟 prod 一致、應用程式能正常啟動。如果匯入報錯或 row count 差異超過預期，備份流程有問題要立刻排查。

1mysql -u root -p local_testdb < backup_20260626_1430.sql
2mysql -u root -p -e "SELECT COUNT(*) FROM orders;" local_testdb

自動化備份（無 SSH 環境的限制下）

無 SSH 環境的自動化受限程度取決於主機提供的能力。三個層級由好到差：

主機有 cron + mysqldump 路徑：部分主機在 cPanel 的「cron 工作」裡允許設定排程指令。mysqldump 通常安裝在 /usr/bin/mysqldump，可以直接用：

1# cPanel cron job（每天凌晨 3 點）
20 3 * * * /usr/bin/mysqldump -u dbuser -p'password' dbname | gzip > /home/user/backups/db_$(date +\%Y\%m\%d).sql.gz

密碼寫在 cron 指令裡不理想但在無 SSH 環境選擇有限。用 .my.cnf 檔案存密碼（chmod 600）較安全，但不是所有主機都支援。

主機有遠端 MySQL 但沒 cron：用本機排程（macOS launchd / Windows Task Scheduler / Linux cron）跑 mysqldump 遠端連線：

 1#!/bin/bash
 2# local-backup.sh — 本機排程每天跑
 3BACKUP_DIR="$HOME/backups/myproject/db"
 4mkdir -p "$BACKUP_DIR"
 5mysqldump -h db-host.example.com -u dbuser -p'password' \
 6  --single-transaction dbname \
 7  | gzip > "$BACKUP_DIR/db_$(date +%Y%m%d_%H%M).sql.gz"
 8
 9# 推到雲端
10rclone copy "$BACKUP_DIR" gdrive:project-backups/db/ --max-age 7d
11
12# 清理超過 30 天的本地備份
13find "$BACKUP_DIR" -name "*.sql.gz" -mtime +30 -delete

沒有 cron 也沒有遠端 MySQL：只能靠手動的 phpMyAdmin 匯出，加上 cPanel 的「備份精靈」（如果主機方案包含）。cPanel 備份精靈可以設定每日或每週的完整備份（含資料庫 + 檔案），但免費方案通常不支援排程。這是最受限的情境——如果連手動匯出都嫌麻煩，最高優先的升級路徑是開通遠端 MySQL 存取。

資料庫變更的 migration 紀律

Schema 變更（加欄位、改索引、拆表）在沒有 migration 工具的 legacy PHP 專案裡，全靠手動在 phpMyAdmin 執行 SQL。migration 紀律的目標是讓每一次 schema 變更有紀錄、可重播、可回退。

Migration 檔案格式

每次 schema 變更寫成一個獨立的 SQL 檔案，存在 repo 的 migrations/ 目錄：

 1-- migrations/2026-06-26-001-add-users-email-verified.sql
 2-- 目的：新增 email 驗證欄位，支援 email 驗證流程
 3-- 回退：ALTER TABLE users DROP COLUMN email_verified;
 4
 5-- UP
 6ALTER TABLE users ADD COLUMN email_verified TINYINT(1) NOT NULL DEFAULT 0 AFTER email;
 7CREATE INDEX idx_users_email_verified ON users (email_verified);
 8
 9-- DOWN（回退用，不自動執行）
10-- DROP INDEX idx_users_email_verified ON users;
11-- ALTER TABLE users DROP COLUMN email_verified;

檔名的結構是 日期-序號-描述，序號處理同一天多次變更的排序。UP 段是要執行的 SQL，DOWN 段是回退 SQL（註解掉，手動需要時才用）。

追蹤哪些 migration 已執行

在資料庫建一張追蹤表：

1CREATE TABLE IF NOT EXISTS migrations_log (
2    id INT AUTO_INCREMENT PRIMARY KEY,
3    filename VARCHAR(255) NOT NULL,
4    applied_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
5    applied_by VARCHAR(100)
6);

每次在 prod 執行完一個 migration，手動插入一筆紀錄：

1INSERT INTO migrations_log (filename, applied_by) VALUES ('2026-06-26-001-add-users-email-verified.sql', 'alice');

查哪些 migration 還沒跑：比對 migrations/ 目錄的檔案清單跟 migrations_log 表的 filename 欄。這不是自動化的 migration runner（像 Laravel 的 artisan migrate），但在沒有框架支援的 legacy 專案裡，一張表加一個目錄就能達到可追蹤的最低標準。

執行流程

高風險的 migration（改大表結構、刪欄位、改資料類型）在步驟 2 要做完整的資料庫 dump 而非只備份受影響的表，因為外鍵和觸發器可能讓影響範圍超出目標表。

還原演練

備份的價值在還原成功的那一刻才被驗證。沒有演練過的備份等同於不存在——匯出可能不完整、SQL 版本可能不相容、匯入順序可能因為外鍵而失敗。

演練流程

在本地用最新的備份還原一次完整的資料庫：

1# 建一個測試用的空資料庫
2mysql -u root -p -e "CREATE DATABASE restore_test;"
3
4# 匯入備份
5mysql -u root -p restore_test < backup_20260626_1430.sql
6
7# 驗證
8mysql -u root -p -e "SHOW TABLES;" restore_test
9mysql -u root -p -e "SELECT COUNT(*) FROM orders;" restore_test

驗證三件事：表結構完整（SHOW TABLES 的表數量跟 prod 一致）、資料完整（關鍵表的 row count 一致）、應用程式能跑（把本地應用指向 restore_test 資料庫、打開首頁和幾個關鍵流程）。

還原時間的量測

記錄從開始匯入到驗證完成的時間。這個數字就是事故時的最快恢復時間。如果一個 500MB 的資料庫匯入需要 40 分鐘，加上排查原因和決策的時間，實際恢復可能超過一小時。知道這個數字，才能在事故時給管理層一個實際的時間預期。

無 SSH 環境沒有 PITR

無 SSH 的主機環境的 MySQL 通常不提供 binlog 層級的 point-in-time recovery。能還原到的最近時間點就是最新備份的時間點——備份是每天凌晨做的、下午三點出事，那就是丟失當天的所有寫入。這是備份頻率需要跟資料變更速率對齊的根本原因。交易密集的站台如果無法接受一天的資料丟失，升級到有 binlog / PITR 的環境（VPS 或 managed MySQL）是必要的投資。

大資料庫的特殊處理

資料庫超過 500MB 時，備份和還原的操作時間和失敗風險都會上升。需要針對大表做特殊處理。

超過 1GB 的單表通常是 log 表、歷史紀錄表、或含有二進位大物件（BLOB）的表。對這類表的備份策略跟業務表不同：

• log / 歷史表：備份時可以加 --where="created_at > DATE_SUB(NOW(), INTERVAL 90 DAY)" 只匯出近期資料，歷史資料另做一次性歸檔
• BLOB 欄位（圖片、PDF）：用 --no-data 單獨匯出 schema，BLOB 內容如果已經搬到檔案系統或 CDN，資料庫裡只需要保留路徑參考
• InnoDB 大表：--single-transaction 避免鎖表，但匯出期間的記憶體消耗跟表大小成正比，本機如果記憶體不足可以加 --quick（逐行讀取、不緩衝整張表）

1# 大表匯出：逐行讀取 + 一致性快照 + 壓縮
2mysqldump -h db-host.example.com -u dbuser -p \
3  --single-transaction --quick \
4  dbname large_table | gzip > large_table_$(date +%Y%m%d).sql.gz

資料庫規模成長到備份時間超過維護視窗（例如匯出要兩小時但只有一小時的低流量時段），代表這類環境的備份能力已經到頂，需要評估升級到有 automated snapshot 的 managed MySQL 或 VPS。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：主文，涵蓋程式碼備份、部署紀律與整體接管流程
• → 程式碼版控與 FTP 部署紀律：DB migration 跟 code deploy 要同步——schema 改了但 code 沒跟上會讓服務壞掉
• → Legacy PHP 的安全盤點：DB credential 的掃描與保護、SQL injection 風險評估
• → Stateful 資源保護與跨服務依賴：IaC 環境裡的備份、deletion protection 與 PITR 設計
• → 治理好習慣：tagging、secret 管理與成本可見性的長期治理

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 backup + PITR — 不是「拷貝資料」、是「N 點任意 restore 的能力」。

「我們每天 mysqldump 一次、放 S3、沒問題吧」是個常見錯誤。問「能不能 restore 到 5 分鐘前」、答案會是 不能。Dump-based backup 只能 restore 到 dump 那個瞬間、5 分鐘前的事故無法 recover、必須等下次 dump。

真正的 backup strategy 是 PITR（point-in-time recovery）：

• 能 restore 到任意過去時間點（RPO 取決於 binlog flush 頻率、可接近 0）
• 由 full backup 基線 + binlog 連續流（從 backup 點到目標時間點的 incremental delta）組成
• Restore 過程：先 restore full backup → 再 apply binlog 到目標 timestamp 或 GTID

這篇 deep article 把 backup 拆解成能力、然後展開達到此能力需要的工具鏈跟工程紀律。

Backup 三層責任

PITR 的 能力 由三層工程責任達成、任一層失效則 PITR 不成立：

1Layer 1: Full Backup（基線）
2   ↓     (mysqldump / XtraBackup / MyDumper / LVM snapshot / EBS snapshot)
3   ↓
4Layer 2: Binlog Stream（incremental）
5   ↓     (sync_binlog=1 + binlog 持續流到 backup storage)
6   ↓
7Layer 3: Restore + Replay 流程
8         (能 restore full + 能 apply binlog 到目標時間點)

每層的 backup 不夠 — 必須有 測試 restore 流程 才算真的有 backup。「dump 在 S3」加「沒有 verified restore」= no backup。

Tool 1：mysqldump — 邏輯備份、最廣容、最慢

1mysqldump --single-transaction --master-data=2 --gtid-purged=ON \
2  --triggers --routines --events \
3  --all-databases > full-backup.sql

輸出：SQL statement、純文字、可 grep / 編輯。

Trade-off：

• 優點：跨 MySQL 版本（5.7 → 8.0 也讀）、跨 cloud / 跨 OS、可選 dump 部分 table
• 缺點：極慢（rebuild 整 DB 從 SQL execute）、大 DB（> 100 GB）不適用、restore 時長 hours+
• --single-transaction：InnoDB only、用 REPEATABLE READ 拿 consistent snapshot、不 lock 表

適合：

• < 100 GB DB
• Schema dump（migration / 給 dev clone DB）
• 跨版本 migrate
• 配 binlog 做 PITR baseline

不適合：

• 500 GB DB（restore 跑 days）

• 高吞吐 production（dump 跑時 hold MVCC read view、bloat）

Tool 2：Percona XtraBackup — 物理備份、快、production 標準

1xtrabackup --backup --target-dir=/backup/full-2026-05-19 \
2  --user=backup --password=... \
3  --slave-info --safe-slave-backup
4# Prepare（apply 內部 redo log、變成可 restore 狀態）
5xtrabackup --prepare --target-dir=/backup/full-2026-05-19

輸出：InnoDB 資料檔案的 binary copy。

Trade-off：

• 優點：極快（直接 copy file、無 SQL execute）、適合 TB-scale DB、restore 跑時間跟 copy file 同
• 缺點：MySQL 版本綁定（XtraBackup 8.0 不能 restore 5.7 backup）、有 storage engine 限制（只 InnoDB）
• Incremental backup 支援：基於 LSN（log sequence number）只 copy 變更 page

Incremental flow：

 1# Day 1: Full backup
 2xtrabackup --backup --target-dir=/backup/full-day1
 3
 4# Day 2: Incremental（only changes since day 1）
 5xtrabackup --backup --target-dir=/backup/inc-day2 \
 6  --incremental-basedir=/backup/full-day1
 7
 8# Restore: Apply incremental on top of full
 9xtrabackup --prepare --apply-log-only --target-dir=/backup/full-day1
10xtrabackup --prepare --apply-log-only --target-dir=/backup/full-day1 \
11  --incremental-dir=/backup/inc-day2
12xtrabackup --prepare --target-dir=/backup/full-day1

適合：

• 100 GB production DB

• 每日 incremental + 週一次 full（典型 enterprise schedule）
• 從自管 MySQL 遷 cloud（XtraBackup + rsync 到 cloud restore）

不適合：

• Schema-only dump（用 mysqldump 更簡單）
• 跨 major version restore

Tool 3：MyDumper — 並行邏輯備份

1mydumper --user=backup --password=... \
2  --threads=8 --rows=100000 \
3  --outputdir=/backup/mydumper-2026-05-19 \
4  --less-locking

輸出：每張 table 一個 .sql file（schema） + 多個 chunked .dat file（資料）。

Trade-off：

• 優點：並行 dump（per-table thread）、比 mysqldump 快 5-10x、可恢復斷點（resume）
• 缺點：tooling 不如 mysqldump 普及、需要單獨裝
• 對應的 myloader restore：也並行、比 mysqldump restore 快 5-10x

適合：

• 100 GB - 1 TB 範圍
• 中型 production、想要邏輯備份的可讀性 + 並行加速

Tool 4：LVM / EBS Snapshot — 物理 file system 層

1# 1. Freeze MySQL（讓 write 暫停）
2mysql> FLUSH TABLES WITH READ LOCK;
3# 2. Trigger snapshot（EBS / LVM）
4aws ec2 create-snapshot --volume-id vol-xxx --description "mysql-2026-05-19"
5# 3. Unfreeze
6mysql> UNLOCK TABLES;

Trade-off：

• 優點：超快（file system 層）、適合 VM-based MySQL（EC2 / on-prem）
• 缺點：必須 暫停 write（短時間 lock）、不能跨 OS / cloud 移植
• AWS RDS / Aurora 全部走這條路（自動 snapshot）

適合：

• AWS RDS / Aurora（自動）
• 自管 MySQL on EC2 with EBS（EBS snapshot 結合 mysql freeze）
• 大 DB 想要 fast backup + fast restore

Binlog-based PITR

Full backup 加上 binlog 才能達到 PITR。Binlog 是 MySQL replication / CDC / PITR 共用的 source。

配置：

1[mysqld]
2log_bin = mysql-bin
3binlog_format = ROW                  # ROW 必須
4binlog_row_image = FULL              # 完整 row image
5sync_binlog = 1                      # 每次 commit fsync binlog（zero loss）
6binlog_expire_logs_seconds = 1209600 # 14 天 retention（依需求調）
7gtid_mode = ON                       # GTID 必須、PITR 用 GTID 識別 transaction
8enforce_gtid_consistency = ON

Binlog backup：

1# 持續 stream binlog 到 backup storage
2mysqlbinlog --read-from-remote-server --raw --stop-never \
3  --user=replication --password=... \
4  --host=primary.example.com \
5  --result-file=/backup/binlog/ mysql-bin.000001 &

--read-from-remote-server + --stop-never 持續從 primary tail binlog、不間斷 stream 到 backup directory。每個 binlog file 寫滿後 close + 開新 file。

Restore + PITR 流程

完整 PITR 流程（restore 到 2026-05-19 14:30:00）：

 1# Step 1: Restore full backup
 2xtrabackup --copy-back --target-dir=/backup/full-2026-05-18  # 前一天 full
 3
 4# Step 2: 啟動 MySQL（會看到 backup 拿那刻的 GTID set）
 5systemctl start mysqld
 6
 7# Step 3: 查 full backup 結束時的 GTID
 8mysql> SHOW MASTER STATUS;
 9+------------------+----------+------------------------------------------+
10| File             | Position | Executed_Gtid_Set                        |
11+------------------+----------+------------------------------------------+
12| mysql-bin.000150 |     1234 | server-uuid:1-12345                      |
13+------------------+----------+------------------------------------------+
14
15# Step 4: Apply binlog 從 backup 之後到目標時間
16mysqlbinlog --start-datetime="2026-05-18 03:00:00" \
17            --stop-datetime="2026-05-19 14:30:00" \
18            /backup/binlog/mysql-bin.000150 \
19            /backup/binlog/mysql-bin.000151 \
20            ...                                # 列所有需要的 binlog
21            | mysql -u root -p
22
23# Step 5: 驗證 GTID set 到目標時間點對應的位置
24mysql> SHOW MASTER STATUS;
25# Executed_Gtid_Set 應包含到目標時間點的 transaction

對 精確 GTID-based PITR（停在特定 transaction、不是 timestamp）：

1mysqlbinlog --include-gtids='server-uuid:1-50000' \
2            /backup/binlog/mysql-bin.000150 ... | mysql -u root -p

5 個 Production 踩雷

1. GTID 處理不一致 — Restore 後 replication broken

XtraBackup restore 時 --slave-info 紀錄 GTID purged set、mysqldump 用 --gtid-purged=ON。如果 restore 後沒正確 set gtid_purged、replica re-attach 時 GTID gap error。

修法：

• XtraBackup restore：用 xtrabackup_binlog_info 內的 GTID set 設 SET GLOBAL gtid_purged='...';
• mysqldump：dump file 內已有 SET @@GLOBAL.GTID_PURGED='...';、執行 dump 自動 set
• Restore 後 先驗證 Executed_Gtid_Set 跟 source 預期對齊、再 START SLAVE

2. Binlog gap — 中間遺漏 file 直接 restore fail

Binlog stream 失聯（network blip / disk full）+ binlog rotate、mysql-bin.000156 不在 backup storage 內。PITR 試圖跨過該 file restore、跳過已 commit transaction、結果 資料不一致（不是錯誤、是 silently incorrect）。

修法：

• Binlog stream 必須持續、失聯 → alert
• 監控 backup storage 內 binlog 連續性（file name 連號、無 gap）
• Restore 前 先驗證 binlog 完整性：mysqlbinlog --verify-binlog-checksum *.bin > /dev/null
• 對 missing binlog 中止 PITR、不繼續 partial restore

3. Backup 沒 verify — 真事故時才發現 restore broken

每天備份成功、storage 用了 5 TB、實際 從未 restore 過。事故發生 restore 才知道 backup file corrupt / GTID 錯 / binlog gap、整套無用。

修法：

• 自動化 restore test：每週 / 每月在 staging server 跑完整 restore + PITR、跑完 SELECT 比對 production
• 驗證 restore 後 row count 跟 production 接近、CHECKSUM TABLE 比對主要 table
• 真的事故時 RTO 才不會 surprise

4. RPO 不到 1 分鐘的代價

「我要 RPO < 1 分鐘」聽起來合理、但實現需要：

• sync_binlog=1（每 commit fsync、寫吞吐降 10-30%）
• Binlog stream 到 獨立 storage（不只是 primary local disk）、cross-region replication（額外 network cost）
• Replica 也用 semi-sync 配合（zero binlog loss）
• 監控 + alert RPO 違反（< 1 分鐘 stream lag）

TCO：~30% 寫吞吐 penalty + 額外 storage / network cost + 7x24 on-call。考慮 real RPO requirement — 多數 application 5 分鐘 RPO 已足夠、追求 1 分鐘 RPO 不划算。

修法：

• 跟 product / business 確認 真 RPO 要求
• RPO budget = 寫吞吐 trade-off + ops cost、不是 free
• 用 Aurora / managed offering 把 RPO 議題 outsource（Aurora < 1 秒 RPO + 自動 cross-AZ）

5. Encryption key 沒備份 — Restore 後解不開資料

啟用 encryption at rest（MySQL 8.0+ default_table_encryption=ON + keyring plugin / component；MariaDB 用 innodb_encrypt_tables）後、所有 InnoDB tablespace 都加密。Master key 在 keyring file 或 KMS-backed component。如果 backup 只 backup MySQL data file、沒備 keyring、restore 後資料 encrypted 但無 key、無法讀。

修法：

• Keyring file 跟 data file 分開儲存、但兩者 都要 backup
• 用 KMS-based keyring（AWS KMS / HashiCorp Vault）取代 file-based、key 不在 MySQL server 上
• Disaster recovery runbook 紀錄 key recovery 流程、不要假設「重 install MySQL」就能解

容量規劃要點

跟其他模組整合

跟 Replication topology

Replication replica 不能取代 backup — replica 上的 DROP TABLE 也會被 replicate、replica 上資料同樣消失。Backup 是 獨立保險。詳見 Replication Topology。

跟 InnoDB Tuning

innodb_flush_log_at_trx_commit=1 + sync_binlog=1 是 backup-friendly 的設定（zero loss）、但寫吞吐降。如果為了寫吞吐放寬 durability、必須接受 PITR window 也 widening。詳見 InnoDB Tuning。

跟 Aurora MySQL

Aurora 完全 outsource backup — automatic continuous backup + PITR < 1 秒、不必管 mysqldump / XtraBackup / binlog stream。從 Aurora 遷出時、需要重新建 self-managed backup chain。詳見 migrate-to-aurora。

跟 PostgreSQL PITR

兩家 PITR 概念類似（full + log replay）、tool name 不同、概念對等。詳見 PostgreSQL PITR + WAL Archiving。

何時 outsource backup

相關連結

• MySQL vendor overview
• MySQL Replication Topology（binlog 跟 PITR 共用 source）
• MySQL InnoDB Tuning（durability + backup 互動）
• migrate-to-aurora（backup outsource）
• PostgreSQL PITR + WAL Archiving（PG sibling）
• 官方：Percona XtraBackup / MyDumper / mysqldump

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 backup / recovery 是 OLTP 必備能力、本文聚焦 PITR（Point-In-Time Recovery）的雙軌資料設計 + production 5 個 failure mode。

問題情境

Logical bug 在 production 部署、執行 6 小時後才發現 — 某個 batch job 把 50 萬筆 user.email 改成 NULL。此時：

• 還原最新 daily backup（昨晚）→ 丟掉今天所有正常寫入（訂單、註冊）
• 從 standby promote → standby 已同步 bug、跟 primary 同狀態
• 從 application log 重建 → 部分操作不可逆（已寄出 email）

PITR 是這類 logical disaster 的標準解 — 不還原到 backup 時間點、而是 還原到 bug 發生前一刻（例：1 分鐘前）。需要 base backup + WAL archive 雙軌資料：base backup 是 snapshot、WAL archive 是 snapshot 之後的所有寫入；recovery 時 replay WAL 到指定 timestamp / LSN / transaction ID。

核心概念：base backup + WAL archive 的雙軌設計

1[Base backup t0]  +  [WAL archive t0 → now]
2     ↓                       ↓
3  全量 snapshot          incremental log
4     ↓                       ↓
5     └────── recover to t_target ──→ [restored cluster at t_target]

兩個軌道各自獨立但必須對齊：

1. Base backup：某時刻整個 data dir 的 snapshot。pg_basebackup / pgBackRest / WAL-G 都產這個；通常 每天 / 每週 跑一次
2. WAL archive：base backup 之後每段 WAL 都 push 到外部 storage（S3 / GCS / NFS）。archive_command 觸發、PostgreSQL 等到 archive 成功才 回收 那段 WAL

兩者組合決定 RPO（recovery point objective）：

• RPO ≈ WAL archive frequency（streaming 即時、archive_timeout 預設 1 分鐘）
• RPO 不是 base backup frequency — daily base backup + 每分鐘 archive WAL → RPO 1 分鐘

RTO（recovery time objective）跟 base backup size + WAL replay 量 相關：

• Restore base backup ~ 1-4 小時（TB 級）
• WAL replay 時間 ~ archive 累積量 / replay throughput

Step-by-step 配置

Primary：archive_command 設好

1# postgresql.conf
2wal_level = replica                          # 預設 replica、PITR 需要
3archive_mode = on                            # 啟用 archive
4archive_command = 'wal-g wal-push %p'        # 或 pgBackRest / 自寫 script
5archive_timeout = 60                         # 60s 無 WAL 時強制切 segment
6max_wal_size = 4GB
7checkpoint_timeout = 15min

archive_command 必須 回 exit code 0 才算成功；非 0 PostgreSQL retry、retry 失敗會在 pg_wal 堆積 WAL 直到 disk 滿。critical：archive_command 不能寫成 silent-fail。

用 pgBackRest 取代手寫 script

production 強烈不建議自寫 archive script — pgBackRest / WAL-G / Barman 處理過所有 edge case：

 1# pgbackrest.conf
 2[global]
 3repo1-type=s3
 4repo1-s3-bucket=mybucket
 5repo1-s3-region=us-east-1
 6repo1-retention-full=4                       # 留 4 個 full backup
 7repo1-retention-diff=8                       # 留 8 個 differential
 8repo1-cipher-type=aes-256-cbc                # encrypt at rest
 9process-max=8                                # parallel restore
10
11[main]
12pg1-path=/var/lib/postgresql/16/main

1# 跑 full backup
2pgbackrest --stanza=main backup --type=full
3
4# archive_command 用 pgbackrest 內建
5archive_command = 'pgbackrest --stanza=main archive-push %p'

pgBackRest 處理：parallel push、compression、encryption、checksum、archive replay timing、backup catalog、retention 自動清理。

Restore：recovery_target_time

1# 1. 從 S3 / repo 拉 base backup
2pgbackrest --stanza=main --type=time \
3  --target="2026-05-18 14:30:00+00" restore
4
5# 2. PostgreSQL 進 recovery mode、自動 replay WAL 到 target time
6# (pgBackRest 寫好 recovery.signal + postgresql.auto.conf)
7
8# 3. 確認到目標 timestamp 後、promote
9pg_ctl promote

Recovery target 三種：

• recovery_target_time：到某 timestamp
• recovery_target_xid：到某 transaction ID（log 有 xid 才好定位）
• recovery_target_lsn：到某 WAL LSN（最精確、但需要事先記下 LSN）

production 多用 timestamp、application log 有時間戳容易定位。

故障演練 / 邊界 case

Case 1：archive_command 靜默失敗

徵兆：DBA 發現某 PITR test 時、最近 3 天的 WAL 在 S3 上沒有；但 PostgreSQL 沒 alert、pg_wal 也沒堆積（早就被回收？）。

根因：archive_command 寫成 aws s3 cp %p s3://bucket/... 2>/dev/null — 錯誤訊息被吞、exit code 卻是 0（cp 失敗但 redirect 後 shell wrapper 不傳 fail code）；PostgreSQL 以為成功、繼續 advance WAL pointer、舊 WAL 已回收、archive 上實際沒有。

修法：

1. 絕對不要靜默 exit code：archive_command 必須 fail loud、exit code 非 0
2. 用 pgBackRest / WAL-G、不自寫 shell 腳本
3. monitoring：對 archive lag 寫 alert

1SELECT pg_last_archived_xact_time(), now() - pg_last_archived_xact_time() AS lag;

alert if lag > 5 minutes

4. 定期測試 restore：每月跑一次 PITR drill、實際從 archive restore + 驗證 timestamp

Case 2：WAL archive lag、primary disk 壓力

徵兆：pg_wal 目錄持續長大、df -h 90%+；pg_stat_archiver 顯示 failed_count 累積、last_failed_time 是 30 分鐘前；archive_command 寫不出去（S3 throttle / network 慢）。

根因：archive_command 寫到 S3、但 S3 rate limit / connection timeout、PostgreSQL retry；WAL 一直在 pg_wal 不能回收、disk 持續長。

修法：

1. 預防：archive_command 內部 retry + parallel push（pgBackRest 自帶 process-max）
2. alert：pg_stat_archiver.failed_count 增長 + primary disk usage > 80%
3. 緊急：暫時改 archive_command 寫 local NFS / 其他 storage、等 S3 恢復再同步；不要直接 disable archive（會丟資料）
4. 架構：archive storage 至少跨 region 兩份、單一 storage 故障不影響 archive

Case 3：recovery 跑到 wrong target time

徵兆：PITR 還原後資料看起來 缺一塊；DBA 後悔 — target time 設早了 30 分鐘、recovery 已 promote、後續 WAL 在新 timeline 上、回不去。

根因：recovery 過程不可逆 — 一旦 promote 開新 timeline、舊 WAL 在新 timeline 上不會被 replay；想還原到更晚 timestamp 必須 重新 restore base backup + WAL。

修法：

1. recovery_target_action = pause（PG 13+）：到 target time 後 暫停、不自動 promote；DBA 手動 query 確認資料對才 promote

1recovery_target_time = '2026-05-18 14:30:00+00'
2recovery_target_action = pause

2. 多次 PITR 試錯：用 獨立 staging cluster restore、驗證 target time 對、再對 production 跑
3. 記錄 target time 來源：application log / event timestamp 多比對、避免時區錯亂（+00 UTC 跟 local time 差）

Case 4：base backup 過期未清、storage 爆

徵兆：S3 backup bucket size 半年內從 200GB 漲到 5TB；DBA 才發現 retention 沒設、daily base backup 留 180 天。

根因：archive_command 自寫腳本沒 retention 邏輯、或 pgBackRest 設了 repo1-retention-full=180 漏看；DB 容量本來就成長 + 每日 full backup 累積。

修法：

1# pgBackRest retention：4 full + auto-expire archive
2repo1-retention-full=4                         # 留 4 個 full backup
3repo1-retention-diff=8                         # 留 8 個 differential
4repo1-retention-archive=4                      # WAL archive 跟 full 對齊
5repo1-retention-archive-type=full

storage budgeting：

• daily full + diff + WAL archive ≈ 1-2x DB size / day
• 4-week retention → ~30-60x DB size storage
• 跨 region replication → 2-3x

Case 5：timeline 分歧後 recovery 模糊

徵兆：production 經歷一次 failover（Patroni promote）+ 之後又 PITR 一次；現在要再 PITR 到 failover 前一刻、archive 上有兩個 timeline、recovery target 搞不清要哪個。

根因：每次 promote 開新 timeline ID（.history 檔）；archive storage 上同 LSN 可能對應不同 timeline；recovery target time 在分歧點附近、ambiguous。

修法：

1. recovery_target_timeline 明示要 follow 哪個 timeline

1recovery_target_time = '2026-05-15 10:00:00+00'
2recovery_target_timeline = '3'                 # 要 follow timeline 3

2. 熟悉 .history 檔：/wal_archive/000000XX.history 記錄 timeline 切換點、PITR 前先看
3. 預防：每次 promote 後 立刻 跑新的 base backup、簡化未來 PITR 流程（不用跨 timeline）

容量 / cost 規劃

實務 default：

• Daily full backup + 4 weeks retention
• WAL archive every 60s（archive_timeout = 60）
• 跨 region replication（S3 → S3 cross-region）
• 月度 restore drill 驗證可用

整合 / 下一步

跟 Patroni HA 整合

Patroni 不管 backup，但 promotion 後 timeline 切換影響 archive：

1. archive_command 用 %t（timeline）+ %f（filename）路徑、避免不同 timeline WAL 覆蓋
2. Patroni recovery_conf 包含 restore_command、standby clone 從 archive 拉
3. 每次 Patroni failover 後跑 full backup、簡化未來 PITR

跟 logical replication 對位

PITR 跟 logical replication 服務不同 use case：

• PITR 是 災難恢復（logical bug / corruption）— 全量還原到某時刻
• Logical replication 是 連續 sync — Kafka / 跨 DB 即時複製

兩者 都依賴 WAL、但目標不同；同 PostgreSQL 可同時跑、互不衝突。

跟 monitoring + alert

關鍵 metric：

1-- archive 健康度
2SELECT * FROM pg_stat_archiver;
3-- archived_count, failed_count, last_archived_wal, last_archived_time
4
5-- WAL 在 pg_wal 等待 archive 量
6SELECT count(*) FROM pg_ls_waldir() WHERE name ~ '^[0-9A-F]{24}$';
7
8-- base backup 上次跑時間
9-- (pgBackRest API 或 backup catalog)

Prometheus alert 三條：archive failed_count 增、archive lag > 5min、base backup > 25h 沒跑。

下一步議題

• Incremental backup（PG 17+）：base backup 不全量、只 base + incremental
• Block-level differential：pgBackRest 已支援
• Cloud-native 替代：RDS / Aurora 用 storage-layer snapshot、不走 PITR 鏈
• pg_dump vs PITR：pg_dump 是 logical backup（resume to different schema OK）、PITR 是 physical（必須同 version + same arch）

相關連結

• 上游 vendor 頁：PostgreSQL
• 上游 chapter：Database Migration Playbook — PITR 是 migration 的失敗回退
• 平行 deep article：Patroni HA / Logical Replication + Debezium / autovacuum tuning
• Methodology：Vendor 深度技術文章的寫作方法論

概念位置

mysqldump 是有 SSH 存取（或 remote MySQL 存取）時的主要備份手段。比 phpMyAdmin 的匯出更可靠——不受 web server 的 timeout 和記憶體限制影響，可以處理數 GB 的資料庫。沒有 SSH 的環境只能退回 phpMyAdmin 匯出。

可觀察訊號

接手時如果 server 上有 cron job 在跑 mysqldump，代表前任有做自動備份——確認輸出的 dump 檔案存在哪、保留幾天、有沒有被驗證過能還原。如果沒有任何 mysqldump cron，代表備份可能只靠 phpMyAdmin 手動匯出或完全沒做。

設計責任

常用的 flag 組合：

1mysqldump -u user -p \
2  --single-transaction \
3  --routines \
4  --triggers \
5  dbname > dump-$(date +%Y%m%d).sql

還原指令：

1mysql -u user -p dbname < dump-20260626.sql

mysqldump 產出的是邏輯備份（SQL 語句），還原速度取決於資料量——幾百 MB 以內分鐘級，數 GB 可能要半小時以上。需要更快的備份/還原（物理備份），要用 Percona XtraBackup 或 MySQL Enterprise Backup。

鄰卡

• phpMyAdmin：無 SSH 時的替代備份手段
• cron：搭配 cron 做定期自動備份

本文的驗收標準是：你能產出 dump、記錄 binlog position、還原到隔離 database、跑 validation query，並寫下 RPO / RTO note。

Create Backup

Create backup 的核心責任是建立可還原 artifact。

1mkdir -p /tmp/mysql-backup-lab
2mysqldump -h 127.0.0.1 -P 33069 -u app_user -papp_pw \
3  --single-transaction --routines --triggers appdb \
4  > /tmp/mysql-backup-lab/appdb.sql

記錄 binlog 狀態：

1mysql -h 127.0.0.1 -P 33069 -u root -proot_pw -e "SHOW BINARY LOG STATUS;"

--single-transaction 適合 InnoDB consistent dump。大型 production 要評估 physical backup、backup lock、replication lag 與 binlog retention。

Mutate Source

Mutate source 的核心責任是讓 restore 時間點具體化。

1mysql -h 127.0.0.1 -P 33069 -u app_user -papp_pw appdb \
2  -e "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key) VALUES (1, 777, 'after-backup-write');"

Source 現在比 backup 多一筆。這能用來討論 RPO 與 binlog PITR。

Restore Isolated Database

Restore isolated database 的核心責任是避免覆蓋 source。

1mysql -h 127.0.0.1 -P 33069 -u root -proot_pw \
2  -e "DROP DATABASE IF EXISTS appdb_restore; CREATE DATABASE appdb_restore;"
3mysql -h 127.0.0.1 -P 33069 -u root -proot_pw appdb_restore \
4  < /tmp/mysql-backup-lab/appdb.sql

Validation：

1mysql -h 127.0.0.1 -P 33069 -u root -proot_pw appdb_restore <<'SQL'
2SELECT COUNT(*) FROM accounts;
3SELECT COUNT(*) FROM ledger_entries;
4SELECT a.owner_name, SUM(l.amount_cents) AS balance_cents
5FROM accounts a JOIN ledger_entries l ON l.account_id = a.id
6GROUP BY a.owner_name;
7SQL

Validation query 要和 application smoke test 對齊。正式 drill 還要啟動 app 指向 restore database。

RPO / RTO Note

RPO / RTO note 的核心責任是把演練結果轉成服務承諾。

完成本篇後，binlog CDC 讀 Binlog CDC；PITR 策略讀 PITR / Backup。

本文的驗收標準是：你能從 live app.db 建立 backup，將它還原到隔離路徑，通過 integrity_check 與核心查詢，並記錄 restore duration。

Prepare Source

Prepare source 的核心責任是建立一個有 WAL 與資料變化的 live database。若你已跑過 local file quickstart，可以直接沿用 /tmp/sqlite-lab/app.db。

1mkdir -p /tmp/sqlite-lab/backup /tmp/sqlite-lab/restore
2cd /tmp/sqlite-lab
3sqlite3 app.db "PRAGMA journal_mode = WAL;"
4sqlite3 app.db "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (2, 100, 'backup-drill-1', '2026-05-21T01:00:00Z');"

這一步讓 source database 有新的資料。後續會用 backup snapshot 和 source 後續寫入做對照。

Create Backup

Create backup 的核心責任是用 SQLite-aware 方法建立一致 snapshot。SQLite CLI .backup 會透過 SQLite backup API 產出目標檔案。

1sqlite3 app.db ".backup 'backup/app-backup.db'"
2sqlite3 backup/app-backup.db "PRAGMA integrity_check;"

預期 integrity_check 輸出 ok。這是最小 backup evidence。

VACUUM INTO 也可以產出 compact copy，適合想順便整理檔案大小的情境。

1sqlite3 app.db "VACUUM INTO 'backup/app-vacuum-copy.db';"
2sqlite3 backup/app-vacuum-copy.db "PRAGMA integrity_check;"

.backup 與 VACUUM INTO 都要在 runbook 中標明使用條件、耗時、目標路徑與失敗處理。正式環境還要記錄檔案大小、checksum 與 storage retention。

Mutate Source After Backup

Mutate source 的核心責任是確認 backup 是時間點 snapshot。備份後對 source 寫入新資料，再用 restore 驗證 backup 保持原時間點。

1sqlite3 app.db "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (1, 777, 'after-backup-write', '2026-05-21T01:05:00Z');"
2sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"
3sqlite3 backup/app-backup.db "SELECT COUNT(*) FROM ledger_entries;"

Source count 應比 backup count 多一筆。這個差異讓 RPO 討論具體化：backup 只保護到它建立的時間點。

Restore Isolated Copy

Restore isolated copy 的核心責任是避免把演練和 source 混在一起。把 backup 複製到 restore path，所有 validation 都對 restore file 執行。

 1cp backup/app-backup.db restore/app-restored.db
 2sqlite3 restore/app-restored.db "PRAGMA integrity_check;"
 3sqlite3 restore/app-restored.db <<'SQL'
 4.headers on
 5.mode column
 6SELECT account_id, SUM(amount_cents) AS balance_cents
 7FROM ledger_entries
 8GROUP BY account_id
 9ORDER BY account_id;
10SQL

正式 restore drill 還要啟動 application 指向 restore/app-restored.db，跑核心 read/write smoke test。若 application 需要 migration，也要確認 restore file 的 PRAGMA user_version 與 app version 相容。

RPO / RTO Note

RPO / RTO note 的核心責任是把演練結果轉成服務承諾。RPO 是可接受資料遺失窗口，RTO 是可接受恢復時間。

可以用 shell 的 time 記錄 restore duration。

1time sqlite3 restore/app-restored.db "PRAGMA integrity_check;"

正式服務要把 RPO / RTO 寫進 observability / runbook。

Known Gap

Known gap 的核心責任是讓 lab 結果誠實。這個 drill 驗證 SQLite-aware backup 與 restore path；它尚未覆蓋 object storage credential、remote retention、large database restore time、encrypted disk、user device support flow 與 legal retention。

完成本篇後，下一步可以進入 WAL busy reproduction 觀察 writer boundary，或進入 migration fixture lab 建立 schema change evidence。

本文是 SQLite overview 的 implementation-layer deep article。Overview 已說明 SQLite 適合 embedded、local-first、edge 與低操作成本場景；本文聚焦 SQLite 檔案生命週期 + backup / restore 邊界。

SQLite 的 file lifecycle 是把「一個資料庫檔案」升級成正式狀態的操作契約。SQLite 省掉 server process、帳號管理與網路連線，但它把 durability、backup、restore、locking 與 corruption recovery 放回 application process、filesystem 與 runbook；讀者要判斷的是這些責任是否已經有人承擔。

這篇文章適合三種情境。第一種是 CLI、desktop、mobile 或 edge service 已經用 SQLite 保存正式資料；第二種是 single-instance backend 想用 SQLite 降低操作成本；第三種是 test fixture 用 SQLite，但需要知道哪些差異會讓 production database 的 bug 漏掉。

核心模型：資料庫檔案是一組受 SQLite 管理的狀態檔

SQLite 的資料庫狀態由 main database file 與 journal / WAL sidecar 共同構成。Rollback journal mode 會在寫入期間產生 journal file；WAL mode 會讓寫入先進入 -wal 檔，並用 -shm 檔協調 reader / writer。操作上看似「一個 .db 檔」，production runbook 要把 sidecar file、checkpoint、backup API 與 restore test 一起納入。

這張表的讀法是先找「誰有權改檔案」。SQLite 的核心風險多半來自繞過 SQLite library 的檔案操作，例如直接 copy 活躍 WAL database、把 database 放在 lock 語意不可靠的 filesystem、或讓多個不協調的 process 同時寫同一份檔案。

WAL mode：讀取並發提升後，writer boundary 仍然存在

WAL mode 的工程價值是讓 reader 與 writer 的衝突下降。讀取可以看 main database 加上 WAL 中的 snapshot，寫入則 append 到 WAL；這讓 read-heavy workload 比 rollback journal mode 更容易撐住互動式服務。

WAL mode 同時保留 single writer boundary。SQLite 仍以檔案鎖與 transaction serialisation 控制寫入；寫入交易越長，其他 writer 等待時間越長，application 看到的訊號通常是 SQLITE_BUSY、latency spike 或 background job 卡住。

WAL mode 的 capacity gate 是「寫入是否仍能用一個 writer 排隊」。如果服務壓力來自大量並行寫入、多 instance active write 或跨 region 寫入，SQLite 的簡單性開始變成排隊與恢復成本；這時候要回到 PostgreSQL、MySQL 或 global distributed OLTP。

Backup boundary：複製檔案與取得一致 snapshot 是兩件事

SQLite backup 的核心責任是取得某一時間點的一致 snapshot。當 database live 且 WAL mode 開啟時，直接複製 .db 檔容易漏掉 -wal 中尚未 checkpoint 的寫入；即使同時複製 sidecar file，也要面對複製期間狀態變動的 race。正式服務應使用 SQLite 提供的 backup path 或可驗證的 filesystem snapshot。

Backup method 的選擇要先回到 RPO 與 RTO。如果產品可以接受每天一次快照，VACUUM INTO 或 scheduled backup 足夠；如果資料損失窗口要降到分鐘級或秒級，就要看 Litestream 類連續複製，或直接升級到 server database 的 PITR / replica 模型。

Restore drill：SQLite production readiness 看還原，不只看備份成功

Restore drill 的責任是證明備份能在事故時接回服務。SQLite 的備份檔通常只有一個 target file，表面上比 PostgreSQL PITR 或 MySQL binlog recovery 簡單；真正的風險在 application binary、schema migration version、file permission、deployment path 與舊 WAL sidecar 是否一起對齊。

一個最小 restore drill 應保留五個檢查點：

1. 從備份產出新的 database file，不覆蓋 production path。
2. 用 application binary 啟動 read-only smoke test，確認 schema version 與 migration table。
3. 跑 row count、critical query、checksum 或 domain validation query。
4. 驗證 file owner、permission、disk path、SELinux / container mount 或 volume 設定。
5. 以 incident decision log 記錄 restore time、data freshness、known gap 與 owner。

Restore drill 的交付物應接回 Observability Evidence Package 與 Incident Decision Log。SQLite 的低操作成本來自日常元件少；事故時仍需要 evidence、owner 與 rollback condition。

Corruption recovery：先保全證據，再決定修復或還原

SQLite corruption recovery 的核心責任是區分「資料庫檔案本身受損」與「application 寫入了錯誤資料」。前者要走 file-level evidence、.recover、backup restore 與 filesystem / hardware investigation；後者要走資料修復、migration rollback 或 business reconciliation。

Corruption 事件的第一個操作是保存原始檔案與 sidecar。直接在疑似受損檔案上跑修復、vacuum 或 application migration，會讓後續 root cause analysis 失去證據；比較穩定的流程是複製原檔、在副本上嘗試 .recover，同時從備份恢復服務路徑。

Anti-recommendation：維持 SQLite 的條件要可被操作驗證

SQLite 的合理使用條件是「單一 writer、檔案生命週期清楚、restore drill 成立」。只要這三件事能被 runbook 驗證，SQLite 在 embedded、desktop、mobile、edge-local 或 small backend 場景可以是 production state。

升級條件則來自操作責任外溢。需要 database user / role、中心化 audit、多人同時寫、跨 instance failover、online schema migration、PITR、read replica 或跨 region transaction 時，server SQL 或 managed SQL 的操作模型會比繼續包裝 SQLite 清楚。

這張表的核心是把操作責任具體化，而非替 SQLite 設流量天花板。小型服務可能用 SQLite 長期穩定運作；同樣流量下，一旦合規、稽核、多人操作或 HA 需求進來，server database 的長期成本會更容易被治理。

操作檢查清單

SQLite production runbook 至少要能回答下列問題：

1. Database file、WAL sidecar 與 backup target 在哪個 volume、由誰擁有。
2. journal_mode、synchronous、busy timeout、checkpoint cadence 與 migration policy 如何設定。
3. Backup 用 .backup / backup API / VACUUM INTO / Litestream 的哪一條路徑。
4. Restore drill 最近一次何時執行，RPO / RTO 是否符合產品承諾。
5. SQLITE_BUSY、WAL growth、disk full、backup failure 與 restore failure 如何告警。
6. Corruption recovery 時誰保存原檔、誰啟動 restore、誰決定修復或 fail-forward。

這份清單要接到服務 ownership，而非留在工程師個人習慣。SQLite 的優勢是 deployment surface 小；production 化的代價是把檔案、備份與恢復流程寫進同一份可交接 runbook。

引用路徑

• 上游 overview：SQLite vendor page
• 服務責任：Source of Truth、Database
• 恢復目標：RPO、RTO
• 證據交接：Observability Evidence Package、Incident Decision Log
• 官方文件：SQLite Write-Ahead Logging、SQLite Backup API、How To Corrupt An SQLite Database File、Recovering Data From A Corrupt SQLite Database、Appropriate Uses For SQLite、Most Widely Deployed SQL Database Engine
• 延伸工具：Litestream restore reference、Litestream getting started