VPS Uzerinde Proxmox Backup Server Kurulumu Rehberi

Proxmox Backup Server'ı bir VPS üzerinde çalıştırmanın sağladıkları

Bir VPS üzerindeki Proxmox Backup Server (PBS), Proxmox VE (sanal ortam) kümenizin halihazırda kullandığı protokol ile iletişim kuran bir uzak yedekleme hedefidir. Bu sayede ilk yedeklemeden sonraki her işlem artımlı (incremental) olur, konuk makineler arasında tekilleştirilir (deduplicated), binanızdan çıkmadan önce şifrelenir ve sonrasında doğrulanabilir hale gelir. Bir blok depolama birimine sahip bir VPS kiralayıp Debian 13 üzerine PBS kurun, bu birim üzerinde bir veri deposu (datastore) oluşturun ve bunu Proxmox VE içerisinde pbs türünde bir depolama alanı olarak ekleyin. Kurulum on dakika sürer. Kurulumdan sonraki her şey; ad alanları (namespaces), çöp toplama (garbage collection), anahtar yönetimi ve bizzat gerçekleştirdiğiniz bir geri yükleme işlemi, yedeğinizin bir yıl sonra bir değer ifade edip etmeyeceğini belirleyen unsurlardır.

vzdump dosyalarını kiralanan bir diske kopyalamak yerine PBS kullanmanın temel nedeni parça deposudur (chunk store). İstemci, her konuk diskini yaklaşık 4 MiB'lık parçalara böler, bunların hash değerlerini hesaplar ve yalnızca veri deposunda henüz bulunmayan parçaları yükler. Çalışan bir sanal makine için QEMU, ilk yedeklemeden sonra değişen blokları kirli bit eşleminde (dirty bitmap) takip eder, böylece bir sonraki çalıştırmada yalnızca bu bloklar yerel diskten okunur. Günde 3 GB değişen 200 GB'lık bir konuk makine, günde yaklaşık 3 GB veri gönderir. Ev tipi bir internet bağlantısı ile kiralanan bir depolama biriminin birlikte çalışmasını sağlayan şey budur; bir VPS'i uzak yedekleme hedefi olarak kullanmak, bir arkadaşınızın evindeki yedek bir diskten daha verimlidir. Hipervizörün kendisinin nerede barındırılması gerektiğine hala karar veriyorsanız, evde Proxmox kullanımı ile kiralanan VPS karşılaştırması bu soruyu ayrı bir başlıkta ele almaktadır.

Kiralamadan önce disk boyutunu belirleyin

Boyutlandırma, kendi verileriniz üzerinde yaptığınız aritmetik bir işlemdir. Sanal diskin toplam boyutunu değil, her bir konuğun (guest) fiilen kullandığı alanı baz alın; ardından günlük değişim miktarını, verileri saklayacağınız gün sayısı ile çarpıp bu değere ekleyin. Sıkıştırma (compression) ve tekilleştirme (deduplication) bu rakamı iyileştirecektir, bu nedenle elde ettiğiniz sonucu bir hedef değil, üst sınır olarak kabul edin.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Bu satırlar bir ölçüm değil, örnek bir çalışmadır. Kullanılan alanı her bir konuğun içindeki df -h komutuyla, günlük değişim miktarını ise PBS görev günlüklerinde (task log) ikinci ve üçüncü yedeklemeler oluştuktan sonraki boyut farkından okuyun.

Örnekteki posta sunucusu konuğu 120 GB alan kullanıyor ve günde yaklaşık 3.0 GB değişim gösteriyor; dolayısıyla otuz günlük snapshot için yaklaşık 210 GB alana ihtiyaç vardır: bir tam kopya artı otuz günlük değişim. Tüm 3 konuk için son sütunu topladığınızda toplam yaklaşık 619 GB elde edersiniz. Dizinler, meta veriler ve garbage collection işleminin sağlıklı çalışması için gereken boşluk payı olarak bu rakamın üzerine beşte bir oranında ekleme yapın; bu da sizi 1 TB'lık bir birime yönlendirir.

