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 destekler; bu sayede uzak tarafta herhangi bir yazılım kurulu olmasına gerek kalmadan bir bucket doğrudan hedef olarak kullanılabilir. Borg ise yedek deposunun bulunduğu makinede borg programının kurulu olmasını gerektirir, çünkü bir Borg deposu dosya sistemi veya API üzerinden değil, bir süreç aracılığıyla sunulur. Eğer hedefiniz nesne depolama ise, tercihiniz doğrudan bellidir. Eğer hedefiniz kontrolünüz altındaki ikinci bir Linux sunucusu ise, Borg kullanılabilir ve genellikle daha hızlı sonuç verir.

Diğer tüm özellikler ikincil derecede öneme sahiptir. Her iki araç da içerik tanımlı parçalama (content defined chunking) yöntemini kullanır; bu sayede 40 GB'lık bir dizinde 200 MB'lık bir değişiklik yapıldığında sadece 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) aracılığıyla 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. Okunması için başka hiçbir şeye gerek yoktur. restic'in bu kadar çok arka ucu desteklemesinin 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 desteklemesinin yöntemi budur.

Bir Borg deposu da disk üzerindeki dosyalardan oluşur ancak Borg, bu depo ile asla 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ına yanıt verir. Borg'un S3 arka ucuna sahip olmamasının ve projenin bunu eklememesinin nedeni budur. Bir bucket (kova) içinde çalıştırılacak 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: biri devre dışı bırakılabilir

Restic her zaman şifrelidir. Şifresiz 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 veriler de kaybolur, çü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 yalnızca parola ile geri yükleme yapılabilir. --encryption=keyfile anahtarı istemci tarafında ~/.config/borg/keys/ içinde tutar; bu durumda tüm depoyu çalan birinin elinde hiçbir şey olmaz, ancak anahtar dosyasını ayrıca yedeklemeniz gerekir, aksi takdirde arşivleriniz okunamaz hale gelir. Her modun, HMAC-SHA256 yerine BLAKE2b ile doğrulama yapan ve SHA hızlandırması olmayan donanımlarda daha hızlı çalışan bir -blake2 varyantı mevcuttur. --encryption=none seçeneği de mevcuttur ve depo, sahibi olduğunuz şifreli bir disk üzerinde durduğunda bu gerçek bir tercihtir.

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 kiralanan bir makinede asla none tercih edilmemelidir.

Sıkıştırma ve restic'in bu özelliği geç almasının nedeni

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 bir parça (chunk) üzerinde bir buluşsal yöntem çalıştırarak, halihazırda sıkıştırılmış verilerin tekrar 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ılan durumdadır ve sıkıştırma, --compression ile auto, off veya max değerleri kullanılarak ayarlanır. Eski bir format 1 deposu, siz onu taşıyana (migrate) kadar sıkıştırılmamış olarak kalır. Bu nedenle, 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 boyutta depolama alanı harcamaya devam ediyorsunuz demektir.

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

Karar genellikle bu noktada verilir.

Restic'in S3'e erişmesi için ortam değişkenlerinde kimlik bilgilerinin tanımlanması yeterlidir; başka bir yerde herhangi bir işlem çalıştırılması gerekmez. Aynı yöntem, kendi barındırdığınız bir bucket için de geçerlidir ve sıkça tercih edilen bir eşleşmedir: kendi VPS'nizde S3 API için MinIO çalıştırın ve restic'i bu hedefe 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ı ve karşı tarafta yüklü bir Borg sürümü gerekir; ayrıca karşı taraftaki sürümün istemci ile uyumlu olması beklenir. Eğer karşı taraf size ait değilse bu durum bir engel teşkil eder. Ancak karşı taraf yönettiğiniz ikinci bir sunucu ise bu durum bir sorun yaratmaz ve her iki aracın sunduğu fidye yazılımlarına karşı en güçlü korumayı sağlar: sadece ekleme yapılabilen (append-only) bir SSH anahtarı. Anahtarı borg serve komutunu çalıştıracak şekilde kısıtladığınızda, istemci arşiv ekleyebilir ancak bunları silemez; böylece güvenliği ihlal edilen bir makine kendi yedekleme 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, sadece 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) özellikleri ile elde edersiniz. Taşıma katmanını da güvenli hale getirin; çünkü bu yapıdaki 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

Her iki proje de kendi verileriniz için güvenebileceğiniz bir kıyaslama raporu yayınlamaz; bu nedenle mekanizmayı temel alarak mantık yürütmek gerekir.

Borg over SSH, 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ğ üzerinde gidiş-dönüş trafiğine dönüşmez.

Nesne depolama (object storage) üzerindeki Restic'in sunucu tarafı yoktur; bu nedenle kendi görünümünü, HTTP üzerinden getirdiği dizin dosyaları ve paket dosyalarından oluşturmak zorundadır. İstek sayısını makul düzeyde tutmak için, yükleme yapmadan ö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 tüm dizin yeniden indirilmez. Bu önbelleği silerseniz, yeniden oluşturma süreci nedeniyle bir sonraki yedekleme yavaş gerçekleşir. Milyonlarca küçük dosyanın bulunduğu yüksek gecikmeli bir bağlantıda, Restic'in aynı veri üzerinde Borg'dan daha yavaş hissedildiği durum budur.

