VPS üzerinde SQLite üretimde kullanılır mı?

SQLite'nin bir VPS üzerinde üretim veritabanı olarak doğru tercih olduğu durumlar

SQLite'ı bir VPS üzerinde üretimde çalıştırmak, çoğu küçük uygulama için doğru tercihtir. Bunun nedeni basittir: tek bir makinedeki tek bir dosyaya yazan tek bir işlem için veritabanı sunucusu gerekmez. İzlenecek bir daemon, güvenlik duvarında açılacak bir port, döndürülecek bir parola veya çalışır durumda tutulacak ikinci bir makine yoktur. Sorgu, ağ üzerinden gidiş dönüş yerine bir işlev çağrısıdır. Bu nedenle 40 sorgu çalıştıran bir sayfa, 40 işlev çağrısına mal olur.

Maliyeti sınırlı ama gerçektir. SQLite, veritabanı dosyasının tamamında aynı anda yalnızca bir yazıcıya izin verir ve dosya iki makine arasında paylaşılamaz. Tek bir uygulama çalıştıran tek bir VPS için bu iki sınır da uygundur. Uygulamanın bu yapıyı aşmasıyla birlikte her iki sınır da kritik hale gelir. Bu kılavuzda SQLite'ı sunucuda güvenli hale getiren ayarlar, Litestream ile sürekli yedekleme ve ne zaman durmanız gerektiği açıklanmaktadır.

Önce komut satırı aracını yükleyin. Aşağıdaki işlemlerin tamamı Ubuntu 24.04 üzerinde gerçekleştirilmiştir.

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

Bu komut, 3. ile başlayan ve ardından derleme tarihi ile kaynak karmasını gösteren bir sürüm bilgisi yazdırır. Ubuntu 24.04, Temmuz 2026 itibarıyla SQLite 3.45.1 sürümünü içerir. Uygulamanız muhtemelen bu ikili dosyayı kullanmaz. Çoğu programlama dili çalışma zamanı, SQLite kitaplığının kendi kopyasını, genellikle daha yeni bir sürümünü, içerir. Bu nedenle yeni bir özelliğe güvenmeden önce veritabanı sürücünüzün bildirdiği sürümü kontrol edin.

WAL modunun ilk değiştirilmesi gereken ayar olmasının nedeni

SQLite, varsayılan olarak geri alma günlüğü kullanır. Bir sayfayı değiştirmeden önce özgün sayfayı bir -journal dosyasına kopyalar, ardından veritabanını yerinde düzenler. Bunu güvenli şekilde yapmak için dosyanın tamamında özel kilit alır. Bu nedenle herhangi bir yazma işlemi devam ederken tüm okuma işlemleri bekler. Bir dizüstü bilgisayarda bu fark edilmez. Bir web sunucusunda yavaş bir yazma işlemi, veritabanına erişen her isteği durdurur.

WAL (write-ahead log) modu işlemlerin sırasını tersine çevirir. Yazma işlemi, yeni sayfaları ayrı bir -wal dosyasına ekler ve ana veritabanına dokunmaz. Okuma işlemleri, başladıkları andaki anlık görüntü üzerinden ana dosyayı okumaya devam eder. Böylece okuma işlemleri yazma işlemini, yazma işlemi de okuma işlemlerini engellemez. Daha sonra bir checkpoint işlemi, WAL dosyasında biriken sayfaları ana veritabanına kopyalar. Bu tek değişiklik, SQLite'ın bir web uygulamasının arkasında kullanılabilir olmasını büyük ölçüde sağlar.

WAL modunu etkinleştirme ve kalıcı olduğunu doğrulama

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

Komut wal çıktısını verir. Bu çıktı yalnızca bilgilendirme amaçlı değildir. PRAGMA journal_mode, veritabanının gerçekten kullandığı modu döndürür. Bu nedenle delete yanıtı, değişikliğin başarısız olduğu ve hâlâ rollback journal kullanıldığı anlamına gelir.

