Sao lưu SQLite thời gian thực lên S3 với Litestream: Hướng dẫn từng bước để phục hồi dữ liệu với RPO bằng 0

Chạy ứng dụng web trên một VPS giá 5 USD/tháng với SQLite đã trở thành một trong những mô hình triển khai yêu thích của tôi. Bạn có thể giảm độ trễ mạng xuống chỉ còn 20 microsecond, tiết kiệm chi phí hosting tối đa và thu gọn toàn bộ stack thành một file binary duy nhất. Dẫu vậy, nhiều kỹ sư vẫn còn ngần ngại. Mối lo thường trực luôn là sự an toàn của dữ liệu: điều gì sẽ xảy ra nếu ổ NVMe của máy chủ bị hỏng, hoặc nhà cung cấp dịch vụ đám mây làm mất instance của bạn?

Các bản sao lưu snapshot định kỳ qua cron để lại một khoảng trống Recovery Point Objective (RPO) đầy rủi ro. Hãy thử xét một ứng dụng dump dữ liệu định kỳ mỗi 6 giờ. Nếu máy chủ gặp sự cố ở mốc 5 giờ 50 phút, bạn sẽ mất trắng gần sáu tiếng giao dịch mua hàng, bình luận hoặc tài khoản đăng ký mới của người dùng. Litestream giải quyết vấn đề này một cách triệt để. Công cụ này stream trực tiếp các frame Write-Ahead Log (WAL) của SQLite lên Amazon S3 hoặc các dịch vụ object storage tương thích S3 theo thời gian thực. Dưới đây là cách cấu hình Litestream từ con số 0 để đạt RPO phục hồi dưới một giây.

Table of Contents

Khởi động nhanh (5 phút): Stream SQLite lên S3

Việc cài đặt và vận hành Litestream trên Linux chỉ mất khoảng ba phút cùng vài dòng lệnh. Chúng ta sẽ cài đặt binary, cấu hình S3 bucket đích và kiểm tra luồng replication trực tiếp đầu tiên.

1. Cài đặt Litestream

Trên Ubuntu hoặc Debian, tải gói release trực tiếp từ GitHub:

# Tải về và cài đặt gói deb của Litestream
wget https://github.com/benbjohnson/litestream/releases/download/v0.3.13/litestream-v0.3.13-linux-amd64.deb
sudo dpkg -i litestream-v0.3.13-linux-amd64.deb

# Kiểm tra phiên bản sau khi cài đặt
litestream version

Bạn triển khai trên Alpine Linux hoặc Fedora? Hãy tải về bản tarball đã được biên dịch sẵn, giải nén và di chuyển file binary vào /usr/local/bin/litestream.

2. Cấu hình thông tin xác thực AWS S3 và Bucket

Tạo một Amazon S3 bucket riêng (ví dụ: my-sqlite-backups-bucket). Thiết lập một IAM user hoặc role được giới hạn quyền chặt chẽ cho bucket đó. Bạn cần bốn quyền: s3:PutObject, s3:GetObject, s3:ListBucket và s3:DeleteObject. Export các API key trong phiên shell của bạn:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_REGION="us-east-1"

3. Replicate và kiểm thử khôi phục dữ liệu

Thiết lập một database thử nghiệm. Kích hoạt chế độ WAL ngay lập tức, vì Litestream dựa vào các WAL frame để theo dõi thay đổi trạng thái:

mkdir -p /var/lib/myapp
sqlite3 /var/lib/myapp/app.db "PRAGMA journal_mode = WAL; CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT); INSERT INTO users (name) VALUES ('Alice');"

Khởi chạy quá trình replication trực tiếp từ terminal:

# Replicate app.db lên S3
litestream replicate /var/lib/myapp/app.db s3://my-sqlite-backups-bucket/app.db

Litestream sẽ đẩy bản snapshot ban đầu lên S3, sau đó chuyển sang trạng thái chờ và lắng nghe các lượt commit vào WAL. Hãy mở cửa sổ terminal thứ hai để tiến hành diễn tập khôi phục:

# Khôi phục trạng thái mới nhất sang một file đích mới
litestream restore -o /tmp/restored-app.db s3://my-sqlite-backups-bucket/app.db

# Xác minh dữ liệu đã được khôi phục thành công
sqlite3 /tmp/restored-app.db "SELECT * FROM users;"

Đi sâu vào cơ chế: Cách Litestream đạt được RPO dưới một giây

Trước khi đưa Litestream vào môi trường production, bạn nên hiểu rõ cơ chế đồng bộ hóa của nó khi truyền dữ liệu. Các hệ quản trị cơ sở dữ liệu quan hệ như PostgreSQL dựa vào các tiến trình replication daemon chuyên dụng để stream write-ahead log tới các read-replica qua giao thức TCP. SQLite về bản chất hoàn toàn khác biệt: đây là một thư viện C chạy in-process và ghi trực tiếp vào các file trên ổ đĩa cục bộ.

