VPS ile site dışı yedekleme nasıl yapılır?

Site dışı yedekleme hedefi nedir

Site dışı yedekleme hedefi, verilerinizin bir kopyasını barındıran ve orijinal sunucudan bağımsız olarak hata verebilen ikinci bir makinedir. Başka bir sağlayıcıdaki VPS, çoğu okuyucunun erişebileceği en uygun maliyetli yöntemdir. Üç gerçekçi yöntem mevcuttur: VPS üzerinde çalışan Proxmox Backup Server, SSH veya S3 üzerinden erişilen bir restic deposu ya da yedekleme sunucusunun çektiği bir rsync yansıması. Hangi yöntemin uygun olduğu, neyi geri yüklediğinize ve ne kadar hızlı geri almanız gerektiğine bağlıdır. Kopyayı kimin silebileceği ise geri kalan detayları belirler.

Site dışı ifadesi, farklı bir hata etki alanı anlamına gelir. Bu, farklı bir sağlayıcı ve sunucunuzu çalıştıran hesapla hiçbir giriş bilgisi paylaşmayan bir hesap kullanmanız gerektiği anlamına gelir. Aynı sağlayıcının farklı bir bölgesindeki ikinci bir sunucu, bir binadaki yangından sağ çıkabilir. Ancak ele geçirilmiş bir kontrol paneli girişinden sağ çıkamaz; çünkü tek bir hesap her iki kopyayı da kontrol eder.

Sağlayıcınızdaki bir snapshot, bu ikinci kopya değildir. Aynı panel şifresinin arkasında yer alır; bu nedenle o şifreyi ele geçiren kişi, sunucuyu ve snapshot'larını tek bir oturumda siler. Snapshot hizmetleri ayrıca gigabayt başına aylık olarak, standart disk fiyatlarının çok üzerinde ücretlendirilir; bu da doksan günlük snapshot tutmayı pahalı hale getirir. VPS snapshot'ları ve yedeklemeler arasındaki fark konusuna, herhangi birine güvenmeden önce göz atmanızda fayda vardır.

Hangi üç biçim size uygun

• Proxmox Backup Server (PBS): Kaynak Proxmox VE (sanal ortam) olduğunda ve geri yüklediğiniz şey bütün bir sanal makine olduğunda kullanılır. Disk imajı seviyesinde yedekleme yapar ve doğrulama işleri hedefteki veriyi tekrar okur.
• Bir restic deposu: Kaynak bir veya birden fazla Linux sunucusu olduğunda ve geri yüklediğiniz şey bir dizin veya veritabanı dökümü olduğunda kullanılır. İstemci tarafında şifreleme yapar; SSH ve S3 protokollerinin yanı sıra kendi REST protokolünü de destekler.
• SSH üzerinden rsync, yedekleme sunucusu tarafından çekilen: Hedefteki dosyaların, ls ve cat ile okunabilen, geri almak için herhangi bir istemci yazılımı gerektirmeyen standart dosyalar olarak durmasını istediğinizde kullanılır.

Karar veremiyorsanız restic çalıştırın. Veri makineden çıkmadan önce şifrelenir ve hedefte bir SSH hesabı ile disk alanı dışında hiçbir şeye ihtiyaç duymaz. Bir VPS üzerinde restic yedeklerini yapılandırma rehberi istemci tarafını daha derinlemesine ele alır; restic ve BorgBackup karşılaştırması ise halihazırda Borg kullanıyorsanız yapacağınız seçimi kapsar.

Hedef boyutu belirleme: bir aylık saklama süresinin maliyeti

Tekilleştirme (deduplication), sayıların beklenenden daha düşük olmasının nedenidir. Hem restic hem de PBS, dosyaları değişken boyutlu parçalara böler ve her parçayı hash değerine göre işler. Her benzersiz parça yalnızca bir kez depolanır. 500 GB boyutundaki bir veri kümesinin ikinci yedeği, ek bir 500 GB daha eklemez. Yalnızca değişen parçaları ekler.