Planın geri kalanı küçük ölçeklidir. PBS, 2 GB RAM ile çalışabilir, 4 GB RAM ile ise rahat eder; çünkü maliyetli işlemler küme (cluster) tarafında gerçekleşir: Proxmox VE düğümü konuk disklerini okur, parçalara ayırır (chunking) ve hash değerlerini hesaplar. VPS'in görevi ise bu parçaları yazmak ve iki ağır işi, yani garbage collection ve doğrulama (verification) işlemlerini yürütmektir. Veri deposunu (datastore) tek bir büyük kök disk yerine ayrı bir blok birim olarak kiralayın; çünkü bir birimi sunucuyu yeniden oluşturmadan daha sonra büyütebilirsiniz.

Debian 13 üzerinde Proxmox Backup Server kurulumu

Ağustos 2026 itibarıyla güncel eşleşme, Debian 13 (kod adı: trixie) üzerinde çalışan Proxmox Backup Server 4 sürümüdür. Eski kılavuzlar PBS 2 ile Debian 11'i eşleştirir; depo tanımlamasında kod adı yer aldığından, eski bir sürüm adını kopyalamak apt üzerinde eksik sürüm dosyası hatasına yol açar. Temiz bir Debian 13 imajı ile başlayın. Aşağıdaki tüm komutları root olarak veya yazıldığı şekliyle sudo ile çalıştırın.

sudo apt update && sudo apt install -y wget
sudo 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

Toplam değer 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 şeklinde görünmelidir. Aksi takdirde durun. Yanlış bir anahtarlık, doğrulamadığınız bir imza ile imzalanmış paketleri yüklemek üzere olduğunuz anlamına gelir.

Destek sözleşmesi olmayan bir sunucu için doğru seçenek olan abonelik gerektirmeyen depoyu /etc/apt/sources.list.d/pbs.sources dosyasına 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

Web arayüzü HTTPS 8007 numaralı port üzerinden yanıt verir. PBS, kullanıcıyı işletim sisteminin kullandığı hesaplarla aynı olan PAM (pluggable authentication modules) üzerinden doğruladığı için root@pam olarak sistem root parolasıyla giriş yapın. Sertifika kendinden imzalıdır ve tarayıcınız bunu belirtecektir. Bu sertifikanın parmak izi, Proxmox VE'nin daha sonra sabitleyeceği değerdir; dolayısıyla bu uyarı, düzeltilmesi gereken bir sorundan ziyade beklenen bir durumdur.

8007 numaralı port, genel internete açık bir giriş formudur; bu nedenle herkesin erişimine açık bırakmayın. Tek bir nftables dosyası bu durumu kapsar. /etc/nftables.conf dosyasını yazmak mevcut kural kümesini sıfırlar, bu nedenle sunucuda güvenlik duvarını yöneten başka bir yapılandırma varsa bu adımı atlayın.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Kuralları sudo systemctl enable --now nftables ile uygulayın. İşlemi yaparken ikinci bir SSH oturumunu açık tutun: policy drop komutu ve SSH kuralındaki tek bir yazım hatası, sunucunuzdan kilitlenmenize neden olur. 203.0.113.7 kısmını kümenizin çıkış yaptığı adresle değiştirin. Eğer bu adres dinamik ise, kuralı servis sağlayıcınızın aralığına genişletin veya bağlantıyı bir tünel üzerinden sonlandırın. Çoğu VPS panelinin, makinenin önünde aynı porta izin vermesi gereken ayrı bir ağ güvenlik duvarı bulunduğunu unutmayın.

Veri deposunu kendi birimine taşıyın

