SQLite kwenye VPS kwa uzalishaji: Mipangilio na mipaka

Wakati SQLite ni hifadhidata sahihi ya uzalishaji kwenye VPS

Kuendesha SQLite katika mazingira ya uzalishaji kwenye VPS ni chaguo sahihi kwa programu nyingi ndogo. Sababu ni rahisi: mchakato mmoja kwenye mashine moja unaoandika kwenye faili moja hauhitaji seva ya hifadhidata. Hakuna daemon ya kusimamia, hakuna port ya kuweka kwenye firewall, hakuna password ya kubadilisha, na hakuna mashine ya pili ya kuendelea kuiendesha. Query ni mwito wa kazi badala ya mzunguko wa mawasiliano kwenye mtandao. Kwa hiyo, ukurasa unaoendesha query 40 hukugharimu miito 40 ya kazi.

Gharama hii ni finyu lakini halisi. SQLite huruhusu mwandishi mmoja tu kwa wakati mmoja katika faili nzima ya hifadhidata, na faili hiyo haiwezi kushirikiwa kati ya mashine mbili. Vizuizi vyote viwili havileti tatizo kwa VPS moja inayoendesha programu moja. Lakini vyote viwili vinakuwa vizuizi visivyovumilika mara tu unapozidi muundo huo. Mwongozo huu unashughulikia mipangilio inayofanya SQLite iwe salama kwenye seva, hifadhi rudufu endelevu kwa kutumia Litestream, na wakati wa kuacha kutumia muundo huu.

Sakinisha kwanza zana ya mstari wa amri. Kila kitu hapa chini kiliendeshwa kwenye Ubuntu 24.04.

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

Hiyo huchapisha toleo linaloanza na 3., likifuatiwa na tarehe ya ujenzi na heshi ya chanzo. Ubuntu 24.04 inasafirisha SQLite 3.45.1 kufikia Julai 2026. Huenda programu yako haitumii binary hii: mazingira mengi ya utekelezaji wa lugha hujumuisha nakala yao ya maktaba ya SQLite, ambayo mara nyingi huwa mpya zaidi. Kwa hiyo, kagua toleo linaloripotiwa na driver ya hifadhidata yako kabla ya kutegemea kipengele cha hivi karibuni.

Kwa nini hali ya WAL ndiyo jambo la kwanza kubadilisha

Kwa chaguo-msingi, SQLite hutumia jarida la kurejesha mabadiliko. Kabla ya kubadilisha ukurasa, hunakili ukurasa wa awali kwenye faili la -journal, kisha huhariri hifadhidata moja kwa moja. Ili kufanya hivyo kwa usalama, hufunga faili lote kwa kufuli la kipekee. Kwa hiyo, kila msomaji husubiri wakati uandishi wowote unaendelea. Kwenye kompyuta mpakato, hili kwa kawaida halionekani. Kwenye seva ya wavuti, uandishi mmoja wa polepole husimamisha kila ombi linalogusa hifadhidata.

Hali ya WAL (write-ahead log) hubadilisha mpangilio huo. Mwandishi huongeza kurasa mpya kwenye faili tofauti la -wal na huacha hifadhidata kuu bila kubadilishwa. Wasomaji huendelea kusoma faili kuu kulingana na nakala ya hali iliyokuwapo walipoanza. Kwa hiyo, wasomaji hawamzuii mwandishi, na mwandishi hawazuii wasomaji. Baadaye, checkpoint hunakili kurasa za WAL zilizokusanywa na kuzirudisha kwenye hifadhidata kuu. Mabadiliko haya ndiyo sehemu kubwa ya kinachofanya SQLite itumike nyuma ya programu ya wavuti.

Washa hali ya WAL na thibitisha kuwa imehifadhiwa

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

Amri hiyo huchapisha wal. Matokeo hayo si pambo. PRAGMA journal_mode hurudisha hali ambayo hifadhidata iko ndani yake kwa kweli, kwa hiyo jibu la delete linamaanisha kuwa mabadiliko yameshindwa na bado unatumia rollback journal.

Hali ya WAL hudumu. Ni bendera iliyo kwenye kichwa cha hifadhidata, si mpangilio wa muunganisho. Kwa hiyo huiwasha mara moja kwa kila faili ya hifadhidata, na kila muunganisho unaofuata hurithi hali hiyo, hata baada ya kuwasha upya mfumo. Thibitisha hilo kwa muunganisho mpya.

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

Sasa unda 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/

