BorgBackup --exclude-if-present ile .nobackup Dosyası Bulunan Klasörleri Atlamak

Yıllardır Proxmox hostları ve bare-metal sunucular üzerindeki kritik verileri korumak için BorgBackup kullanıyorum. Tekrarlayan bir sorun, yedeklenecek içeriği yönetmek—özellikle geliştiriciler veya sistem yöneticileri geçici önbellekler, loglar veya test verilerini paylaşılan dizinlere bırakırken ortaya çıkıyor. Yeni bir gürültülü klasör her ortaya çıktığında exclude desenlerini elle düzenlemek hata yapmaya açıktır ve zahmetli.

Benim çözümüm basit: .nobackup dosyası içeren her dizini BorgBackup’ın atlamasını sağlamak. Bu, --exclude-if-present bayrağını kullanarak statik exclude listesini dinamik, kendi kendine hizmet veren bir mekanizmaya dönüştürür. Artık node_modules veya .cache gibi gereksiz dizinleri aramaya gerek kalmıyor—bu dizinler, sıfır baytlık bir dosya bırakarak kendilerini hariç tutabilir.

How --exclude-if-present Works in Borg

Borg’un exclude desenleri, bir yolu eşleştirmek yerine bir dosya aramak için özel bir mod destekler. Eğer bu dosya bir dizinde varsa, Borg o dizin ağacının tamamının yedeğini almaktan vazgeçer. Sözdizimi basittir:

borg create --exclude-if-present .nobackup /mnt/repo::hostname-{now:%Y-%m-%d} /data

Burada, Borg /data dizinini tarar. .nobackup adlı bir dosya içeren bir dizine her ulaştığında, o dizinin altına inmeyi durdurur ve o dizini arşivden hariç tutar. İşaret dosyası (.nobackup) kendisi yedeğe alınmaz—sadece bir sinyal olarak kullanılır.

Bu yöntem, klasör isimlerini tahmin etmeyi gerektiren regex tabanlı excludes’tan daha temizdir. Ayrıca, uzun bir exclude listesiyle her yolu tarama performans maliyetini de önler.

Pratik Örnek: Uygulama Önbelleklerini ve Günlüklerini Hariç Tutma

Dosya sunucularımızda, geliştiriciler genellikle /srv/app dizinini monte eder; her alt dizin bir hizmeti temsil eder. Bazıları büyük önbellek dizinleri oluşturur; diğerleri ayrıntılı hata ayıklama günlükleri yazar. Geliştiricilerin yedekleme politikalarını hatırlamasını istemek yerine, onlara hariç tutma seçeneği sunuyoruz.

Bir dağıtım sonrası, bir hizmet şu dizinleri bırakabilir:

/srv/app/api/v2/cache/
/srv/app/api/v2/logs/
/srv/app/worker/tmp/

Bu dizinlerden herhangi biri .nobackup dosyası içeriyorsa, Borg bu dizinleri yedeklemeden çıkarır. Bu kuralı, bilinen gürültülü konumlarda .nobackup dosyasını oluşturan bir post-dağıtım betiğiyle zorunlu kılıyoruz:

# api/v2 dağıtıldıktan sonra
touch /srv/app/api/v2/cache/.nobackup
touch /srv/app/api/v2/logs/.nobackup

Artık sonraki yedekleme bu ağaçları otomatik olarak atlar. Borg yapılandırmasında herhangi bir değişiklik yapmaya gerek yoktur.

Diğer Excludes ile Birleştirme

--exclude-if-present ile birlikte normal --exclude desenlerini de kullanabilirsiniz. Örneğin, işletim sistemi seviyesindeki çöp dosyalar için genel excludes tutuyorum:

borg create \
  --exclude '*/.cache/*' \
  --exclude '*/__pycache__/*' \
  --exclude-if-present .nobackup \
  /mnt/backups::daily-{now:%Y-%m-%d} \
  /srv /etc /root

