Jinsi ya kutumia SQLite kwenye VPS kwa uzalishaji

SQLite inapokuwa hifadhidata sahihi ya uzalishaji kwenye VPS

Kuendesha SQLite katika mazingira ya uzalishaji kwenye VPS ni chaguo sahihi kwa programu nyingi ndogo, na sababu ni rahisi: mchakato mmoja kwenye mashine moja unaoandika kwenye faili moja hauhitaji seva ya hifadhidata. Hakuna daemon ya kusimamia, hakuna port ya kulinda kwa firewall, hakuna password ya kubadilisha, wala mashine ya pili ya kuhakikisha inaendelea kufanya kazi. Query ni mwito wa function badala ya safari ya kwenda na kurudi kwenye mtandao, kwa hiyo ukurasa unaotekeleza queries arobaini hugharimu miito ya function arobaini.

Gharama hiyo ina mipaka iliyo wazi na ni halisi. SQLite inaruhusu writer mmoja tu kwa wakati mmoja kwenye faili nzima ya hifadhidata, na faili hilo haliwezi kushirikiwa kati ya mashine mbili. Mipaka yote miwili inafaa kwa VPS moja inayoendesha programu moja. Mipaka yote miwili inakuwa kizuizi kikubwa mara tu unapozidi muundo huo. Mwongozo huu unaeleza settings zinazofanya SQLite iwe salama kwenye seva, backup endelevu kwa kutumia Litestream, na wakati wa kuacha kutumia SQLite.

Sakinisha command line tool kwanza. Kila kitu hapa chini kilitekelezwa kwenye Ubuntu 24.04.

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

Hiyo huchapisha toleo linaloanza na 3. likifuatiwa na tarehe ya build na source hash. Ubuntu 24.04 inasambaza SQLite 3.45.1 kufikia Oktoba 2026. Huenda programu yako haitumii binary hii: runtime nyingi za lugha hujumuisha nakala yao ya SQLite library, mara nyingi ikiwa mpya zaidi, kwa hiyo hakikisha toleo ambalo database driver yako inaripoti kabla ya kutegemea feature mpya.

Kwa nini WAL mode ndilo jambo la kwanza unalopaswa kubadilisha

Kwa chaguo-msingi, SQLite hutumia rollback journal. Kabla ya kubadilisha ukurasa, hunakili ukurasa asilia kwenye faili la -journal, kisha hufanya marekebisho kwenye hifadhidata yenyewe. Ili kufanya hivyo kwa usalama, hufunga faili zima kwa exclusive lock, hivyo kila msomaji husubiri wakati wowote uandishi unapofanyika. Kwenye kompyuta ya kibinafsi, hakuna anayegundua hili. Kwenye seva ya wavuti, uandishi mmoja wa polepole husimamisha kila ombi linalohitaji hifadhidata hiyo.

WAL (write-ahead log) mode hubadili utaratibu huu. Mwandishi huongeza kurasa mpya kwenye faili tofauti la -wal na kuiacha hifadhidata kuu ikiwa salama. Wasomaji huendelea kusoma faili kuu katika snapshot waliyoanza nayo, hivyo wasomaji hawamzuii mwandishi na mwandishi hawazuii wasomaji. Baadaye, checkpoint hunakili kurasa zilizokusanywa za WAL kurudi kwenye hifadhidata kuu. Mabadiliko haya pekee ndiyo sababu kuu inayofanya SQLite iweze kutumika nyuma ya programu ya wavuti.

Washa hali ya WAL na uthibitishe kuwa imekubali

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

Amri hiyo huchapisha wal. Tokeo hilo si mapambo. PRAGMA journal_mode hurejesha hali ambayo hifadhidata inayo kwa sasa, kwa hivyo jibu la delete linamaanisha kuwa mabadiliko yameshindikana na bado uko kwenye rollback journal.