Veri deposu, kök dosya sistemi üzerinde barındırılmamalıdır. Bir veri deposu paylaşılan kök dosya sistemini doldurduğunda, yedekleme işlemi başarısız olur; bununla birlikte sorunun nedenini anlamanızı sağlayacak günlük kayıtları dahil olmak üzere sunucudaki her şey durur. Blok birimini bağlayın, biçimlendirin, mount edin ve veri deposunu ancak bu mount noktasının içinde oluşturun.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Cihaz adını lsblk üzerinden alın. Çoğu KVM imajında /dev/vdb, diğerlerinde ise /dev/sdb olarak görünür; bu konuda varsayımda bulunmak asla güvenli değildir. Mount işlemini /etc/fstab dosyasına etiket (label) kullanarak ekleyin; böylece yeniden başlatma sonrası cihaz ismi değişse bile veri deposu yanlış diske yönlendirilmez:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt komutu cihazı, yolu ve rw,relatime dahil olmak üzere seçenekleri listelemelidir. Bu tek satırda iki hata gizlidir. Eğer mount noktası mevcut değilse ve siz yine de veri deposunu oluşturursanız, PBS verileri mount noktasının altındaki kök dosya sistemine yazar. Bir sonraki başarılı mount işleminde bu veriler silinmeden gizlenir; veri deposu boş görünür ve kök dosya sistemi dolu kalmaya devam eder. Eğer seçenekler noatime içeriyorsa, PBS çalışmayı reddeder; çünkü veri deposu oluşturulurken ve her çöp toplama (garbage collection) işleminde erişim zamanı güvenlik kontrolü gerçekleştirir.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Bu işlem, 0000 ile ffff arasında isimlendirilmiş 65536 alt dizin içeren bir .chunks dizini oluşturur. Veri deposu birkaç büyük dosyadan değil, yüz binlerce küçük dosyadan oluşur. Buradan iki sonuç çıkar. Bir veri deposunu standart dosya seviyesinde araçlarla kopyalamak, kullanılamayacak kadar yavaştır. Ayrıca yedeklemeler çalışırken alınan bir sağlayıcı birim anlık görüntüsü (snapshot), tutarlı bir kopya değildir; bu durum, anlık görüntülerin yedeklerin yerini tutmaması kuralının başka her yerde geçerli olma nedenidir.

Namespace'ler iki ana bilgisayarın çakışmasını önler

Bir veri deposu varsayılan olarak düz bir yapıdadır. Yedeklemeler vm/100, ct/101 ve host/<name> şeklinde adlandırılır. Her biri 100 numaralı ID'ye sahip bir konuk makine barındıran iki küme aynı gruba yazarsa, snapshot'ları birbirine karışır ve bunlardan biri için yazılan bir saklama kuralı diğerinin snapshot'larını da sayar. Namespace'ler, her kaynağa tek bir veri deposu içinde kendi ağacını sağlar.

Bunları PBS ana bilgisayarı üzerinde oluşturun. --repository argümanı [[auth-id@]server[:port]:]datastore biçimindedir, bu nedenle yerel bir namespace root@pam@localhost:store1 şeklinde okunur ve komut root parolasını ister.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

Tekilleştirme (deduplication) bu ayrımdan etkilenmez. Parçalar (chunks) tüm veri deposu genelinde paylaşılır, bu nedenle üç farklı namespace'e dağılmış on adet Debian konuğu, temel sistemin yalnızca bir kopyasını saklar. Her ana bilgisayar için ayrı bir veri deposu yerine namespace kullanan tek bir veri deposu tercih etmenin nedeni budur: ayrı veri depoları ayrı parça havuzları anlamına gelir ve ayrı parça havuzları, aynı Debian kurulumu için defalarca ödeme yapmak demektir.

Her kaynağa, kendi namespace'i ile sınırlandırılmış ayrı bir hesap verin. Bir API (uygulama programlama arayüzü) anahtarı, bir kullanıcıya ait olan ve kendi izinlerini taşıyan bir kimlik bilgisidir; çalınma ihtimali olan bir makinede tam olarak ihtiyaç duyulan şey budur.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Token komutu, gizli anahtarı tam olarak bir kez yazdırır:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Bunu hemen kopyalayın, çünkü PBS anahtarın size tekrar gösterebileceği hiçbir kopyasını tutmaz. Erişim denetimi komutunu iki kez inceleyin. Komut, kullanıcıyı değil backup@pbs!pve-home token'ını belirtir; çünkü token izinleri yalnızca token'ın kendisini adlandıran girdilerden hesaplanır. Yalnızca backup@pbs için oluşturulan bir girdi, token'ın hiçbir erişim yetkisine sahip olmamasına neden olur ve ilk yedekleme, ağ üzerinde görünen herhangi bir sorundan ziyade izin hataları nedeniyle başarısız olur. Yol (path) da aynı derecede önemlidir: /datastore/store1/pve-home ile sınırlandırılmış bir token, office namespace'i içindeki hiçbir şeyi okuyamaz veya silemez; böylece güvenliği ihlal edilmiş bir küme, başka bir sahanın geçmişini yok edemez.