Bu nedenle depo boyutu, anlık görüntü (snapshot) sayısını değil, en eski anlık görüntünüzün yaşını takip eder. 500 GB veriniz olduğunu ve her gün 5 GB yeni benzersiz veri eklendiğini varsayalım. Depo, 500 GB'lık temel veriyi ve politikanın tuttuğu en eski anlık görüntüye kadar geçen her gün için yaklaşık 5 GB veriyi barındırır.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Dolar sütunu, depoyu aylık TB başına 10 ABD doları üzerinden fiyatlandırır. Bu, herhangi bir sağlayıcıdan alınmış bir teklif değil, hesaplama için bir yer tutucudur; bu nedenle değerlendirdiğiniz planın gerçek TB başına fiyatını kullanın. Bir haftalık günlük yedekler yaklaşık 535 GB yer kaplar. Bir yıllık geçmiş ise 2,325 GB yer kaplar; bu da haftalık yedekleme için $5.35 maliyet karşısında aylık $23.25 maliyet anlamına gelir. Geçmiş veriler ucuzdur. Asıl ödeme yaptığınız kısım temel kopyadır.

Tekilleştirme, halihazırda sıkıştırılmış veya şifrelenmiş olarak gelen veriler üzerinde etkisizdir. Gzip ile sıkıştırılmış bir veritabanı dökümü her çalıştırıldığında tamamen değişir; bu nedenle her döküm yeni parçalar olarak kaydedilir ve depo her gece tam bir döküm boyutu kadar büyür. Dökümü sıkıştırılmamış olarak yazın ve yedekleme aracının sıkıştırmasına izin verin; restic 0.14 sürümünden beri sıkıştırılmış depoları desteklemektedir ve 0.19 sürümü fastest ve better zstd modlarını eklemiştir. Fotoğraf ve video kütüphaneleri de aynı nedenle kötü tekilleştirilir; bu yüzden bu verilerin boyutunu yukarıdaki satırlara göre değil, gerçek büyüme oranlarına göre hesaplayın.

Burada CPU'dan ziyade boşta duran disk alanı satın alıyorsunuz; bu durum tam olarak depolama odaklı bir VPS'in standart bir VPS'ten daha avantajlı olduğu senaryodur.

Bant genişliği ve geri yükleme süresi neden planı belirler

Disk, maliyetin düşük olduğu kısımdır. İlk yükleme ve olası bir geri yükleme ise maliyetli olan kısımlardır. 500 GB, 4 trilyon bit eder; bu değeri bağlantı hızına böldüğünüzde tam bir geri yüklemenin ne kadar süreceğinin alt sınırını elde edersiniz.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Bunlar, protokol yükü hesaba katılmamış hat hızı değerleridir; bu nedenle bunları en iyi senaryo olarak değerlendirin. 100 Mbit/s hızında tam bir geri yükleme, veriye erişim sağlanmadan önce 11.1 saat gerektirir. 40 Mbit/s hızındaki bir ev interneti yüklemesinden ise 27.8 saat sürer. 1 Gbit/s port üzerinde aynı geri yükleme 1.1 saat alır. Çok sayıda küçük dosya, matematiksel hesaptan daha yavaş işlenir; çünkü dosyalar birkaç yüz kilobaytın altına düştüğünde dosya başına düşen işlem yükü baskın hale gelir.

Buradan iki sonuç çıkar. Eğer kurtarma süresi hedefiniz (RTO), yani tolere edebileceğiniz kesinti süresi dört saat ise, 100 Mbit/s bağlantı üzerinden 500 GB'lık bir geri yükleme bu süreyi çoktan aşmış demektir ve daha ucuz disk kullanmak bu sorunu çözmez. Ayrıca çoğu VPS planı giden trafiği ücretlendirir; bu nedenle tek bir tam geri yükleme, yedekleme sunucusunun aylık veri kotasının 0,5 TB'ını tüketir. Veriye ihtiyaç duymadan önce bu kotayı kontrol edin ve kotayı aştığınızda sağlayıcının nasıl bir işlem uyguladığını öğrenin.

İlk yedekleme tüm veri setini kapsar ve yapacağınız en yavaş işlem olacaktır. Yedeklemeyi Cuma günü başlatın ve kaynağın yükleme hattını doyurmaması için hız sınırlaması uygulayın: restic --limit-upload değerini KiB/saniye cinsinden kullanır, rsync ise --bwlimit değerini kullanır.

Şekil 1: Uzak veri deposu olarak Proxmox Backup Server

