Kutumia SQLite kwenye VPS kwa programu ndogo

Wakati SQLite inapofaa kama database ya uzalishaji kwenye VPS

Kutumia 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 database. Hakuna daemon ya kusimamia, hakuna port ya kufungia kwa firewall, hakuna nenosiri la kubadilisha mara kwa mara, na hakuna mashine ya pili ya kuhakikisha inafanya kazi. Query ni mwito wa utendaji (function call) badala ya safari ya mtandao, kwa hivyo ukurasa unaoendesha query arobaini unagharimu mwito arobaini wa utendaji.

Gharama yake ni ndogo na ya kweli. SQLite inaruhusu mwandishi mmoja kwa wakati mmoja kwenye faili nzima ya database, na faili hiyo haiwezi kushirikiwa kati ya mashine mbili. Vikwazo vyote viwili ni sawa kwa VPS moja inayoendesha programu moja. Vyote viwili vinakuwa kikwazo kikubwa pale unapozidi uwezo wa usanidi huo. Mwongozo huu unashughulikia mipangilio inayofanya SQLite kuwa salama kwenye seva, backup endelevu kwa kutumia Litestream, na hatua ambayo unapaswa kuacha kuitumia.

Sakinisha zana ya mstari wa amri (command line tool) kwanza. Kila kitu hapa chini kimeendeshwa kwenye Ubuntu 24.04.

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

Hiyo inachapisha toleo linaloanza na 3. likifuatiwa na tarehe ya ujenzi na hash ya chanzo. Ubuntu 24.04 inatoa SQLite 3.45.1 kufikia Julai 2026. Programu yako pengine haitumii binary hii: lugha nyingi za programu huja na nakala yao ya maktaba ya SQLite, mara nyingi ikiwa ya toleo jipya zaidi, kwa hivyo hakikisha toleo ambalo dereva wa database yako anaripoti kabla ya kutegemea kipengele kipya.

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.

Backup endelevu kwa kutumia Litestream

Nakala ya kila usiku hupoteza hadi siku nzima ya data iliyoandikwa, na kuendesha cp dhidi ya database ya SQLite inayotumika kunaweza kutoa nakala isiyofunguka. Mambo mawili ni salama. sqlite3 app.db ".backup /path/to/backup.db" hutumia interface ya backup ya mtandaoni ya SQLite na hufanya kazi dhidi ya database inayotumika. Litestream huenda mbali zaidi: hufuatilia WAL na kusafirisha mabadiliko kwenye hifadhi ya object (object storage) kwa kuendelea, jambo linalopunguza uwezekano wa kupoteza data kutoka siku moja hadi sekunde moja hivi.

Litestream ni binary moja ya Go inayofanya kazi kando ya programu yako. Haikai katikati ya programu na database. Programu yako huandika kwenye SQLite kama kawaida, na Litestream husoma WAL na kupakia mabadiliko yaliyotokea.

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 ni toleo ambalo ukurasa rasmi wa usakinishaji wa Linux unalielezea kufikia Julai 2026, na v0.5.15 ilifuata tarehe 21 Julai 2026. Badilisha toleo katika mistari yote miwili ili ilingane na tag ya sasa kwenye ukurasa wa releases, na chukua kifurushi cha arm64 kinacholingana ikiwa VPS yako ni arm64.

Faili ya usanidi iko kwenye /etc/litestream.yml. Anza na replica ya faili ya ndani, kwa sababu inathibitisha mzunguko mzima bila kuhitaji vitambulisho vya wingu (cloud credentials).

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

Kumbuka kuwa sehemu hiyo ni replica, umoja. Litestream 0.5 ilibadilisha safu ya replicas kutoka mfululizo wa 0.3 na kizuizi kimoja cha replica, na usanidi wenye entries mbili sasa hushindwa kuanza. Miongozo mingi ya watu wengine bado inaonyesha safu ya zamani, kwa hivyo nakili umbo lililo hapo juu badala ya mfano wa kwanza unaopata kwenye utafutaji. Mfululizo wa 0.5 pia ulibadilisha jina la subcommand ya litestream wal kuwa litestream ltx, kwa sababu muundo wa backup kwenye diski ulibadilika.

Thibitisha kuwa usanidi unasomeka (parses) kabla ya kuwezesha chochote.

sudo litestream databases -config /etc/litestream.yml

Kisha thibitisha mzunguko mzima kwa mkono. Fomu hii huruka faili ya usanidi na kurudufu database moja kwenye njia moja.

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

Hiyo huendesha mbele (foreground) na kuendelea kufanya kazi. Kwenye shell ya pili, andika mstari (row) na urejeshe 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;"

Hesabu inajumuisha mstari mpya. Ikiwa haujumuishi, mabadiliko hayajasawazishwa bado: Litestream husukuma data kwa sync-interval ambayo chaguo-msingi ni sekunde 1, kwa hivyo subiri na urejeshe tena. Sekunde hiyo moja pia ndiyo hatua yako ya kurejesha (recovery point). Ajali hupoteza zaidi maandishi ya muda wa usawazishaji wa mwisho, na hakuna usanidi unaoweza kufanya hiyo kuwa sifuri.

Kwa hifadhi halisi, badilisha kizuizi cha replica na URL ya S3. Hii hufanya kazi dhidi ya Amazon S3 na dhidi ya hifadhi ya object 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

Weka vitambulisho nje ya faili hiyo. Litestream husoma LITESTREAM_ACCESS_KEY_ID na LITESTREAM_SECRET_ACCESS_KEY kutoka kwa mazingira (environment), kwa hivyo viweke kwenye systemd drop-in inayomilikiwa na root na yenye mode 600.