WAL modu kalıcıdır. Bir bağlantı ayarı değil, veritabanı üstbilgisindeki bir işarettir. Bu nedenle her veritabanı dosyası için bir kez çalıştırılması yeterlidir. Yeniden başlatma sonrasında kurulan bağlantılar dahil olmak üzere sonraki tüm bağlantılar bu ayarı devralır. Bunu yeni bir bağlantıyla doğrulayın.

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

Şimdi bir tablo oluşturun ve diskte nelerin oluştuğuna bakın.

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/

Artık üç dosya vardır: app.db, app.db-wal ve app.db-shm. -wal dosyası henüz checkpoint işlemine alınmamış committed sayfaları içerir. -shm dosyası, tüm bağlantıların eşleyerek WAL içeriği konusunda aynı bilgiyi kullanmasını sağlayan paylaşılan bellek dizinidir. Her iki dosya da veritabanının parçasıdır ve geçici dosya değildir. Uygulama çalışırken yalnızca app.db dosyasını kopyalarsanız, son committed işlemlerin tümünü içermeyen bir dosya elde edersiniz. app.db dosyasını silip diğer iki dosyayı yerinde bırakırsanız SQLite, bu eski WAL sayfalarını o ad altında oluşan yeni dosyaya uygular. Bir veritabanını sıfırlamaya çalışırken yeni bir veritabanının bozulmasının nedeni budur.

Her üretim uygulamasının ihtiyaç duyduğu bağlantı ayarları

Yalnızca journal_mode veritabanında saklanır. Aşağıdaki diğer tüm ayarlar bağlantıya özeldir. Bu nedenle uygulamanın, açtığı her bağlantıda bu ayarı çalıştırması gerekir. Buna havuzun arka planda oluşturduğu her bağlantı da dahildir.

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

busy_timeout = 5000, database is locked döndürmeden önce SQLite'ın kilitli bir veritabanı için 5000 milisaniyeye kadar yeniden denemesini sağlar. Varsayılan değer 0'dır. Bu nedenle SQLite, iki yazma işlemi çakıştığında varsayılan olarak ilk anda başarısız olur. Bu tek değerin ayarlanması, SQLite'ın kendisine atfedilen kilit hatalarının çoğunu ortadan kaldırır.

synchronous = NORMAL, WAL modunda doğru ayardır ve bu ayarın ödünleşimi anlaşılmalıdır. FULL değerinde SQLite, her commit işleminde WAL üzerinde fsync çağrısı yapar. NORMAL değerinde ise eşzamanlamayı checkpoint işlemleri sırasında yapar. SQLite belgeleri, nelerden vazgeçildiğini açıkça belirtir: Güç kesintisi veya zorla sıfırlama sonrasında işlemler artık kalıcı olmaz. Veritabanı bu güç kaybı nedeniyle bozulamaz. Yalnızca diske yazılmamış son commit işlemleri kaybedilir. Bir VPS üzerinde bu genellikle doğru ödünleşimdir. Çünkü her yazma işleminin yolundan bir fsync çağrısını çıkarır.

foreign_keys = ON, geriye dönük uyumluluk nedeniyle varsayılan olarak kapalıdır ve bağlantıya özeldir. REFERENCES yan tümceleriyle dolu bir şema, her bağlantı bunu etkinleştirene kadar hiçbir şeyi zorunlu kılmaz.

Bir ayar yalnızca daha sonraki aşamada önem kazanır. SQLite, WAL 1000 sayfayı aştığında otomatik olarak checkpoint işlemi başlatır. Bu işlem, o anda bir işlemi tamamlayan bağlantı tarafından gerçekleştirilir. Tek başına bu durum sorun oluşturmaz. Ancak Litestream çalışırken konu hâline gelir. Çünkü Litestream, checkpoint işlemlerinin ne zaman gerçekleşeceğini denetlemek ister.

database is locked ayarlandıktan sonra neden hâlâ gerçekleşir?

Bu, kullanıcıları Postgres'e geri yönlendiren hatadır ve tek bir nedeni vardır.

Meşgul zaman aşımı bir meşgul işleyicisi kurar. Ancak SQLite bu işleyiciyi çağıracağını garanti etmez.