PBS, kaynak Proxmox VE olduğunda ve geri yükleme birimi sanal makine olduğunda uygundur. Bir VPS, Proxmox ISO dosyasını önyükleyemeyeceği için PBS'i Debian üzerine kurun. Ağustos 2026 itibarıyla güncel sürüm 4.2'dir ve Debian 13 (trixie) üzerine inşa edilmiştir.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Bu sağlama toplamını (checksum), Proxmox paket depoları sayfasında yayınlanan değerle karşılaştırın. Bir apt deposu, yalnızca doğruladığınız anahtar kadar güvenilirdir. Ardından /etc/apt/sources.list.d/proxmox.sources komutunu yazın:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Veri deposuna kendi dosya sistemini veya kendi birimini (volume) atayın. Dolu bir veri deposu yedeklemeleri durdurur; kök dosya sistemini paylaşan bir veri deposu ise dolduğunda tüm sunucuyu devre dışı bırakır.

Daha sonra, kaynağın kullanacağı hesabı oluşturun ve parolası yerine bir token verin.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Token gizli anahtarı yalnızca bir kez görüntülenir ve tekrar okunamayacağından, göründüğünde kaydedin. Rol, token kadar önemlidir. DatastoreBackup kendi yedeklerini oluşturabilir ve geri yükleyebilir; ayrıca Datastore.Prune ayrıcalığını taşımadığı için bu token, yazdığı bir anlık görüntüyü (snapshot) silemez.

PBS üzerindeki saklama politikası iki yarıdan oluşur ve ikincisi insanların göz ardı ettiği kısımdır. Budama (prune) işlemi anlık görüntüleri kaldırır. Çöp toplama (garbage collection) işlemi ise hiçbir anlık görüntü tarafından referans verilmeyen parçaları (chunks) siler. Boş alan, budama işleminden sonra değil, çöp toplama işleminden sonra açığa çıkar.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Kaldırmayı planladığı anlık görüntü listesi doğru göründüğünde --dry-run komutunu çalıştırın. Çöp toplama işlemi iki aşamada çalışır: önce hala referans verilen her parçanın erişim zamanını günceller, ardından erişim zamanı, işlemin başlamasından 24 saat 5 dakika öncesinden daha eski olan parçaları siler. Bu yetkisiz kullanım süresi (grace period), devam eden bir yedekleme tarafından yazılmakta olan bir parçanın silinmemesi için mevcuttur. Budama işlemini günlük, çöp toplama işlemini ise haftalık olarak veri deposu üzerinde zamanlayın ve hedef sistemin kendi parçalarını yeniden okuyup disk üzerindeki bozulmaları geri yükleme işleminden önce raporlaması için bir doğrulama (verify) işi ekleyin.

Kaynak bir PBS örneği ise, uzak konumdaki sunucu, veriyi itilmesini beklemek yerine çekebilir (pull).

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Bu eşitleme (sync) işini, varsayılan çekme yönünde VPS üzerinde çalıştırın. VPS, evdeki veri deposuna erişir; bu da evdeki sunucunun, uzak kopyaya erişebilecek hiçbir kimlik bilgisine sahip olmadığı anlamına gelir.

Biçim 2: SSH veya S3 üzerinden restic deposu

Debian ve Ubuntu, restic paketini sunar ancak her ikisi de güncel sürümün gerisinde kalır. Ağustos 2026 itibarıyla güncel sürüm 0.19.1'dir. Resmi binary dosyasını kaynak sunucuya kurun.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version, sürüm bilgisini ve derlendiği Go derleyicisini yazdırır. Sonraki yükseltmeler sudo restic self-update ile yapılır; bu komut resmi binary dosyalarında çalışır, apt üzerinden kurulan kopyalarda çalışmaz.

Yedekleme VPS'i üzerinde, başka hiçbir varlığa sahip olmayan bir hesap oluşturun ve ardından kaynak sunucunun açık anahtarını /home/resticsrv/.ssh/authorized_keys dosyasına kopyalayın.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Depoyu kaynak sunucudan, SFTP üzerinden başlatın.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Bu parolayı, ne bu sunucuda ne de yedekleme hedefinde bulunmayan bir yerde saklayın. Parolayı kaybederseniz depo tamamen okunamaz hale gelir ve hiçbir kurtarma yolu yoktur. İstemci taraflı şifrelemenin doğası gereği bu durum kaçınılmazdır.

Saklama politikası tek bir komuttur ve ikinci yarısı diskte yer açan kısımdır.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget anlık görüntüleri (snapshots) siler. prune, yalnızca bu anlık görüntülerin referans verdiği paket dosyalarını siler ve --prune, bir öğe gerçekten kaldırıldığında bu işlemi otomatik olarak çalıştırır. Bu parametre olmadan depo boyutu asla küçülmez. restic check depo yapısını doğrular, --read-data-subset=10% ise paket dosyalarının onda birini yeniden okuyup hash değerlerini kontrol eder; bu işlem, her şeyi okuma maliyeti olmadan hedefteki bozulmaları tespit eder. Diğer biçim olan --read-data-subset=1/10, sabit bir onda birlik kısmı kontrol eder; bu nedenle ilk sayıyı her hafta artırmak, on hafta içinde tüm deponun taranmasını sağlar.

