SQLite Yedekleme: Canlı Veritabanını Güvenle Kopyalama

Neden düz dosya kopyalama yeterli değil

SQLite veritabanı tek bir dosya olduğu için ilk akla gelen yöntem dosyayı cp ile kopyalamaktır. Belgeler bu yöntemin tarihsel olarak şöyle uygulandığını anlatır: önce SQLite üzerinden dosyaya paylaşımlı bir kilit alınır, dosya dış bir araçla kopyalanır, ardından kilit bırakılır. Bu çoğu durumda hızlıdır, ancak üç zayıf noktası vardır. Kopyalama sürdüğü sürece veritabanına yazmak isteyen herkes bekler; bellek içi veritabanları bu yolla kopyalanamaz; kopyalama sırasında elektrik kesilir ya da işletim sistemi çökerse yedek dosyası bozuk kalabilir.

Kilit almadan yapılan kopyalama daha tehlikelidir. Bozulma nedenlerini anlatan belge, arka planda çalışan otomatik yedekleme sistemlerinin bir işlemin ortasında dosyayı kopyalayabileceğini ve ortaya çıkan kopyanın bir kısmı eski, bir kısmı yeni içerik taşıdığı için bozuk olabileceğini açıkça yazar. Aynı belge, etkin bir işlem yokken dosyayı kopyalamanın güvenli olduğunu, ancak son yazma işlemi yarıda kaldıysa -journal ya da -wal dosyasının da veritabanıyla birlikte kopyalanması gerektiğini belirtir. Sıradan rsync için de durum aynıdır: SQLite işlemlerini tanımadığı için farklı işlemlere ait sayfaları aynı kopyada birleştirebilir.

WAL modunda sorun daha görünürdür. Bu modda değişiklikler önce ayrı bir -wal dosyasının sonuna eklenir ve ancak "checkpoint" adı verilen işlemle asıl veritabanı dosyasına taşınır. Yalnızca .db dosyasını kopyalarsanız henüz taşınmamış, onaylanmış işlemleri kaybedebilirsiniz. Bu ayrıntılar SQLite WAL modu yazısında anlatılıyor; bu yazının konusu, bu riskleri hiç düşünmek zorunda kalmadan yedek almanızı sağlayan yöntemler.

Yöntemlerin karşılaştırması

Tablodaki ilk üç yöntem aynı makinede yedek almak içindir. sqlite3_rsync ise yedeği doğrudan başka bir sunucuya taşır ve iki taraf zaten birbirine çok benziyorsa yalnızca farklı sayfaları gönderir. Uygulamanız SQLite'ı bir programlama dili üzerinden kullanıyorsa aynı yöntemlere kod içinden de ulaşabilirsiniz; Python sqlite3, Node.js node:sqlite ve PHP PDO yazıları bağlayıcıların kullanımını anlatır. VACUUM INTO sıradan bir SQL ifadesi olduğu için her bağlayıcıdan aynı şekilde çalıştırılabilir.

.backup ile çevrimiçi yedek

sqlite3 komut satırı aracındaki .backup komutu, SQLite'ın çevrimiçi yedek (online backup) arayüzünü kullanır. Bu arayüz bir veritabanının içeriğini başka bir veritabanı dosyasına kopyalar ve hedefteki eski içeriği tamamen değiştirir. İşlem tamamlandığında hedef dosya, kopyalamanın başladığı andaki kaynak veritabanının bit bit aynısı olur. Komutun en basit kullanımı tek satırdır ve kabuk betiklerine kolayca eklenir:

# Çalışan bir veritabanının tutarlı kopyasını tek satırda alın
sqlite3 app.db ".backup yedek.db"

# Yedeği hemen doğrulayın
sqlite3 yedek.db "PRAGMA integrity_check"
# çıktı: ok

Komut, isteğe bağlı bir şema adı ve hedef dosya adı alır. Şema adı verilmezse main veritabanı yedeklenir; bağlı (ATTACH edilmiş) bir veritabanını yedeklemek için onun adını yazarsınız. .save komutu .backup için bir takma addır. Etkileşimli bir oturumda aynı işlem şöyle görünür:

-- sqlite3 app.db ile açılmış oturumda:
SELECT count(*) FROM musteri;
-- çıktı: 3

.backup yedek.db
.backup main yedek2.db

-- Başka bir bağlantı yazıyorsa kilidi en fazla 5 saniye bekle
.timeout 5000
.backup yedek3.db

Burada .timeout komutu önemlidir. Belgelerdeki örnek kodda da vurgulandığı gibi, kaynak dosyaya başka bir süreç erişiyorsa yedek işlemi gerekli kilidi hemen alamayabilir ve SQLITE_BUSY hatasıyla sonlanabilir. Bağlantıya bir bekleme süresi tanımlandığında yedek adımları da bu süreyi kullanır, yani kilit açılana kadar belirtilen milisaniye boyunca yeniden dener. Kilit hatalarının genel nedenleri ve PRAGMA busy_timeout ayarı database is locked hatası yazısında ayrıntılı anlatılıyor.

Çevrimiçi yedek arayüzünün en önemli özelliği, kopyayı parça parça yapabilmesidir. Belgelerdeki ikinci örnek, her adımda beş sayfa kopyalayıp 250 milisaniye bekleyen bir döngü kurar; bekleme sırasında kaynakta hiçbir okuma kilidi tutulmaz ve diğer bağlantılar yazmaya devam edebilir. Kaynak, yedek sürerken başka bir bağlantı tarafından değiştirilirse SQLite bunu fark eder ve kopyalamayı genellikle baştan başlatır. Sonuç her durumda tutarlıdır, ancak belgeler çok sık yazılan bir veritabanında yeniden başlatmalar o kadar sık olabilir ki yedeğin hiç bitmeyebileceği uyarısını da yapar. Yoğun yazma alan sistemlerde yedeği trafiğin düşük olduğu saatlere planlamanın nedeni budur.

Kullandığımız 3.50.6 sürümünün .help backup çıktısı komutun iki seçeneğini de listeler: --append yedeği appendvfs ile var olan bir dosyanın sonuna ekler, --async ise hedefe günlük dosyası ve fsync() kullanmadan yazar. İkinci seçenek hızlıdır ama yedek sırasında güç kesilirse hedef dosya güvende değildir; gece yedeklerinde varsayılan davranışı korumanızı öneririz.

.restore ile geri yükleme

.restore ters yönde çalışır: verdiğiniz dosyanın içeriğini açık olan veritabanına yükler ve mevcut içeriği siler. Aşağıdaki örnekte sqlite3 dosya adı verilmeden başlatıldı, yani bellekte geçici bir veritabanı açıldı ve yedek bu boş veritabanına yüklendi. Bu yöntem, yedeğin içeriğini canlı dosyaya dokunmadan incelemek için de pratiktir.

-- sqlite3 ile (dosya adı vermeden) açılan bellek içi oturumda:
.restore yedek.db
SELECT id, ad, sehir FROM musteri ORDER BY id;
-- çıktı:
-- 1|Ayşe|İzmir
-- 2|Mehmet|Bursa
-- 3|Zeynep|Ankara

VACUUM INTO ile küçültülmüş yedek

VACUUM INTO, veritabanını sıfırdan yeniden kurarken çıktıyı asıl dosyanın üzerine yazmak yerine yeni bir dosyaya yazar. Belgelere göre özgün dosya değişmez ve yeni dosya aynı mantıksal içeriği, tamamen sıkıştırılmış olarak taşır. Silinmiş satırlardan kalan boş sayfalar kopyaya taşınmaz; bu yüzden yedek mümkün olan en küçük boyuttadır ve silinen içeriğin adli inceleme ile geri getirilebilecek izlerini barındırmaz. Komut sıradan bir SQL ifadesi olduğu için komut satırı aracı olmayan ortamlarda, örneğin uygulamanın kendi bağlantısından da çalıştırılabilir.

VACUUM INTO 'yedek-20261107.db';

-- Aynı adla ikinci kez denerseniz:
VACUUM INTO 'yedek-20261107.db';
-- hata: output file already exists