Hali ya WAL ni ya kudumu. Ni flag iliyo kwenye header ya hifadhidata badala ya kuwa mpangilio wa muunganisho, kwa hivyo unaifanyia kazi mara moja kwa kila faili ya hifadhidata na kila muunganisho unaofuata huirithi, hata baada ya reboot. Thibitisha hilo kwa muunganisho mpya.

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

Sasa tengeneza jedwali na uangalie kinachoonekana kwenye diski.

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/

Kuna faili tatu sasa: app.db, app.db-wal na app.db-shm. Faili ya -wal huhifadhi kurasa zilizokamilishwa (committed) ambazo hazijafanyiwa checkpoint bado. Faili ya -shm ni index ya kumbukumbu iliyoshirikiwa ambayo kila muunganisho huichora (map) ili wote wakubaliane kuhusu yaliyomo kwenye WAL. Zote mbili ni mali ya hifadhidata na si faili za muda (scratch files). Nakili app.db pekee wakati programu inafanya kazi na utapata faili inayokosa kila commit ya hivi karibuni. Futa app.db na uache nyingine mbili zikiwa mahali pake na SQLite itatumia kurasa hizo za zamani za WAL kwenye faili yoyote mpya itakayoonekana kwa jina hilo, ambayo ndiyo njia ambayo watu huharibu hifadhidata mpya wakati wakijaribu kuweka upya (reset) moja.

Mipangilio ya muunganisho inayohitajika na kila programu ya uzalishaji

Ni journal_mode pekee inayohifadhiwa kwenye database. Kila mpangilio mwingine hapa chini ni wa kila muunganisho, kumaanisha kuwa programu yako lazima iutekeleze kwenye kila muunganisho unaofungua, ikijumuisha kila muunganisho ambao pool huunda kwa nyuma.

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

busy_timeout = 5000 huiambia SQLite iendelee kujaribu tena database iliyofungwa kwa hadi milisekunde 5000 kabla ya kurejesha database is locked. Chaguo-msingi ni 0, kwa hivyo kwa kawaida SQLite hushindwa mara moja wakati waandishi wawili wanapogongana. Kuweka thamani hii moja huondoa makosa mengi ya kufunga (lock errors) ambayo mara nyingi hupewa lawama SQLite yenyewe.

synchronous = NORMAL ndio mpangilio sahihi katika hali ya WAL, na ni muhimu kuelewa mabadilishano yake. Katika FULL, SQLite hufanya fsync kwenye WAL katika kila commit. Katika NORMAL, husawazisha (sync) wakati wa checkpoints badala yake. Nyaraka za SQLite ziko wazi kuhusu kile unachopoteza: miamala (transactions) haidumu tena baada ya kukatika kwa umeme au kuzimwa kwa ghafla. Database haiwezi kuharibika kwa sababu ya kupoteza umeme huko, unapoteza tu commits za mwisho ambazo hazikuwa zimefika kwenye diski. Kwenye VPS, hiyo kwa kawaida ni biashara sahihi, kwa sababu huondoa fsync kutoka kwenye njia ya kila uandishi mmoja.

foreign_keys = ON imezimwa kwa chaguo-msingi kwa ajili ya utangamano wa nyuma, na ni ya kila muunganisho. Schema iliyojaa vifungu vya REFERENCES haitekelezi chochote hadi kila muunganisho uwashe mpangilio huu.

Mpangilio mwingine mmoja ni muhimu baadaye tu. SQLite hufanya checkpoints kiotomatiki mara tu WAL inapokua zaidi ya kurasa 1000, na kazi hiyo hufanywa na muunganisho wowote unaomaliza muamala wakati huo. Hiyo ni sawa kwa yenyewe. Inakuwa swali wakati Litestream inapoendesha, kwa sababu Litestream inataka udhibiti wa wakati checkpoints zinapotokea.

Kwa nini database is locked bado hutokea baada ya kuweka busy_timeout

Hii ndiyo hitilafu inayowafanya watu kurudi kutumia Postgres, na ina sababu moja mahususi.

Busy timeout huweka busy handler, na SQLite haiahidi kuuiita.