Bir çalışma yarıda kesilirse, bir sonraki çalışma repository is already locked exclusively by PID hatasıyla durur. Başka bir yedekleme işleminin çalışmadığından emin olun ve ardından restic unlock ile kilidi kaldırın.

Nesne depolama (object storage) için depo dizgisi s3:https://s3.example.net/web1 halini alır; kimlik bilgileri ise AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY içerisinde tanımlanır. Diğer tüm işlemler aynıdır; restic, aynı VPS üzerinde çalışan kendi kendine barındırılan MinIO nesne deposu ile bu şekilde iletişim kurar.

Şekil 3: SSH üzerinden rsync ile yalnızca çekme (pull-only) anahtarı

Bu yapının güvenlik özelliği yön bağımlılığıdır. Yedekleme VPS'i kaynağa bağlanır ve verileri okur. Kaynak sunucuda yedekleme ana bilgisayarına ait bir anahtar veya rota bulunmaz; bu nedenle kaynağın ele geçirilmesi durumunda yedeklere erişim sağlanamaz.

Yedekleme VPS'i üzerinde bir anahtar çifti oluşturun, ardından genel anahtarı (public key) zorunlu bir komutla (forced command) kaynak sunucuya yükleyin.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync, Debian 13 ve Ubuntu 24.04 üzerinde /usr/bin/rrsync dizininde rsync paketiyle birlikte gelir. -ro yalnızca okuma izni verir ve -no-del parametresini zorunlu kılar; bu sayede anahtar, kaynak üzerinde yazma veya silme işlemi yapamaz. restrict, port yönlendirme ve pty dahil olmak üzere bu senaryoda gereksiz olan SSH özelliklerini devre dışı bırakır; böylece anahtar etkileşimli oturum açmak için kullanılamaz. Yollar, belirttiğiniz dizine göre görecelidir; bu nedenle / uzak yolu, kaynak üzerinde /srv dizinine karşılık gelir.

Çekme işlemi, hardlink kullanarak geçmişi korur. Yeni ağaçtaki değişmemiş dosyalar, önceki ağaca ait hardlink'lerdir; bu sayede ikinci bir kopya yerine yalnızca bir dizin girişi kaplarlar.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

İşlemin sonundaki yeniden adlandırma, tarihli dizinin güvenilir olmasını sağlar: dizin adı yalnızca rsync başarıyla (0 koduyla) tamamlandığında görünür hale gelir; böylece kesintiye uğrayan bir aktarım asla tamamlanmış bir anlık görüntü (snapshot) gibi görünmez. Eski ağaçları tek satırlık bir komutla, otuz tanesini tutacak şekilde temizleyin.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Bu yapının maliyeti konusunda gerçekçi olun. Hardlink'ler yalnızca dosya bazında tekilleştirme yapar; 4 GB'lık bir disk imajında tek bir bayt değiştiğinde restic veya PBS gibi araçlar sadece değişen parçaları saklarken, bu yöntem 4 GB'ın tamamını kopyalar. Ayrıca hedef sunucudaki dosyalar düz metin (plaintext) olarak tutulur; bu nedenle yedekleme VPS'inde root yetkisine sahip olan herkes dosyaları okuyabilir.

İstemci tarafı şifreleme ile hedef sunucunun düz metni görmemesi

Yedekleme VPS'ini tam olarak kontrol etmediğiniz bir makine olarak değerlendirin. Bu sunucunun bir sağlayıcısı vardır; bu sağlayıcının personeli ve binadan çıkarılan arızalı diskleri olabilir.

restic, her veri parçasını göndermeden önce kaynak üzerinde şifreler; bu nedenle depo, boyut ve zamanlama meta verileriyle birlikte şifreli metinden oluşur. PBS'de şifreleme isteğe bağlıdır: bir anahtar oluşturun ve ardından her yedekleme işleminde bu anahtarı kullanın.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Kağıt anahtarın çıktısını alın ve fiziksel bir yerde saklayın. Proxmox belgeleri risk konusunda oldukça nettir: anahtar olmadan yedeklenen dosyalara erişilemez. Anahtarı yedekleme hedefinde tutmayın; şifreli metnin yanında saklanan bir anahtar kimseyi korumaz.