-- Dosya adı bir SQL ifadesi olabilir; tarih ve saatle benzersiz ad üretin
VACUUM INTO 'yedek-' || strftime('%Y%m%d-%H%M%S', 'now') || '.db';

Hedef dosya daha önce var olmamalı ya da boş olmalıdır; aksi hâlde komut hata verir. Bu kural, yanlışlıkla eski bir yedeğin üzerine yazmanızı engeller, ancak her çalıştırmada farklı bir dosya adı üretmenizi de gerektirir. Dosya adı metne dönüşen herhangi bir SQL ifadesi olabildiği için yukarıdaki gibi tarih ve saat fonksiyonlarıyla benzersiz ad oluşturabilirsiniz; bu fonksiyonların ayrıntıları SQLite tarih ve saat fonksiyonları yazısında.

Belgeler VACUUM INTO ile çevrimiçi yedek arayüzü arasındaki farkı şöyle özetler: VACUUM INTO daha küçük bir dosya üretir ve dosya sistemine daha az yazar, yedek arayüzü ise daha az işlemci kullanır ve adım adım çalıştırılabilir. Komut işlem anlamında tutarlıdır, yani çıktı özgün veritabanının tek bir andaki görüntüsüdür. Yine de komut çalışırken beklenmedik bir kapanma ya da elektrik kesintisi olursa çıktı dosyası eksik ve bozuk kalabilir. Özgün veritabanının PRAGMA synchronous ayarı NORMAL ya da FULL ise SQLite yazma bittikten sonra çıktıyı diske eşitler; böylece komut tamamlandıktan sonraki bir kesinti yedeği bozmaz.

Komutun iki sınırlaması daha var. Açık bir işlem içinde çalıştırılamaz; aynı bağlantıda henüz sonlandırılmamış bir sorgu da okuma işlemini açık tutarak komutun başarısız olmasına yol açabilir. Öte yandan sıradan VACUUM bir yazma işlemi olduğu hâlde VACUUM INTO değildir; başka bir bağlantının yazma kilidi tutması onu engellemez.

BEGIN;
VACUUM INTO 'gecici.db';
-- hata: cannot VACUUM from within a transaction
ROLLBACK;

Bağlı bir veritabanını yedeklemek için şema adını komutun ortasına yazarsınız: VACUUM arsiv INTO 'arsiv-yedek.db'. 3.53.0 sürüm notlarına göre hedef olarak reserve=N parametresi taşıyan bir URI dosya adı verildiğinde, kopyanın sayfa başına ayrılan boş alan miktarı N olarak ayarlanır (N 0 ile 255 arasında). Bu özellik 3.53.0 ve sonrasını gerektirir ve URI dosya adlarının etkin olmasına bağlıdır. Sıradan VACUUM komutunun dosyayı nasıl küçülttüğü SQLite VACUUM ve auto_vacuum yazısında anlatılıyor.

WAL modundaki veritabanlarını yedeklemek

WAL modunda çalışan bir veritabanında da her iki yöntem güvenle çalışır, çünkü ikisi de veriyi SQLite üzerinden okur ve -wal dosyasındaki onaylanmış değişiklikleri görür. Denememizde iki yöntemin ürettiği dosyalar arasında küçük ama önemli bir fark çıktı:

PRAGMA journal_mode = WAL;
-- çıktı: wal
.backup wal_yedek.db
VACUUM INTO 'wal_vacuum.db';

.open wal_yedek.db
PRAGMA journal_mode;
-- çıktı: wal

.open wal_vacuum.db
PRAGMA journal_mode;
-- çıktı: delete

.backup kaynağın sayfalarını başlık bilgisiyle birlikte kopyaladığı için yedek dosyası da WAL modunda açıldı. VACUUM INTO ile üretilen kopya ise geri alma günlüğü (delete) modundaydı. WAL modu veritabanı dosyasında kalıcı olarak saklanan bir ayar olduğu için, yedeği doğrudan canlıya alacaksanız açtıktan sonra PRAGMA journal_mode değerini kontrol edin ve gerekiyorsa yeniden ayarlayın. Arşiv amaçlı tutulan tek dosyalık yedeklerde delete modu aslında daha pratiktir; dosyanın yanında -wal ya da -shm dosyası oluşmaz.