SQLite, meşgul işleyicisinin çağrılmasının kilitlenmeye yol açabileceğini belirlerse, meşgul işleyicisini çağırmak yerine uygulamaya doğrudan SQLITE_BUSY döndürür.

SQLite'ın önlediği kilitlenme, bir işlem yükseltildiğinde gerçekleşir. SQLite'ta tek başına kullanılan BEGIN, BEGIN DEFERRED anlamına gelir. Bundan sonraki ilk ifade bir SELECT ise okuma işlemi içindesinizdir. Aynı işlem içindeki daha sonraki bir UPDATE yazma işlemine dönüşmek istediğinde ve başka bir bağlantı okuma işleminiz başladıktan sonra yazma yaptıysa, SQLite sizi bekletemez. Bunun nedeni, anlık görüntünüzün artık güncel olmaması ve beklemenin iki bağlantının birbirini kilitlemesine yol açacak olmasıdır. Belgelerde sonuç doğrudan belirtilir:

Sonraki yazma ifadeleri, mümkünse işlemi yazma işlemine yükseltir veya SQLITE_BUSY döndürür.

5000 milisaniyelik zaman aşımınıza hiç başvurulmaz. Hata hemen döner. Bu nedenle ayarın hiçbir etkisi olmadığı görülür.

Çözüm tek kelimedir.

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

BEGIN IMMEDIATE yazma kilidini başlangıçta, herhangi bir şey okumadan önce alır. Yükseltme gerçekleşmez. Bu nedenle önlenmesi gereken bir kilitlenme olmaz. Meşgul işleyicisi uygulanır ve bağlantı hata vermek yerine sırasını bekler. Salt okunur işlemleri ertelenmiş durumda tutun. Yazma içeren her işlem immediate olmalıdır.

Kilit hatalarının ikinci nedeni daha zor fark edilir: yazma işlemini yavaş çalışmalar boyunca açık tutmak. SQLite yazma işlemlerini seri hâle getirir. Bu nedenle açılan, ağ üzerinden harici bir API çağıran ve ardından commit yapan bir işlem, bu çağrı boyunca diğer tüm yazma işlemlerini engeller. Gereken verileri okuyun, işlemi kapatın, yavaş çalışmayı gerçekleştirin. Ardından sonucu kaydetmek için kısa bir yazma işlemi açın.

Litestream ile sürekli yedekleme

Her gece alınan bir kopya, bir güne kadar olan yazma işlemlerini kaybettirir. Canlı bir SQLite veritabanında cp çalıştırılması ise açılamayacak bir kopya oluşturabilir. İki yöntem güvenlidir. sqlite3 app.db ".backup /path/to/backup.db", SQLite'ın çevrim içi yedekleme arayüzünü kullanır ve kullanımda olan bir veritabanında çalışır. Litestream daha ileri gider: WAL'ı izler ve değişiklikleri nesne depolamaya sürekli olarak aktarır. Böylece en kötü durumdaki veri kaybı bir günden yaklaşık bir saniyeye iner.

Litestream, uygulamanızın yanında çalışan tek bir Go ikilisidir. Uygulama ile veritabanı arasında konumlanmaz. Uygulamanız SQLite'a önceki gibi yazmaya devam eder. Litestream ise WAL'ı okur ve değişen verileri yükler.

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, Temmuz 2026 itibarıyla resmi Linux kurulum sayfasında belgelenen sürümdür. v0.5.15 ise 21 Temmuz 2026 tarihinde yayımlanmıştır. Her iki satırdaki sürümü releases sayfasındaki geçerli etiketle eşleşecek şekilde değiştirin. VPS sisteminiz arm64 ise bunun yerine eşleşen arm64 paketini kullanın.

Yapılandırma dosyası /etc/litestream.yml konumundadır. Önce yerel bir dosya replikasıyla başlayın. Böylece bulut kimlik bilgilerine gerek kalmadan tüm akışın çalıştığı doğrulanır.

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

