VPS에서 SQLite를 프로덕션으로 운영하는 방법

VPS에서 SQLite가 적합한 프로덕션 데이터베이스인 경우

VPS에서 프로덕션 환경으로 SQLite를 실행하는 것은 대부분의 소규모 애플리케이션에 적합합니다. 이유는 간단합니다. 한 컴퓨터의 한 프로세스가 하나의 파일에 쓰는 경우 데이터베이스 서버가 필요하지 않습니다. 감독해야 할 데몬이 없고, 방화벽에서 열거나 닫을 포트가 없으며, 교체해야 할 비밀번호가 없고, 계속 실행 상태로 유지해야 할 두 번째 컴퓨터도 없습니다. 쿼리는 네트워크 왕복이 아니라 함수 호출이므로, 40개의 쿼리를 실행하는 페이지에는 함수 호출 40회가 필요합니다.

비용은 제한적이지만 분명합니다. SQLite는 전체 데이터베이스 파일에서 한 번에 하나의 writer만 허용하며, 파일을 두 컴퓨터 간에 공유할 수 없습니다. 단일 VPS에서 단일 애플리케이션을 실행하는 경우에는 두 제한 모두 문제가 되지 않습니다. 이 구조를 벗어나는 순간 두 제한 모두 치명적인 문제가 됩니다. 이 가이드에서는 서버에서 SQLite를 안전하게 사용하기 위한 설정, Litestream을 사용한 지속적 백업, 그리고 사용을 중단해야 하는 시점을 설명합니다.

먼저 명령줄 도구를 설치합니다. 아래의 모든 명령은 Ubuntu 24.04에서 실행했습니다.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

이 명령은 3.로 시작하는 버전과 빌드 날짜 및 소스 해시를 출력합니다. 2026년 7월 기준으로 Ubuntu 24.04에는 SQLite 3.45.1이 포함되어 있습니다. 애플리케이션에서는 이 바이너리를 사용하지 않을 가능성이 높습니다. 대부분의 언어 런타임은 SQLite 라이브러리의 자체 사본을 포함하며, 최신 버전인 경우도 많기 때문입니다. 따라서 최신 기능에 의존하기 전에 데이터베이스 드라이버가 보고하는 버전을 확인합니다.

WAL 모드를 가장 먼저 변경하는 이유

기본적으로 SQLite는 롤백 저널을 사용합니다. 페이지를 변경하기 전에 원래 페이지를 -journal 파일에 복사한 다음 데이터베이스를 직접 수정합니다. 이 작업을 안전하게 수행하려면 전체 파일에 배타적 잠금을 설정해야 하므로, 쓰기 작업이 진행되는 동안 모든 읽기 작업이 대기합니다. 노트북에서는 이를 알아차리기 어렵습니다. 웹 서버에서는 느린 쓰기 작업 하나가 데이터베이스에 액세스하는 모든 요청을 지연시킵니다.

WAL(선행 기록 로그) 모드는 순서를 반대로 처리합니다. 쓰기 작업은 새 페이지를 별도의 -wal 파일에 추가하고 주 데이터베이스는 그대로 둡니다. 읽기 작업은 시작 시점의 스냅샷에서 주 파일을 계속 읽으므로, 읽기 작업이 쓰기 작업을 차단하지 않고 쓰기 작업도 읽기 작업을 차단하지 않습니다. 이후 checkpoint가 누적된 WAL 페이지를 주 데이터베이스에 복사합니다. 이 한 가지 변경만으로도 SQLite를 웹 애플리케이션에서 사용할 수 있게 하는 핵심 조건 대부분이 충족됩니다.

WAL 모드를 활성화하고 적용 여부 확인

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

이 명령은 wal을 출력합니다. 이 출력은 장식이 아닙니다. PRAGMA journal_mode는 데이터베이스가 실제로 사용 중인 모드를 반환합니다. 따라서 delete이라는 응답은 변경에 실패했으며 아직 rollback journal을 사용 중이라는 의미입니다.