.dump ile metin yedeği

.dump komutu veritabanının tüm içeriğini tek bir UTF-8 metin dosyasına, yani veritabanını yeniden kuran SQL ifadelerine dönüştürür. Çıktı saf SQL olduğu için okunabilir, sürüm kontrolünde farkı görülebilir ve gerektiğinde başka veritabanı motorlarına aktarmak için başlangıç noktası olur. Belgelerdeki örnek, dökümü psql komutuna yönlendirerek PostgreSQL'e aktarır; ancak tip ve sözdizimi farkları nedeniyle her şema bu kadar sorunsuz taşınmaz.

sqlite3 app.db .dump
# çıktı:
# PRAGMA foreign_keys=OFF;
# BEGIN TRANSACTION;
# CREATE TABLE musteri(id INTEGER PRIMARY KEY, ad TEXT NOT NULL, sehir TEXT);
# INSERT INTO musteri VALUES(1,'Ayşe','İzmir');
# INSERT INTO musteri VALUES(2,'Mehmet','Bursa');
# INSERT INTO musteri VALUES(3,'Zeynep','Ankara');
# COMMIT;

Belgelerin arşiv kopyası için önerdiği yöntem dökümü gzip ile sıkıştırmaktır. Geri yüklemek için dosyayı açıp sqlite3 aracına girdi olarak vermeniz yeterlidir:

# Sıkıştırılmış metin yedeği
sqlite3 app.db .dump | gzip -c > app.dump.gz

# Başka bir dosyaya geri yükleme
zcat app.dump.gz | sqlite3 geri.db
sqlite3 geri.db "SELECT count(*) FROM musteri"
# çıktı: 3

Metin yedeğinin bedeli boyut ve süredir. Büyük bir veritabanında döküm almak da geri yüklemek de ikili kopyadan belirgin biçimde uzun sürer, çünkü geri yükleme sırasında bütün satırlar yeniden eklenir ve bütün indeksler yeniden kurulur. Bu yüzden .dump günlük yedeğin yerine değil, uzun süreli arşiv, şema incelemesi veya motor değiştirme gibi durumlar için ek bir araç olarak düşünülmelidir. Tek tek tabloları dökmek ve diğer nokta komutları için SQLite CLI nokta komutları yazısına bakın.

sqlite3_rsync ile başka bir sunucuya eşitleme

sqlite3_rsync, SQLite projesinin ayrı bir yardımcı programıdır ve ilk olarak 3.47.0 sürümüyle deneysel olarak eklenmiştir. Bir kaynak (ORIGIN) ve bir kopya (REPLICA) alır; ikisinden biri KULLANICI@SUNUCU:YOL biçiminde uzak bir adres olabilir, iletişim SSH üzerinden yapılır. İki tarafın da yerel olması da desteklenir. Program çalışırken her iki veritabanı da canlı kalabilir: başka programlar kaynağa yazabilir, kopyadan okuyabilir. Kopya, komutun başladığı andaki kaynağın tutarlı bir görüntüsü olur; komut sürerken kaynağa yapılan değişiklikler bu çalıştırmada kopyaya aktarılmaz.

# Yerel veritabanını uzak sunucudaki kopyaya eşitler (kopya yoksa oluşturulur)
sqlite3_rsync /srv/uygulama/app.db yedekci@yedek-sunucu:/yedek/app.db

# rsync benzeri ayrıntılı çıktı
sqlite3_rsync /srv/uygulama/app.db yedekci@yedek-sunucu:/yedek/app.db -v

# Uzak taraftaki program SSH'in PATH'inde değilse yerini belirtin
sqlite3_rsync app.db yedekci@yedek-sunucu:/yedek/app.db --exe /opt/bin/sqlite3_rsync

# Yerelde 3.50.0+, uzakta 3.49.1 veya daha eski sürüm varsa (belgelerdeki geçici çözüm)
sqlite3_rsync app.db yedekci@yedek-sunucu:/yedek/app.db --protocol 1