Yerel disk veya hızlı bir yerel ağ (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ı vererek başarısız olur. Desteklenen yöntem, her istemci için ayrı bir depo kullanılmasıdır. Bu durum, tekilleştirmenin (deduplication) 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 bir 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 verisinin de kaybedilmesi anlamına gelir.

Saklama politikası: forget ve prune kullanımı 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ı tuzağa düşmek mümkündür ve bunu açıkça belirtmek gerekir. Borg içinde borg prune arşivleri siler ancak disk alanını kendi başına boşaltmaz. Alan, borg compact çalıştırıldığında geri kazanılır; bu nedenle sadece budama (prune) yapan ancak sıkıştırma (compact) yapmayan bir cron işi, arşiv listesi kısa kalsa bile deponun sürekli büyümesine neden olur. Restic içinde ise --prune olmadan çalıştırılan forget, yalnızca snapshot referanslarını kaldırır; veriler, bir prune işlemi çalışana kadar depoda kalmaya devam eder.

Budama 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ı size bildirir; bu, durumu bir geri yükleme sırasında öğrenmekten çok daha güvenli bir yöntemdir.

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 biçimine 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ı yazarak onları kaybedersiniz.

Hatasız tamamlanan bir geri yükleme bile tek başına kanıt sayılmaz; çünkü üst katmandaki uygulamanın tam bir geri yüklemenin ne olduğuna dair kendi kuralları vardır: Postgres veri dizininin bir kopyasından yeniden oluşturulan bir Immich sunucusu, diskteki tüm fotoğraflarla geri döner ancak zaman çizelgesi boş görünür. Bu, Immich yedekleme ve geri yükleme rehberinde aşılması gereken temel sorundur.

Hangi aracı seçerseniz seçin, zamanlama işin yalnızca yarısıdır. Geri yükleme işlemini, tıpkı VPS için restic yedekleme rehberi içinde systemd timer ile yapıldığı gibi, düzenli olarak takip ettiğiniz bir zamanlayıcı ile geçici bir dizine gerçekleştirin.

Hangi iş için hangisi tercih edilmeli

Hedef nesne depolama (object storage) ise, tek bir binary dosyası ile uzak uçta başka bir yazılıma ihtiyaç duymadan çalışmak istiyorsanız, birden fazla makinenin birbirine karşı tekilleştirme (deduplication) yapmasını hedefliyorsanız veya geri yüklemeyi yapan kişi siz olmayacaksanız restic tercih edin. Tek bir statik binary dosyası ve depo için bir URL ile çalışması, operasyonel açıdan rakipsizdir.

Hedef kontrolünüz altındaki bir Linux sunucusu ise, 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 edin. Daha eski bir araçtır, kararlı sürümleri yavaş ilerler; yedekleme yazılımlarında bu bir özelliktir.

Her iki araç da doğru cevaptır. Yanlış cevap, asla test etmediğinizdir. Eğer halihazırda uygulama seviyesinde dump alıyorsanız, bunları tutmaya devam edin: veritabanı dump'ları ile Docker üzerinde Nextcloud kurulumu içindeki model her iki araç için de geçerlidir; çünkü rastgele bir anda kopyalanan canlı bir veritabanı dosyası, veritabanının yedeği sayılmaz.

FAQ

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

Yerel diskte veya hızlı bir yerel ağda (LAN) performansları birbirine yakındır; her ikisi de kaynak üzerindeki okuma ve hash hızına bağlı olarak sınırlanır. Borg, çok sayıda küçük dosyanın bulunduğu yüksek gecikmeli bir SSH bağlantısında genellikle daha iyi sonuç verir; çü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. Hedef nesne depolama (object storage) olduğunda ise restic daha avantajlıdır; çünkü Borg nesne depolama ile doğrudan çalışamaz.

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çerisinde böyle bir süreç çalışmaz. Kullanıcılar, nesne depolamayı rclone ile bir dosya sistemi gibi bağlayarak (mount) bu sorunu aşmaya çalışmaktadır; ancak Borg projesi bunu önermez. Çünkü bir işlem sırasında bağlantının kopması, deponun bozulmasına yol açabilir. Nesne depolama kullanmanız gerekiyorsa restic tercih edin.

Her iki aracı da aynı veriler ü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) kopyalar için ise restic ile nesne depolamaya yedek alırlar. Bu araçlar hiçbir veriyi paylaşmaz; bu nedenle 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 geri yükleme yöntemini de test ettiyseniz uygulayın.

Depo parolasını kaybedersem ne olur?

Her iki araçta da veriler kurtarılamaz hale gelir. Restic, anahtarını paroladan scrypt kullanarak türetir ve bunu atlamanın bir yolu yoktur. Borg, repokey modunda şifrelenmiş anahtarı deponun içinde saklar, bu sayede sadece parola ile geri yükleme yapılabilir; keyfile modunda ise ayrıca ~/.config/borg/keys/ dizinindeki anahtar dosyasına da 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. Şimdi 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.