Restic mi BorgBackup mı? Hangisi kullanılmalı?

Restic ve BorgBackup, tek paragrafta

Restic ve BorgBackup, bir Linux sunucusunun yinelenen verileri ayıklanmış, şifrelenmiş ve artımlı yedeklerini alma işini yapar. Seçimi belirleyen fark, yedeğin nereye yazıldığıdır. Restic, S3 ve diğer nesne depolama API'lerini yerel olarak destekler. Bu nedenle bir bucket, uzak uçta herhangi bir yazılım kurulumu gerektirmeyen birincil hedeftir. Borg ise repository'yi barındıran makinede borg programının kurulu olmasını gerektirir. Çünkü Borg repository'si bir dosya sistemi veya API tarafından değil, bir işlem tarafından sunulur. Hedef nesne depolamaysa yanıt zaten bellidir. Hedef denetiminizdeki ikinci bir Linux makinesiyse Borg kullanılabilir ve çoğu zaman daha hızlıdır.

Diğer tüm farklar daha küçüktür. Her ikisi de dosyaları içerik tanımlı parçalara böler. Bu nedenle 200 MB değişen 40 GB boyutundaki bir dizin yaklaşık 200 MB veri yükler. Her ikisi de istemci tarafında şifreleme yapar. Her ikisi de bir snapshot'ı FUSE (userspace dosya sistemi) ile bağlar. Böylece tek bir dosya dışarı kopyalanabilir. Temmuz 2026 itibarıyla restic sürümü 0.19.1, Borg'un kararlı serisi ise 1.4 ve sürümü 1.4.5'tir. Borg 2.0 yıllardır beta aşamasındadır ve hâlâ yalnızca test amaçlı olarak işaretlenmiştir. Bu nedenle bugün dağıtılması gereken sürüm 1.4'tür.

Gerçek fark depo modelidir

Bir restic deposu, dosyalardan oluşan bir dizindir: config, keys/, snapshots/, index/ ve paket dosyaları içeren data/. Bu depoyu okumak için başka bir şey gerekmez. restic bu nedenle çok sayıda arka uçla çalışabilir. Blob'ları yazabilen, okuyabilen, listeleyebilen ve silebilen her depolama alanı bir restic deposu barındırabilir. Bu sayede tek bir ikili dosya yerel yolları, SFTP'yi, kendi REST sunucusunu, S3'ü, Backblaze B2'yi, Azure'ı, Google Cloud Storage'ı ve rclone'ın erişebildiği her şeyi destekler.

Borg deposu da diskteki dosyalardan oluşur, ancak Borg bu depoyla basit bir aktarım üzerinden hiçbir zaman iletişim kurmaz. Uzak bir depo için Borg, SSH üzerinden karşı tarafta borg serve işlemini başlatır ve bu işlemle kendi protokolü üzerinden iletişim kurar. Sunucu tarafı gerçek işi yürütür: depoyu barındırır, işlemi uygular ve dizin sorgularını yanıtlar. Borg'un S3 arka ucuna sahip olmamasının ve projenin böyle bir arka uç eklememesinin nedeni budur. Bir bucket içinde çalıştırılacak bir işlem yoktur.

Bu tek tasarım özelliğ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: bunlardan biri devre dışı bırakılabilir

Restic her zaman şifrelidir. Şifrelenmemiş bir çalışma modu yoktur. restic init bir parola ister, scrypt ile bu paroladan bir anahtar türetir ve bundan sonra yazılan her pack dosyası şifrelenir ve kimlik doğrulaması yapılır. Parola kaybedilirse veriler de kaybedilir; çünkü tasarım gereği kurtarma yolu yoktur.

Borg, şifrelemeyi repository oluşturulurken seçilebilir hale getirir ve bu seçim kalıcıdır. borg init --encryption=repokey şifrelenmiş anahtarı repository içinde tutar; bu nedenle yalnızca parola ile geri yükleme yapılabilir. --encryption=keyfile anahtarı istemcide ~/.config/borg/keys/ içinde tutar; bu nedenle repository'nin tamamını çalan kişinin elinde yine de hiçbir şey olmaz. Ancak bu anahtar dosyasının ayrıca yedeklenmesi gerekir; aksi halde arşivler okunamaz. Her modun, HMAC-SHA256 yerine BLAKE2b ile kimlik doğrulaması yapan bir -blake2 varyantı vardır. Bu varyant, SHA hızlandırması olmayan donanımlarda daha hızlıdır. --encryption=none de kullanılabilir. Repository sahibi olunan şifreli bir diskte bulunduğunda bu gerçek bir seçenektir.