rsync yansımalarının buna eşdeğer bir yapısı yoktur. Dosyalar olduğu gibi aktarılır. Veriler hassas ise, hedef sunucunun bunları okuyabileceğini kabul edin ya da diğer iki yöntemden birini kullanın.

Ele geçirilmiş bir kaynağın kendi yedeklerini silmesini engelleme

Bir saldırgan, kaynağı ele geçirdiğinde ilk olarak yedekleri arar; yedekleri yükleyen kimlik bilgileri de doğrudan makine üzerinde bulunur. Eğer bu kimlik bilgisi silme yetkisine de sahipse, saldırgan bunu kullanır.

PBS, bu sorunu roller ile çözer. Yalnızca DatastoreBackup yetkisine sahip bir token, yeni snapshot'lar yazabilir ve kendi snapshot'larını geri yükleyebilir; ancak budama (pruning) yapamaz. Çünkü bir snapshot'ı silmek için ayrı bir Datastore.Prune yetkisi gerekir. Saklama (retention) işlemlerini PBS tarafında çalıştırın; böylece kaynak makine, herhangi bir şeyi silebilecek bir kimlik bilgisine sahip olmaz.

SFTP üzerinden restic kullanıldığında böyle bir ayrım yoktur, çünkü depolama alanına yazma yapan SSH anahtarı, aynı zamanda oradan silme de yapabilir. Bunun çözümü REST backend kullanmaktır. Yedekleme VPS'i üzerinde rest-server'ı --append-only ile çalıştırın. Bu, yeni yedeklerin oluşturulmasına izin verirken mevcut olanların silinmesini ve değiştirilmesini engeller. İstemciyi rest:https://backup.example.net:8000/web1 adresine, RESTIC_REST_USERNAME ve RESTIC_REST_PASSWORD kullanarak yönlendirin. Kaynak makineden gelen bir restic forget --prune komutu bu durumda başarısız olur; hedeflenen sonuç da budur. Bu nedenle saklama işlemleri, kendi kimlik bilgilerine sahip ikinci bir makine üzerinden yürütülür. restic kılavuzu, append-only (yalnızca ekleme yapılabilen) depolama alanlarında sayı tabanlı politikalar yerine --keep-within kullanılmasını önerir. Aksi takdirde, depolama alanını gereksiz snapshot'larla dolduran bir saldırgan, gerçek yedeklerinizi --keep-last penceresinin dışına itebilir.

rsync, kaynağın hedef için herhangi bir kimlik bilgisine sahip olmaması nedeniyle, veriyi çekme (pull) yöntemiyle aynı sorunu yapısal olarak çözer.

Tek bir kural her üç yöntem için de geçerlidir: Yedekleri silme yetkisine sahip kimlik bilgisi, yedeklenen makineden farklı bir makinede bulunmalıdır.

Geri yükleme tatbikatını takvime ekleyin

Daha önce geri yüklemediğiniz bir yedekleme sadece bir varsayımdır. Her çeyrek dönem için bir saat ayırın ve yedeklemenizi test edin.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r komutunun hiçbir çıktı vermemesi, geri yüklenen ağacın canlı sistemle eşleştiği anlamına gelir. PBS üzerinde aynı tatbikat proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ komutu ile yapılır; buna ek olarak, hedefteki parçaları yeniden okuyan ve sağlama toplamı hatalarını raporlayan zamanlanmış bir doğrulama işi çalıştırılır.

Tatbikat, baytların sağlam olmasından daha fazlasını kanıtlamalıdır.

• Geri yüklemeyi kaynak makineden değil, üçüncü bir makineden yapın; çünkü kaynak makine, yok olduğunu varsaydığınız sistemin ta kendisidir. Bu, depo parolasının veya PBS anahtarının kaynak makineye ihtiyaç duyulmadan erişilebilir olması gerektiği anlamına gelir.
• Geri yükleme süresini ölçün ve not edin, ardından bunu taahhüt ettiğiniz RTO değeri ile karşılaştırın. Yukarıdaki tablo transfer alt sınırını göstermektedir. Gerçek süre; şifre çözme, diske yazma ve hangi snapshot'ın gerekli olduğunu belirlemek için harcanan zamanı da içerir.
• Durum bilgisi içeren bir veriyi geri yükleyin; örneğin, geçici bir instance üzerinde yükleyeceğiniz bir veritabanı dökümü gibi. Sadece açılan bir tar dosyası, uygulamanın çalışacağının kanıtı değildir.