Bu komutlar belgelerden derlendi; deneme ortamımızda sqlite3_rsync bulunmadığı için çalıştırılmadı. Belgelerdeki sınırlamalar şunlardır: program çalışırken kopya salt okunurdur; her çalıştırmada tek bir veritabanı eşitlenir; iki taraftan en az biri yerel makinede olmalıdır; uzak taraftaki program SSH'in varsayılan PATH değişkenindeki bir dizinde, örneğin /usr/local/bin içinde durmalı ya da --exe ile yeri gösterilmelidir. Kopya tablo ve indeks içeriği bakımından bayt bayt aynıdır, ancak veritabanı başlığındaki değişiklik sayacı ve sürüm alanı gibi birkaç küçük alan farklı olabilir.

Sürümler önemlidir. 3.50.0 sürüm notlarına göre iki tarafın da WAL modunda olma ve aynı sayfa boyutunu kullanma şartı kaldırılmış ve iki taraf birbirine çok benzediğinde daha az bant genişliği kullanan bir protokol eklenmiştir. Belgeler yeni protokolün iki tarafta da 3.50.0 veya sonrası gerektirdiğini, aksi hâlde eski protokole dönüldüğünü belirtir. Yerelde 3.50.0 ve sonrası, uzakta 3.49.1 veya öncesi kullanıldığında protokol pazarlığındaki bir hata yüzünden program takılabilir; önerilen çözüm iki tarafa da güncel sürümü kurmak, mümkün değilse --protocol 1 seçeneğini eklemektir. 3.53.0 ile SSH bağlantı noktasını belirtmek için -p veya --port seçeneği gelmiştir.

Bant genişliği konusunda belgeler şu bilgiyi verir: iki taraf baştan çok farklıysa toplam trafik veritabanı boyutunu yüzde birkaç oranında aşabilir, çünkü sayfa özetleri de gönderilir. Taraflar birbirine çok benziyorsa, ki düzenli eşitlemede durum genellikle budur, trafik çoğu zaman veritabanı boyutunun on binde birinden azdır. Belgelerdeki testlerde 500 MB'lık bir veritabanı tipik olarak yaklaşık 20 KB ağ trafiğiyle eşitlenmiştir.

Yedeği doğrulamak

Alınmamış bir yedek kadar, açılamayan bir yedek de işe yaramaz. Her yedekten sonra en azından iki kontrol yapmanızı öneririz: dosyanın yapısal bütünlüğü ve içeriğin canlı veritabanıyla tutarlılığı. Yedeği ATTACH ile bağlayıp her iki kontrolü tek oturumda yapabilirsiniz:

ATTACH 'yedek.db' AS y;
PRAGMA y.integrity_check;
-- çıktı: ok

SELECT (SELECT count(*) FROM main.musteri) AS canli,
       (SELECT count(*) FROM y.musteri) AS yedek;
-- çıktı: 3|3

DETACH y;

PRAGMA integrity_check bozuk sayfa, eksik indeks girdisi gibi yapısal sorunları arar ve sorun yoksa tek satırda ok döndürür. Satır sayısı karşılaştırması ise yedeğin beklediğiniz tabloyu içerdiğini gösterir; canlı veritabanı yedekten sonra yazma almaya devam ettiği için sayıların ileride farklılaşması normaldir. Bütünlük denetiminin ayrıntıları ve bozuk bir dosyadan veri kurtarma bozuk veritabanı kurtarma yazısında, birden fazla dosyayla aynı anda çalışma ise SQLite ATTACH DATABASE yazısında anlatılıyor. En güvenilir doğrulama, yedeği düzenli aralıklarla ayrı bir ortamda gerçekten geri yükleyip uygulamanın onunla çalıştığını görmektir.

Sunucuda otomatik yedek için notlar