Pratik kural şudur: normal bir sunucu yedeklemesi için repokey-blake2, repository tamamen güvenilmeyen bir yerde bulunduğunda keyfile kullanılmalı ve kiralanmış bir makinede asla none kullanılmamalıdır.

Sıkıştırma ve restic'in bunu geç kullanmaya başlamasının nedeni

Borg, başlangıçtan beri sıkıştırma kullanır. Varsayılan seçenek lz4 değeridir. Bu seçenek, her durumda etkin bırakılabilecek kadar hızlı olduğu için seçilmiştir. zstd, 1 ile 22 arasındaki düzeyleri kabul eder ve varsayılan olarak 3 değerini kullanır. zlib ve lzma, zamandan çok bayt sayısına önem verilen durumlar içindir. auto, verilerin zaten sıkıştırılmış olup olmadığını her parça için sezgisel olarak denetler. Böylece veriler ikinci kez sıkıştırılmaz.

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 repository format 2 çıkana kadar hiç sıkıştırma kullanmıyordu. Yeni bir repository için artık varsayılan format 2'dir. Sıkıştırma, --compression kullanılarak auto, off veya max değerleriyle ayarlanır. Eski format 1 repository, taşınana kadar sıkıştırılmadan kalır. Bu nedenle restic repository'niz 0.14 sürümünden eskiyse ve taşıma işlemi yapmadıysanız, metin, log ve veritabanı dökümleri için hâlâ tam boyut kadar depolama alanı kullanırsınız.

Uzak hedefler: S3 ve SSH

Seçim genellikle burada yapılır.

Restic'in S3'e erişmesi için ortamda kimlik bilgileri bulunması yeterlidir; başka bir yerde çalışan ek bir bileşen gerekmez. Aynı yaklaşım, kendiniz barındırdığınız bir bucket için de kullanılabilir. Bu yaygın bir eşleştirmedir: kendi VPS'inizde S3 API'si için MinIO çalıştırın ve restic'i buna 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 repository'ye erişmesi için SSH ve uzak tarafta Borg kurulumu gerekir. Uzak taraftaki sürümün istemciyle uyumlu olması da gerekir. Uzak taraf size ait değilse bu durum ek yük oluşturur. Zaten yönettiğiniz ikinci bir sunucuysa sorun oluşturmaz. Ayrıca her iki aracın ransomware saldırılarına karşı sunduğu en güçlü denetimi sağlar: yalnızca ekleme yapabilen bir SSH anahtarı. Anahtarı borg serve çalıştırmaya zorlayın. Böylece istemci arşiv ekleyebilir, ancak arşiv silemez. Bu sayede ihlal edilmiş bir makine kendi geçmişini silemez.

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

Restic'te bunun eşdeğeri yalnızca, yalnızca ekleme modunu destekleyen kendi REST server'ını çalıştırdığınızda bulunur. Düz S3 kullanımında aynı sonuç bucket policy veya object lock ile elde edilir. Bu iş restic'e değil, sağlayıcıya aittir. Aktarımı da kısıtlayın. SSH tarafı, diğer tüm oturum açma işlemleri kadar dikkatli yapılandırılmalıdır: yedekleme hesabına yalnızca anahtar kullanan ve kısıtlı bir authorized_keys girdisine sahip SSH uygulayın.

Her tasarımın ortaya çıkardığı hız özellikleri

Her iki proje de kendi verileriniz için güvenmeniz gereken bir kıyaslama yayımlamamaktadır. Bu nedenle mekanizmaya göre değerlendirme yapılmalıdır.

SSH üzerinden Borg, gecikmenin bulunduğu bağlantılarda hızlıdır; çünkü sunucu tarafı akıllıdır. İstemci bir istek gönderir, uzak borg serve işlemi bu isteği depo dizininden yanıtlar ve işlem tek bir yerde gerçekleştirilir. Parça aramaları, her küçük dosya için ağ üzerinden gidiş-dönüşlere dönüşmez.