VPS'i Proxmox VE içinde yedekleme depolama alanı olarak ekleme

Öncelikle PBS sunucusu üzerindeki sertifika parmak izini okuyun.

sudo proxmox-backup-manager cert info | grep Fingerprint

Ardından, kümenin herhangi bir düğümünde şu komutu çalıştırın:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Üçüncü satırdaki yer tutucunun yerine cert info değerini yapıştırın. --password parametresini değer girmeden kullanmak, pvesm komutunun bu değeri etkileşimli olarak istemesini sağlar; böylece token gizli anahtarı shell geçmişinize kaydedilmez. Bu değer /etc/pve/priv/storage/pbs-offsite.pw dosyasında saklanır ve depolama tanımının kendisi, kümedeki her düğüme kopyalanan /etc/pve/storage.cfg dosyasına yazılır; dolayısıyla bu yapılandırmayı tüm küme için yalnızca bir kez yapmanız yeterlidir.

--prune-backups keep-all=1 parametresi, Proxmox VE'ye hiçbir şeyi silmemesini söyler. Saklama politikası (retention) PBS tarafında yönetilmelidir ve bunun açık bir nedeni vardır: bu sayede token silme yetkisine sahip olmaz; böylece fidye yazılımı tarafından şifrelenen bir küme, kendisini kurtarması amaçlanan uzak yedekleme geçmişini temizleyemez.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status komutu, durum sütununda active ifadesini ve yanında veri deposunun toplam ve kullanılan alan miktarını görüntüler. inactive hatası, düğümün 8007 numaralı porta yönelik bir TLS (transport layer security) oturumunu tamamlayamadığı anlamına gelir; bu durum kimlik bilgilerinden ziyade bir güvenlik duvarı veya parmak izi sorununa işaret eder.

İlk yedekleme her şeyi yükler, bu nedenle başlatmadan önce hesaplamanızı yapın. 200 GB, 1600 gigabit eder; 100 Mbit bir uplink saniyede 0.1 gigabit veri taşır. Bu durumda minimum süre yaklaşık dört buçuk saattir, gerçek süre ise daha uzun olacaktır. Yedeklemeyi bant genişliğine ihtiyaç duymadığınız bir zamanda başlatın. Sonraki her çalıştırma yalnızca yeni veri parçalarını gönderir.

İstemci tarafında şifreleme ve anahtarın konumu

VPS, sahibi olmadığınız bir bilgisayardır. Şifrelemeyi istemci tarafında yapın; böylece veri deposu, sağlayıcının okuyamayacağı parçalar tutar.

sudo pvesm set pbs-offsite --encryption-key autogen

Bu komut, /etc/pve/priv/storage/pbs-offsite.enc dizinine yalnızca root kullanıcısı tarafından okunabilen yeni bir anahtar yazar ve bu anahtar /etc/pve içeriğinin geri kalanıyla birlikte çoğaltılır. Bir sonraki yedeklemeden itibaren istemci, her parçayı dışarı göndermeden önce şifreler. Sunucu, anlık görüntülerinizi (snapshot) ve boyutlarını listelemeye devam edebilir ancak içeriklerini okuyamaz.

Şimdi, bu yapıyı bir yük olmaktan çıkarıp gerçek bir yedekleme haline getiren kısma gelelim. Oluşturulan anahtarın bir parolası yoktur ve yalnızca koruduğu küme (cluster) üzerinde bulunur. Eğer bu küme çalınırsa veya başkası tarafından şifrelenirse, VPS kimsenin açamayacağı veriler barındırır. Anahtarı oluşturduğunuz gün kümenin dışına kopyalayın.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey komutu, anahtarı kağıda basılıp başka bir yerde saklanması gereken bir belge olarak yazdırır. Dosyanın kendisini gizli bir veri olarak kabul edin; çünkü dosyaya sahip olan herkes, bu anahtarla yapılmış tüm yedeklemelerin şifresini çözebilir. Daha büyük kurulumlar için PBS, proxmox-backup-client key create-master-key ile oluşturulan bir RSA (Rivest Shamir Adleman) anahtar çifti olan ana anahtarı (master key) da destekler. Bu yapıda her yedekleme kendi şifreleme anahtarını genel anahtar (public key) ile şifrelenmiş olarak saklarken, özel anahtar (private key) kurtarma amacıyla çevrimdışı tutulur.