Alan adının replica, yani tekil olduğunu unutmayın. Litestream 0.5, 0.3 serisindeki replicas dizisini tek bir replika bloğuyla değiştirmiştir. Artık iki giriş içeren bir yapılandırma başlangıçta başarısız olur. Birçok üçüncü taraf kılavuzunda hâlâ eski dizi gösterilir. Bu nedenle arama sonuçlarında karşılaşılan ilk örneği değil, yukarıdaki yapıyı kullanın. 0.5 serisi ayrıca litestream wal alt komutunu litestream ltx olarak yeniden adlandırmıştır. Bunun nedeni, diskteki yedekleme biçiminin değişmesidir.

Herhangi bir şeyi etkinleştirmeden önce yapılandırmanın ayrıştırıldığını doğrulayın.

sudo litestream databases -config /etc/litestream.yml

Ardından gidiş-dönüşü elle doğrulayın. Bu biçim yapılandırma dosyasını atlar ve tek bir veritabanını tek bir yola replike eder.

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

Bu komut ön planda çalışır ve çalışmaya devam eder. İkinci bir kabukta bir satır yazın ve replikayı yeni bir dosyaya geri yükleyin.

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

Sayaç yeni satırı içerir. İçermiyorsa değişiklik henüz eşitlenmemiştir. Litestream, varsayılanı 1 saniye olan bir sync-interval üzerinden gönderim yapar. Biraz bekleyin ve geri yükleme işlemini yeniden çalıştırın. Bu bir saniye aynı zamanda kurtarma noktanızdır. Bir çökme, en fazla son eşitleme aralığındaki yazma işlemlerini kaybettirir. Hiçbir yapılandırma bu kaybı sıfıra indirmez.

Gerçek depolama için replika bloğunu bir S3 URL'siyle değiştirin. Bu yöntem Amazon S3 ile ve diğer sağlayıcıların S3 uyumlu nesne depolama hizmetleriyle çalışır.

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

snapshot:
  interval: 24h
  retention: 24h

Kimlik bilgilerini bu dosyada tutmayın. Litestream, LITESTREAM_ACCESS_KEY_ID ve LITESTREAM_SECRET_ACCESS_KEY değerlerini ortamdan okur. Bu değerleri root tarafından sahip olunan ve modu 600 olan bir systemd drop-in dosyasına ekleyin.

Yukarıdaki anlık görüntü değerleri varsayılan değerlerdir. Saklama süresinin varsayılan değeri ise çoğu kişiyi şaşırtır. Saklama süresi, Litestream'in anlık görüntüleri ve bunlara ait dosyaları ne kadar süreyle tuttuğunu belirtir. Bu nedenle ne kadar geriye dönük geri yükleme yapılabileceğini de belirler. Yirmi dört saatlik süre, Çarşamba sabahı fark edilen hatalı bir migration işleminin Pazartesi durumundan geri yüklenemeyeceği anlamına gelir. retention: 168h değerini bir hafta olarak ayarlayın ve ek depolama maliyetini karşılayın.

İhtiyaç duymadan önce geri yüklemeyi doğrulayın

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

Bir veritabanı yolu verildiğinde litestream restore, /etc/litestream.yml içinde eşleşen replikayı bulur ve indirir. PRAGMA integrity_check, sağlam bir dosyada ok çıktısını verir. Farklı herhangi bir çıktı, geri yüklenen kopyanın kullanılamaz olduğunu gösterir. Bunu bir systemd hizmeti ve zamanlayıcı ile zamanlanmış olarak çalıştırın ve çıktıyı okuyun. Bir yedeği en az bir kez geri yüklemeden çalıştığını bilemezsiniz.

Litestream'i systemd altında çalıştırma

Debian paketi, litestream birimiyle birlikte kurulur ve bu birim /etc/litestream.yml dosyasını okur.

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

Sağlıklı çıktı, yapılandırmadaki her veritabanını adlandırır ve ardından dönemsel eşitleme satırları dışında sessiz kalır. Veritabanı yolunuza karşı alınan no such file or directory hatası, yapılandırmadaki yolun yanlış olduğu veya işlemin bu yolu okuyamadığı anlamına gelir. Birim varsayılan olarak root hesabıyla çalışır. Bu, bu iş için gerekenden fazla ayrıcalıktır. Litestream'in hem veritabanını hem de veritabanını içeren dizini okuyup yazabilmesi gerekir. Çünkü veritabanınızın yanındaki -wal ve -shm dosyalarıyla çalışır. Bu nedenle uygulamanızın zaten kullandığı hesabı verin.

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