Thamani za snapshot hapo juu ni chaguo-msingi, na chaguo-msingi la uhifadhi (retention) huwashangaza watu. Retention ni muda ambao Litestream huhifadhi snapshots na faili zinazohusiana nazo, kwa hivyo pia ni muda gani unaoweza kurudi nyuma ili kurejesha data. Saa ishirini na nne inamaanisha kuwa uhamiaji (migration) mbaya unaogundua Jumatano asubuhi hauwezi kurejeshwa kutoka hali ya Jumatatu. Weka retention: 168h kwa wiki moja na ulipe gharama ya hifadhi ya ziada.

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 litestream unit inayosoma /etc/litestream.yml.

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

Pato lenye afya huorodhesha kila database kutoka kwenye usanidi na kisha kubaki kimya isipokuwa kwa mistari ya mara kwa mara ya kusawazisha (sync). Hitilafu ya no such file or directory dhidi ya njia ya database yako inamaanisha kuwa njia iliyo kwenye usanidi si sahihi, au mchakato hauwezi kuisoma. Unit hii huendeshwa kama root kwa chaguo-msingi, jambo ambalo ni upendeleo mkubwa kuliko ule unaohitajika kwa kazi hii. Litestream lazima iweze kusoma na kuandika kwenye database na saraka (directory) inayoshikilia database hiyo, kwa sababu inafanya kazi na faili za -wal na -shm zilizopo karibu na database yako, kwa hivyo ipe akaunti ambayo programu yako tayari inaitumia.

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

Itumie kwa sudo systemctl daemon-reload na sudo systemctl restart litestream. Kusanidi akaunti ya huduma maalum yenye upendeleo mdogo huchukua dakika chache, na ndiyo tofauti kati ya wakala wa kuhifadhi nakala (backup agent) na mchakato wa pili wa root kwenye seva.

Maelezo moja ya mpangilio ni muhimu ikiwa utawahi kujenga upya mashine kuanzia mwanzo. Unataka database irejeshwe kabla ya programu kuanza. litestream restore inakubali -if-db-not-exists, ambayo hutoa 0 wakati faili tayari ipo, kwa hivyo ni salama kuiendesha kila wakati wa boot. Iweke kwenye mstari wa ExecStartPre kwenye unit ya programu yako na VPS mpya itavuta database chini wakati ile iliyopo haitafanya chochote. litestream replicate ina bendera (flag) inayolingana ya -restore-if-db-not-exists ikiwa ungependelea kuiweka sehemu moja.

Mahali ambapo SQLite inafeli kwenye VPS

Mfumo wa faili wa mtandao (Network filesystems). Hii ni kikomo ambacho huwezi kukikwepa kwa usanidi wowote. Hali ya WAL inahitaji kila mchakato unaotumia hifadhidata ushiriki eneo dogo la kumbukumbu, ambalo ndilo linalotolewa na faili ya -shm. Nyaraka za SQLite zinaeleza sheria hii bila masharti:

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

Kwa hivyo, hifadhidata iliyopo kwenye NFS (network file system) au SMB share iliyopachikwa (mounted) inaweza kuharibika, na hakuna pragma inayoweza kuizuia. Kuna tofauti hapa ambayo watu huikosa. Kifaa cha block cha mtandao (network block device), ambacho ndicho watoa huduma wengi wa VPS huambatanisha kama hifadhi ya ziada, huonekana kwa Linux kama diski ya kawaida yenye mfumo wa faili wa kawaida, na hiyo ni sawa. Share ya faili iliyopachikwa (mounted file share) si hivyo.

Seva ya pili ya programu. Hakuna mpangilio unaoweza kufanya hili lifanye kazi. Mara tu unapohitaji mashine mbili zinazohudumia data ileile, unahitaji hifadhidata inayozungumza kupitia mtandao. Amua kuhusu hatua hiyo wakati bado una muda wa kuipanga.

Mizigo mikubwa ya uandishi (Write-heavy workloads). Mwandishi mmoja kwa wakati mmoja ni sifa ya muundo wa faili, si kitu kinachoweza kurekebishwa. Uandishi mfupi ni wa gharama nafuu kwa sababu kila commit ni nyongeza kwenye WAL, kwa hivyo throughput hufuata latency ya uandishi mdogo wa diski yako kwa karibu zaidi kuliko CPU yako. Tazama NVMe dhidi ya hifadhi ya SATA SSD kwenye VPS ili kuona jinsi tofauti hiyo inavyoonekana. Miamala mirefu (long transactions) ndiyo tatizo halisi, kwa sababu huweka kila mwandishi mwingine kwenye foleni nyuma yao.

Queries za uchambuzi (Analytical queries). SQLite ni hifadhi ya safu (row store) iliyojengwa kwa ajili ya miamala. Dashibodi inayochanganua safu milioni mia moja ni kazi tofauti kwa zana tofauti, na DuckDB ikilinganishwa na SQLite kwa kazi za seva inaelezea mahali ambapo mstari huo unapoishia.

VACUUM chini ya replication. VACUUM kamili huandika upya faili nzima ya hifadhidata, jambo ambalo linamaanisha Litestream inabidi ipakie yote tena, na nyaraka za Litestream zinashauri kutoiendesha wakati replication inafanya kazi. Simamisha replicator, fanya vacuum, ianzishe tena, na utarajie snapshot mpya kamili.

Replicators wawili kwenye hifadhidata moja. Usiendeshe kamwe michakato miwili ya Litestream dhidi ya hifadhidata ileile au sehemu ileile ya replica. Nyaraka ziko wazi kuwa kuzuia hili ni jukumu lako, na matokeo yake ni replica ambayo huwezi kuirejesha (restore).

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.