• Yedeği aynı dizinde bırakmayın: Yedeği aldıktan sonra başka bir diske veya sunucuya taşıyın. Aynı diskte duran kopya, disk arızasına karşı koruma sağlamaz.
• Dosya izinlerini kontrol edin: Yedek dosyası canlı veritabanıyla aynı veriyi taşır. Yedek dizinine yalnızca yedekleme işini çalıştıran kullanıcının erişebilmesi gerekir.
• Yerel diskte çalışın: Belgeler ağ dosya sistemlerinde kilitlemenin güvenilir olmadığını ve bunun bozulmaya yol açabildiğini vurgular. Canlı veritabanını yerel diskte tutup yedeği oradan uzak hedefe taşımak daha güvenlidir.
• Günlük dosyalarını ayırmayın: Bir nedenle dosya kopyalamak zorunda kalırsanız, yarım kalmış bir işlemden sonra -journal veya -wal dosyasını veritabanıyla birlikte taşıyın. Belgeler bunları ayırmanın veya başka bir veritabanının günlüğüyle karıştırmanın bozulmaya yol açtığını listeler.
• Dosyayı başka bir araçla açıp kapatmayın: Belgeler, SQLite bağlantıları açıkken aynı süreçte dosyayı doğrudan open() ve close() ile okumanın POSIX kilitlerini düşürebileceğini anlatır. Yedeği SQLite'ın kendi araçlarıyla almak bu tuzaktan da korur.

Sık yapılan hatalar

• Sadece .db dosyasını kopyalamak: WAL modunda henüz checkpoint edilmemiş işlemler -wal dosyasında durur. Kopyayı .backup veya VACUUM INTO ile alın.
• VACUUM INTO hedefini önceden oluşturmak: Hedef dosya var ve boş değilse komut "output file already exists" hatası verir. Her yedek için yeni bir ad üretin veya eski dosyayı önceden taşıyın.
• VACUUM INTO komutunu işlem içinde çalıştırmak: BEGIN ile açılmış bir işlemin içinde komut reddedilir.
• .restore yönünü karıştırmak: .restore açık veritabanını dosyadaki içerikle değiştirir; canlı veritabanında yanlışlıkla çalıştırılması son değişiklikleri siler.
• Yedeği hiç denememek: Doğrulanmamış yedek yalnızca bir umut verir. integrity_check ve düzenli geri yükleme testi yapın.

Sık Sorulan Sorular

Hangi yöntemi seçmeliyim?

Aynı makinede düzenli yedek için .backup veya VACUUM INTO yeterlidir. Diskte yer ve aktarım boyutu önemliyse ya da silinen verinin izinin kalmaması gerekiyorsa VACUUM INTO, işlemci yükü önemliyse veya yedeği adım adım almak istiyorsanız yedek arayüzünü kullanan .backup uygundur. Yedeği doğrudan başka bir sunucuya taşımak için sqlite3_rsync tasarlanmıştır.

Yedek alırken uygulamamı durdurmam gerekir mi?

Hayır. Bu yazıdaki yöntemler canlı veritabanında çalışır. Belgelere göre yedek arayüzü bütün veritabanını tek adımda kopyaladığında kopyalama süresince kaynakta okuma kilidi tutar ve bu sürede diğer bağlantılar yazamaz; adım adım kopyalamada ise kilit yalnızca okuma anlarında tutulur. Çok sık yazılan sistemlerde yedeğin yeniden başlaması ve uzaması mümkündür.

Bellek içi veritabanını diske kaydedebilir miyim?

Evet. Belgelerdeki ilk örnek tam olarak bunu yapar: yedek arayüzü bellek içi bir veritabanını dosyaya, dosyayı da belleğe kopyalayabilir. Komut satırında :memory: ile çalışırken .backup dosya.db veya .save dosya.db yazmanız yeterlidir.

.dump yedeği ikili yedekten daha mı güvenli?

Daha güvenli değil, daha taşınabilirdir. Metin dosyası farklı bir SQLite sürümünde veya başka bir araçta okunabilir, ama geri yüklemesi daha uzun sürer. Çoğu kurulumda ikili yedeği esas alıp metin dökümünü ek arşiv olarak tutmak iyi bir dengedir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: SQLite öğrenme rehberi · SQLite VACUUM ve auto_vacuum · SQLite WAL modu · Bozuk veritabanı kurtarma · SQLite ATTACH DATABASE · Veritabanı yedekleme stratejileri