sudo systemctl daemon-reload ve sudo systemctl restart litestream ile uygulayın. en az ayrıcalıkla özel bir hizmet hesabı oluşturmak birkaç dakika sürer. Bu, yedekleme aracını makinedeki ikinci bir root işleminden ayıran farktır.

Makineyi sıfırdan yeniden oluşturmanız gerekirse bir sıralama ayrıntısı önemlidir. Uygulama başlamadan önce veritabanının geri yüklenmesi gerekir. litestream restore, dosya zaten mevcut olduğunda 0 durum koduyla çıkan -if-db-not-exists seçeneğini kabul eder. Bu nedenle her açılışta güvenle çalıştırılabilir. Bunu uygulamanızın birimindeki ExecStartPre satırına ekleyin. Böylece yeni bir VPS veritabanını indirirken mevcut bir VPS hiçbir işlem yapmaz. litestream replicate, bunu tek bir yerde tutmayı tercih ederseniz karşılık gelen -restore-if-db-not-exists seçeneğine sahiptir.

SQLite'ın bir VPS üzerinde çalışmadığı durumlar

Ağ dosya sistemleri. Bu, yapılandırmayla aşamayacağınız bir sınırdır. WAL modu, veritabanını kullanan her işlemin küçük bir bellek alanını paylaşmasını gerektirir. Bu alanı -shm dosyası sağlar. SQLite belgelerinde bu kural açıkça belirtilir:

Veritabanını kullanan tüm işlemler aynı ana bilgisayarda olmalıdır; WAL, ağ dosya sistemi üzerinden çalışmaz.

Bu nedenle, bağlı bir NFS (ağ dosya sistemi) veya SMB paylaşımındaki veritabanı bozulabilir. Hiçbir pragma bunu önleyemez. Burada genellikle gözden kaçan bir ayrım vardır. Çoğu VPS sağlayıcısının ek depolama olarak bağladığı ağ blok aygıtı, Linux tarafından üzerinde olağan bir dosya sistemi bulunan normal bir disk olarak görülür. Bu kullanım uygundur. Bağlı bir dosya paylaşımı ise uygun değildir.

İkinci bir uygulama sunucusu. Hiçbir ayar bu yapıyı çalışır hâle getirmez. Aynı verileri sunan iki makineye ihtiyaç duyulduğunda, ağ üzerinden iletişim kuran bir veritabanına geçilmesi gerekir. Bu geçişi planlamak için hâlâ zaman varken karar verilmelidir.

Yazma ağırlıklı iş yükleri. Aynı anda yalnızca bir yazıcının çalışabilmesi, dosya biçiminin bir özelliğidir; ayarlanabilir bir seçenek değildir. Kısa yazma işlemleri ekonomiktir, çünkü her commit WAL'a ekleme olarak gerçekleştirilir. Bu nedenle aktarım hızı, CPU'dan çok diskin küçük yazma gecikmesine bağlıdır. Bu farkın nasıl göründüğü VPS üzerinde NVMe ile SATA SSD depolama karşılaştırması bölümünde açıklanır. Asıl sorun uzun işlemlerdir. Bu işlemler, diğer tüm yazıcıları sıraya alır.

Analitik sorgular. SQLite, işlemler için tasarlanmış bir satır deposudur. Yüz milyon satırı tarayan bir gösterge tablosu farklı bir araç gerektiren farklı bir iştir. Sunucu çalışmaları için DuckDB ile SQLite karşılaştırması bölümünde bu ayrımın nerede olduğu açıklanır.

Çoğaltma sırasında VACUUM. Tam bir VACUUM işlemi, veritabanı dosyasının tamamını yeniden yazar. Bu nedenle Litestream dosyanın tamamını yeniden yüklemek zorunda kalır. Litestream belgeleri, çoğaltma etkin durumdayken bu işlemin doğrudan çalıştırılmasını önermez. Çoğaltıcı durdurulmalı, vacuum çalıştırılmalı ve ardından yeniden başlatılmalıdır. Yeni bir tam anlık görüntü oluşturulması beklenmelidir.