Sasa kuna faili tatu: app.db, app.db-wal na app.db-shm. Faili ya -wal huhifadhi kurasa zilizothibitishwa ambazo bado hazijawekwa kwenye checkpoint. Faili ya -shm ni faharasa ya kumbukumbu inayoshirikiwa ambayo kila muunganisho huweka kwenye nafasi yake ya kumbukumbu, ili yote ikubaliane kuhusu yaliyomo kwenye WAL. Faili zote mbili ni sehemu ya hifadhidata na si faili za muda. Ukibakiza app.db peke yake wakati programu inaendelea kufanya kazi, utapata faili inayokosa kila commit ya hivi karibuni. Ukifuta app.db na kuacha faili mbili nyingine mahali pake, SQLite itatumia kurasa hizo zilizopitwa na wakati za WAL kwenye faili mpya yoyote itakayotokea chini ya jina hilo. Hivyo watu huharibu hifadhidata mpya wanapojaribu kuiweka upya.

Mipangilio ya muunganisho ambayo kila programu ya uzalishaji inahitaji

Ni journal_mode pekee inayohifadhiwa kwenye hifadhidata. Kila mpangilio mwingine hapa chini ni wa kila muunganisho. Hii inamaanisha kuwa programu yako lazima iutekeleze kwenye kila muunganisho inayofungua, ikiwemo kila muunganisho ambao pool huunda chinichini.

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

busy_timeout = 5000 huiambia SQLite iendelee kujaribu kufikia hifadhidata iliyofungwa kwa muda wa hadi milisekunde 5000 kabla ya kurejesha database is locked. Chaguo-msingi ni 0. Kwa hiyo, kwa chaguo-msingi, SQLite hushindwa mara moja wakati wa kwanza waandishi wawili wanapokutana. Kuweka thamani hii moja huondoa makosa mengi ya kufungwa ambayo kwa kawaida huhusishwa na SQLite yenyewe.

synchronous = NORMAL ndiyo mipangilio sahihi katika hali ya WAL, na ni muhimu kuelewa mabadilishano yake. Katika FULL, SQLite huita fsync kwenye WAL baada ya kila commit. Katika NORMAL, husawazisha data wakati wa checkpoints badala yake. Nyaraka za SQLite zinaeleza wazi unachopoteza: miamala si thabiti tena baada ya kukatika kwa umeme au kuwashwa upya kwa nguvu. Hifadhidata haiwezi kuharibika kwa sababu ya kupotea kwa umeme huko; unapoteza tu commits za mwisho ambazo hazikuwa zimefika kwenye diski. Kwenye VPS, kwa kawaida hilo ndilo badilishano linalofaa, kwa sababu linaondoa fsync moja kwenye mchakato wa kila uandishi.

foreign_keys = ON imezimwa kwa chaguo-msingi kwa ajili ya uoanifu wa matoleo ya zamani, na ni ya kila muunganisho. Schema yenye vifungu vingi vya REFERENCES hailazimishi chochote hadi kila muunganisho iwashie mpangilio huu.

Mpangilio mwingine huwa muhimu baadaye pekee. SQLite huanzisha checkpoints kiotomatiki mara WAL inapokua na kuzidi kurasa 1000. Kazi hiyo hufanywa na muunganisho wowote unaomaliza muamala wakati huo. Hilo ni sawa lenyewe. Linakuwa suala wakati Litestream inaendeshwa, kwa sababu Litestream inataka kudhibiti wakati checkpoints zinapotokea.

Kwa nini database is locked bado hutokea baada ya kuweka busy_timeout

Hili ndilo kosa linalowafanya watu warudi Postgres, na lina sababu moja mahususi.

Muda wa kusubiri busy huweka busy handler, lakini SQLite haihakikishi kuwa itaitekeleza.

SQLite ikibaini kuwa kuiita busy handler kunaweza kusababisha deadlock, itarudisha SQLITE_BUSY kwa programu badala ya kuiita busy handler.

Deadlock inayozuiwa hutokea muamala unapopanuliwa. BEGIN tupu katika SQLite inamaanisha BEGIN DEFERRED. Ikiwa taarifa ya kwanza baada yake ni SELECT, uko katika muamala wa kusoma. UPDATE ya baadaye katika muamala huohuo inapohitaji kubadilika kuwa muamala wa kuandika, na muunganisho mwingine umeandika tangu usomaji wako uanze, SQLite haiwezi kukusubiri. Snapshot yako tayari imepitwa na wakati, na kusubiri kungekwamisha miunganisho hiyo miwili dhidi ya kila mmoja. Nyaraka zinaeleza matokeo moja kwa moja:

Taarifa za kuandika zinazofuata zitaongeza muamala kuwa muamala wa kuandika ikiwezekana, au zirudishe SQLITE_BUSY.

Muda wako wa kusubiri wa millisekunde 5000 hauhusishwi kamwe. Kosa hutokea mara moja, ndiyo maana inaonekana kana kwamba 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 upanuzi wa muamala, kwa hiyo hakuna deadlock ya kuepuka. Busy handler hutumika, na muunganisho husubiri zamu yake badala ya kushindwa. Acha miamala ya kusoma pekee iwe deferred. Muamala wowote unaojumuisha uandishi unapaswa kuwa immediate.

Sababu ya pili ya makosa ya lock ni ngumu zaidi kugundua: kuweka muamala wa kuandika wazi wakati wa kazi inayochukua muda. SQLite huweka waandishi katika mfuatano mmoja, kwa hiyo muamala unaofunguka, kuita API ya nje kupitia mtandao, kisha kufanya commit utawazuia waandishi wengine wote kwa muda wote wa mwito huo. Soma unachohitaji, funga muamala, fanya kazi inayochukua muda, kisha fungua muamala mfupi wa kuandika ili kuhifadhi matokeo.

Hifadhi rudufu endelevu kwa kutumia Litestream

Nakala ya kila usiku inaweza kupoteza hadi siku moja ya mabadiliko, na kuendesha cp dhidi ya hifadhidata hai ya SQLite kunaweza kutengeneza 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 kupakia mabadiliko kwenye hifadhi ya vitu mfululizo. Hivyo, upotevu wa juu zaidi wa data hupungua kutoka siku moja hadi takriban sekunde moja.

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

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 ndiyo toleo lililoandikwa kwenye ukurasa rasmi wa usakinishaji wa Linux kufikia July 2026, na v0.5.15 ilifuata tarehe 21 July 2026. Badilisha toleo katika mistari yote miwili ili lilingane na tagi ya sasa kwenye ukurasa wa matoleo. Tumia kifurushi kinacholingana cha arm64 badala yake ikiwa VPS yako ni arm64.

Faili ya usanidi iko katika /etc/litestream.yml. Anza na replica ya faili ya ndani, kwa sababu hii inathibitisha mchakato mzima bila kuhitaji vitambulisho vya huduma ya wingu.

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

Kumbuka kuwa sehemu hiyo ni replica, katika umoja. Litestream 0.5 ilibadilisha array ya replicas kutoka mfululizo wa 0.3 na kuwa kizuizi kimoja cha replica. Usanidi wenye maingizo mawili sasa hushindwa wakati wa kuanza. Miongozo mingi ya wahusika wengine bado huonyesha array ya zamani. Kwa hiyo, nakili muundo ulio hapo juu badala ya mfano wa kwanza unaopatikana kwenye utafutaji. Mfululizo wa 0.5 pia ulibadilisha jina la subcommand litestream wal kuwa litestream ltx, kwa sababu muundo wa hifadhi ya nakala kwenye diski ulibadilika.

Thibitisha kuwa usanidi unatambulika kabla ya kuwezesha chochote.

sudo litestream databases -config /etc/litestream.yml

Kisha thibitisha mzunguko mzima kwa mkono. Muundo huu huruka faili ya usanidi na kuiga hifadhidata moja hadi njia moja.

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

Hii huendesha katika foreground na kuendelea kufanya kazi. Katika shell ya pili, andika row na urejeshe replica kwenye faili jipya.

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

Hesabu inajumuisha row mpya. Ikiwa haijumuishi, mabadiliko bado hayajasawazishwa. Litestream husukuma mabadiliko kwa sync-interval ambayo kwa kawaida ni sekunde 1. Subiri kisha urejeshe tena. Sekunde hiyo moja ndiyo pia sehemu yako ya urejeshaji. Mfumo ukiharibika, utapoteza kwa kiwango cha juu mabadiliko yaliyoandikwa tangu muda wa mwisho wa usawazishaji. Hakuna usanidi unaoweza kupunguza muda huo hadi sifuri.

Kwa hifadhi halisi, badilisha kizuizi cha replica kwa URL ya S3. Hii hufanya kazi na Amazon S3 na pia hifadhi ya vitu inayooana na S3 kutoka kwa watoa huduma 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 vitambulisho ndani ya faili hiyo. Litestream husoma LITESTREAM_ACCESS_KEY_ID na LITESTREAM_SECRET_ACCESS_KEY kutoka kwenye mazingira ya mfumo. Viweke katika systemd drop-in inayomilikiwa na root na yenye mode 600.

