Restic mi BorgBackup mı: Hangisini Seçmeli?

Restic ve BorgBackup karşılaştırması

Restic ve BorgBackup, bir Linux sunucusunun tekilleştirilmiş, şifrelenmiş ve artımlı yedeklerini alma konusunda aynı temel işlevi görür. Seçimi belirleyen temel fark, yedeğin depolandığı yerdir. Restic, S3 ve diğer nesne depolama API'lerini yerel olarak desteklediği için bir bucket, karşı tarafta herhangi bir yazılım kurulu olmasına gerek kalmadan birinci sınıf bir hedef haline gelir. Borg ise, bir Borg deposu dosya sistemi veya API ile değil, bir süreç (process) tarafından sunulduğu için, depoyu barındıran makinede borg programının kurulu olmasını gerektirir. Hedefiniz nesne depolama ise, cevap zaten bellidir. Hedefiniz kontrolünüz altındaki ikinci bir Linux sunucusu ise, Borg tercih edilebilir ve genellikle daha hızlıdır.

Diğer tüm özellikler daha küçük farklardır. Her iki araç da dosyaları içerik tanımlı parçalara ayırır; bu sayede 40 GB'lık bir dizinde 200 MB'lık bir değişiklik yapıldığında yaklaşık 200 MB veri yüklenir. Her ikisi de şifrelemeyi istemci tarafında gerçekleştirir. Her ikisi de bir snapshot'ı FUSE (userspace dosya sistemi) ile bağlayarak tek bir dosyayı geri almanıza olanak tanır. Temmuz 2026 itibarıyla restic 0.19.1 sürümündedir ve Borg'un kararlı serisi 1.4.5 sürümüyle 1.4'tür. Borg 2.0 yıllardır beta aşamasındadır ve hala yalnızca test amaçlı olarak işaretlenmiştir; bu nedenle bugün dağıtmanız gereken sürüm 1.4'tür.

Depo modeli asıl farkı yaratır

Bir restic deposu; config, keys/, snapshots/, index/ ve data/ ile dolu paket dosyalarından oluşan bir dizindir. Depoyu okumak için başka hiçbir şeye ihtiyaç duyulmaz. restic'in bu kadar çok arka ucu destekleyebilmesinin nedeni budur. Blob verilerini koyabilen, alabilen, listeleyebilen ve silebilen her depolama alanı bir restic deposunu barındırabilir; tek bir binary dosyasının yerel yolları, SFTP'yi, kendi REST sunucusunu, S3'ü, Backblaze B2'yi, Azure'u, Google Cloud Storage'ı ve rclone'un erişebildiği her şeyi desteklemesi bu sayede mümkün olur.

Bir Borg deposu da disk üzerindeki dosyalardan oluşur ancak Borg, bu depo ile hiçbir zaman basit bir taşıma protokolü üzerinden iletişim kurmaz. Uzak bir depo için Borg, karşı tarafta SSH üzerinden borg serve sürecini başlatır ve bu süreçle kendi protokolü üzerinden konuşur. Sunucu tarafı gerçek işi yapar: depoyu tutar, işlemi uygular ve dizin sorgularını yanıtlar. Borg'un S3 arka ucuna sahip olmamasının ve projenin bunu eklememesinin nedeni budur. Bir bucket (kova) içinde çalıştırılabilecek bir süreç yoktur.

Bu tek tasarım gerçeği, aşağıdaki pratik farkların çoğunu ortaya çıkarır.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Şifreleme: bir tanesi kapatılabilir

Restic her zaman şifrelidir. Şifrelemesiz bir mod bulunmamaktadır. restic init bir parola ister, scrypt kullanarak bu paroladan bir anahtar türetir ve sonrasında yazılan her paket dosyası şifrelenir ve doğrulanır. Parolayı kaybederseniz verileriniz gider, çünkü tasarım gereği bir kurtarma yolu yoktur.

Borg, depo oluşturma aşamasında şifrelemeyi bir tercih haline getirir ve bu tercih kalıcıdır. borg init --encryption=repokey şifreli anahtarı deponun içinde tutar, bu sayede sadece parola ile geri yükleme yapılabilir. --encryption=keyfile anahtarı istemci tarafında ~/.config/borg/keys/ içinde tutar; böylece deponun tamamını çalan birinin elinde hiçbir şey olmaz, ancak bu anahtar dosyasını ayrıca yedeklemeniz gerekir, aksi takdirde arşivleriniz okunamaz hale gelir. Her modun, donanımsal SHA hızlandırması olmayan sistemlerde daha hızlı olan HMAC-SHA256 yerine BLAKE2b ile doğrulama yapan bir -blake2 varyantı mevcuttur. --encryption=none de mevcuttur ve depo, sahibi olduğunuz şifreli bir disk üzerinde durduğunda gerçek bir seçenektir.

