Bir sunucuyu aylarca sorunsuz çalıştırabilirsiniz; ama yedekleme stratejiniz yoksa tek bir disk arızası, yanlış bir DROP TABLE ya da bir fidye yazılımı saldırısı her şeyi bir anda silip süpürebilir. Yıllardır sistem yöneticiliği yapan herkesin bildiği acı bir gerçek vardır: veriyi kaybetmek kolay, geri getirmek çoğu zaman imkânsızdır. İşte tam bu yüzden yedeği "ara sıra bir tar arşivi almak" olarak görmek yerine, disten tasarruf eden, şifreli ve otomatik çalışan bir sistem olarak kurmak gerekir. BorgBackup (kısaca borg), bu ihtiyacı karşılamak için tasarlanmış, açık kaynaklı ve olgun bir yedekleme aracıdır.
Bu rehberde Borg'un neden basit bir kopyalama aracından çok daha fazlası olduğunu ele alacağız: blok düzeyinde tekilleştirme (deduplication) ile aynı veriyi bir kez saklaması, AES ile uçtan uca şifreleme yapması, artımlı yedekleri her seferinde "tam yedek" gibi göstermesi ve prune ile saklama politikasını otomatik yönetmesi. Depo oluşturmaktan (borg init) uzak sunucuya SSH ile yedek göndermeye, cron ile otomasyondan geri yüklemeye kadar tüm akışı gerçek komutlarla göstereceğiz. Klasik bir yaklaşımla, örneğin rsync ile yedekleme yönteminden gelen bir okuyucu için Borg'un getirdiği kazanımları da net biçimde karşılaştıracağız.
BorgBackup Nedir ve Neyi Farklı Yapar?#
BorgBackup, dosyalarınızı bir "depo" (repository) içine yedekleyen, komut satırından çalışan bir programdır. Onu cp, scp veya sıradan bir tar arşivinden ayıran üç temel özelliği vardır: tekilleştirme, şifreleme ve sıkıştırma. Bu üçü bir arada çalıştığında, sonuç hem çok az yer kaplayan hem de gizliliği korunan bir yedek sistemi olur.
Borg her yedeği bir "arşiv" (archive) olarak depoya ekler. Ama arka planda dosyaları sabit boyutlu kopyalar olarak değil, değişken boyutlu parçalara (chunk) böler ve her parçayı içeriğinin karma değeriyle (hash) tanımlar. Aynı içeriğe sahip bir parça depoda zaten varsa, Borg onu tekrar yazmaz; sadece referans verir. Bu yüzden 100 GB'lık bir sunucuyu her gün yedeklediğinizde, ikinci günden itibaren depoya eklenen veri yalnızca o gün gerçekten değişen kısımlar kadardır. On günlük yedek, 10 x 100 GB değil, ilk tam yedek artı değişikliklerin toplamı kadar yer kaplar.
Şifreleme tarafında Borg, veriyi depoya yazmadan önce istemci tarafında şifreler (client-side encryption). Yani yedek sunucusu ele geçse bile, parola olmadan içeriği okumak mümkün değildir. Bu, yedekleri kiralık bir depolama alanında veya güvenmediğiniz bir sunucuda tutarken çok değerli bir güvencedir. Sıkıştırma ise (lz4, zstd, zlib) tekilleştirmeden sonra kalan veriyi daha da küçültür. Bu üç mekanizmanın birleşimi, Borg'u özellikle sınırlı disk ve bant genişliğine sahip senaryolarda öne çıkarır.
Tekilleştirme ve Şifreleme Neden Bu Kadar Önemli?#
Tekilleştirmenin gücünü somut bir örnekle görelim. Diyelim ki bir web sunucusunda 40 GB'lık dosya ve bir de WordPress veritabanı var. Klasik bir "her gün tam yedek al" yaklaşımında bir ay boyunca günlük yedek tutmak yaklaşık 30 x 40 GB = 1.2 TB alan ister. Borg'da ise ilk gün 40 GB yazılır, sonraki günlerde yalnızca değişen bloklar eklenir. Günlük değişim ortalama 500 MB ise, bir aylık depo yaklaşık 40 GB + 29 x 500 MB ≈ 54 GB olur. Fark, yirmi katın üzerindedir.
Bu tasarruf yalnızca disk maliyeti değildir; aynı zamanda hız ve bant genişliği demektir. Uzak bir sunucuya yedek gönderiyorsanız, ağdan yalnızca yeni parçalar geçer. Bu yüzden ilk yedek uzun sürse de sonraki günlük yedekler çoğu zaman birkaç dakikada biter. Aşağıdaki tablo, üç yaklaşımın kabaca nasıl ölçeklendiğini özetler:
| Özellik | tar + gzip | rsync | BorgBackup |
|---|---|---|---|
| Tekilleştirme | Yok | Dosya düzeyinde | Blok düzeyinde (chunk) |
| Artımlı yedek | Zor/manuel | Doğal (delta) | Doğal + snapshot |
| Şifreleme | Ayrı adım (gpg) | Yok (SSH taşımada) | Yerleşik (AES-CTR) |
| Bütünlük doğrulama | Yok | Yok | borg check (HMAC) |
| Saklama politikası | Manuel | Manuel (find) | Yerleşik (borg prune) |
| Depo boyutu | En büyük | Orta | En küçük |
Şifrelemenin önemi ise gizlilik ve mevzuat açısından belirginleşir. Yedekleriniz müşteri verisi, veritabanı dökümleri veya kişisel bilgiler içeriyorsa, bunların şifresiz bir yedek diskinde durması ciddi bir risktir. Borg'un istemci tarafı şifrelemesi sayesinde yedek deposu üçüncü tarafta olsa dahi veri güvende kalır. Bu konuyu daha geniş bir güvenlik çerçevesinde ele almak isterseniz, sunucularınız için ek koruma katmanları sağlayan SSL ve WAF hizmetlerimize de göz atabilirsiniz.
Kurulum ve Depo Oluşturma (borg init)#
Borg, çoğu dağıtımın paket deposunda bulunur. Ubuntu/Debian ve AlmaLinux/Rocky için kurulum tek satırdır:
# Ubuntu / Debian
sudo apt update && sudo apt install -y borgbackup
# AlmaLinux / Rocky / RHEL (EPEL gerekebilir)
sudo dnf install -y epel-release
sudo dnf install -y borgbackup
# Sürümü doğrula
borg --version
Yedek almadan önce bir depo (repository) oluşturmanız gerekir. Depo, tüm arşivlerin ve tekilleştirilmiş parçaların saklandığı dizindir. borg init komutu bu depoyu şifreleme moduyla birlikte hazırlar. Önerilen mod, parolayı deponun içine (şifreli olarak) gömen repokey veya daha hızlı karma için repokey-blake2'dir:
# Yerel bir depo oluştur (parola korumalı, blake2 ile)
borg init --encryption=repokey-blake2 /yedek/borg-depo
Komut sizden bir parola isteyecektir. Bu parola olmadan yedeklerinize asla erişemezsiniz — depo şifreli olduğu için Borg dahi parolasız açamaz. Bu yüzden parolayı bir parola yöneticisinde saklamak hayati önemdedir. Şifreleme modlarının farkı şöyledir: repokey anahtarı deponun içinde tutar (deponuz güvendeyse pratiktir), keyfile anahtarı ayrı bir dosyada tutar (deponuz güvenmediğiniz bir yerdeyse daha güvenlidir), none ise şifrelemeyi kapatır ve yalnızca tamamen izole ortamlarda önerilir.
Depo bir kez oluşturulduktan sonra her komutta tam yolunu yazmak yorucu olur. İşleri kolaylaştırmak için ortam değişkenleri kullanabilirsiniz:
# Depo yolunu ve parolayı ortam değişkenine al
export BORG_REPO=/yedek/borg-depo
export BORG_PASSPHRASE='cok-gizli-uzun-parola'
BORG_PASSPHRASE özellikle cron ile otomasyonda gereklidir, çünkü betik interaktif olarak parola soramaz. Bu değişkeni güvenli izinlere sahip (chmod 600) ayrı bir dosyada tutup betikten okumak, parolayı doğrudan crontab içine yazmaktan daha güvenlidir.
İlk Yedeği Almak (borg create)#
Depo hazır olduğuna göre ilk yedeği alabiliriz. borg create komutu bir arşiv oluşturur. Arşiv adını genellikle tarih/saat ile benzersiz yaparız ki her yedek ayrı bir noktayı temsil etsin:
# Bir web dizini + sistem yapılandırmasını yedekle
borg create --stats --progress \
--compression zstd,6 \
::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
/var/www \
/etc \
/home
Buradaki :: ifadesi BORG_REPO değişkenindeki depoya işaret eder; küme parantezli {hostname} ve {now} kalıpları arşiv adını otomatik doldurur. --compression zstd,6 orta düzey bir sıkıştırma sunar (1 en hızlı, 22 en yoğun; zstd,6 günlük kullanımda hız/oran dengesi iyidir). --stats bittiğinde ne kadar veri işlendiğini ve tekilleştirme sonrası depoya ne eklendiğini gösterir; bu çıktı Borg'un değerini gözle görmek için birebirdir.
Yedeğe her şeyi dahil etmek istemezsiniz. Geçici dosyalar, önbellekler, log arşivleri ve paket dizinleri hem yer kaplar hem gereksizdir. --exclude ile bunları dışarıda bırakabilirsiniz:
borg create --stats \
--exclude '/var/www/*/cache' \
--exclude '*.log' \
--exclude '/home/*/.cache' \
--exclude-caches \
::'{hostname}-{now:%Y-%m-%d}' \
/var/www /etc /home
--exclude-caches özellikle pratiktir: içinde CACHEDIR.TAG bulunan dizinleri otomatik atlar (birçok uygulama önbellek dizinlerini böyle işaretler). İlk yedek, deponun sıfırdan dolması nedeniyle uzun sürebilir; ama merak etmeyin, bir sonraki bölümde göreceğiniz gibi ikinci yedekten itibaren süre dramatik biçimde düşer. Veritabanı yedeklerini de bu akışa katmak isterseniz, önce mysqldump ile bir döküm alıp onu Borg'a dahil etmek yaygın bir yöntemdir; cPanel yedekleme tarafında veritabanı dökümlerinin nasıl alındığını daha ayrıntılı ele alıyoruz.
Yedekleri Listeleme, Doğrulama ve Geri Yükleme#
Yedek almak yarısıdır; asıl amaç gün geldiğinde geri yükleyebilmektir. Önce depodaki arşivleri listeleyelim:
# Depodaki tüm arşivleri (yedek noktalarını) listele
borg list
# Belirli bir arşivin içindeki dosyaları gör
borg list ::sunucu-2026-07-10
Bir arşivi tamamen geri yüklemek için borg extract kullanılır. Dikkat: extract, komutu çalıştırdığınız dizine göre açar, bu yüzden önce doğru bir hedef dizine geçin:
# Boş bir kurtarma dizinine geç ve arşivi aç
mkdir -p /kurtarma && cd /kurtarma
borg extract ::sunucu-2026-07-10
# Yalnızca tek bir yolu geri getir (örn. sadece bir siteyi)
cd /kurtarma
borg extract ::sunucu-2026-07-10 var/www/site
Tek bir dosyayı hızlıca kurtarmak için en zarif yöntem, arşivi bir dizin olarak bağlamaktır (mount). Borg, FUSE ile arşivi salt-okunur bir klasör gibi gösterir; içinde gezip istediğiniz dosyayı kopyalayabilirsiniz:
# Arşivi bir noktaya bağla
mkdir -p /mnt/borg
borg mount ::sunucu-2026-07-10 /mnt/borg
# Dosyayı normal şekilde kopyala
cp /mnt/borg/var/www/site/wp-config.php /var/www/site/
# İşin bitince ayır
borg umount /mnt/borg
Yedeklerin bozulmadığından emin olmak için düzenli olarak borg check çalıştırın. Bu komut, depo ve arşivlerin bütünlüğünü HMAC ile doğrular; bir parça bozulmuşsa erkenden haber verir. Unutmayın: test edilmemiş yedek, yedek değildir. Ayda bir örnek bir geri yükleme yapıp içeriği doğrulamak, kritik bir alışkanlıktır.
# Depo ve arşiv bütünlüğünü doğrula
borg check --verbose /yedek/borg-depo
Uzak Depoya SSH ile Yedekleme#
Aynı sunucudaki bir diske yedek almak, disk arızasına karşı sizi korumaz; ikisi de aynı anda gidebilir. Gerçek koruma, yedeğin farklı bir fiziksel makinede durmasıyla gelir. Borg bunu SSH üzerinden yerel bir kurulum gerektirmeden yapar — tek koşul, uzak sunucuda da borg yüklü olmasıdır. Uzak depo yolu, kullanıcı@sunucu:yol biçimindedir:
# Uzak sunucuda bir depo oluştur (bir kez)
borg init --encryption=repokey-blake2 \
[email protected]:/depo/web01
# Uzak depoya yedek gönder
borg create --stats --progress \
[email protected]:/depo/web01::'{hostname}-{now:%Y-%m-%d}' \
/var/www /etc
Otomasyonun sorunsuz çalışması için SSH anahtar tabanlı kimlik doğrulama şarttır; aksi halde cron içindeki komut parola bekleyip takılır. Yerel sunucuda bir anahtar üretip açık anahtarı uzak sunucuya kopyalayın:
# Anahtar çifti oluştur (parolasız, otomasyon için)
ssh-keygen -t ed25519 -f ~/.ssh/borg_key -N ''
# Açık anahtarı yedek sunucusuna yükle
ssh-copy-id -i ~/.ssh/borg_key.pub [email protected]
Güvenliği artırmak için uzak sunucudaki ~/.ssh/authorized_keys dosyasında bu anahtarı yalnızca Borg'a izin verecek şekilde kısıtlayabilirsiniz. command="borg serve --restrict-to-path /depo/web01",restrict öneki, o anahtarla bağlanan tarafın yalnızca belirtilen depo yolunda Borg çalıştırabilmesini sağlar; başka hiçbir kabuk komutu çalışmaz. Bu, ele geçen bir anahtarın zararını ciddi biçimde sınırlar. SSH sertleştirmenin genel prensiplerini kendi sunucunuzda uygularken, tam kök erişimine sahip bir VDS ya da sanal sunucu bu tür özel yapılandırmalar için ideal bir zemin sunar.
Saklama Politikası: borg prune#
Her gün yedek alırsanız deponuz sonsuza kadar büyümez — çünkü tekilleştirme sağ olsun — ama yine de sınırsız sayıda arşivi elle yönetmek istemezsiniz. borg prune, akıllı bir saklama politikasıyla eski arşivleri otomatik temizler. Klasik yaklaşım "son 7 gün, son 4 hafta, son 6 ay" gibi bir zaman piramididir:
# Saklama politikası uygula (silinecekleri önce göster)
borg prune --list --dry-run \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6 \
--glob-archives '{hostname}-*'
# Emin olduktan sonra gerçek prune
borg prune --list \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6 \
--glob-archives '{hostname}-*'
Bu politika şu anlama gelir: son 7 günün her günü, son 4 haftanın birer yedeği ve son 6 ayın birer yedeği saklanır; arada kalan gereksiz arşivler silinir. --dry-run ile önce neyin silineceğini görmek, tıpkı rsync'teki gibi kaza riskini ortadan kaldırır. Birden fazla sunucuyu aynı depoya yedekliyorsanız --glob-archives ile yalnızca ilgili makinenin arşivlerini hedeflemek çok önemlidir; aksi halde başka bir sunucunun yedeklerini yanlışlıkla budayabilirsiniz.
Önemli bir ayrıntı: prune arşivleri silinmiş olarak işaretler ama diskteki yeri hemen boşaltmaz. Modern Borg sürümlerinde yeri fiilen geri kazanmak için ayrıca borg compact çalıştırmanız gerekir:
# Silinen arşivlerin kapladığı alanı fiilen boşalt
borg compact /yedek/borg-depo
Cron ile Tam Otomatik Yedekleme#
Elle çalıştırılan yedek, er ya da geç unutulur. Bütün akışı — yedek al, saklama politikası uygula, alanı boşalt — tek bir betikte toplayıp cron ile her gece çalıştırmak, Borg'u gerçek bir koruma sistemine dönüştürür. Aşağıda üretimde kullanabileceğiniz sağlam bir örnek betik var (/root/borg-yedek.sh):
#!/bin/bash
set -o pipefail
# --- Ayarlar ---
export BORG_REPO='[email protected]:/depo/web01'
export BORG_PASSPHRASE="$(cat /root/.borg-pass)"
export BORG_RSH='ssh -i /root/.ssh/borg_key'
LOG='/var/log/borg-yedek.log'
echo "=== Yedek başladı: $(date) ===" >> "$LOG"
# 1) Yedek al
borg create --stats --compression zstd,6 \
--exclude '/var/www/*/cache' \
--exclude '*.log' \
--exclude-caches \
::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
/var/www /etc /home >> "$LOG" 2>&1
create_durum=$?
# 2) Saklama politikası
borg prune --list \
--keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
--glob-archives '{hostname}-*' >> "$LOG" 2>&1
prune_durum=$?
# 3) Alanı boşalt
borg compact >> "$LOG" 2>&1
# 4) Sonuç bildir
if [ $create_durum -eq 0 ] && [ $prune_durum -eq 0 ]; then
echo "=== Yedek başarılı: $(date) ===" >> "$LOG"
else
echo "!!! Yedek HATA (create=$create_durum prune=$prune_durum): $(date)" >> "$LOG"
fi
Parolayı betiğe gömmek yerine 600 izinli /root/.borg-pass dosyasından okumak daha güvenlidir. Betiği çalıştırılabilir yapıp cron'a ekleyin:
# Betiği çalıştırılabilir yap
chmod +x /root/borg-yedek.sh
chmod 600 /root/.borg-pass
# crontab'ı düzenle
crontab -e
crontab içine her gece 02.30'da çalışacak satırı ekleyin:
# Her gece 02:30'da Borg yedeği al
30 2 * * * /root/borg-yedek.sh
Artık sunucunuz her gece kendiliğinden tekilleştirilmiş, şifreli ve uzak bir yedek alır, eski arşivleri budar ve alanı geri kazanır. Log dosyasını ara sıra kontrol etmeyi ve mümkünse betiğe bir bildirim adımı (e-posta veya webhook) eklemeyi ihmal etmeyin; sessizce başarısız olan bir yedek, olmayan bir yedekten daha tehlikelidir. Bu tür betiklerle uğraşmak yerine yönetilen bir çözüm isterseniz, tüm yedekleme ve bakımı bizim üstlendiğimiz sunucu yönetimi ve yedekleme hizmetlerimiz devreye girebilir.
Borg mu, rsync mi? Hangi Durumda Ne Kullanmalı?#
Bu iki araç rakip değil, çoğu zaman tamamlayıcıdır. rsync, bir dizini başka bir yere birebir "aynalamak" için mükemmeldir: dağıtım yaparken, iki sunucuyu senkron tutarken veya basit bir yansıma isterken sadedir ve her yerde bulunur. Ancak rsync tek başına bir yedek geçmişi tutmaz; --link-dest ile snapshot benzeri bir yapı kurabilseniz de bu, Borg'un blok düzeyi tekilleştirmesi kadar verimli değildir ve yerleşik şifreleme sunmaz.
Borg ise "zaman içinde çok sayıda yedek noktası tutmak, bunları şifrelemek ve minimum yer kaplamak" senaryosunda açık ara öndedir. Değişen az miktarda veriyle onlarca yedek noktasını saklamak, tek komutla saklama politikası uygulamak ve tek parolayla tüm geçmişi güvenceye almak istiyorsanız Borg doğru araçtır. Pratik bir öneri: statik dosya yansıması ve hızlı dağıtım için rsync'i, tarihli ve şifreli felaket-kurtarma yedekleri için Borg'u birlikte kullanın. Paylaşımlı bir ortamdaysanız ve kabuk erişiminiz kısıtlıysa, kontrol paneli üzerinden yedek almanın yollarını cPanel yedekleme rehberimizde bulabilirsiniz.
Sıkça Sorulan Sorular#
BorgBackup rsync'ten daha mı iyi?#
İkisi farklı işler için tasarlanmıştır, bu yüzden "daha iyi" sorusu senaryoya bağlıdır. rsync bir dizini başka bir konuma birebir aynalamak ve hızlı senkronizasyon için idealdir, ancak yerleşik şifreleme veya tarihli yedek geçmişi sunmaz. Borg ise blok düzeyinde tekilleştirme, istemci tarafı şifreleme ve prune ile otomatik saklama politikası sağladığı için çok sayıda tarihli ve gizliliği korunan yedek tutmak istediğinizde çok daha uygundur. Pek çok yönetici statik yansıma için rsync'i, felaket kurtarma yedekleri için Borg'u birlikte kullanır.
Borg deposunun parolasını unutursam ne olur?#
Depo şifreliyse ve parolayı kaybederseniz, o depodaki hiçbir yedeğe erişemezsiniz; Borg dahil hiçbir araç şifreyi kıramaz, bu güvenlik özelliğinin bir gereğidir. Bu yüzden parolayı ve repokey modunda dahi ayrıca dışa aktardığınız anahtarı bir parola yöneticisinde veya güvenli bir yerde mutlaka saklamalısınız. borg key export komutuyla anahtarı yedekleyip güvenli bir konumda tutmak, olası bir depo bozulmasına karşı da ek bir güvence sağlar.
Borg gerçekten ne kadar yer kazandırır?#
Kazanç, verinizin ne kadar tekrar içerdiğine ve günlük değişim oranına bağlıdır, ama çoğu sunucu senaryosunda çok belirgindir. Her gün tam yedek yerine Borg kullandığınızda ilk yedek tüm veriyi yazar, sonraki yedekler yalnızca değişen blokları ekler; bu sayede bir aylık günlük yedek, otuz kat değil çoğu zaman tek bir tam yedeğin biraz üzerinde yer kaplar. borg create --stats çıktısındaki "Deduplicated size" satırı, o yedekte depoya fiilen ne eklendiğini gösterir ve tasarrufu somut biçimde görmenizi sağlar.
Borg yedeğini cron ile nasıl otomatikleştiririm?#
Yedek al, prune ile eski arşivleri buda ve compact ile alanı boşalt adımlarını tek bir kabuk betiğinde toplayıp bu betiği cron'a ekleyerek otomatikleştirirsiniz. Cron interaktif parola soramayacağı için parolayı BORG_PASSPHRASE ortam değişkeninden (tercihen 600 izinli ayrı bir dosyadan okuyarak) sağlamanız ve uzak yedeklerde SSH anahtar tabanlı kimlik doğrulama kurmanız gerekir. Betiğe bir log çıktısı ve başarısızlık durumunda bildirim eklemek, sessizce başarısız olan yedekleri erkenden fark etmenizi sağlar.
Borg ile uzaktaki sunucuya yedek almak için karşı tarafta ne gerekir?#
Uzak sunucuda yalnızca Borg'un kurulu olması ve SSH ile erişilebilir bir kullanıcının bulunması yeterlidir; ayrı bir sunucu yazılımı ya da ajan gerekmez. Depoyu kullanıcı@sunucu:yol biçiminde belirtir ve otomasyon için SSH anahtar tabanlı kimlik doğrulama kurarsınız. Güvenliği artırmak isterseniz uzak taraftaki authorized_keys içinde command="borg serve --restrict-to-path ..." kısıtlaması ekleyerek o anahtarın yalnızca belirli bir depoda Borg çalıştırabilmesini sağlayabilirsiniz.
Borg yedeğinin bozulmadığından nasıl emin olurum?#
Yedeklerin bütünlüğünü borg check komutuyla doğrularsınız; bu komut depo ve arşivleri HMAC ile denetleyip bozulan parçaları erkenden bildirir. Ayrıca gerçek güvence yalnızca geri yükleme testiyle gelir: düzenli aralıklarla (örneğin ayda bir) bir arşivi borg mount ile bağlayıp veya ayrı bir dizine borg extract ile açıp içeriği kontrol etmelisiniz. Otomatik yedeklerin log dosyasını periyodik okuyarak hata olup olmadığını izlemek de bu doğrulamanın bir parçasıdır.
Kapanış#
BorgBackup, doğru kurulduğunda bir sistem yöneticisinin elindeki en güçlü yedekleme araçlarından biridir. Blok düzeyi tekilleştirme sayesinde onlarca tarihli yedeği tek bir tam yedeğe yakın alanda saklar, istemci tarafı şifreleme ile verinizi güvenmediğiniz depolarda bile korur, prune ile saklama politikasını otomatik yönetir ve cron ile birleştiğinde 7/24 sizin yerinize çalışır. rsync'in birebir aynalama sadeliğiyle Borg'un şifreli ve verimli snapshot geçmişini birlikte kullanmak, çoğu üretim sunucusu için en sağlam kombinasyondur.
Yine de en iyi yedek betiği bile disk arızasına, veri merkezi sorununa veya bir insan hatasına karşı tek başına yeterli olmayabilir. Bu tür yedek çözümlerini özgürce kurup çalıştırabileceğiniz tam kök erişimli VDS ve sanal sunucularımızı inceleyebilir, tüm yedekleme ve bakımı bize bırakmak isterseniz yedekleme ve sunucu yönetimi hizmetlerimize göz atabilirsiniz. Web siteniz için hazır bir altyapı arıyorsanız, otomatik yedek seçenekleriyle gelen hosting paketlerimiz de iyi bir başlangıç noktasıdır.