Thamani za snapshot zilizo hapo juu ndizo chaguo-msingi, na chaguo-msingi la retention huwashangaza watu. Retention ni muda ambao Litestream huhifadhi snapshots na faili zinazohusiana nazo. Kwa hiyo, huamua pia umbali wa nyuma ambao unaweza kurejesha. Saa ishirini na nne humaanisha kuwa uhamishaji mbaya unaogunduliwa Jumatano asubuhi hauwezi tena kurejeshwa kutoka hali ya Jumatatu. Weka retention: 168h kwa wiki moja na ulipe gharama ya hifadhi ya ziada.

Thibitisha urejeshaji kabla hujauhitaji

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

Kwa kutumia njia ya hifadhidata, litestream restore hutafuta nakala pacha inayolingana katika /etc/litestream.yml na kuipakua. PRAGMA integrity_check huchapisha ok kwenye faili salama, na matokeo mengine yoyote yanamaanisha kuwa nakala iliyorejeshwa haiwezi kutumika. Endesha hili kwa ratiba ukitumia huduma na kipima muda cha systemd, kisha soma matokeo. Mpaka urejeshe nakala rudufu mara moja, hujui kama inafanya kazi.

Kuendesha Litestream chini ya systemd

Kifurushi cha Debian husakinisha kitengo cha litestream kinachosoma /etc/litestream.yml.

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

Matokeo yenye afya hutaja kila hifadhidata kutoka kwenye usanidi, kisha hubaki kimya isipokuwa mistari ya ulandanishi ya mara kwa mara. Hitilafu ya no such file or directory dhidi ya njia ya hifadhidata yako inamaanisha kuwa njia iliyo kwenye usanidi si sahihi, au mchakato hauwezi kuisoma. Kitengo huendeshwa kama root kwa chaguomsingi, jambo ambalo linatoa ruhusa zaidi kuliko kazi hii inavyohitaji. Litestream lazima iweze kusoma na kuandika hifadhidata pamoja na saraka iliyo na hifadhidata hiyo, kwa sababu hufanya kazi na faili za -wal na -shm zilizo kando ya hifadhidata yako. Kwa hiyo, ipe akaunti ambayo programu yako tayari inatumia.

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

Tumia mipangilio hiyo kwa sudo systemctl daemon-reload na sudo systemctl restart litestream. Kusanidi akaunti maalum ya huduma yenye ruhusa chache huchukua dakika chache. Hilo hutofautisha wakala wa chelezo na mchakato wa pili wa root kwenye seva.

Mpangilio mmoja wa kuanzisha ni muhimu ikiwa utaunda upya mashine kuanzia mwanzo. Unataka hifadhidata irejeshwe kabla ya programu kuanza. litestream restore inakubali -if-db-not-exists, ambayo hutoka kwa msimbo 0 ikiwa faili tayari ipo. Kwa hiyo, ni salama kuiendesha kila wakati wa kuwasha mfumo. Weka katika mstari wa ExecStartPre wa kitengo cha programu yako, na VPS mpya itapakua hifadhidata huku VPS iliyopo isipofanye chochote. litestream replicate ina alama ya -restore-if-db-not-exists inayolingana ikiwa ungependa kuiweka katika sehemu moja.

VPS kwenye mipaka ya SQLite

Mifumo ya faili ya mtandao. Hiki ndicho kikomo ambacho huwezi kukiepuka kwa usanidi. Hali ya WAL inahitaji kila mchakato unaotumia database kushiriki eneo dogo la kumbukumbu. Eneo hilo hutolewa na faili ya -shm. Nyaraka za SQLite zinaeleza kanuni hii 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 iliyowekwa (mfumo wa faili wa mtandao) au share ya SMB inaweza kuharibika. Hakuna pragma inayozuia hilo. Kuna tofauti ambayo watu wengi hukosa. Kifaa cha block cha mtandao, ambacho watoa huduma wengi wa VPS huambatisha kama hifadhi ya ziada, huonekana kwa Linux kama diski ya kawaida yenye mfumo wa faili wa kawaida. Hilo ni sawa. File share iliyowekwa si sawa.

Seva ya pili ya programu. Hakuna usanidi unaofanya hili lifanye kazi. Mara tu unapohitaji mashine 2 zitumie data ileile, unahitaji database inayowasiliana kupitia mtandao. Panga mabadiliko hayo mapema, wakati bado una muda wa kuyapanga.