Tek bir veritabanında iki çoğaltıcı. Aynı veritabanına veya aynı replica hedefinə karşı hiçbir zaman iki Litestream işlemi çalıştırılmamalıdır. Belgelerde, bunun önlenmesinin kullanıcının sorumluluğu olduğu açıkça belirtilir. Aksi durumda geri yüklenemeyen bir replica oluşur.

Litestream'in kapsamadıkları

Litestream yalnızca veritabanı dosyasını korur. Başka hiçbir şeyi korumaz. Yüklenen dosyalar, uygulama yapılandırması, TLS (transport layer security) sertifikaları ve unit dosyalarının tümü yine sizin tarafınızdan yönetilmelidir. Belirli aralıklarla restic ile şifrelenmiş sunucu dışı yedekleri kullanın. Böylece her iki bölüm de kapsanır. Makine yeniyse yeni bir VPS üzerinde ilk on dakika, bu kılavuzun önceden tamamlandığını varsaydığı kullanıcı hesabı ve güvenlik duvarı işlemlerini kapsar.

FAQ

SQLite üretim uygulaması için yeterli midir?

Tek bir sunucudaki tek bir uygulama için, WAL modunu etkinleştirmeniz, busy timeout ayarlamanız ve sürekli yedekleme yapmanız koşuluyla evet. Önemli sınırlamalar yapısaldır: aynı anda yalnızca bir yazma işlemi yapılabilir ve yalnızca bir ana bilgisayar kullanılabilir. Bu sınırlar içinde kalan bir uygulama, ağ üzerinden ek bağlantı gerektirmeyen ve izlenecek ayrı bir işlem bulunmayan bir veritabanına sahip olur. Uygulama bu sınırlara sığmıyorsa client-server veritabanı gerekir. Hiçbir ayar bunu değiştirmez.

busy_timeout ayarladıktan sonra neden hâlâ database is locked alıyorum?

Çünkü beklemek deadlock oluşturabilecekse SQLite busy handler mekanizmasını atlar. Yalın bir BEGIN ile başlayan işlem ertelenmiş durumdadır: başlangıçtaki SELECT işlemi bu işlemi bir okuma işlemine dönüştürür ve sonraki yazma işleminin yükseltilmesi gerekir. Bu sırada başka bir bağlantı yazma yaptıysa SQLite, okuma anlık görüntünüz artık güncel olmadığı için busy handler mekanizmasını çağırmak yerine hemen SQLITE_BUSY döndürür. Yazma yapacak her işlemi BEGIN IMMEDIATE ile başlatın. Böylece yazma kilidi başlangıçta alınır ve timeout uygulanır.

SQLite veritabanımı ağ depolamasında tutabilir miyim?

NFS veya SMB gibi bir ağ dosya sisteminde tutamazsınız. WAL modu, tüm işlemlerin -shm dosyası üzerinden belleği paylaşmasını gerektirir. SQLite belgeleri, veritabanını kullanan her işlemin aynı ana bilgisayarda bulunması gerektiğini belirtir. Sağlayıcınızın bağladığı ağ blok aygıtı farklıdır: Linux bunu üzerinde normal bir dosya sistemi bulunan normal bir disk olarak görür ve SQLite burada çalışır.

Zaten nightly backup çalıştırıyorsam Litestream kullanmam gerekir mi?

Bu, ne kadar veri kaybetmeyi göze alabileceğinize bağlıdır. Nightly job, yirmi dört saate kadar yazma işlemini kaybetmeniz anlamına gelir. Litestream yaklaşık saniyede bir senkronize olur. Bu nedenle bir çökme durumunda yaklaşık son saniyeyi kaybedersiniz. Ayrıca veritabanı dosyasını cp ile kopyalamaktan daha güvenlidir. Bu komut, veritabanı yazma işleminin ortasındayken dosyayı kopyalayabilir. Litestream yalnızca veritabanını kapsar. Bu nedenle yanında genel dosya yedeklemesini de çalışır durumda tutun.