Tasarımın bir sonucunu, işlem sonrasında değil, başlamadan önce bilmekte fayda vardır. Şifreli yedeklemeler için parça özeti (chunk digest), düz metin içeriğinin şifreleme anahtarıyla birleştirilmesiyle hesaplanır. Bu nedenle, farklı anahtarlarla şifrelenmiş iki özdeş parça farklı özetler üretir ve birbirleri arasında tekilleştirme (deduplication) yapılamaz. Anahtarı değiştirmek, bir sonraki yedeklemede her şeyin yeniden yüklenmesi anlamına gelir; eski parçalar ise anlık görüntüler temizlenene ve toplanana kadar orada kalmaya devam eder. Şifreleme konusundaki kararınızı ilk yüklemeden önce verin.

Budama işaretleri ve çöp toplama (garbage collection) geri kazanımı

Bu bölüm atlanan ve depolama alanını dolduran kısımdır. Bir snapshot'ı budamak, onun meta verilerini (manifest, indeksler, günlük ve notlar) kaldırır. Ancak hiçbir chunk dosyasını silmez. Chunk'lar snapshot'lar arasında paylaşıldığı için, kalan tüm indeksler okunana kadar hiçbir chunk'ın kullanılmadığı anlaşılamaz; bu okuma işlemini yapan görev ise çöp toplamadır. Budama zamanlaması olan ancak çöp toplama zamanlaması olmayan bir veri deposu sürekli büyür.

Her ikisini de ayarlayın. Önce saklama politikası, her namespace için bir iş:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Ardından veri deposu üzerinde, budama işinden birkaç saat sonra ve yedekleme penceresinin dışında olacak şekilde toplama zamanlamasını ayarlayın:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Bu ayrımı PBS sunucusu üzerinde bir kez kendiniz doğrulayın:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Budama işini çalıştırın, ardından df komutunu kullanın; kullanılan alan miktarının değişmediğini göreceksiniz. Çöp toplama işlemini çalıştırın ve tekrar df komutunu kullanın; bu kez alanın boşaldığını göreceksiniz.

Çöp toplama işlemi iki aşamada çalışır. Birinci aşama, veri deposundaki her indeksi tarar ve bu indekslerin referans verdiği her chunk'ın erişim zamanını günceller. İkinci aşama, erişim zamanı, işlemin başladığı andan 24 saat 5 dakika öncesinden veya hala yazılmakta olan en eski yedeğin başlangıç zamanından (hangisi daha eskiyse) daha eski olan chunk'ları siler. Bu marjın var olma sebebi, Linux'un dosya sistemlerini varsayılan olarak relatime ile mount etmesidir; bu ayar erişim zamanını her okumada değil, yaklaşık günde bir kez günceller. Bu nedenle, bir saat önce yazılmış bir chunk, henüz hiçbir şey ona referans vermese bile silinmez. Budama ile boşaltılan alan, chunk'ın en son dokunulduğu andan bir günden fazla süre geçtikten sonra yapılan ilk toplama işleminde görünür hale gelir. Hiçbir şey geri kazanılmamış gibi görünen bir veri deposu, genellikle bu zaman aralığının içindedir.

Küçük bir VPS üzerinde bu, sunucunun çalıştırdığı en ağır iştir çünkü birim üzerindeki her chunk dosyasının istatistiklerini (stat) kontrol eder. Görev günlüğü, nelerin silindiğini ve nelerin bekleme süresi nedeniyle hala beklediğini gösteren bir özetle biter. Eğer çok fazla bekleyen öğe varsa, işlemi ertesi gün tekrar çalıştırın. PBS, gc-atime-safety-check ve gc-atime-cutoff seçeneklerini veri deposu ayar seçenekleri olarak sunar; ancak her ikisi de varsayılan hallerinde bırakılmalıdır. Bu seçenekler, erişim zamanlarını kaydedemeyen depolama birimleri için mevcuttur. noatime ile mount edilmiş bir dosya sisteminde güvenlik denetimini kapatmak, canlı snapshot'ların referans verdiği chunk'ların kaybolmasına neden olur.