Ikiwa SQLite itaamua kuwa kuita busy handler kunaweza kusababisha deadlock, itarejesha SQLITE_BUSY kwenye programu badala ya kuita busy handler.

Deadlock inayojaribu kuepukwa hutokea wakati transaction inapopandishwa daraja (upgrade). BEGIN ya kawaida katika SQLite inamaanisha BEGIN DEFERRED. Ikiwa taarifa ya kwanza baada yake ni SELECT, uko kwenye read transaction. Wakati UPDATE ya baadaye katika transaction hiyo hiyo inahitaji kuwa write transaction, na muunganisho mwingine umeandika tangu usomaji wako ulipoanza, SQLite haiwezi kukuweka ukisubiri, kwa sababu snapshot yako imeshapitwa na wakati na kusubiri kutasababisha tu miunganisho yote miwili kufungiana (deadlock). Nyaraka zinaeleza matokeo moja kwa moja:

Taarifa za uandishi zinazofuata zitapandisha daraja transaction hiyo kuwa write transaction ikiwa inawezekana, au kurejesha SQLITE_BUSY.

Timeout yako ya milisekunde 5000 haitumiwi kamwe. Hitilafu inakuja mara moja, ndiyo maana inaonekana kama mpangilio haukufanya kazi.

Suluhisho ni neno moja.

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

BEGIN IMMEDIATE huchukua write lock mwanzoni, kabla ya kusoma chochote. Hakuna upandishaji daraja, kwa hivyo hakuna deadlock ya kuepuka, hivyo busy handler inafanya kazi na muunganisho husubiri zamu yake badala ya kufeli. Acha read-only transactions zikiwa deferred. Transaction yoyote inayohusisha uandishi inapaswa kuwa immediate.

Sababu ya pili ya hitilafu za lock ni ngumu zaidi kuigundua: kuacha write transaction ikiwa wazi wakati wa kazi za polepole. SQLite hupanga waandishi kwa mtiririko (serialise), kwa hivyo transaction inayofunguka, kupiga simu ya API ya nje kupitia mtandao, na kisha kufanya commit itazuia kila mwandishi mwingine kwa muda wote wa simu hiyo. Soma unachohitaji, funga transaction, fanya kazi ya polepole, kisha fungua write transaction fupi ili kuhifadhi matokeo.

Hifadhi rudufu endelevu kwa kutumia Litestream

Nakala ya kila usiku inaweza kupoteza maandishi ya hadi siku moja, na kuendesha cp dhidi ya hifadhidata ya SQLite inayotumika kunaweza kutoa nakala ambayo haitafunguka. Kuna njia mbili salama. sqlite3 app.db ".backup /path/to/backup.db" hutumia kiolesura cha SQLite cha kuhifadhi rudufu mtandaoni na hufanya kazi dhidi ya hifadhidata inayotumika. Litestream huenda zaidi: hufuatilia WAL na kutuma mabadiliko kwenye object storage mfululizo. Hii hupunguza upotezaji wa data wa hali mbaya zaidi kutoka siku moja hadi takriban sekunde moja.

Litestream ni binary moja ya Go inayoendesha pamoja na programu yako. Haiwekiwi kati ya programu na hifadhidata. Programu yako huandika kwenye SQLite kama kawaida, na Litestream husoma WAL na kupakia mabadiliko yaliyofanyika.

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 bado ndiyo release iliyoandikwa kwenye ukurasa rasmi wa usakinishaji wa Linux kufikia October 2026. Releases mpya zimefuata: v0.5.15 tarehe 21 July 2026, na v0.5.17, tag mpya zaidi, tarehe 31 August 2026. Badilisha version katika mistari yote miwili ilingane na tag ya sasa kwenye ukurasa wa releases. Tumia package inayolingana ya arm64 badala yake ikiwa VPS yako ni arm64.

Faili ya configuration iko kwenye /etc/litestream.yml. Anza na local file replica, kwa sababu hii inathibitisha mzunguko mzima bila kuhitaji cloud credentials.

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

