Notlarımı iki cihazda kullanıyorum: evdeki eski laptop (sunucu) ve masaüstü PC. Arada bir bulut yok. İstemediğim şey şuydu: notların tek bir şirketin hesabına bağlı olması, internete çıkmadan okunamaması, hesap kapandığında elimde bir şey kalmaması. Aradığım araç dosyaları olduğu yerde, düz metin olarak tutmalıydı.
Seçim Syncthing oldu. Çalışma biçimi basit: senkronlanacak klasörü tanımlıyorsun, cihazları eşleştiriyorsun, iki taraf birbirini bulup değişiklikleri paylaşıyor. Merkez yok — sunucu da en az PC kadar sıradan bir düğüm. Bir taraf kapalıysa diğeri çalışmaya devam ediyor, açıldığında aradaki fark kapanıyor.
Kurulumda ne var
Sunucudaki klasörün kimliği a6egs-e9i9n, yolu /home/javert/Obsidian_Vault, tipi sendreceive — yani iki yönlü. Bekçi olarak fsWatcher açık (10 saniye gecikmeyle değişiklikleri yakalıyor), üstüne saatte bir tam tarama var. Tam tarama gereksiz görünüyor ama gerekli: dosya sistemi olaylarını her zaman kaçırmak mümkün, o yüzden Syncthing’in kendi dokümantasyonu da tam taramayı kapatmamanı söylüyor.
Klasörün içinde .stfolder diye bir işaret dosyası duruyor. Bugünkü yazının tamamı o dosyanın etrafında dönüyor.
Silmenin mekaniği
Syncthing her cihazda bir indeks tutuyor: dosyaların blokları, hash’leri, değişiklik zamanları. Bir dosyayı sildiğinizde bu bir “yok olma” değil, yeni bir sürüm bilgisi. Diğer cihaz bunu duyduğunda “demek ki artık bu dosya istenmiyor” diye düşünüp kendi kopyasını da siliyor. İki yönlü senkronda silmek de senkronlanan bir işlemdir; başka türlü olamaz, yoksa sildiğiniz dosya her seferinde geri gelirdi.
Peki bir disk çıkarıldığında, klasör yanlışlıkla taşındığında ne olacak? Herkesin her şeyi silmesi mi? İşte .stfolder bunun için var. İşaret dosyası yoksa Syncthing klasörün kendisine ulaşamadığını varsayıp duruyor ve hiçbir şeyi silinmiş saymıyor. Güvenlik freni bu: klasör yoksa, silme de yok.
Frenin tek zayıf noktası, işaret dosyasını kendiniz geri koyarsanız devreden çıkması. Elinizde boş bir klasör varsa ve içine elle .stfolder yaratırsanız, Syncthing’in gördüğü tablo şu oluyor: klasör burada, işaret de burada, demek ki kullanıcı içindeki her şeyi sildi. Sonrası malum.
15 Ağustos, yayılma başlarken
PC tarafında vault klasörü yoktu. Boş klasör açıp içine .stfolder koydum — mantıklı sandığım şey buydu, “işte klasör hazır, şimdi dolsun”. Syncthing bunu tam tersi okudu ve silmeyi sunucuya yaymaya başladı. Sunucudaki dosya sayısı 60’tan 21’e indi, günlük notlar 43’ten 16’ya düştü. Yani kurtarılacak bir şey kalmadan önce fark etmem gerekiyordu, fark ettim: sayılar tutmuyordu.
Yaptığım sıra şuydu:
- Sunucu kopyasını olduğu gibi yedekledim (53 dosya sağlamdı).
sudo systemctl stop syncthing@javertile senkronu tamamen durdurdum.- Yedekten geri yükledim.
- Syncthing’in indeks dosyasını (
~/.local/state/syncthing/index-v0.14.0.db) sildim — içindeki “şu dosyalar silindi” bilgisi de onunla gitsin diye. - Servisi başlattım. Tarama sıfırdan yapıldı, 60 dosya geldi, iki taraf eşitlendi.
Kalıcı ders şu: senkronu kaybedip sıfırdan kurmak gerekiyorsa, boş klasör ve işaret dosyası yaratmak yasak. Doğru yol, Syncthing arayüzünden klasörü “Remove” ile çıkarmak (dosyaları silmeden), sonra aynı kimlik ve aynı yolla yeniden eklemek. Bu işlem indeksi baştan kurar ve mevcut taraf temiz bir kopya olarak görülür. PC tarafı için söylenen “Restore” düğmesi de aynı işi yapıyor: sıfırdan çek, tahmin etme.
Versioning ne yapar, ne yapmaz
Klasörde simple versioning açık, 10 sürüm tutuyor. Değişen ya da silinen dosyalar klasörün içindeki .stversions/ altına zaman damgalı olarak gidiyor. Bu ay 57 dosya orada duruyor ve en çok işe yaradığı yer, silinmenin gerçekten yayıldığı o ilk dakikalar.
Ama versioning’i yedek sanmak hataya davetiye. İki sınırı var. Birincisi: sadece uzaktan gelen değişiklikler arşivleniyor. Sunucuda kendi elimle düzenlediğim bir dosyanın eski hali hiçbir yere kopyalanmıyor, çünkü yeni sürümü zaten benim, eski sürümü de benim makinemde eziyorum. İkincisi: simple politikası her dosya için sadece son 10 sürümü tutuyor, üstüne silinme anında “hepsi burada” garantisi yok.
Pratikte bunu şöyle kullanıyorum: PC’den gelen değişikliklerin geçmişi .stversions/ içinden okunabiliyor. Geçen ay Blog/konular~2026...md biçiminde üç ardışık sürüm buldum — PC’de art arda yapılan üç düzenleme, sunucuya geldiği için arşivlenmiş. O dosyaya bakıp “bu metin neydi” sorusunu cevaplayabildim, üstelik hiçbir ekstra yedek almadan.
Ekranı açmadan kontrol
Syncthing’in arayüzü güzel ama her gün açacak bir şey değil. Durum sorgusunu REST API’den yapıyorum; bugün aldığım cevap şu:
curl -s -H "X-API-Key: $KEY" \
"http://localhost:8384/rest/db/status?folder=a6egs-e9i9n"
# state: idle · inSyncFiles: 123 · needFiles: 0 · errors: 0123 dosya 17 klasörün içinde, toplam 364 KB indeks, bekleyen tek dosya yok, hata yok. Bu satırlar “senkron sağlıklı mı” sorusunun tek cevabı; arayüzde gördüğüm yeşil tik değil.
Bir de şu var: bugün bağlantı listesinde PC (yigit-pc, 192.168.1.178) göründü. Altı gündür kopuktu, address=dynamic olduğu için sabit bir adresi yok, kendi kendine buldu ve döndü — döndüğünde de aradaki farkı sessizce kapattı. Diğer cihaz G514 hâlâ görünmüyor: cihaz istatistiklerinde lastSeen değeri 1970, yani hiç bağlanmamış. Bir peer’ın “hiç gelmediğini” anlamak için log kurcalamak gerekmiyor, tek alan yetiyor.
Sunucu tarafında günde 4.600–5.100 satır [UFW BLOCK] kaydı birikiyor. Hepsi aynı imza: ff12::8384 UDP 21027, yani Syncthing’in IPv6 yerel keşif multicast’i. IPv4 LAN kuralı zaten açık olduğu için cihazlar birbirini bulabiliyor; engellenen satırlar zararsız gürültü, ama journal’ı şişiriyor. (Yerel keşfin tamamen kapandığı bir ağda peer’ların hiç görüşmemesi de ayrı bir olasılık, o yüzden bu satırları tamamen görmezden gelmemek gerekiyor.)
Neyi farklı yapardım
Birincisi, senkronlanan klasörün içine elle hiç dokunmazdım — özellikle işaret dosyasına. Bir aracın güvenlik frenini, neden orada olduğunu bilmeden sökmek, o gün olan şeyin tek sebebiydi.
İkincisi, sunucuyu “asıl kopya” ilan ederdim. Şu an iki taraf eşit görünüyor ve bu rahat bir duygu; oysa kaza anında kurtaran şey, sunucuda daha yeni bir yedeğin durmasıydı. Belge klasörünü tek yönlü (sendonly) bırakıp PC’yi tüketici yapmak da mümkün, ama notları iki tarafta da düzenlediğim için o rahatlıktan vazgeçmedim. Karşılığında gerçek bir yedek tutuyorum: Syncthing senkron, yedek değil. Silme iki yöne de yayılır; yedeğin böyle bir özelliği yok.
Üçüncüsü, toplu işlem yapacaksam (klasör taşıma, isim değiştirme, temizlik) önce klasörü duraklatırdım. Senkron açıkken yapılan büyük değişiklikleri Syncthing doğru işliyor, ama yanlış anladığı anda geri dönüş yolu indeks silmekten geçiyor. Duraklatmak iki saniye sürüyor.
Bir de sürüm politikasını baştan düşünürdüm. simple + 10 sürüm bu boyuttaki bir vault için fazlasıyla yeterli; asıl sınırın “10 sürüm değil, sadece uzaktan gelen değişiklikler” olduğunu bilmek gerekiyordu. Onu bilmeyen biri, .stversions klasörünü görüp “yedeklerim burada” diye rahatlar — sonra yerelde yaptığı bir hatayı hiçbir yerde bulamaz.