SQLite בסביבת ייצור על שרת VPS: מדריך מעשי

מתי SQLite הוא מסד הנתונים הנכון לייצור בשרת VPS

הרצת SQLite בסביבת ייצור על גבי שרת VPS היא הבחירה הנכונה עבור רוב היישומים הקטנים, והסיבה לכך פשוטה: תהליך אחד על מכונה אחת הכותב לקובץ אחד אינו זקוק לשרת מסד נתונים. אין daemon שיש לנטר, אין פורט שצריך להגדיר ב־firewall, אין סיסמה שצריך להחליף, ואין מכונה שנייה שצריך לשמור עליה פעילה. שאילתה היא קריאת פונקציה ולא סבב תקשורת ברשת, כך שדף שמריץ ארבעים שאילתות עולה לכם ארבעים קריאות פונקציה בלבד.

המחיר הוא מוגבל ומוחשי. SQLite מאפשר כותב אחד בלבד בכל רגע נתון על פני כל קובץ מסד הנתונים, ולא ניתן לשתף את הקובץ בין שתי מכונות. שתי המגבלות הללו מקובלות עבור שרת VPS יחיד המריץ יישום יחיד. שתיהן קטלניות ברגע שאתם חורגים מהמבנה הזה. מדריך זה מכסה את ההגדרות שהופכות את SQLite לבטוח בשרת, גיבוי רציף באמצעות Litestream, והנקודה שבה עליכם לעצור.

התקינו תחילה את כלי שורת הפקודה. כל מה שמופיע להלן הורץ על Ubuntu 24.04.

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

פקודה זו מדפיסה גרסה המתחילה ב־3. ולאחריה תאריך בנייה ו־hash של קוד המקור. נכון ליולי 2026, Ubuntu 24.04 מספקת את SQLite בגרסה 3.45.1. סביר להניח שהיישום שלכם אינו משתמש בבינארי הזה: רוב סביבות ההרצה של שפות תכנות כוללות עותק משלהן של ספריית SQLite, לעיתים קרובות גרסה חדשה יותר, לכן בדקו את הגרסה שמדווח מנהל מסד הנתונים שלכם לפני שאתם מסתמכים על תכונה חדשה.

מדוע מצב WAL הוא השינוי הראשון שיש לבצע

כברירת מחדל, SQLite משתמש ב-rollback journal. לפני שינוי של דף, הוא מעתיק את הדף המקורי לקובץ -journal, ולאחר מכן עורך את מסד הנתונים במקומו. כדי לעשות זאת בצורה בטוחה, הוא נועל את כל הקובץ בנעילה בלעדית, ולכן כל קורא ממתין בזמן שמתבצעת כתיבה כלשהי. במחשב נייד איש אינו מבחין בכך. בשרת אינטרנט, כתיבה איטית אחת מעכבת כל בקשה שניגשת למסד הנתונים.

מצב WAL (קיצור של write-ahead log) הופך את הסדר. הכותב מצרף את הדפים החדשים לקובץ -wal נפרד ומשאיר את מסד הנתונים הראשי ללא שינוי. הקוראים ממשיכים לקרוא את הקובץ הראשי בנקודת הזמן (snapshot) שבה התחילו, כך שהקוראים אינם חוסמים את הכותב והכותב אינו חוסם את הקוראים. מאוחר יותר, פעולת checkpoint מעתיקה את דפי ה-WAL שנצברו בחזרה למסד הנתונים הראשי. שינוי יחיד זה הוא מרבית מה שהופך את SQLite לשימושי מאחורי יישום אינטרנט.

הפעלת מצב WAL ואימות ההגדרה

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

הפקודה מדפיסה wal. פלט זה אינו קישוט. PRAGMA journal_mode מחזירה את המצב שבו מסד הנתונים נמצא בפועל, לכן תשובה של delete משמעותה שהשינוי נכשל ואתם עדיין משתמשים ב-rollback journal.

מצב WAL הוא קבוע. מדובר בדגל בכותרת (header) של מסד הנתונים ולא בהגדרת חיבור, לכן מריצים אותו פעם אחת לכל קובץ מסד נתונים וכל חיבור לאחר מכן יורש אותו, גם לאחר אתחול. ניתן להוכיח זאת באמצעות חיבור חדש.

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/