Nesne depolama kullanan restic'in sunucu tarafı yoktur. Bu nedenle kendi durumunu HTTP üzerinden aldığı dizin ve paket dosyalarından oluşturmalıdır. İstek sayısını makul düzeyde tutmak için yüklemeden önce çok sayıda küçük parçayı daha büyük paket dosyalarında birleştirir. Ayrıca bir sonraki çalıştırmada dizinin tamamını yeniden almamak için ~/.cache/restic konumunda yerel bir önbellek tutar. Bu önbellek silinirse sonraki yedekleme, önbelleği yeniden oluşturduğu için 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 diskte veya hızlı bir LAN üzerinde fark büyük ölçüde kapanır. Her iki araç da sonunda kaynağı okuma ve özetleme hızlarıyla sınırlı hale gelir.

Birden çok makineyi kilitleme ve yedekleme

Borg 1.4, işlemin tamamı boyunca depo üzerinde özel kilit alır. Aynı anda tek bir depoya yazan iki istemci desteklenmez: İkinci istemci bekler, ardından kilit zaman aşımı nedeniyle başarısız olur. Desteklenen yapı, her istemci için bir depo kullanılmasıdır. Bunun sonucu olarak tekilleştirme yalnızca bir makinenin deposu içinde gerçekleşir. Bu nedenle birbirine çok benzeyen on sunucu, aynı temel sistemin on kopyasını depolar.

Restic, bir yedekleme paylaşımlı kilit aldığı ve yalnızca prune gibi bakım işlemleri özel kilit gerektirdiği için aynı anda birden çok istemcinin tek bir depoya yedekleme yapmasına izin verir. Tek bir restic deposuna yönlendirilen birbirine benzeyen on sunucu birbirleriyle tekilleştirme yapar. İkinci sunucu ve sonraki sunucular genellikle çok az veri depolar. Bunun bedeli etki alanıdır: Her şeyi içeren tek bir depo ve tek bir parola bulunur. Parolanın kaybedilmesi, on sunucudaki tüm verilerin kaybedilmesine yol açar.

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

Her iki araç da "neyin saklanacağına karar verme" ile "alanı geri kazanma" işlemlerini birbirinden ayırır. İkinci adımı ayrıca ç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ı hata yapılabilir ve bunun açıkça belirtilmesi gerekir. Borg'da borg prune arşivleri kaldırır, ancak tek başına disk alanını serbest bırakmaz. Alan, borg compact çalıştığında geri kazanılır. Bu nedenle arşivleri prune eden, ancak compact işlemini hiç çalıştırmayan bir cron işi, arşiv listesi kısa kalırken sürekli büyüyen bir repository oluşturur. restic'te ise --prune olmadan forget yalnızca snapshot başvurularını kaldırır. Veriler, prune çalıştırılana kadar repository'de kalır.

Prune işleminden sonra restic check çalıştırın. Bu komut repository yapılarını doğrular ve bir bozulma varsa bildirir. Bu, sorunu restore sırasında öğrenmekten çok daha iyidir.

Geri yükleme: önemli olan tek test

Her iki araç da bir snapshot'ı mount ederek içeriğine göz atmanıza olanak tanır. Tek bir dosyayı geri getirmenin 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 edilmelidir. Arşiv içindeki yollar, baştaki slash olmadan saklanır. Bu nedenle etc/nginx doğru seçimdir; /etc/nginx ise hiçbir eşleşme bulamaz ve hiçbir şey çıkarmadan, bunu açıklayan bir hata da vermeden sonlanır. Extraction işlemi ayrıca geçerli çalışma dizinine yazar. Bu nedenle önce bir scratch dizinine geçilmelidir. Aksi halde eski dosyalar canlı dosyaların üzerine yazılır.

Hangi araç seçilirse seçilsin, schedule işin yalnızca yarısıdır. VPS için restic yedekleme kılavuzunun geri kalanı bölümündeki tam uygulamada systemd timer ile yapıldığı gibi, gerçekten izlenen bir zamanlayıcıyla scratch dizinine restore işlemi çalıştırılmalıdır.

Hangi iş için hangisi daha uygundur