Dünyanın en ucuz diski bile, üzerinden bir kez geri yükleme yapana kadar hiçbir değer taşımaz.

FAQ

VPS sağlayıcımda aldığım snapshot, site dışı (off-site) bir yedekleme midir?

Hayır. Bir sağlayıcı snapshot'ı; aynı hesapta, aynı panel girişi arkasında ve kopyaladığı sunucuyla aynı faturada yer alır. O giriş bilgilerini ele geçiren kişi, sunucuyu ve tüm snapshot'larını tek bir oturumda silebilir. Snapshot'lar riskli bir yükseltme öncesinde hızlı geri dönüş için kullanışlıdır ancak ikinci bir konum sayılmazlar. Site dışı bir kopya; farklı bir hesapta, ideal olarak farklı bir sağlayıcıda ve kaynak makinenin sahip olmadığı kimlik bilgileriyle tutulmalıdır.

Bir aylık yedekleme geçmişi için ne kadar disk alanına ihtiyacım var?

Disk boyutunu snapshot sayısına göre değil, en eski snapshot'ınızın yaşına göre hesaplayın. Tekilleştirme (deduplication) yapan bir araç, her benzersiz veri parçasını bir kez saklar; bu nedenle depo boyutu, yaklaşık olarak kaynak boyutuna, günlük değişen benzersiz verinin saklama süresiyle çarpımının eklenmesiyle bulunur. Günde 5 GB değişen 500 GB veri için, bir haftalık günlük yedekleme yaklaşık 535 GB, bir yıllık geçmiş ise 2,325 GB yer kaplar. Üzerine ek bir pay bırakın; çünkü disk dolduğunda bir sonraki yedekleme başarısız olur ve restic'in prune işlemi, alanı geri kazanmadan önce paket dosyalarını yeniden düzenlemek için boş alana ihtiyaç duyar.

Güvenliği ihlal edilmiş bir sunucu, kendi site dışı yedeklerini silebilir mi?

Evet, buna karşı önlem almadıysanız silebilir. Standart bir SSH veya SFTP deposunda, yazma yetkisi olan anahtar silme yetkisine de sahiptir. Kaynak sunucuya veri silemeyeceği bir kimlik bilgisi tanımlayın: yalnızca DatastoreBackup rolüne sahip, Datastore.Prune ayrıcalığı bulunmayan bir PBS API token'ı kullanın veya restic'i --append-only ile başlatılmış bir rest-server'a karşı çalıştırın; bu yapılandırma mevcut yedeklerin silinmesini ve değiştirilmesini reddeder. "Çekme" (pull) tabanlı bir tasarım daha güvenlidir, çünkü bu durumda kaynak sunucu, yedekleme sunucusuna dair hiçbir kimlik bilgisine sahip olmaz. Saklama süresi (retention) işlemlerini kaynak sunucunun dışındaki taraftan yönetin.

Yedekleme VPS'imde Proxmox Backup Server mı yoksa restic mi çalıştırmalıyım?

Aracı, geri yükleme biriminize göre seçin. Kaynak Proxmox VE ise ve tüm sanal makineyi geri istiyorsanız PBS kullanın; çünkü PBS disk imajı seviyesinde yedekleme yapar ve sanal makineyi tek adımda geri yükler. Kaynak bir Linux sunucusuysa ve dosyalar ile veritabanı dökümlerini geri istiyorsanız restic kullanın; restic hedefte yalnızca bir SSH hesabına ihtiyaç duyar ve veriyi göndermeden önce şifreler. İkisini birden çalıştırmak yaygın bir uygulamadır: Hipervizör için PBS, üzerinde olmayan sunucular için restic.

Bir VPS yedeğinden geri yükleme yapmak ne kadar sürer?

Veri boyutunu bağlantı hızına bölerek alt sınırı bulun, ardından şifre çözme ve yazma süresini ekleyin. 100 Mbit/s bağlantı üzerinden 500 GB veri, hat hızında yaklaşık 11.1 saat sürer; aynı geri yükleme 1 Gbit/s port üzerinden 1.1 saatte tamamlanır. Çok sayıda küçük dosya, dosya başına düşen ek yük nedeniyle bu matematiksel hesaptan daha yavaş işlenir. Gerçek bir geri yükleme işlemini zamanlayın ve bu ölçülen değeri kullanın; çünkü kurtarma planınızın güvenebileceği tek veri budur.