WAL 모드는 지속적으로 유지됩니다. WAL 모드는 연결 설정이 아니라 데이터베이스 헤더에 저장되는 플래그입니다. 따라서 데이터베이스 파일마다 한 번만 실행하면 됩니다. 이후 생성되는 모든 연결은 재부팅 후에도 이 설정을 상속합니다. 새 연결을 사용하여 이를 확인합니다.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

이제 테이블을 생성하고 디스크에 어떤 파일이 나타나는지 확인합니다.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

이제 파일이 3개 있습니다. app.db, app.db-wal, app.db-shm입니다. -wal 파일에는 아직 checkpoint되지 않은 커밋된 페이지가 저장됩니다. -shm 파일은 모든 연결이 매핑하는 shared memory 인덱스입니다. 이를 통해 모든 연결이 WAL의 내용을 동일하게 인식합니다. 두 파일 모두 데이터베이스에 속하며 임시 파일이 아닙니다. 애플리케이션이 실행 중일 때 app.db만 복사하면 최근 커밋이 모두 누락된 파일을 얻게 됩니다. app.db을 삭제하고 나머지 두 파일을 그대로 두면, SQLite는 해당 이름으로 새 파일이 생성될 때 오래된 WAL 페이지를 그 파일에 적용합니다. 이 때문에 데이터베이스를 초기화하려다가 새 데이터베이스를 손상시킬 수 있습니다.

운영 환경의 모든 애플리케이션에 필요한 연결 설정

journal_mode만 데이터베이스에 저장됩니다. 아래의 다른 모든 설정은 연결별 설정입니다. 따라서 애플리케이션이 여는 각 연결에서 이 설정을 실행해야 합니다. 백그라운드에서 connection pool이 생성하는 모든 연결도 포함됩니다.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000는 SQLite가 잠긴 데이터베이스에 대해 최대 5000밀리초 동안 재시도하도록 설정합니다. 그 후 database is locked을 반환합니다. 기본값은 0입니다. 따라서 기본 상태에서는 두 writer가 겹치는 첫 순간에 SQLite가 즉시 실패합니다. 이 값을 하나만 설정해도 SQLite 자체의 문제로 오해하는 잠금 오류 대부분이 사라집니다.

synchronous = NORMAL은 WAL mode에서 적절한 설정입니다. 다만 그에 따른 절충을 이해해야 합니다. FULL에서는 SQLite가 모든 commit마다 WAL에 fsync를 호출합니다. NORMAL에서는 checkpoint 시점에 동기화합니다. SQLite 문서는 이 설정으로 포기하는 내용을 명확히 설명합니다. 정전이나 강제 재설정이 발생하면 transaction이 더 이상 지속성을 보장받지 못합니다. 정전으로 데이터베이스가 손상되는 것은 아닙니다. 디스크에 아직 기록되지 않은 마지막 commit만 손실됩니다. VPS에서는 일반적으로 이 절충이 적절합니다. 모든 write 경로에서 fsync를 제거할 수 있기 때문입니다.

foreign_keys = ON은 이전 버전과의 호환성을 위해 기본적으로 비활성화되어 있으며, 연결별 설정입니다. REFERENCES 절이 가득한 schema도 각 연결에서 이 설정을 활성화하기 전까지는 아무것도 강제하지 않습니다.

나중에만 중요한 설정이 하나 더 있습니다. WAL 크기가 1000 pages를 초과하면 SQLite가 자동으로 checkpoint를 실행합니다. 이 작업은 그 시점에 transaction을 완료하는 연결이 수행합니다. 그 자체로는 문제가 없습니다. 하지만 Litestream이 실행 중이면 상황이 달라집니다. Litestream은 checkpoint 실행 시점을 제어하려고 하기 때문입니다.

database is locked을 설정한 후에도 계속 발생하는 이유

이 오류 때문에 Postgres로 돌아가는 경우가 많습니다. 원인은 하나입니다.