Pratik kural şudur: normal bir sunucu yedeği için repokey-blake2, deponun tam olarak güvenmediğiniz bir yerde bulunduğu durumlar için keyfile kullanılmalı ve kiralanmış bir makinede asla none tercih edilmemelidir.

Sıkıştırma ve restic'in bu özelliği neden geç aldığı

Borg, başlangıcından beri sıkıştırma yapmaktadır. Varsayılan değer olan lz4, her şey için açık bırakılabilecek kadar hızlı olduğu için seçilmiştir. zstd, 1 ile 22 arasında seviyeleri kabul eder ve varsayılan olarak 3 değerini kullanır. zlib ve lzma, dakikalardan ziyade bayt boyutuna önem verdiğiniz durumlar için mevcuttur. auto ise her parça (chunk) üzerinde bir buluşsal yöntem çalıştırarak, halihazırda sıkıştırılmış verilerin iki kez sıkıştırılmasını önler.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic, restic 0.14.0 veya daha yeni bir sürüm gerektiren depo formatı 2'ye kadar hiçbir sıkıştırma özelliğine sahip değildi. Format 2 artık yeni depolar için varsayılandır ve sıkıştırma, auto, off veya max değerleriyle --compression üzerinden ayarlanır. Eski format 1 depoları, siz onları taşıyana (migrate) kadar sıkıştırılmamış halde kalır. Bu nedenle, eğer restic deponuz 0.14 sürümünden eskiyse ve hiçbir zaman taşıma işlemi yapmadıysanız, metin dosyaları, günlük kayıtları ve veritabanı dökümleri için hala tam boyut üzerinden depolama maliyeti ödüyorsunuz demektir.

Uzak hedefler: S3 ve SSH karşılaştırması

Seçimin genellikle yapıldığı nokta burasıdır.

Restic'in S3'e erişmesi için ortam değişkenlerinde kimlik bilgilerinin bulunması yeterlidir; başka bir yerde herhangi bir şeyin çalışmasına gerek yoktur. Aynı yöntem, kendi barındırdığınız bir bucket için de geçerlidir ve bu yaygın bir eşleştirmedir: kendi VPS'inizde S3 API için MinIO çalıştırın ve restic'i buraya yönlendirin.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg'un uzak bir depoya erişmesi için SSH bağlantısına ve karşı tarafta kurulu bir Borg sürümüne ihtiyacı vardır; ayrıca karşı taraftaki sürümün istemci ile uyumlu olması gerekir. Eğer karşı taraf size ait değilse bu bir zorluktur. Ancak karşı taraf zaten yönettiğiniz ikinci bir sunucu ise bu durum bir sorun teşkil etmez ve size her iki aracın sunduğu fidye yazılımlarına karşı en güçlü kontrolü sağlar: salt ekleme (append-only) yapılabilen bir SSH anahtarı. Anahtarı borg serve komutunu çalıştıracak şekilde kısıtlarsanız, istemci arşiv ekleyebilir ancak bunları silemez; böylece güvenliği ihlal edilmiş bir makine kendi geçmişini temizleyemez.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic'in buna eşdeğer bir özelliği yalnızca, salt ekleme modunu destekleyen kendi REST sunucusunu çalıştırdığınızda mevcuttur. Standart S3 üzerinde ise aynı etkiyi, restic'in değil sağlayıcının sorumluluğunda olan bucket politikaları veya nesne kilitleme (object lock) ile elde edersiniz. Aktarımı da kısıtlayın; çünkü bu senaryonun SSH tarafı, diğer tüm giriş yöntemleri ile aynı özeni hak eder: yedekleme hesabı için kısıtlanmış authorized_keys girdisi ile sadece anahtar tabanlı SSH yöntemini uygulayın.

Hız: her tasarımın getirdiği sonuçlar

Hiçbir proje, kendi verileriniz için güvenebileceğiniz bir kıyaslama (benchmark) yayınlamaz; bu nedenle mekanizmaya bakarak mantık yürütmek gerekir.

SSH üzerinden Borg, sunucu tarafı akıllı olduğu için gecikmeli bağlantılarda hızlıdır. İstemci bir soru sorar, uzak borg serve süreci bunu depo dizininden yanıtlar ve işlem tek bir noktada tamamlanır. Parça (chunk) aramaları, her küçük dosya için ağ gidiş-dönüş süresine (round trip) dönüşmez.