Kumbuka kwamba field ni replica, ikiwa katika umoja. Litestream 0.5 ilibadilisha array ya replicas kutoka series ya 0.3 na kuweka replica block moja. Configuration yenye entries mbili sasa hushindwa wakati wa kuanza. Guides nyingi za wahusika wengine bado zinaonyesha array ya zamani. Kwa hiyo, nakili muundo ulio hapo juu badala ya mfano wa kwanza unaopatikana kwenye utafutaji. Series ya 0.5 pia ilibadilisha jina la subcommand litestream wal kuwa litestream ltx, kwa sababu format ya backup iliyo kwenye diski ilibadilika.

Hakikisha configuration inasomeka kabla ya kuwezesha chochote.

sudo litestream databases -config /etc/litestream.yml

Kisha thibitisha mzunguko wa kwenda na kurudi mwenyewe. Muundo huu huruka faili ya configuration na ku-replicate database moja kwenda kwenye path moja.

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

Hii huendesha katika foreground na huendelea kuendesha. Katika shell ya pili, andika row moja kisha restore replica kwenye faili mpya.

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 inajumuisha row mpya. Ikiwa haiijumuishi, mabadiliko bado hayajasynciwa: Litestream husukuma kwa sync-interval ambayo default yake ni sekunde 1. Subiri kisha ufanye restore tena. Sekunde hiyo moja ndiyo recovery point yako pia. Crash hupoteza maandishi ya muda usiozidi sync interval ya mwisho. Hakuna configuration inayoweza kufanya muda huo uwe sifuri.

Kwa storage halisi, badilisha replica block iwe S3 URL. Hii hufanya kazi na Amazon S3 na object storage inayooana na S3 kutoka kwa providers wengine.

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

snapshot:
  interval: 24h
  retention: 24h

Usiweke credentials kwenye faili hiyo. Litestream husoma LITESTREAM_ACCESS_KEY_ID na LITESTREAM_SECRET_ACCESS_KEY kutoka kwenye environment. Ziweke kwenye systemd drop-in inayomilikiwa na root na yenye mode 600.

Thamani za snapshot zilizo hapo juu ndizo defaults, na default ya retention huwashangaza watu. Retention ni muda ambao Litestream huhifadhi snapshots na files zinazohusiana nazo. Kwa hiyo, pia huonyesha unaweza kurejesha data ya zamani kwa umbali gani wa wakati. Saa ishirini na nne inamaanisha migration mbaya unayoigundua Jumatano asubuhi haiwezi tena kurejeshwa kutoka hali ya Jumatatu. Katika Litestream 0.5, retention ni setting ya kimataifa ndani ya root snapshot block, si ya kila replica. Kwa wiki moja, badilisha block hiyo iwe retention: 168h na ulipe gharama ya storage ya ziada. Mstari wa retention: ndani ya replica block ni syntax ya series ya 0.3. Litestream 0.5 huupuuza bila kutoa error na huendelea kutumia default ya saa 24.

Thibitisha urejeshaji kabla ya kuuhitaji

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

Ukipewa njia ya database, litestream restore hutafuta replica inayolingana katika /etc/litestream.yml na kuipakua. PRAGMA integrity_check huchapisha ok kwenye faili iliyo salama, na matokeo mengine yoyote yanamaanisha kuwa nakala iliyorejeshwa haifai kutumika. Endesha hii kwa ratiba ukitumia systemd service na timer na usome matokeo yake. Hadi utakapofanikiwa kurejesha backup mara moja, huna uhakika kama inafanya kazi.

Endesha Litestream chini ya systemd

Kifurushi cha Debian husakinisha unit ya litestream inayosoma /etc/litestream.yml.

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

Output sahihi hutaja kila database kutoka kwenye config, kisha hubaki kimya isipokuwa mistari ya sync ya vipindi. Error ya no such file or directory kwenye path ya database yako inamaanisha kuwa path iliyo kwenye config si sahihi, au mchakato hauwezi kuisoma. Kwa default, unit huendeshwa kama root, jambo lenye privileges nyingi kuliko kazi hii inavyohitaji. Litestream lazima iweze kusoma na kuandika database pamoja na directory inayoihifadhi, kwa sababu hufanya kazi na files za -wal na -shm zilizo karibu na database yako. Kwa hiyo, iendeshe kwa user account ambayo application yako tayari hutumia, yaani appuser katika mifano hii.

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