Hedef nesne depolama ise, tek bir ikili dosya kullanmak ve uzak uçta yazılım çalıştırmamak istiyorsanız, birden fazla makinenin birbirine göre tekilleştirme yapması gerekiyorsa veya geri yüklemeyi yapacak kişi siz olmayacaksanız restic tercih edilmelidir. Bir repository URL'siyle kullanılan tek bir statik ikili dosyadır. İşletim açısından bunu aşmak zordur.

Hedef kontrolünüzdeki bir Linux makinesi ise, bağlantıda gecikme varsa ve veri kümesi milyonlarca küçük dosyadan oluşuyorsa, fidye yazılımlarına karşı bir denetim olarak yalnızca ekleme yapılabilen SSH key kullanmak istiyorsanız veya sıkıştırmayı her iş için ayrı ayarlamak istiyorsanız Borg tercih edilmelidir. Daha eski bir araçtır. Kararlı serisi yavaş ilerler. Backup yazılımında bu bir avantajdır.

Her ikisi de doğru seçimdir. Yanlış seçim, hiç test edilmeyen seçimdir. Uygulama düzeyinde dump alıyorsanız bunları koruyun: veritabanı dump'ları içeren Docker üzerindeki Nextcloud kurulumu bölümündeki yaklaşım her iki araç için de geçerlidir. Çünkü canlı bir veritabanı dosyasının rastgele bir anda kopyalanması, veritabanının backup'ı değildir.

FAQ

restic veya BorgBackup daha mı hızlıdır?

Yerel diskte veya hızlı bir LAN üzerinde performansları birbirine yakındır. Her ikisinde de performans, kaynak üzerindeki okuma ve özetleme hızlarıyla sınırlanır. Çok sayıda küçük dosya içeren ve gecikmesi yüksek bir SSH bağlantısında genellikle Borg daha iyi performans gösterir. Bunun nedeni, uzak taraftaki bir borg serve işleminin her parça için ağ üzerinden gidiş dönüş yapmadan dizin sorgularını yanıtlayabilmesidir. Hedef nesne depolama olduğunda ise genellikle restic daha iyi performans gösterir. Borg bu hedefe doğrudan erişemez.

BorgBackup ile S3 veya Backblaze B2 üzerine yedek alınabilir mi?

Doğrudan alınamaz. Bir Borg deposu SSH üzerinden borg serve işlemi tarafından sunulur. Bir bucket içinde böyle bir işlem çalışmaz. Nesne depolama, rclone ile dosya sistemi olarak bağlanarak kullanılabilir. Ancak Borg projesi bunu önermez. Bunun nedeni, işlem sırasında bağlantısı kesilen bir bağlamanın depoyu bozabilmesidir. Nesne depolamaya ihtiyacınız varsa restic kullanın.

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

Evet. Bazı kullanıcılar bunu yapar: hızlı yerel geri yükleme için Borg ile ikinci bir sunucuya, site dışı kopya için restic ile nesne depolamaya yedek alınır. Bu araçlar hiçbir şeyi paylaşmaz. Bu nedenle okuma ve özetleme maliyetini iki kez ödersiniz. Ayrıca güvenli biçimde saklanması gereken iki parolanız olur. Bunu yalnızca her iki geri yüklemeyi de test ettiyseniz yapın.

Depo parolasını kaybedersem ne olur?

Her iki araçta da veriler kurtarılamaz. Restic anahtarını paroladan scrypt ile türetir ve bunun bir atlatma yolu yoktur. Borg repokey modunda şifrelenmiş anahtarı deponun içinde saklar. Bu nedenle geri yükleme için yalnızca parola yeterlidir. keyfile modunda ise ~/.config/borg/keys/ konumundaki anahtar dosyası da gerekir. Parolayı, yedeklenen sunucuda bulunmayan bir parola yöneticisinde saklayın. keyfile kullanıyorsanız Borg anahtarını borg key export ile dışa aktarın.

Borg 2.0'ı beklemeli miyim?

Hayır. Temmuz 2026 itibarıyla Borg 2.0 hâlâ beta aşamasındadır ve sürümü 2.0.0b22'dir. Proje bu sürümü yalnızca test amaçlı olarak belirtir. Kararlı seri 1.4'tür ve güncel sürüm 1.4.5'tir. Şimdilik 1.4 ile başlayın. Borg 2 depo biçimini değiştirir ve belgelenmiş bir yükseltme yolu sunar. Bu nedenle bugün başlamak ileride geçiş yapmanızı engellemez.