Doğrulama, parçaların hala okunabilir olduğunu kanıtlar

Sorunsuz bir şekilde yüklenen bir yedekleme, bir yıl sonra okunamaz hale gelebilir. Doğrulama işlemi, parçaları yeniden okur ve bunları dizinde saklanan sağlama toplamları (checksum) ile karşılaştırır; böylece hasar, geri yükleme sırasında değil, planlı bir şekilde tespit edilir.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Küçük bir VPS üzerinde iş parçacığı (thread) sayılarını düşük tutun. Doğrulama işlemi disk ve CPU kaynaklarıyla sınırlıdır; aksi takdirde sunucuda çalışan diğer işlemlerle kaynak rekabetine girer. Zamanlama için web arayüzündeki datastore'un Verify Jobs sekmesini kullanın: halihazırda doğrulanmış snapshot'ları atlayan ve 30 günden eski olan her şeyi yeniden doğrulayan haftalık bir görev, iş yükünü tekrarlamadan zaman içinde tüm veri deposunu kapsar.

Doğrulaması başarısız olan bir snapshot, veri deposu görünümünde başarısız olarak işaretlenir. Bunu görmezden gelmeyin. Parçalar paylaşımlı olduğundan, temel bir imajdan kaynaklanan tek bir hasarlı parça, genellikle ona referans veren tüm snapshot'ların başarısız olmasına neden olur. Onarım yöntemi, başarısız olan snapshot'ları unutmak (forget) ve eksik parçaları tekrar yükleyen yeni bir yedekleme çalıştırmaktır. Hatalar sürekli ortaya çıkıyorsa, veri deposunun altındaki depolama biriminden şüphelenin ve sürücünün doğrulama görevinden önce sizi uyarması için VPS üzerinde disk sağlığı izleme kurulumunu yapın.

Bir geri yükleme testi yapın, ardından bunu küme dışında test edin

Bir yedeği geri yüklemediğiniz sürece çalıştığından emin olamazsınız. İki farklı test, farklı durumları kontrol eder.

Küme üzerinde tüm konuk (guest) sistem:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

pvesm list çıktısının ilk sütunu birim kimliğidir (volume ID) ve zaman damgası bunun bir parçasıdır; bu nedenle örnekteki değeri yazmak yerine kendinizinkini kopyalayın. Kullanılmayan bir konuk kimliğine ve farklı bir depolama alanına geri yükleme yapın, ardından ağ arayüzü bağlantısını keserek başlatın. Yedeklerin çalışıp çalışmadığını kontrol etmek için asla çalışan bir konuk sistemin üzerine geri yükleme yapmayın; çünkü yarıda kalan bir geri yükleme, mevcut çalışan kopyanızı da kaybetmenize neden olur.

İkinci test, kimsenin yapmadığı testtir. Kümenin bulunduğu binanın yok olduğunu varsayın ve kümenin parçası olmayan bir makineden geri yükleme yapın. Herhangi bir Debian 13 makinesinde, sadece istemci (client-only) deposunu /etc/apt/sources.list.d/pbs-client.sources olarak ekleyin:

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

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Tırnak içindeki üç yer tutucuyu kendi değerlerinizle doldurun ve son satırdaki arşiv adını snapshot files çıktısından alın. Bu, ilk testin kanıtlayamadığı şeyi kanıtlar: anahtar dosyanızın kopyasının gerçek verileri şifresini çözebildiğini ve istemciyi, küme yapılandırmanızı hiç barındırmamış bir makineden yönetebileceğinizi gösterir. İhtiyaç duyulan dört değeri (depo dizgisi, token gizli anahtarı, parmak izi ve anahtar dosyası) not edin ve bunları felaket kurtarma planınızın işaret ettiği yerde bir arada tutun.

Tekilleştirmenin disk maliyetiniz üzerindeki etkileri

Tekilleştirme (deduplication) gerçek bir işlemdir ve tüm veri deposu genelinde çalışır. On adet Debian misafir sistemi, temel sistemin tek bir kopyasını paylaştığı için, ikinci özdeş misafir sistemin depolama maliyeti neredeyse sıfırdır. Bu işlem aynı zamanda yükleme bant genişliğinden de tasarruf sağlar; çünkü istemci, sunucuda zaten mevcut olan herhangi bir veri parçası için verinin kendisi yerine bir sağlama toplamı (checksum) gönderir.