busy timeout은 busy handler를 등록하지만, SQLite가 이 handler를 호출한다고 보장하지는 않습니다.

SQLite가 busy handler를 호출하면 deadlock이 발생할 수 있다고 판단하면, busy handler를 호출하는 대신 애플리케이션에 SQLITE_BUSY를 반환합니다.

SQLite가 방지하는 deadlock은 transaction을 업그레이드할 때 발생합니다. SQLite에서 단독으로 사용하는 BEGIN은 BEGIN DEFERRED을 의미합니다. 그 다음 첫 번째 statement가 SELECT이면 read transaction 상태입니다. 같은 transaction에서 나중에 실행한 UPDATE이 write transaction으로 전환되어야 할 때, 다른 connection이 read 시작 후에 데이터를 썼다면 SQLite는 기다리게 할 수 없습니다. 이미 snapshot이 오래된 상태이고, 기다리면 두 connection이 서로를 deadlock 상태로 만들기 때문입니다. 문서에도 결과가 명확하게 설명되어 있습니다.

이후 write statement는 가능한 경우 transaction을 write transaction으로 업그레이드하거나 SQLITE_BUSY를 반환합니다.

설정한 5000 millisecond timeout은 확인되지 않습니다. 오류가 즉시 반환되므로 설정이 적용되지 않은 것처럼 보입니다.

해결 방법은 한 단어입니다.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE은 아무것도 읽기 전에 시작 시점에 write lock을 획득합니다. 따라서 업그레이드가 발생하지 않고, 방지해야 할 deadlock도 없습니다. 그러므로 busy handler가 적용되고 connection은 실패하는 대신 순서를 기다립니다. 읽기 전용 transaction은 deferred 상태로 유지합니다. write를 포함하는 transaction은 immediate 상태여야 합니다.

lock 오류의 두 번째 원인은 발견하기 더 어렵습니다. 느린 작업이 끝날 때까지 write transaction을 열어 두는 경우입니다. SQLite는 writer를 직렬화하므로 transaction을 연 뒤 네트워크를 통해 외부 API를 호출하고 커밋하는 transaction은 해당 호출이 진행되는 동안 다른 모든 writer를 차단합니다. 필요한 데이터를 읽은 후 transaction을 닫습니다. 느린 작업을 수행한 다음 결과를 저장하기 위해 짧은 write transaction을 엽니다.

Litestream를 사용한 연속 백업

야간 복사만 사용하면 최대 하루치 쓰기를 잃을 수 있습니다. 실행 중인 SQLite 데이터베이스에서 cp를 실행하면 열리지 않는 복사본이 생성될 수 있습니다. 안전한 방법은 2가지입니다. sqlite3 app.db ".backup /path/to/backup.db"는 SQLite의 온라인 백업 인터페이스를 사용하므로 사용 중인 데이터베이스에서도 작동합니다. Litestream는 여기서 더 나아갑니다. WAL을 감시하고 변경 사항을 object storage로 지속적으로 전송합니다. 따라서 최악의 데이터 손실 범위가 하루에서 약 1초로 줄어듭니다.

Litestream는 애플리케이션 옆에서 실행되는 Go 바이너리 1개입니다. 애플리케이션과 데이터베이스 사이에 위치하지 않습니다. 애플리케이션은 이전과 동일하게 SQLite에 쓰고, Litestream는 WAL을 읽어 변경된 내용을 업로드합니다.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

v0.5.14는 2026년 7월 기준 공식 Linux 설치 페이지에 문서화된 릴리스입니다. v0.5.15는 2026년 7월 21일에 이어서 릴리스되었습니다. 두 줄의 버전을 releases 페이지의 현재 tag에 맞게 변경합니다. VPS가 arm64라면 일치하는 arm64 패키지를 대신 사용합니다.

구성 파일은 /etc/litestream.yml에 있습니다. 먼저 local file replica로 시작합니다. 그러면 cloud credentials 없이 전체 동작 과정을 검증할 수 있습니다.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