Tumia usanidi huo kwa sudo systemctl daemon-reload na sudo systemctl restart litestream. Kuweka account maalum ya service yenye privileges chache huchukua dakika chache. Hii ndiyo tofauti kati ya backup agent na mchakato wa pili unaoendeshwa kama root kwenye seva.

Mpangilio mmoja ni muhimu ikiwa utawahi kujenga upya mashine kuanzia mwanzo. Unataka database irejeshwe kabla ya application kuanza. litestream restore inakubali -if-db-not-exists, ambayo hutoka kwa exit code 0 ikiwa file tayari lipo. Kwa hiyo, ni salama kuiendesha kila boot. Weka kwenye mstari wa ExecStartPre wa unit ya application yako. VPS mpya itapakua database, huku VPS iliyopo ikiwa tayari bila kufanya chochote. litestream replicate ina flag inayolingana ya -restore-if-db-not-exists ikiwa ungependa kuiweka sehemu moja.

SQLite inapowasha kwenye VPS

Mifumo ya faili ya mtandao. Hiki ndicho kikomo ambacho huwezi kukiepuka kwa usanidi. Modi ya WAL inahitaji kila mchakato unaotumia database kushiriki eneo dogo la kumbukumbu, ambalo hutolewa na faili ya -shm. Documentation ya SQLite inaeleza sheria hiyo bila masharti:

Michakato yote inayotumia database lazima iwe kwenye kompyuta mwenyeji moja; WAL haifanyi kazi kupitia mfumo wa faili wa mtandao.

Kwa hiyo, database iliyo kwenye NFS iliyomountiwa (network file system) au share ya SMB inaweza kuharibika, na hakuna pragma inayozuia hilo. Kuna tofauti hapa ambayo watu wengi huikosa. Kifaa cha block cha mtandao, ambacho ndicho VPS providers wengi huambatisha kama storage ya ziada, huonekana kwa Linux kama disk ya kawaida yenye filesystem ya kawaida, na hilo ni salama. File share iliyomountiwa si salama.

Seva ya pili ya programu. Hakuna setting inayofanya hili lifanye kazi. Ukihitaji mashine mbili zihudumie data ileile, unahitaji database inayowasiliana kupitia mtandao. Amua kuhusu mabadiliko hayo ukiwa bado una muda wa kuyapanga.

Mizigo yenye kuandika sana. Mwandishi mmoja kwa wakati mmoja ni sifa ya muundo wa faili, si setting inayoweza kurekebishwa. Maandishi mafupi ni nafuu kwa sababu kila commit huongezwa kwenye WAL, kwa hiyo throughput inategemea zaidi latency ya disk katika maandishi madogo kuliko CPU yako. Tazama NVMe dhidi ya storage ya SATA SSD kwenye VPS ili kuona tofauti hiyo. Transactions ndefu ndizo tatizo halisi, kwa sababu huweka kila mwandishi mwingine kwenye foleni nyuma yake.

Queries za uchanganuzi. SQLite ni row store iliyoundwa kwa transactions. Dashboard inayochanganua rows milioni mia moja ni kazi tofauti kwa tool tofauti, na DuckDB ikilinganishwa na SQLite kwa matumizi ya seva inaeleza mpaka huo unapopita.