Bu işlemin yapmadığı şeyleri açıkça belirtmekte fayda vardır.

• Değişen verileri küçültmez. Her gece dosyalarının büyük kısımlarını yeniden yazan bir veritabanı, her gece yeni veri parçaları üretir ve saklama süresi (retention) bunları çoğaltır.
• Yukarıda belirtildiği gibi, bir şifreleme anahtarı sınırının ötesine geçemez.
• İsim alanlarının (namespaces) temel argümanı olan veri deposu sınırının ötesine geçemez.
• Bir birimin dolmasını engellemez. Veri deposu dolduğunda yedeklemeler başarısız olur ve tek çözüm daha büyük bir birim veya daha kısa bir saklama süresidir.

Altına başka bir tekilleştirme katmanı eklemeyin. Veri parçaları istemci tarafından zaten tekilleştirilmiş ve sıkıştırılmış olarak gelir; bu nedenle bir veri deposunun altındaki ZFS tekilleştirmesi, yazılmadan önce kaldırılmış eşleşmeleri aramak için RAM harcar. Bu noktada birim üzerinde standart ext4 veya xfs kullanımı doğru tercihtir.

Web arayüzü, veri deposu için bir tekilleştirme faktörü raporlar. Bu sayı misafir sistemlerinizi tanımlar ve planlama yaparken dikkate alınması gereken tek değer budur; çünkü yayınlanan oranlar başkalarının verilerini tanımlar. Eğer Proxmox misafiri olmayan makinelerin dosya düzeyinde yedeklerine de ihtiyacınız varsa, bunları aynı VPS üzerinde yan yana çalıştırın: PBS, tüm misafir sistemler için hipervizör farkındalığına sahip bir hedeftir; restic ve BorgBackup dizinleri hedefler ve restic ile VPS'e yedekleme yöntemi, PBS'in kapsaması amaçlanmayan dizüstü bilgisayarlar ve bağımsız sunucular için uygundur.

Hata modları ve karşılaşacağınız durumlar

Depolama alanı etkin değil olarak görünüyor. pvesm status --storage pbs-offsite, düğüm 8007 numaralı porta TLS oturumu başlatamadığında inactive çıktısını verir. VPS üzerindeki güvenlik duvarını, ardından sağlayıcının ağ güvenlik duvarını ve son olarak parmak izini kontrol edin. Sertifika ile eşleşmeyen bir parmak izi, engellenmiş bir port ile aynı hatayı verir ve sertifika her değiştirildiğinde bu değer güncellenir.

İlk yedekleme izin hatası nedeniyle başarısız oluyor. Erişim denetim girdisi, kullanıcı yerine token bilgisini içermeli ve depolama alanının işaret ettiği ad alanını kapsamalıdır. Başka bir yere bakmadan önce web arayüzündeki veri deposu izinleri sekmesinden her ikisini de doğrulayın.

Çöp toplama (garbage collection) işlemi başlamayı reddediyor. Erişim zamanı güvenlik denetimi başarısız olmuştur; bu durum neredeyse her zaman veri deposu dosya sisteminin noatime ile mount edildiği anlamına gelir. Durumu doğrulamak için findmnt -no OPTIONS /mnt/datastore/store1 komutunu çalıştırın, /etc/fstab içindeki seçeneği düzeltin ve yeniden mount edin. Sorunu aşmak için bu denetimi devre dışı bırakmayın.

Veri deposu sürekli büyüyor. Budama (prune) işleri çalışıyor ancak hiçbir alan geri kazanılmıyor. Ya bir çöp toplama zamanlaması yoktur ya da tüm işlemler yedeklemelerin hemen ardından çalıştığı için 24 saatlik yetkisiz kullanım süresi (grace window) içinde kalıyordur. Zamanlamayı proxmox-backup-manager datastore show store1 ile kontrol edin.