Burada, Borg önce statik excludes’leri uygular, ardından dosya gezintisi sırasında .nobackup dosyasının varlığını kontrol eder. Sıralama doğruluk açısından çok önemli olmasa da, scriptlerde niyetin daha açık görünmesi için --exclude-if-present’i geniş kapsamlı desenlerin sonrasına yerleştirmek faydalı olabilir.

Marker File En İyi Uygulamaları

Birkaç konvansiyonun karışıklığı önlemeye yardımcı olduğunu buldum:

Boş bir dosya kullan: touch .nobackup yeterlidir.
Dizin Git içindeyse, sürüm kontrolüne ekle—böylece opt-out kodu takip eder.
Ekibinizin runbook'una belgele: "Bir dizini yedeklerden hariç tutmak için .nobackup ekleyin."
Güvenlik için ona güvenmeyin; bir araçtır, erişim kontrolü değil.

Bir dikkat edilmesi gereken durum: .nobackup dosyasını kendinizi yedeklerseniz (örneğin daha geniş bir include üzerinden), Borg dizini yine hariç tutar ama markör dosyasını kaydeder. Bunu da önlemek için, include/exclude mantığınızın bu dosyayı yanlışlıkla yakalamamasını sağlayın. Uygulamada, tüm dizini hariç tuttuğumuz için bu bir sorun değildir.

İzleme ve Denetim

Çalıştığını doğrulamak için, Borg çıktısındaki A (eklenen) ve x (hariç tutulan) bayraklarını kontrol ederim. Kuru çalıştırma, hariç tutulanları net bir şekilde gösterir:

borg create --dry-run --exclude-if-present .nobackup --list /mnt/repo::test /srv

Şu gibi satırlara bak:

 x srv/app/api/v2/cache/
 x srv/app/api/v2/logs/
   A srv/app/api/v2/src/

Bir dizin x olarak işaretlenmişse ve hariç tutulmamalıysa, yanlış yerde bir .nobackup dosyası olup olmadığını kontrol et. Tersine, büyük bir veri hala ekleniyorsa, işaretçinin var olduğundan ve Borg sürecinin tarafından okunabilir olduğundan emin ol.

Yedekleme istatistiklerini izleme sistemimize de kaydediyorum. Hariç tutulan veride ani bir artış, genellikle yeni bir önbellek yoğun dağıtımın canlıya geçtiğini gösterir—bu aslında faydalı bir geri bildirimdir.

Bu bölüm metnini Türkçeye çevir. Anlam aynı kalsın. İngilizce cümle bırakma.

Bu Yaklaşım Manuel Exclude Listelerden Neden Daha İyi?

Bu yaklaşım öncesinde, /etc/borg/excludes dosyasında sürekli büyüyen bir --exclude listesi tutuyordum. Bu şunları gerektiriyordu:

Klasör adlarını tahmin etmek
Her backend değişikliğinde dosyayı güncellemek
Fazla veya az exclude yapmaya yol açabilecek yazım hatalarına karşı risk almak

.nobackup ile, karar veriyle aynı yerde yaşıyor. Geliştirler, altyapı bileti açmadan kendi yedekleme izlerini kontrol edebiliyor. Bu, en iyi anlamda sola kaydırma: politika kod olarak, kural tarafından zorunlu kılınıyor.

[Restic snapshot diffs](https://furkanikkan.com/urun/restic-anlik-goruntu-degisikliklerini-diff-ve-jq-ile-gorsellestirme-85) konulu yazımda da belirttiğim gibi, otomasyon sadece sezgisel olduğunda toil azaltır. Bu desen bu dengeyi yakalar: sıfır bakım yükü, açık semantik ve mevcut Borg iş akışlarıyla tam uyumluluk.

Yedekleme balonunu takip etmekten yoruldunysan, sonraki borg create komutuna --exclude-if-present .nobackup eklemeyi dene. Görürsün ki, exclude listelerini düzenlemek yerine .nobackup işaretleyici dosyaları eklemek çok daha sık olur.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M