VACUUM wakati wa replication. VACUUM kamili huandika upya faili nzima ya database, jambo linalobatilisha ufuatiliaji wa kiwango cha page ambao Litestream inategemea, na documentation ya Litestream inashauri dhidi ya kuiendesha in place wakati replication inaendelea. Inapendekeza VACUUM INTO, ambayo huandika nakala iliyocompactiwa kwenye faili tofauti na kuacha ya awali bila kuibadilisha. Ikiwa lazima uendeshe vacuum in place, utaratibu ulioandikwa kwenye documentation ni mrefu kuliko restart: simamisha replicator, endesha vacuum, futa directory fiche ya ufuatiliaji ya Litestream iliyo karibu na database pamoja na data ya replica ya remote iliyopo, kisha iwashe tena ili ianze na full snapshot mpya. Hatua hiyo ya mwisho hutupa historia ya restore uliyokuwa nayo.

Replicators wawili kwenye database moja. Usiendeshe kamwe michakato miwili ya Litestream dhidi ya database ileile au destination ileile ya replica. Documentation inaeleza wazi kwamba kuzuia hali hii ni jukumu lako, na matokeo yake ni replica ambayo huwezi kuirestore.

Mambo ambayo Litestream haishughulikii

Litestream hulinda faili ya database pekee na si kitu kingine. Faili zilizopakiwa, usanidi wa programu, vyeti vya TLS (transport layer security) na unit files ni wajibu wako kuzisimamia. Iunganishe na backups zilizosimbwa nje ya seva kwa kutumia restic kulingana na ratiba ili sehemu zote mbili ziwe zinalindwa. Ikiwa mashine ni mpya, dakika kumi za kwanza kwenye VPS mpya inashughulikia akaunti ya mtumiaji na kazi ya firewall ambayo mwongozo huu unachukulia kuwa imeshakamilika.

FAQ

Je, SQLite inafaa kwa programu ya uzalishaji (production)?

Kwa programu moja kwenye seva moja, ndiyo, mradi uwashe WAL mode, uweke busy timeout, na ufanye backup mfululizo. Vikwazo muhimu ni vya kimuundo: mwandishi mmoja kwa wakati mmoja, na mashine moja ya mwenyeji (host). Programu inayokidhi vigezo hivyo hupata database isiyo na network hop na isiyo na mchakato tofauti wa kufuatilia. Programu isiyokidhi vigezo hivyo inahitaji database ya aina ya client-server, na hakuna marekebisho yoyote yatakayobadilisha ukweli huo.

Kwa nini bado napata database is locked baada ya kuweka busy_timeout?

Kwa sababu SQLite huruka busy handler wakati kusubiri kunaweza kusababisha deadlock. Transaction inayoanza na BEGIN tupu huahirishwa: SELECT ya kwanza huiweka kwenye read transaction, na uandishi wa baadaye lazima ufanye upgrade. Ikiwa muunganisho mwingine uliandika katikati, SQLite hurejesha SQLITE_BUSY mara moja badala ya kuita busy handler yako, kwa sababu read snapshot yako imeshapitwa na wakati. Anza transaction yoyote itakayoandika kwa BEGIN IMMEDIATE ili write lock ichukuliwe mapema na timeout itumike.

Je, ninaweza kuhifadhi database yangu ya SQLite kwenye network storage?

Hapana, kwenye network filesystem kama NFS au SMB. WAL mode inahitaji michakato yote kushiriki kumbukumbu kupitia faili la -shm, na nyaraka za SQLite zinasema kuwa kila mchakato unaotumia database lazima uwe kwenye kompyuta moja ya mwenyeji. Network block device iliyounganishwa na mtoa huduma wako ni kitu tofauti: Linux huona diski ya kawaida yenye filesystem ya kawaida, na SQLite hufanya kazi hapo.

Je, ninahitaji Litestream ikiwa tayari ninafanya backups za kila usiku?

Inategemea kiasi cha data unachoweza kumudu kupoteza. Kazi ya kila usiku inamaanisha kupoteza hadi saa ishirini na nne za uandishi. Litestream husawazisha takriban mara moja kwa sekunde, kwa hivyo crash itakugharimu takriban sekunde ya mwisho. Pia ni salama zaidi kuliko kunakili faili la database kwa cp, ambayo inaweza kunasa database katikati ya uandishi. Litestream inashughulikia database pekee, kwa hivyo endelea na backup ya jumla ya faili pembeni yake.