필드가 단수형인 replica라는 점에 유의합니다. Litestream 0.5에서는 0.3 시리즈의 replicas 배열이 단일 replica 블록으로 변경되었습니다. 이제 2개의 항목이 있는 구성은 startup 시 실패합니다. 많은 third-party 가이드가 여전히 이전 배열을 보여 줍니다. 따라서 검색 결과에서 처음 표시되는 예제가 아니라 위의 구조를 복사합니다. 0.5 시리즈에서는 디스크 백업 형식이 변경되었기 때문에 litestream wal subcommand 이름도 litestream ltx로 변경되었습니다.

무언가를 활성화하기 전에 구성이 파싱되는지 확인합니다.

sudo litestream databases -config /etc/litestream.yml

그런 다음 수동으로 전체 왕복을 검증합니다. 이 형식은 구성 파일을 건너뛰고 데이터베이스 1개를 경로 1개에 복제합니다.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

이 명령은 foreground에서 실행되며 계속 실행됩니다. 두 번째 shell에서 행을 1개 쓰고 replica를 새 파일로 restore합니다.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

이 count에는 새 행이 포함됩니다. 포함되지 않았다면 아직 변경 사항이 sync되지 않은 것입니다. Litestream는 기본값이 1초인 sync-interval 주기로 push하므로 잠시 기다린 후 다시 restore합니다. 이 1초가 recovery point이기도 합니다. 충돌이 발생하면 마지막 sync interval 이후의 쓰기를 최대한 잃을 수 있습니다. 어떤 구성으로도 이 값을 0으로 만들 수는 없습니다.

실제 storage를 사용하려면 replica 블록을 S3 URL로 변경합니다. Amazon S3와 다른 provider의 S3-compatible object storage에서 모두 작동합니다.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

credentials를 해당 파일에 저장하지 않습니다. Litestream는 환경에서 LITESTREAM_ACCESS_KEY_ID 및 LITESTREAM_SECRET_ACCESS_KEY을 읽습니다. 따라서 root가 소유하고 mode가 600인 systemd drop-in에 해당 값을 넣습니다.

위 snapshot 값은 기본값이며, retention 기본값은 주의가 필요합니다. retention은 Litestream가 snapshot과 해당 snapshot에 속한 파일을 보관하는 기간입니다. 따라서 restore할 수 있는 과거 시점의 범위이기도 합니다. 24시간으로 설정하면 수요일 아침에 발견한 잘못된 migration을 월요일 상태에서 이미 복구할 수 없습니다. retention: 168h를 1주일로 설정하고 추가 storage 비용을 지불합니다.

복구가 필요하기 전에 복구를 검증합니다

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

데이터베이스 경로를 지정하면 litestream restore가 /etc/litestream.yml에서 일치하는 복제본을 조회하고 가져옵니다. PRAGMA integrity_check는 정상 파일에서 ok을 출력합니다. 다른 출력이 나타나면 복구된 사본을 사용할 수 없습니다. systemd 서비스와 타이머를 사용해 이 작업을 일정에 따라 실행하고 출력을 확인합니다. 백업을 한 번 복구해 보기 전에는 백업이 정상적으로 작동하는지 알 수 없습니다.

systemd에서 Litestream 실행

Debian 패키지는 litestream unit을 설치하며, 이 unit은 /etc/litestream.yml을 읽습니다.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

정상적인 출력에서는 설정에 지정된 각 데이터베이스의 이름을 표시한 후 주기적인 동기화 줄을 제외하고는 출력을 중단합니다. 데이터베이스 경로에 대해 no such file or directory 오류가 발생하면 설정의 경로가 잘못되었거나 프로세스에 해당 경로를 읽을 권한이 없는 것입니다. 기본적으로 unit은 root로 실행되지만, 이 작업에 필요한 권한보다 많습니다. Litestream은 데이터베이스와 데이터베이스가 있는 디렉터리 모두를 읽고 쓸 수 있어야 합니다. 데이터베이스 옆에 있는 -wal 파일과 -shm 파일을 사용하기 때문입니다. 따라서 애플리케이션이 이미 사용하는 계정을 지정합니다.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