Nesne depolama (object storage) üzerindeki Restic'in sunucu tarafı yoktur; bu nedenle resmini, HTTP üzerinden getirdiği dizin dosyalarından ve paket dosyalarından oluşturmak zorundadır. İstek sayısını makul düzeyde tutmak için, yüklemeden önce birçok küçük parçayı daha büyük paket dosyalarında birleştirir ve ~/.cache/restic içinde yerel bir önbellek tutar; böylece bir sonraki çalıştırmada dizinin tamamı tekrar indirilmez. Bu önbelleği silerseniz, bir sonraki yedekleme işlemi yeniden oluşturma nedeniyle yavaşlar. Milyonlarca küçük dosyanın bulunduğu yüksek gecikmeli bir bağlantıda, Restic'in aynı veriler üzerinde Borg'dan daha yavaş hissedildiği durum budur.

Yerel bir diskte veya hızlı bir LAN üzerinde bu fark büyük ölçüde kapanır ve her iki araç da kaynak veriyi okuma ve hash'leme hızlarıyla sınırlı hale gelir.

Kilitleme ve birden fazla makinenin yedeklenmesi

Borg 1.4, işlem süresince depo üzerinde özel bir kilit tutar. İki istemcinin aynı anda tek bir depoya yazması mümkün değildir: ikinci istemci bekler ve ardından kilit zaman aşımı hatası verir. Desteklenen yöntem, istemci başına bir depo kullanılmasıdır. Bu durum, tekilleştirmenin yalnızca tek bir makinenin deposu içinde gerçekleştiği anlamına gelir; dolayısıyla birbirinin aynısı on sunucu, aynı temel sistemin on kopyasını saklar.

Restic, birden fazla istemcinin aynı anda tek bir depoya yedekleme yapmasına izin verir; çünkü yedekleme işlemi paylaşımlı bir kilit alır ve yalnızca prune gibi bakım işlemleri özel kilit gerektirir. Tek bir restic deposuna yönlendirilen on benzer sunucu, birbirlerine göre tekilleştirme yapar ve ikinci sunucudan itibaren depolanan veri miktarı genellikle çok az olur. Bunun maliyeti ise etki alanının genişliğidir: tek bir parola ve her şeyi barındıran tek bir depo söz konusudur; bu nedenle parolanın kaybedilmesi on sunucunun tüm verilerinin kaybedilmesi anlamına gelir.

Saklama politikası: forget ve prune ile prune ve compact karşılaştırması

Her iki araç da "neyin saklanacağına karar verme" işlemini "alanı geri kazanma" işleminden ayırır ve her ikisinde de ikinci adımı sizin çalıştırmanız gerekir.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Her iki araçta da aynı tuzak mevcuttur ve bunu açıkça belirtmek gerekir. Borg içinde borg prune arşivleri kaldırır ancak tek başına disk alanını boşaltmaz. Alan, borg compact çalıştırıldığında geri kazanılır; bu nedenle sadece prune yapan ancak compact yapmayan bir cron işi, arşiv listesini kısa tutarken deponun sürekli büyümesine neden olur. Restic içinde forget komutunun --prune olmadan kullanılması yalnızca snapshot referanslarını siler; veriler, bir prune işlemi çalışana kadar depoda kalmaya devam eder.

Prune işleminden sonra restic check komutunu çalıştırın. Bu komut, depo yapılarını doğrular ve herhangi bir hasar olup olmadığını bildirir; bu, durumu bir geri yükleme sırasında öğrenmekten çok daha güvenlidir.

Geri yükleme: tek geçerli test

Her iki araç da bir snapshot'ı bağlayarak (mount) içeriğine göz atmanıza olanak tanır. Tek bir dosyayı geri almanın en hızlı yolu budur.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

borg extract içindeki yol formatına dikkat edin. Arşiv içindeki yollar başında eğik çizgi (slash) olmadan saklanır; bu nedenle etc/nginx doğrudur, /etc/nginx ise hiçbir şeyle eşleşmez ve hiçbir hata mesajı vermeden hiçbir dosyayı çıkarmaz. Çıkarma işlemi mevcut çalışma dizinine yazma yapar; bu yüzden önce geçici bir dizine geçin, aksi takdirde canlı dosyaların üzerine eski dosyaları yazarsınız.

Hangi aracı seçerseniz seçin, zamanlama işin sadece yarısıdır. Geri yükleme işlemini, bir VPS için restic yedekleme rehberi içerisinde systemd zamanlayıcısı ile yapıldığı gibi, düzenli olarak takip ettiğiniz bir zamanlayıcı ile geçici bir dizine çalıştırın.

Hangi iş için hangisi tercih edilmeli