כעת קיימים שלושה קבצים: app.db, app.db-wal ו-app.db-shm. הקובץ -wal מכיל דפים שבוצע להם commit אך טרם עברו checkpoint. הקובץ -shm הוא אינדקס זיכרון משותף שכל חיבור ממפה, כך שכולם מסונכרנים לגבי תוכן ה-WAL. שניהם שייכים למסד הנתונים ואינם קובצי עבודה זמניים. אם תעתיקו את app.db לבדו בזמן שהיישום רץ, תקבלו קובץ שחסרים בו כל ה-commits האחרונים. אם תמחקו את app.db ותשאירו את השניים האחרים במקומם, SQLite יחיל את דפי ה-WAL הישנים על כל קובץ חדש שיופיע תחת שם זה; כך אנשים משחיתים מסד נתונים חדש בזמן שהם מנסים לאפס אחד קיים.

הגדרות החיבור שכל יישום בסביבת production חייב

רק journal_mode נשמר בתוך מסד הנתונים. כל שאר ההגדרות להלן הן ברמת החיבור, מה שאומר שהיישום שלכם חייב להריץ אותן בכל חיבור שהוא פותח, כולל כל חיבור שמאגר (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, ולכן כברירת מחדל SQLite נכשל מיידית בפעם הראשונה שבה שני תהליכי כתיבה מתנגשים. הגדרת ערך יחיד זה פותרת את רוב שגיאות הנעילה שמיוחסות בטעות ל-SQLite עצמו.

synchronous = NORMAL היא ההגדרה הנכונה במצב WAL, וכדאי להבין את הפשרה הכרוכה בכך. ב-FULL,‏ SQLite מבצע fsync על ה-WAL בכל commit. ב-NORMAL, הוא מסנכרן רק בנקודות ביקורת (checkpoints). התיעוד של SQLite מבהיר היטב על מה מוותרים: טרנזקציות אינן עמידות (durable) עוד לאחר הפסקת חשמל או אתחול קשיח. מסד הנתונים לא ייפגם כתוצאה מאובדן החשמל, אתם פשוט תאבדו את ה-commits האחרונים שטרם הגיעו לדיסק. בשרת VPS זו בדרך כלל הפשרה הנכונה, כיוון שהיא מוציאה את פעולת ה-fsync מנתיב הכתיבה של כל פעולה בודדת.

foreign_keys = ON כבויה כברירת מחדל לצורך תאימות לאחור, והיא מוגדרת לכל חיבור בנפרד. סכימה מלאה בסעיפי REFERENCES לא תאכוף דבר כל עוד כל חיבור לא מפעיל הגדרה זו.

הגדרה אחת נוספת חשובה רק בשלב מאוחר יותר. SQLite מבצע checkpoint באופן אוטומטי ברגע שקובץ ה-WAL גדל מעבר ל-1000 דפים, והעבודה מבוצעת על ידי החיבור שמסיים טרנזקציה באותו רגע. זה תקין כשלעצמו. העניין הופך למורכב כאשר Litestream רץ, כיוון ש-Litestream דורש שליטה על מועד ביצוע ה-checkpoints.

מדוע database is locked עדיין מתרחשת לאחר הגדרת busy_timeout

זהו הכשל שגורם למשתמשים לחזור ל־Postgres, ויש לו סיבה אחת ספציפית.

הגדרת busy_timeout מתקינה מטפל עסוק (busy handler), אך SQLite לא מתחייבת להפעיל אותו.

אם SQLite קובעת שהפעלת המטפל העסוק עלולה להוביל ל-deadlock, היא תחזיר SQLITE_BUSY ליישום במקום להפעיל את המטפל.

ה-deadlock שהיא מונעת מתרחש בעת שדרוג טרנזקציה. פקודת BEGIN פשוטה ב-SQLite משמעותה BEGIN DEFERRED. אם הפקודה הראשונה אחריה היא SELECT, אתם נמצאים בטרנזקציית קריאה. כאשר פקודת UPDATE מאוחרת יותר באותה טרנזקציה צריכה להפוך לטרנזקציית כתיבה, וחיבור אחר ביצע כתיבה מאז תחילת הקריאה שלכם, SQLite לא יכולה לגרום לכם להמתין. זאת כיוון שה-snapshot שלכם כבר אינו מעודכן, והמתנה רק תגרום ל-deadlock בין שני החיבורים. התיעוד מצהיר על התוצאה במפורש:

פקודות כתיבה עוקבות ישדרגו את הטרנזקציה לטרנזקציית כתיבה אם הדבר אפשרי, או יחזירו SQLITE_BUSY.

ה-timeout שלכם, המוגדר ל-5000 מילי-שניות, כלל לא נלקח בחשבון. השגיאה מופיעה באופן מיידי, וזו הסיבה שנראה כאילו ההגדרה לא עשתה דבר.

הפתרון מורכב ממילה אחת.

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

BEGIN IMMEDIATE תופסת את נעילת הכתיבה כבר בהתחלה, לפני קריאת נתונים כלשהם. אין כאן שדרוג, לכן אין deadlock למנוע, ולכן המטפל העסוק אכן פועל והחיבור ממתין לתורו במקום להיכשל. השאירו טרנזקציות לקריאה בלבד במצב deferred. כל טרנזקציה המכילה כתיבה צריכה להיות immediate.

הסיבה השנייה לשגיאות נעילה קשה יותר לאיתור: החזקת טרנזקציית כתיבה פתוחה בזמן ביצוע פעולות איטיות. SQLite מבצעת סריאליזציה לכותבים, לכן טרנזקציה שנפתחת, קוראת ל-API חיצוני דרך הרשת, ורק אז מבצעת commit, תחסום כל כותב אחר למשך זמן הקריאה. קראו את מה שדרוש לכם, סגרו את הטרנזקציה, בצעו את הפעולה האיטית, ולאחר מכן פתחו טרנזקציית כתיבה קצרה כדי לשמור את התוצאה.

גיבוי רציף באמצעות Litestream

עותק לילי גורם לאובדן של עד יום שלם של כתיבות, והרצת cp מול מסד נתונים פעיל של SQLite עלולה להפיק עותק שלא ניתן לפתיחה. שני דברים הם בטוחים. sqlite3 app.db ".backup /path/to/backup.db" משתמש בממשק הגיבוי המקוון של SQLite ועובד מול מסד נתונים בשימוש. Litestream מרחיק לכת יותר: הוא עוקב אחר ה-WAL ושולח שינויים לאחסון אובייקטים באופן רציף, מה שמצמצם את תרחיש אובדן הנתונים הגרוע ביותר מיום שלם לכשנייה אחת.

Litestream הוא קובץ בינארי יחיד של Go שרץ לצד היישום שלכם. הוא אינו יושב בין היישום לבין מסד הנתונים. היישום שלכם כותב ל-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 היא המהדורה שדף ההתקנה הרשמי ל-Linux מתעד נכון ליולי 2026, וגרסה v0.5.15 שוחררה ב-21 ביולי 2026. שנו את הגרסה בשתי השורות כדי שתתאים ל-tag העדכני בדף ה-releases, והשתמשו בחבילת ה-arm64 המתאימה אם ה-VPS שלכם הוא מסוג arm64.

קובץ התצורה נמצא ב-/etc/litestream.yml. התחילו עם עותק מקומי (replica), כיוון שהוא מוכיח את תקינות התהליך כולו ללא צורך בפרטי גישה לענן.

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

שימו לב שהשדה הוא replica, ביחיד. גרסה 0.5 של Litestream החליפה את המערך replicas מסדרת 0.3 בבלוק replica יחיד, ותצורה המכילה שני ערכים תיכשל כעת בעת העלייה. מדריכים רבים של צד שלישי עדיין מציגים את המערך הישן, לכן העתיקו את המבנה שלעיל במקום את הדוגמה הראשונה שמופיעה בחיפוש. סדרת 0.5 גם שינתה את שם פקודת המשנה litestream wal ל-litestream ltx, כיוון שפורמט הגיבוי על הדיסק השתנה.

ודאו שהתצורה תקינה מבחינת syntax לפני שאתם מפעילים דבר מה.

sudo litestream databases -config /etc/litestream.yml

לאחר מכן, הוכיחו את תהליך ה-round trip באופן ידני. צורה זו מדלגת על קובץ התצורה ומשכפלת מסד נתונים אחד לנתיב אחד.

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

תהליך זה רץ בחזית וממשיך לפעול. בטרמינל שני, כתבו שורה ושחזרו את ה-replica לקובץ חדש.

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;"

הספירה כוללת את השורה החדשה. אם לא, השינוי טרם סונכרן: Litestream מבצע דחיפה לפי sync-interval שברירת המחדל שלו היא 1 שנייה, לכן המתינו ושחזרו שוב. אותה שנייה אחת היא גם נקודת השחזור שלכם. קריסה תגרום לאובדן של לכל היותר הכתיבות מהסנכרון האחרון, ושום תצורה לא תביא זאת לאפס.

עבור אחסון אמיתי, החליפו את בלוק ה-replica בכתובת S3 URL. זה עובד מול Amazon S3 ומול אחסון אובייקטים תואם S3 מספקים אחרים.

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

snapshot:
  interval: 24h
  retention: 24h

שמרו על פרטי הגישה מחוץ לקובץ זה. Litestream קורא את LITESTREAM_ACCESS_KEY_ID ו-LITESTREAM_SECRET_ACCESS_KEY ממשתני הסביבה, לכן הציבו אותם ב-drop-in של systemd בבעלות root ועם הרשאות 600.

ערכי ה-snapshot שלעיל הם ברירת המחדל, וערך ברירת המחדל של ה-retention מפתיע אנשים. Retention הוא משך הזמן שבו Litestream שומר snapshots והקבצים השייכים להם, ולכן הוא גם קובע כמה זמן אחורה ניתן לשחזר. עשרים וארבע שעות אומרות שמיגרציה כושלת שתגלו בבוקר יום רביעי כבר לא תהיה ניתנת לשחזור ממצב של יום שני. הגדירו retention: 168h לשבוע ושלמו על האחסון הנוסף.

וודאו את תקינות השחזור לפני שתזדקקו לו

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 מאתר את ה-replica התואם בתוך /etc/litestream.yml ומוריד אותו. הפקודה PRAGMA integrity_check מדפיסה ok עבור קובץ תקין; כל פלט אחר מעיד על כך שהעותק המשוחזר אינו שמיש. הריצו זאת לפי לוח זמנים באמצעות שירות וטיימר של systemd ובדקו את הפלט. כל עוד לא ביצעתם שחזור של גיבוי לפחות פעם אחת, אינכם יכולים לדעת אם הוא אכן עובד.

הרצת Litestream תחת systemd

חבילת ה-Debian מתקינה יחידת litestream הקוראת את /etc/litestream.yml.

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

פלט תקין מציג את שמות מסדי הנתונים מתוך קובץ התצורה ולאחר מכן נותר שקט, למעט שורות סנכרון תקופתיות. שגיאת no such file or directory מול נתיב מסד הנתונים מעידה על כך שהנתיב בקובץ התצורה שגוי, או שהתהליך אינו מורשה לקרוא אותו. כברירת מחדל, היחידה רצה כ-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 אם הקובץ כבר קיים, ולכן בטוח להריץ אותו בכל עלייה של המערכת. הוסף אותו לשורת ExecStartPre ביחידת ה-systemd של היישום שלך; כך, שרת VPS חדש ימשוך את מסד הנתונים, בעוד שרת קיים לא יבצע פעולה נוספת. ל-litestream replicate יש דגל תואם בשם -restore-if-db-not-exists, אם אתה מעדיף לרכז את ההגדרה במקום אחד.

מתי SQLite נכשל בשרת VPS

מערכות קבצים מבוססות רשת. זוהי מגבלה שלא ניתן לעקוף באמצעות הגדרות. מצב WAL מחייב את כל התהליכים המשתמשים במסד הנתונים לשתף אזור זיכרון קטן, וזהו התפקיד של הקובץ -shm. התיעוד של SQLite מציב כלל זה ללא סייגים:

כל התהליכים המשתמשים במסד נתונים חייבים להיות על אותו מחשב מארח; WAL אינו עובד על גבי מערכת קבצים מבוססת רשת.

לכן, מסד נתונים שנמצא על כונן NFS (מערכת קבצים ברשת) או שיתוף SMB עלול להשתבש, ושום pragma לא ימנע זאת. יש כאן הבחנה שמשתמשים רבים מפספסים. התקן בלוקים רשתי, שזה מה שרוב ספקי ה-VPS מצרפים כאחסון נוסף, מופיע בלינוקס ככונן רגיל עם מערכת קבצים רגילה, וזה תקין. שיתוף קבצים מותקן אינו כזה.

שרת יישומים שני. אין הגדרה שתגרום לזה לעבוד. ברגע שאתם זקוקים לשני מחשבים המשרתים את אותם הנתונים, אתם זקוקים למסד נתונים שמדבר על גבי הרשת. החליטו על המעבר הזה בעוד שיש לכם זמן לתכנן אותו.

עומסי עבודה עתירי כתיבה. כותב אחד בכל פעם הוא מאפיין של פורמט הקובץ, לא פרמטר שניתן לכוונון. כתיבות קצרות הן זולות מכיוון שכל commit הוא הוספה ל-WAL, לכן קצב העבודה תלוי יותר ב-latency של כתיבות קטנות בכונן שלכם מאשר ב-CPU. ראו NVMe מול אחסון SATA SSD ב-VPS כדי להבין איך ההבדל הזה נראה. טרנזקציות ארוכות הן הבעיה האמיתית, מכיוון שהן גורמות לכל שאר הכותבים להמתין בתור אחריהן.

שאילתות אנליטיות. SQLite הוא מאגר שורות שנבנה עבור טרנזקציות. לוח מחוונים שסורק מאה מיליון שורות הוא משימה אחרת עבור כלי אחר, והמאמר DuckDB בהשוואה ל-SQLite לעבודה בשרת מכסה היכן עובר הגבול הזה.

VACUUM תחת שכפול. פעולת VACUUM מלאה כותבת מחדש את כל קובץ מסד הנתונים, מה שאומר ש-Litestream צריך להעלות את כולו מחדש. התיעוד של Litestream ממליץ לא להריץ זאת בזמן שהשכפול פעיל. עצרו את המשכפל, בצעו vacuum, הפעילו אותו מחדש, והיערכו ל-snapshot מלא וחדש.

שני משכפלים על מסד נתונים אחד. לעולם אל תריצו שני תהליכי Litestream מול אותו מסד נתונים או מול אותו יעד שכפול. התיעוד מבהיר שמניעת מצב זה היא באחריותכם, והתוצאה היא עותק משוכפל שלא ניתן לשחזר.

מה Litestream לא מכסה

Litestream מגן על קובץ מסד הנתונים בלבד. קבצים שהועלו, הגדרות היישום, תעודות TLS (אבטחת שכבת תעבורה) וקובצי ה-unit נותרים באחריותך. מומלץ לשלב זאת עם גיבויים מוצפנים מחוץ לשרת באמצעות restic לפי לוח זמנים, וכך שני החלקים יהיו מכוסים. אם מדובר במכונה חדשה, המדריך עשר הדקות הראשונות ב-VPS חדש מכסה את הגדרת חשבון המשתמש וה-firewall, פעולות שמדריך זה מניח שכבר בוצעו.

FAQ

האם SQLite מתאים ליישום בסביבת production?

עבור יישום יחיד על שרת יחיד, התשובה היא כן, בתנאי שמפעילים מצב WAL, מגדירים busy timeout ומבצעים גיבוי רציף. המגבלות המשמעותיות הן מבניות: כותב אחד בלבד בכל רגע נתון, ומכונה מארחת אחת. יישום שעומד במגבלות אלו נהנה ממסד נתונים ללא צורך בניתוב רשת או בתהליך נפרד לניטור. יישום שאינו עומד במגבלות אלו זקוק למסד נתונים מסוג client-server, ושום כוונון לא ישנה זאת.

מדוע אני עדיין מקבל database is locked לאחר הגדרת busy_timeout?

מכיוון ש־SQLite מדלג על ה־busy handler כאשר המתנה עלולה לגרום ל-deadlock. טרנזקציה שמתחילה ב-BEGIN פשוט היא מושהית (deferred): פקודת SELECT ראשונית מכניסה אותה לטרנזקציית קריאה, ופעולת כתיבה מאוחרת יותר מחייבת שדרוג. אם חיבור אחר ביצע כתיבה בפרק הזמן הזה, SQLite מחזיר SQLITE_BUSY באופן מיידי במקום להפעיל את ה-busy handler, כיוון שצילום המצב (snapshot) של הקריאה שלך כבר אינו עדכני. התחילו כל טרנזקציה שכוללת כתיבה עם BEGIN IMMEDIATE, כך שנעילת הכתיבה תתבצע מראש וה-timeout יחול כנדרש.

האם ניתן לשמור את מסד הנתונים של SQLite על אחסון רשת?

לא על מערכת קבצים מבוססת רשת כמו NFS או SMB. מצב WAL מחייב את כל התהליכים לשתף זיכרון דרך קובץ -shm, והתיעוד של SQLite קובע שכל תהליך המשתמש במסד הנתונים חייב להימצא על אותו שרת מארח. התקן בלוקים (network block device) שמסופק על ידי ספק הענן הוא עניין שונה: מערכת ההפעלה Linux מזהה אותו כדיסק רגיל עם מערכת קבצים רגילה, ו־SQLite עובד שם ללא בעיות.

האם אני זקוק ל-Litestream אם אני כבר מריץ גיבויים ליליים?

זה תלוי בכמות הנתונים שאתה יכול להרשות לעצמך לאבד. משימה לילית משמעותה אובדן של עד עשרים וארבע שעות של כתיבות. Litestream מסנכרן נתונים בערך פעם בשנייה, כך שקריסה תעלה לך לכל היותר בשנייה האחרונה של הנתונים. הוא גם בטוח יותר מאשר העתקת קובץ מסד הנתונים באמצעות cp, פעולה שעלולה לתפוס את מסד הנתונים באמצע תהליך כתיבה. Litestream מכסה רק את מסד הנתונים, לכן מומלץ להמשיך להריץ גיבוי קבצים כללי במקביל.