sudo systemctl daemon-reload 및 sudo systemctl restart litestream으로 적용합니다. 최소 권한을 가진 전용 서비스 계정 설정에는 몇 분이면 충분합니다. 이는 백업 에이전트와 서버에서 실행되는 두 번째 root 프로세스를 구분하는 중요한 차이입니다.

처음부터 시스템을 다시 구축할 때는 실행 순서가 중요합니다. 애플리케이션이 시작되기 전에 데이터베이스를 복원해야 합니다. litestream restore은 -if-db-not-exists을 허용하며, 파일이 이미 있으면 0으로 종료하므로 부팅할 때마다 실행해도 안전합니다. 애플리케이션 unit의 ExecStartPre 줄에 이를 추가하면 새 VPS는 데이터베이스를 다운로드하고, 기존 VPS에서는 아무 작업도 수행하지 않습니다. 한 곳에서 관리하려면 litestream replicate에 해당하는 -restore-if-db-not-exists 플래그가 있습니다.

VPS에서 SQLite가 중단되는 경우

네트워크 파일 시스템. 이는 설정으로 우회할 수 없는 제한입니다. WAL 모드에서는 데이터베이스를 사용하는 모든 프로세스가 작은 메모리 영역을 공유해야 하며, -shm 파일이 이 영역을 제공합니다. SQLite 문서는 이 규칙을 예외 없이 명시합니다.

데이터베이스를 사용하는 모든 프로세스는 동일한 호스트 컴퓨터에 있어야 합니다. WAL은 네트워크 파일 시스템에서 작동하지 않습니다.

따라서 마운트된 NFS(네트워크 파일 시스템) 또는 SMB 공유에 데이터베이스를 두면 데이터가 손상될 수 있으며, 이를 방지하는 pragma는 없습니다. 여기에는 사람들이 자주 혼동하는 차이가 있습니다. 대부분의 VPS provider가 추가 스토리지로 연결하는 네트워크 블록 장치는 Linux에서 일반 파일 시스템이 있는 일반 디스크로 인식되므로 문제가 없습니다. 마운트된 파일 공유는 그렇지 않습니다.

두 번째 애플리케이션 서버. 이 구성을 작동하게 만드는 설정은 없습니다. 동일한 데이터를 두 대의 시스템에서 제공해야 한다면 네트워크를 통해 통신하는 데이터베이스가 필요합니다. 아직 계획을 세울 시간이 있을 때 이 전환을 결정해야 합니다.

쓰기 중심 워크로드. 한 번에 하나의 writer만 사용할 수 있는 것은 파일 형식의 특성이며, 조정할 수 있는 설정이 아닙니다. 각 commit이 WAL에 추가되므로 짧은 쓰기는 비용이 낮습니다. 따라서 처리량은 CPU보다 디스크의 소규모 쓰기 지연 시간에 더 큰 영향을 받습니다. 이 차이가 어떻게 나타나는지는 VPS에서 NVMe와 SATA SSD 스토리지 비교를 참조하십시오. 실제 문제는 긴 transaction입니다. 긴 transaction이 다른 모든 writer를 대기열 뒤에 세우기 때문입니다.

분석 쿼리. SQLite는 transaction을 위해 설계된 행 저장소입니다. 1억 개의 행을 검색하는 dashboard는 다른 도구가 필요한 다른 작업입니다. 서버 작업에서 DuckDB와 SQLite 비교에서 그 경계가 어디에 있는지 설명합니다.

복제 환경의 VACUUM. 전체 VACUUM은 데이터베이스 파일 전체를 다시 작성합니다. 따라서 Litestream은 파일 전체를 다시 업로드해야 하며, Litestream 문서에서는 복제가 활성화된 상태에서 이를 실행하지 않도록 권고합니다. replicator를 중지하고 vacuum을 실행한 다음 다시 시작하십시오. 새로운 전체 snapshot이 생성됩니다.