Hedef nesne depolama (object storage) olduğunda, tek bir binary dosyası ile karşı tarafta herhangi bir yazılım gereksinimi istemediğinizde, birden fazla makinenin birbirine karşı tekilleştirme (deduplication) yapmasını istediğinizde veya geri yüklemeyi yapacak kişi siz olmadığınızda restic tercih edilmelidir. Tek bir statik binary dosyası ve depo için bir URL adresi ile çalışması, operasyonel açıdan rakipsizdir.

Hedef kontrolünüz altındaki bir Linux sunucusu olduğunda, bağlantıda gecikme (latency) varsa ve veri seti milyonlarca küçük dosyadan oluşuyorsa, fidye yazılımlarına karşı bir önlem olarak sadece ekleme yapılabilen (append-only) SSH anahtarı kullanmak istiyorsanız veya sıkıştırma ayarlarını iş bazında özelleştirmek istiyorsanız Borg tercih edilmelidir. Daha eski bir araçtır, kararlı sürümleri yavaş ilerler ve yedekleme yazılımlarında bu bir özelliktir.

Her iki araç da doğru tercihtir. Yanlış olan tek cevap, asla test etmediğiniz yedekleme yöntemidir. Eğer halihazırda uygulama seviyesinde dökümler alıyorsanız, bunları almaya devam edin: veritabanı dökümleri ile Docker üzerinde Nextcloud kurulumu içindeki yöntem her iki araç için de geçerlidir; çünkü rastgele bir anda kopyalanan canlı bir veritabanı dosyası, veritabanı yedeği sayılmaz.

FAQ

restic mi yoksa BorgBackup mı daha hızlıdır?

Yerel disk veya hızlı bir yerel ağ (LAN) üzerinde performansları birbirine yakındır; her ikisi de kaynak üzerindeki okuma ve hash hızına bağlı olarak sınırlanır. Borg, yüksek gecikmeli SSH bağlantılarında ve çok sayıda küçük dosya içeren durumlarda daha avantajlıdır; çünkü karşı taraftaki borg serve süreci, her bir veri parçası (chunk) için ağ üzerinden gidiş-dönüş yapmadan dizin sorgularını yanıtlar. Restic ise hedef nesne depolama (object storage) olduğunda daha başarılıdır; Borg bu tür depolama alanlarını doğrudan desteklemez.

BorgBackup ile S3 veya Backblaze B2 üzerine yedekleme yapılabilir mi?

Doğrudan yapılamaz. Bir Borg deposu, SSH üzerinden borg serve süreci tarafından sunulur ve bir bucket içinde böyle bir süreç çalışmaz. Kullanıcılar, nesne depolamayı rclone ile dosya sistemi olarak bağlayarak (mount) bu sorunu aşmaya çalışmaktadır; ancak Borg projesi bunu önermez. Bir işlem sırasında bağlantının kopması, deponun bozulmasına (corruption) yol açabilir. Nesne depolama kullanmanız gerekiyorsa restic tercih edilmelidir.

Her iki aracı aynı veri üzerinde çalıştırabilir miyim?

Evet, bazı kullanıcılar bunu yapmaktadır: Hızlı yerel geri yükleme için Borg ile ikinci bir sunucuya, tesis dışı (offsite) kopya için ise restic ile nesne depolamaya yedekleme alırlar. Bu araçlar birbirinden bağımsız çalıştığı için okuma ve hash maliyetini iki kez ödersiniz ve güvenli bir şekilde saklamanız gereken iki ayrı parolanız olur. Bunu yalnızca her iki aracın geri yükleme süreçlerini de test ettiyseniz uygulayın.

Depo parolasını kaybedersem ne olur?

Her iki araçta da veriler kurtarılamaz hale gelir. Restic, anahtarını scrypt kullanarak paroladan türetir ve bunu atlamanın bir yolu yoktur. Borg, repokey modunda şifrelenmiş anahtarı deponun içinde saklar, bu nedenle sadece parola ile geri yükleme yapılabilir; keyfile modunda ise ayrıca ~/.config/borg/keys/ dizinindeki anahtar dosyasına ihtiyacınız olur. Parolayı, yedeklenen sunucuda bulunmayan bir parola yöneticisinde saklayın ve keyfile kullanıyorsanız Borg anahtarını borg key export ile dışa aktarın.

Borg 2.0 sürümünü beklemeli miyim?

Hayır. Temmuz 2026 itibarıyla Borg 2.0 hala beta aşamasındadır (2.0.0b22) ve proje bunu yalnızca test amaçlı olarak tanımlamaktadır. Kararlı seri 1.4'tür ve güncel sürümü 1.4.5'tir. Şu an 1.4 ile başlayın. Borg 2, depo formatını değiştirmektedir ve belgelenmiş bir yükseltme yolu sunmaktadır; bu nedenle bugün başlamak sizi ileride zor durumda bırakmaz.