Eskiden hızlı olan bir yedekleme saatler sürüyor. Durdurulan, taşınan veya geri yüklenen bir konuk sistem, kirli bit eşlemini (dirty bitmap) kaybeder; bu nedenle bir sonraki yedekleme, çok az veri yüklense bile küme tarafında tüm diski okur. Görev günlüğü, küçük bir yükleme miktarı ile uzun bir süre gösterir ve bir sonraki çalıştırma tekrar hızlı olur. Eğer VPS üzerindeki tüm işler yavaşsa, sorun genellikle veri deposunun dışındadır ve ölçülmesi gereken ilk şey CPU steal time from a noisy neighbour değeridir.

FAQ

Prune işlemi çalışmasına rağmen Proxmox Backup Server veri depom neden büyümeye devam ediyor?

Çünkü prune işlemi yalnızca anlık görüntü meta verilerini (manifest, dizinler, günlük ve notlar) siler. Chunk'lar, hiçbir dizinin referans vermediği parçalar garbage collection tarafından silinene kadar diskte kalmaya devam eder. Veri deposuna proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' ile bir zamanlama tanımlayın ve proxmox-backup-manager garbage-collection start store1 öncesi ve sonrasında veri deposu yolunda df -h komutunu çalıştırarak durumu doğrulayın. En az bir günlük bir gecikme bekleyin; çünkü ikinci aşama yalnızca erişim zamanı 24 saat 5 dakikadan eski olan chunk'ları siler.

Bir Proxmox Backup Server VPS'i ne kadar disk alanına ihtiyaç duyar?

Her konuğun fiilen kullandığı alanı toplayın, ardından her konuğun günlük değişim miktarını saklama süreniz olan gün sayısı ile çarpıp ekleyin. Sıkıştırma ve tekilleştirme (deduplication) avantaj sağladığı için bu toplam bir üst sınırdır. Dizinler ve çalışma alanı için yaklaşık beşte bir oranında ekleme yapın, ardından satın alabileceğiniz bir birim boyutuna yuvarlayın. İlk yedeklemeden önce yapılan tahmin her zaman bir yönde hatalı olacağından, iki hafta sonra veri deposu görünümündeki gerçek kullanım değerlerini tekrar kontrol edin.

Yedekleme şifreleme anahtarı nerede saklanmalıdır?

Koruduğu küme dışında herhangi bir yerde. Proxmox VE anahtarı /etc/pve/priv/storage/<storage>.enc dizininde tutar; bu dizin her düğüme kopyalandığı için küme ile birlikte kaybolur. İlk gün anahtarı dışarı kopyalayın, proxmox-backup-client key paperkey ile yazdırın ve bu kopyayı farklı bir binada saklayın. Anahtarın chunk özetinde (digest) yer aldığını, bu nedenle anahtarı daha sonra değiştirmenin bir sonraki yedeklemede her şeyin yeniden yüklenmesi anlamına geleceğini unutmayın.

Her Proxmox ana bilgisayarı için bir veri deposu mu yoksa namespace mi kullanmalıyım?

Her kaynak ana bilgisayar veya küme için bir veri deposu ve bir namespace kullanın. Tekilleştirme veri depoları arasında değil, veri deposu içinde çalışır; bu nedenle ana bilgisayara göre bölmek, aynı temel imajların defalarca depolanmasına neden olur. Namespace'ler yedekleme gruplarını birbirinden ayırır; böylece her ikisinde de 100 ID'li konuk bulunan iki ana bilgisayar çakışmaz ve /datastore/store1/pve-home biçimindeki bir erişim kontrol yolu, her ana bilgisayarın API token'ını kendi namespace'i ile sınırlar.

Küçük bir VPS, Proxmox yedekleme sunucusu olarak yeterli olur mu?

Genellikle ev laboratuvarları için yeterlidir; çünkü chunking ve hashing işlemleri yedekleme sunucusunda değil, Proxmox VE düğümünde gerçekleşir. VPS yalnızca chunk'ları yazar ve iki ağır iş olan garbage collection ve doğrulama (verification) işlemlerini çalıştırır. VPS'e 4 GB RAM verin ve doğrulama iş parçacığı (thread) sayılarını düşük tutun. Her iki işi de yedekleme penceresinin dışında zamanlayın; eğer disk performansına göre çok daha uzun sürüyorsa, daha büyük bir plana geçmeden önce steal time değerini ölçün.