하나의 데이터베이스에서 실행하는 두 개의 replicator. 동일한 데이터베이스 또는 동일한 replica destination에 대해 두 개의 Litestream process를 실행하지 마십시오. 이를 방지할 책임은 사용자에게 있다고 문서에 명시되어 있습니다. 이를 어기면 복원할 수 없는 replica가 생성됩니다.

Litestream이 다루지 않는 항목

Litestream은 데이터베이스 파일만 보호합니다. 그 외에는 보호하지 않습니다. 업로드된 파일, 애플리케이션 구성, TLS(전송 계층 보안) 인증서 및 unit 파일은 모두 별도로 관리해야 합니다. 일정에 따라 restic을 사용한 암호화된 외부 백업과 함께 사용하면 두 영역을 모두 보호할 수 있습니다. 시스템이 새 시스템이라면 새 VPS에서 처음 10분 동안 수행할 작업에서 이 가이드가 이미 완료된 것으로 가정하는 사용자 계정 및 방화벽 작업을 다룹니다.

FAQ

SQLite가 운영 환경의 애플리케이션에 충분합니까?

서버 1대에서 애플리케이션 1개를 실행한다면 충분합니다. 단, WAL 모드를 활성화하고 busy timeout을 설정하며 지속적으로 백업해야 합니다. 중요한 제한은 구조적입니다. 한 번에 작성할 수 있는 writer는 1개이고, 호스트 시스템도 1대입니다. 이러한 제한에 맞는 애플리케이션은 네트워크 홉이나 별도로 모니터링할 프로세스 없이 데이터베이스를 사용할 수 있습니다. 이 제한에 맞지 않는 애플리케이션에는 client-server 데이터베이스가 필요합니다. 튜닝만으로는 이 요구 사항을 바꿀 수 없습니다.

busy_timeout을 설정했는데도 database is locked가 계속 발생하는 이유는 무엇입니까?

대기로 인해 deadlock이 발생할 수 있는 경우 SQLite가 busy handler를 건너뛰기 때문입니다. bare BEGIN로 시작하는 transaction은 deferred 상태입니다. 여는 SELECT가 이를 read transaction으로 만들고, 이후 write 작업은 transaction을 업그레이드해야 합니다. 그 사이에 다른 connection이 write 작업을 수행하면 read snapshot이 이미 오래된 상태이므로 SQLite는 busy handler를 호출하지 않고 즉시 SQLITE_BUSY를 반환합니다. write 작업을 수행할 모든 transaction은 BEGIN IMMEDIATE로 시작하십시오. 그러면 처음부터 write lock을 획득하므로 timeout이 적용됩니다.

SQLite 데이터베이스를 network storage에 둘 수 있습니까?

NFS 또는 SMB와 같은 network filesystem에는 둘 수 없습니다. WAL 모드는 모든 프로세스가 -shm 파일을 통해 메모리를 공유해야 합니다. SQLite 문서에는 데이터베이스를 사용하는 모든 프로세스가 동일한 호스트 컴퓨터에 있어야 한다고 명시되어 있습니다. provider가 연결한 network block device는 다른 유형입니다. Linux에서는 이를 일반 filesystem이 있는 일반 디스크로 인식하므로 SQLite를 사용할 수 있습니다.

이미 nightly backup을 실행하고 있어도 Litestream이 필요합니까?

손실을 감수할 수 있는 데이터 양에 따라 다릅니다. nightly job은 최대 24시간의 write 작업을 잃을 수 있음을 의미합니다. Litestream은 약 1초마다 동기화하므로 crash가 발생해도 대략 마지막 1초의 데이터만 손실됩니다. 또한 cp로 데이터베이스 파일을 복사하는 것보다 안전합니다. cp는 write 작업 중간의 데이터베이스를 복사할 수 있기 때문입니다. Litestream은 데이터베이스만 보호하므로 일반 파일 backup도 함께 실행해야 합니다.