Mizigo yenye maandishi mengi. Mwandishi 1 kwa wakati mmoja ni sifa ya muundo wa faili, si mpangilio unaoweza kurekebishwa. Maandishi mafupi ni nafuu kwa sababu kila commit huongezwa kwenye WAL. Kwa hiyo, throughput inategemea zaidi muda wa kusubiri wa diski kwa maandishi madogo kuliko CPU yako. Tazama NVMe ikilinganishwa na hifadhi ya SATA SSD kwenye VPS ili kuona tofauti hiyo. Shida halisi ni transactions ndefu, kwa sababu zinaweka kila mwandishi mwingine kwenye foleni nyuma yake.

Query za uchanganuzi. SQLite ni row store iliyoundwa kwa transactions. Dashboard inayochanganua rows milioni 100 inahitaji kazi tofauti na tool tofauti. DuckDB ikilinganishwa na SQLite kwa kazi za seva inaeleza mpaka huo unapopatikana.

VACUUM wakati wa replication. VACUUM kamili huandika upya faili nzima ya database. Hilo linamaanisha kuwa Litestream lazima ipakie faili yote tena. Nyaraka za Litestream zinashauri usiiendeshe mahali pake wakati replication inaendelea. Simamisha replicator, endesha vacuum, iwashe tena, na tarajia snapshot mpya kamili.

Replicator 2 kwenye database moja. Usiendeshe kamwe michakato 2 ya Litestream dhidi ya database moja au destination moja ya replica. Nyaraka zinaeleza wazi kuwa kuzuia hali hii ni jukumu lako. Matokeo yake ni replica ambayo huwezi kurejesha.

Litestream hailindi

Litestream hulinda faili ya database pekee na si kitu kingine. Faili zilizopakiwa, usanidi wa programu, vyeti vya TLS (usalama wa safu ya usafirishaji) na faili za unit bado ni jukumu lako. Iunganishe na nakala rudufu zilizosimbwa za nje ya mashine kwa kutumia restic kwa ratiba, na sehemu zote mbili zitakuwa zimelindwa. Ikiwa mashine ni mpya, dakika kumi za kwanza kwenye VPS mpya zinashughulikia akaunti ya mtumiaji na usanidi wa firewall ambao mwongozo huu unachukulia kuwa tayari umekamilika.

FAQ

Je, SQLite inatosha kwa programu ya production?

Kwa programu moja kwenye server moja, ndiyo, mradi uwashe hali ya WAL, uweke muda wa kusubiri busy, na uifanyie backup mfululizo. Vizuizi muhimu ni vya kimuundo: mwandishi mmoja kwa wakati mmoja, na mashine host moja. Programu inayotoshea ndani ya mipaka hiyo hupata database bila hatua ya mtandao na bila mchakato tofauti wa kuufuatilia. Programu isiyotoshea ndani ya mipaka hiyo inahitaji database ya client-server, na tuning yoyote haiwezi kubadilisha hali hiyo.

Kwa nini bado ninapata 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 kufungua huiweka katika read transaction, na write ya baadaye lazima ibadilishe hali hiyo. Ikiwa connection nyingine iliandika katikati, SQLite hurejesha SQLITE_BUSY mara moja badala ya kuita busy handler yako, kwa kuwa read snapshot yako tayari imepitwa na wakati. Anzisha transaction yoyote itakayoandika kwa BEGIN IMMEDIATE ili write lock ichukuliwe mwanzoni na timeout itumike.

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

Si kwenye network filesystem kama NFS au SMB. Hali ya WAL inahitaji michakato yote ishiriki kumbukumbu kupitia faili ya -shm, na nyaraka za SQLite zinasema kwamba kila mchakato unaotumia database lazima uwe kwenye host computer moja. Network block device iliyoambatishwa na provider wako ni kitu tofauti: Linux huiona kama disk ya kawaida yenye filesystem ya kawaida, na SQLite hufanya kazi hapo.

Je, ninahitaji Litestream ikiwa tayari ninaendesha backup za kila usiku?

Inategemea kiasi cha data unachoweza kukubali kupoteza. Kazi ya kila usiku inamaanisha kupoteza hadi saa ishirini na nne za writes. Litestream husawazisha takribani mara moja kwa sekunde, hivyo crash husababisha upoteze takribani sekunde ya mwisho. Pia ni salama zaidi kuliko kunakili faili ya database kwa cp, kwa kuwa hiyo inaweza kunasa database ikiwa inaendelea kuandika. Litestream hushughulikia database pekee, kwa hiyo endelea kuendesha backup ya jumla ya faili sambamba nayo.