Vai trò của chế độ WAL trong SQLite

Theo mặc định, SQLite hoạt động ở chế độ rollback-journal, khóa toàn bộ database trong suốt quá trình ghi. Việc kích hoạt Write-Ahead Logging (PRAGMA journal_mode = WAL;) sẽ thay đổi hoàn toàn mô hình I/O này. Các tác vụ ghi vào database không còn sửa đổi trực tiếp trên file .db chính nữa. Thay vào đó, chúng được ghi nối tiếp vào một file đi kèm mang tên .db-wal.

Các tiến trình đọc tiếp tục truy vấn các trang dữ liệu trước đó từ file .db mà không chặn các tiến trình ghi, trong khi các tiến trình ghi thêm các trang mới vào log. Theo định kỳ, SQLite sẽ thực hiện một tiến trình checkpoint. Thao tác này sẽ ghi các trang từ .db-wal trở lại file gốc và reset lại log. Các công cụ sao lưu cron thông thường hay gặp lỗi ở điểm này: chúng thường sao chép file ngay giữa chừng checkpoint, dẫn đến tình trạng rách trang (torn pages) và làm hỏng file backup.

Cơ chế Continuous Frame Shadowing

Litestream chạy như một daemon nhẹ song hành cùng ứng dụng của bạn. Nó theo dõi file chỉ mục WAL của SQLite (.db-shm) thông qua các bộ đếm khóa trong bộ nhớ dùng chung (shared-memory lock counters). Mỗi khi một transaction được commit, Litestream sẽ đọc ngay các frame 4KB vừa ghi. Thay vì chờ đợi checkpoint, nó gom các frame mới thành các file nén Litestream Snapshot (LSS), sau đó đẩy chúng lên S3 chỉ trong khoảng 100 đến 250 millisecond.

[Ứng dụng ghi dữ liệu] 
        │
        ▼
  app.db-wal (NVMe cục bộ)
        │
  [Litestream theo dõi các WAL frame]
        │
        ├───────────────┬───────────────┐
        ▼               ▼               ▼
  Snapshot (Gốc)     Frame WAL 1     Frame WAL 2   --> Lưu trữ S3

Việc truyền dữ liệu liên tục này thu hẹp thời gian rủi ro mất dữ liệu từ hàng giờ xuống dưới một giây. Ngay cả trong các tác vụ ghi hàng loạt, Litestream vẫn stream dữ liệu nhanh tương đương tốc độ I/O của ổ đĩa. Khi kiểm thử các script seed dữ liệu hoặc chuẩn bị import lượng lớn (chẳng hạn như pipe dữ liệu JSON chuyển đổi từ trình duyệt vào các bảng SQLite), mọi bản ghi được commit vào WAL đều được chuyển lên S3 chỉ vài giây sau khi quá trình nạp dữ liệu hoàn tất.

Cách dùng nâng cao: Docker, Systemd và thiết lập Multi-Replica

Việc chạy lệnh thủ công trên terminal chỉ phù hợp khi kiểm thử cục bộ, còn các máy chủ production cần có trình quản lý tiến trình systemd, dự phòng đa đám mây (multi-cloud redundancy) và entrypoint rõ ràng cho container.

1. Cấu hình qua litestream.yml

Quản lý cơ sở dữ liệu và các replica đích thông qua file /etc/litestream.yml:

dbs:
  - path: /var/lib/myapp/app.db
    replicas:
      - type: s3
        bucket: my-sqlite-backups-bucket
        path: app.db
        region: us-east-1
        sync-interval: 1s
        retention: 72h
      # Replica off-site phụ (Cloudflare R2)
      - type: s3
        endpoint: https://<account-id>.r2.cloudflarestorage.com
        bucket: my-dr-backup
        path: app.db
        access-key-id: ${R2_ACCESS_KEY_ID}
        secret-access-key: ${R2_SECRET_ACCESS_KEY}

Litestream hỗ trợ stream song song tới nhiều endpoint cùng lúc. Trong cấu hình này, các transaction đã commit sẽ được gửi đồng thời lên AWS S3 và Cloudflare R2, giúp bảo vệ hệ thống trước sự cố gián đoạn của bất kỳ nhà cung cấp dịch vụ đơn lẻ nào.

2. Quản lý Litestream với Systemd

Tạo một file service tại /etc/systemd/system/litestream.service:

[Unit]
Description=Dịch vụ Replication SQLite Litestream
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
EnvironmentFile=/etc/default/litestream
ExecStart=/usr/local/bin/litestream replicate -config /etc/litestream.yml
Restart=always
RestartSec=5s
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Lưu thông tin xác thực bucket vào /etc/default/litestream, giới hạn quyền chỉ dành cho root (chmod 600), reload lại systemd và khởi động service:

sudo systemctl daemon-reload
sudo systemctl enable --now litestream
sudo systemctl status litestream

3. Mô hình “Exec” cho Docker Container

Chạy Litestream bên trong Docker không đòi hỏi các hệ thống điều phối nhiều container phức tạp. Litestream cung cấp chế độ giám sát tiến trình thông qua lệnh litestream exec. Khi container khởi động, nó sẽ tải về bản sao lưu database mới nhất nếu volume cục bộ đang trống, thực thi ứng dụng của bạn như một tiến trình con và tiếp tục stream các WAL frame cho đến khi tắt ứng dụng.

Dưới đây là file entrypoint hoàn chỉnh cho container production (run.sh):

#!/bin/sh
set -e

DB_PATH="/data/app.db"

# Khôi phục từ S3 nếu file database cục bộ chưa tồn tại
if [ ! -f "$DB_PATH" ]; then
  echo "Không tìm thấy database cục bộ. Đang khôi phục từ S3..."
  litestream restore -if-replica-exists -o "$DB_PATH" s3://$S3_BUCKET/app.db
fi

# Chạy Litestream với vai trò giám sát lệnh khởi chạy ứng dụng chính
exec litestream exec -config /etc/litestream.yml -- ./my-web-server -db "$DB_PATH"

Nếu máy chủ vật lý gặp sự cố, bạn chỉ cần khởi tạo một container thay thế ở bất kỳ đâu. Script sẽ phát hiện thư mục trống, kéo toàn bộ trạng thái database từ S3 về đến tận giây cuối cùng và khởi chạy ứng dụng của bạn.

Kinh nghiệm thực tế và xử lý sự cố trong môi trường production

Vận hành Litestream dưới tải lượng truy cập liên tục đòi hỏi bạn phải theo dõi kỹ hành vi của file WAL, cơ chế giám sát và chính sách lưu trữ trên cloud storage.

Kiểm soát tiến trình Checkpointing của SQLite

Thông thường, SQLite sẽ tự động kích hoạt checkpoint khi file WAL đạt 1.000 trang (~4MB). Litestream xử lý tốt trường hợp này mà không gặp trở ngại nào. Tuy nhiên, các truy vấn đọc kéo dài (chẳng hạn như báo cáo phân tích chạy mất 30 giây) sẽ giữ các khóa chia sẻ (shared lock), làm tắc nghẽn quá trình checkpoint. Khi điều này xảy ra, file WAL có thể phình to lên tới nhiều gigabyte. Hãy theo dõi trực tiếp dung lượng file:

# Kiểm tra dung lượng hiện tại của file WAL
ls -lh /var/lib/myapp/app.db*

Hãy luôn cấu hình connection pool của SQLite với thời gian chờ bận (chẳng hạn: PRAGMA busy_timeout = 5000;). Điều này giúp tránh việc tranh chấp khóa tạm thời làm chậm trễ quá trình xử lý các frame.

Giám sát trạng thái đồng bộ hóa

Kiểm tra xem Litestream có đang theo dõi các lượt ghi dữ liệu chuẩn xác hay không bằng lệnh generations:

litestream generations -config /etc/litestream.yml /var/lib/myapp/app.db

Lệnh này sẽ liệt kê các thế hệ backup (generations) được lưu trên S3 kèm theo thời điểm tạo. Nếu danh sách trống hoặc thời gian đồng bộ bị đình trệ, hãy kiểm tra ngay log của daemon bằng lệnh journalctl -u litestream -n 100 để phát hiện kịp thời các lỗi xác thực hoặc timeout mạng.

Thiết lập S3 Lifecycle Rules

Litestream sẽ tự động xóa các snapshot hết hạn dựa theo cấu hình retention của bạn (ví dụ: retention: 72h). Mặc dù vậy, các tác vụ multipart upload bị gián đoạn có thể để lại các mảnh chunk thừa không được tham chiếu trên AWS. Hãy thiết lập một S3 Lifecycle Rule để tự động hủy các tác vụ multipart upload chưa hoàn tất sau 3 ngày. Điều này ngăn các mảnh upload thừa làm đội chi phí hóa đơn AWS hàng tháng của bạn.

Sự kết hợp giữa SQLite và Litestream mang lại cho bạn độ trễ đọc dưới một millisecond từ ổ lưu trữ NVMe cục bộ, đồng thời vẫn đảm bảo khả năng khôi phục sau thảm họa của các nền tảng đám mây phân tán. Bạn có được độ bền vững vượt trội mà không cần bận tâm đến gánh nặng vận hành phức tạp của một cụm cơ sở dữ liệu phân tán nhiều node.