Proxmox Backup Server: garbage Collection ve Prune

Giriş

Bu eğitimde, Proxmox Backup Server bakımını prune işleri ve garbage collection ile uzun süreli yedek depolama için nasıl yapılandıracağınız anlatılmaktadır. Proxmox Prune yapılandırmasını ayarlayacak, Proxmox Garbage Collection işlemini zamanlayacak ve datastore'unuzun kullanılabilir tüm disk alanını doldurana kadar büyümemesi için depolama kullanımını tahmin edeceksiniz.

Bu eğitimin sonunda, bir Proxmox Backup Server datastore'u için zamanlanmış bir prune politikasına ve garbage collection takvimine; günlük, haftalık ve aylık yedekler için pratik saklama (retention) örneklerine sahip olacaksınız.

Ön koşullar

Başlamadan önce aşağıdakilere sahip olduğunuzdan emin olun:

• Proxmox Backup Server 4.2.x veya üzeri
• Mevcut veya planlanan yedeklere sahip, yapılandırılmış bir PBS datastore'u
• Proxmox Backup Server web arayüzüne yönetici erişimi
• root veya yeterli PBS yönetim izinlerine sahip başka bir kullanıcı olarak shell erişimi
• Proxmox VE yedekleme işleri ve PBS namespace'leri hakkında temel bilgi
• Yapılandırmayı tamamlamak için yaklaşık 30 dakika

Bu eğitim, orta düzey sistem yöneticileri için hazırlanmıştır.

Adım 1: Prune ve Garbage Collection'ın birlikte nasıl çalıştığını anlayın

Proxmox Backup Server'da budama (prune) ve garbage collection ayrı bakım işlemleridir. Bunların birlikte nasıl çalıştığını anlamak, etkili Proxmox datastore yönetimi için gereklidir.

Bir prune işi, hangi yedek snapshot'larının tutulacağına ve hangilerinin görünür yedek geçmişinden kaldırılacağına karar verir. PBS bir snapshot'ı prune ettiğinde snapshot'ın meta verilerini, dizinlerini, günlüklerini ve notlarını kaldırır. Kullanılmayan yedek chunk'larını hemen kaldırmaz. Prune edilen snapshot'ların başvurduğu chunk'lar daha sonra garbage collection tarafından kaldırılır.

Garbage collection (GC), kullanılmayan chunk'ları chunk deposundan silerek datastore alanını boşaltır. PBS tekilleştirilmiş (deduplicated) chunk'lar kullandığından, bir chunk birden fazla yedek snapshot'ı tarafından referans alınabilir. Bu nedenle PBS, bir snapshot'ın prune edildiği anda chunk'ları güvenli biçimde silemez. Önce, geriye kalan hiçbir snapshot'ın veya çalışan bir yedeğin bunlara hâlâ başvurmadığını doğrulamalıdır.

PBS, chunk kaldırma için ayrıca bir yaşlandırma süresi (grace period) kullanır. GC sırasında chunk'lar işaretlenir ve temizlenir (mark and sweep); ancak yaşlandırma süresi içindeki chunk'lar kaldırılmayı bekleyenler (pending removals) olarak bildirilir ve hemen silinmez. Bu, çalışan yedekleri korur ve özellikle yaygın relatime bağlama davranışında dosya sistemi erişim zamanı davranışını hesaba katar.

Adım 2: Mevcut datastore yapılandırmasını inceleyin

Bunu hem CLI üzerinden hem de web arayüzünden yapabilirsiniz.

Kullanılabilir datastore'ları listeleyin:

proxmox-backup-manager datastore list

Beklenen çıktı: datastore listesi tablosu.

Proxmox VE yedeklerinizi depolayan datastore'u seçin. Aşağıdaki örneklerde <DATASTORE_NAME> ifadesini kendi datastore adınızla değiştirin.

Mevcut garbage collection durumunu kontrol edin:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Datastore için geçerli GC durumunu görmelisiniz. GC hiç çalıştırılmadıysa çıktıda önceki başarılı bir çalıştırma görünmeyebilir.

Mevcut prune işlerini listeleyin:

proxmox-backup-manager prune-job list

Mevcut prune işlerini veya hiç prune işi yapılandırılmadıysa boş bir liste görmelisiniz.

Web arayüzünden doğrulamak için Datastore - <DATASTORE_NAME> - Prune & GC Jobs bölümüne gidin:

Adım 3: Uzun süreli yedek saklama politikası planlayın

Saklama politikası, geri yükleme gereksinimlerine ve depolama kapasitesine uygun olmalıdır. Pek çok Proxmox yedek saklama planında pratik bir uzun süreli politika, büyükbaba-baba-oğul (grandfather-father-son) düzenini kullanır:

Saklama seçeneği	Örnek değer	Sonuç
keep-daily	14	Yedek alınan 14 gün boyunca günde bir yedek tutar
keep-weekly	8	Yedek alınan 8 hafta boyunca haftada bir yedek tutar
keep-monthly	12	Yedek alınan 12 ay boyunca ayda bir yedek tutar
keep-yearly	2	Yedek alınan 2 yıl boyunca yılda bir yedek tutar

PBS saklama seçenekleri zaman aralıklarına (time buckets) göre işlenir. Örneğin keep-daily, saklanan her gün için en son yedeği tutar; yedek alınmayan günler sayılmaz. keep-weekly, saklanan her ISO haftası için en son yedeği tutar; yedek alınmayan haftalar sayılmaz.

Günlük yedekleme takvimi için aşağıdaki politikalardan biriyle başlayın:

Politika	Saklama ayarları	Kullanım senaryosu
Temkinli	keep-daily 7 keep-weekly 4 keep-monthly 6	Küçük datastore veya kısa geri yükleme geçmişi
Dengeli	keep-daily 14 keep-weekly 8 keep-monthly 12	Tipik VM ve konteyner yedekleri
Uzun süreli	keep-daily 30 keep-weekly 12 keep-monthly 24 keep-yearly 3	Daha büyük datastore veya uyumluluk gereği tutulan geçmiş

Adım 4: Saklamayı uygulamadan önce yedek depolama alanını tahmin edin

Uzun süreli yedek depolama için alan planlaması, VM'in tam boyutunu snapshot sayısıyla çarpmakla aynı şey değildir. Proxmox Backup Server tekilleştirme kullandığından, her yeni yedek genellikle yalnızca değişen chunk'ları ve meta verileri depolar. Yine de temkinli bir tahmin yapmalısınız.

Şu formülü kullanın:

Tahmini depolama = başlangıçtaki korunan veri + günlük değişen veri * saklanan gün eşdeğeri + güvenlik payı

Örnek 1: Bir VM grubu için dengeli saklama:

Değer	Örnek
Korunan VM verisi	2 TB
Ortalama günlük değişen veri	80 GB
Saklama politikası	14 günlük · 8 haftalık · 12 aylık
Güvenlik payı	yüzde 25

Saklanan yaklaşık değişiklik noktaları:

14 daily + 8 weekly + 12 monthly = 34 restore points

Yaklaşık değişen veri:

80 GB * 34 = 2720 GB

Pay eklenmeden önceki yaklaşık toplam:

2000 GB + 2720 GB = 4720 GB

Yüzde 25 güvenlik payı ekleyin:

4720 GB * 1.25 = 5900 GB

Bu iş yükü için yaklaşık 6 TB kullanılabilir datastore kapasitesi planlayın.

Örnek 2: Daha küçük bir datastore politikası:

Değer	Örnek
Korunan VM verisi	1 TB
Ortalama günlük değişen veri	30 GB
Saklama politikası	7 günlük · 4 haftalık · 6 aylık
Güvenlik payı	yüzde 25

Yaklaşık geri yükleme noktaları:

7 + 4 + 6 = 17 restore points

Yaklaşık depolama:

1000 GB + (30 GB * 17) = 1510 GB
1510 GB * 1.25 = 1887.5 GB

Bu iş yükü için yaklaşık 2 TB kullanılabilir datastore kapasitesi planlayın.

Adım 5: Web arayüzünde prune işi oluşturun

1. Proxmox Backup Server web arayüzünü açın.
2. Datastore öğesini seçin.
3. <DATASTORE_NAME> öğesini seçin.
4. Prune & GC sekmesini açın.
5. Add Prune Job düğmesine tıklayın.
6. Datastore alanını <DATASTORE_NAME> olarak ayarlayın.
7. Yalnızca tek bir namespace'i prune etmek istiyorsanız Namespace alanını ayarlayın.
8. Saklama değerlerini yapılandırın; örneğin keep-daily için 14, keep-weekly için 8 ve keep-monthly için 12.
9. Takvimi ayarlayın; örneğin 03:00.
10. Prune işini kaydedin.

Beklenen sonuç: PBS, datastore veya namespace için zamanlanmış bir prune işi oluşturur. Bu iş, saklama politikanız tarafından artık seçilmeyen yedek snapshot'larını düzenli olarak kaldırır.

Adım 6: Komut satırından prune işi oluşturun

Aynı prune işini PBS shell'inden de oluşturabilirsiniz.

Tüm datastore için prune işi:

proxmox-backup-manager prune-job create pve-longterm \
  --store <DATASTORE_NAME> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term Proxmox backup retention"

Beklenen sonuç: PBS, pve-longterm adında bir prune işi oluşturur.

Namespace'e özel prune işi:

proxmox-backup-manager prune-job create pve-namespace-longterm \
  --store <DATASTORE_NAME> \
  --ns <NAMESPACE> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term retention for namespace"

Beklenen sonuç: PBS yalnızca seçilen namespace'i prune eder. Bu, farklı kümelerin, kiracıların (tenant) veya ortamların farklı saklama politikaları gerektirdiği durumlarda yararlıdır.

Prune işini listeleyin:

proxmox-backup-manager prune-job list

Beklenen çıktı: Proxmox yedek temizleme işi listesi tablosu.

Adım 7: Garbage Collection zamanlamasını yapılandırın

Prune eski snapshot meta verilerini kaldırdıktan sonra, kullanılmayan chunk alanını geri kazanmak için GC'nin çalışması gerekir. Haftalık GC takvimi, çoğu kurulum için iyi bir başlangıç noktasıdır.

Haftalık GC takvimi ayarlayın:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --gc-schedule "Sun 04:00"

Bunu web arayüzünde Datastore - <DATASTORE_NAME> - Prune & GC Jobs → Garbage Collection Jobs → Edit yolunu izleyerek yapılandırabilirsiniz:

Beklenen sonuç: PBS, datastore için garbage collection'ı her Pazar saat 04:00'e zamanlar.

GC durumunu kontrol edin:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Beklenen çıktı, datastore adını ve en son veya sonraki GC çalıştırmasına ilişkin bilgileri içerir.

GC'yi elle de başlatabilirsiniz:

proxmox-backup-manager garbage-collection start <DATASTORE_NAME>

Beklenen sonuç: PBS, datastore için bir GC görevi başlatır.

Adım 8: Güvenli bir prune ve GC takvimi seçin

Pratik bir takvim şöyledir:

Görev	Örnek takvim	Gerekçe
Proxmox VE yedekleme işi	Her gün 01:00	Önce yeni yedekleri oluşturur
PBS prune işi	Her gün 03:00	Saklama dışındaki snapshot'ları kaldırır
PBS GC işi	Haftalık, Pazar günü 04:00	Prune sonrasında kullanılmayan chunk'ları geri kazanır

Bu sıralama, eski snapshot'lar kaldırılmadan önce yeni yedeklerin hazır olmasını sağlar. Ayrıca prune ve GC görevleri başlamadan önce PBS'e yedek yazımlarını tamamlaması için zaman tanır.

Yoğun ortamlarda yedekleme, doğrulama, prune, senkronizasyon ve GC görevlerinin aynı anda çalışmasından kaçının. G/Ç çekişmesini azaltmak için bakım işlerini zaman bakımından kademelendirin.

Adım 9: Yapılandırmayı doğrulayın

Prune işlerini listeleyin:

proxmox-backup-manager prune-job list

İşin beklenen datastore, namespace, takvim ve keep değerlerine sahip olduğunu doğrulayın.

Tek bir prune işini görüntüleyin:

proxmox-backup-manager prune-job show pve-longterm

Beklenen sonuç: PBS, yapılandırılmış saklama seçeneklerini gösterir.

GC yapılandırmasını kontrol edin:

proxmox-backup-manager garbage-collection list

Beklenen sonuç: PBS, GC işi bulunmayan datastore'lar dahil tüm datastore'ların garbage collection durumunu listeler.

Web arayüzünden datastore kullanımını kontrol edin:

• Datastore öğesini açın.
• <DATASTORE_NAME> öğesini seçin.
• Datastore kullanımını ve görev geçmişini inceleyin.
• Tasks bölümünü açın ve prune ile GC işlerinin başarıyla tamamlandığını doğrulayın.

Beklenen sonuç: Datastore zamanlanmış bakım etkinliğini gösterir ve eski snapshot'lar yapılandırılmış Proxmox Prune yapılandırmasına göre kaldırılır.

Adım 10: Depolama büyümesini zaman içinde izleyin

PBS'te prune işlerini yapılandırdıktan sonra depolama kullanımını en az bir tam saklama döngüsü boyunca izleyin. Örneğin keep-monthly 12 yapılandırdıysanız, uzun vadeli eğilimin netleşmesi için birkaç aylık veriye ihtiyacınız vardır.

Şu metrikleri inceleyin:

Metrik	Neyin kontrol edileceği
Datastore'un kullanılan alanı	Yedek depolama optimizasyonunun çalışıp çalışmadığını doğrular
Prune görev günlükleri	Snapshot'ların kaldırıldığını doğrular
GC görev günlükleri	Kullanılmayan chunk'ların silindiğini doğrular
Kaldırılmayı bekleyenler (pending removals)	GC yaşlandırma süresini bekleyen chunk'ları gösterir
Yedek işi boyutu eğilimi	Değişen verinin artıp artmadığını gösterir

Datastore beklenenden hızlı büyümeye devam ediyorsa, dosya sistemi dolmadan önce saklamayı azaltın veya depolama ekleyin.

Yaygın ayarlamalar:

Sorun	Ayarlama
Datastore çok hızlı doluyor	keep-daily, keep-weekly veya keep-monthly değerini azaltın
Yakın tarihli geri yükleme noktası çok az	keep-daily değerini artırın
Aylık geçmiş çok kısa	keep-monthly değerini artırın
Yedekler bakımla çakışıyor	Prune veya GC'yi daha geç bir saate taşıyın
GC az alan boşaltıyor	Prune işlerinin eski snapshot'ları gerçekten kaldırdığını doğrulayın

Değişiklikleri geri alma

Bir prune işini kaldırmak için:

proxmox-backup-manager prune-job remove pve-longterm

Beklenen sonuç: PBS, prune işi yapılandırmasını kaldırır.

Datastore'u silmeden GC takvimini devre dışı bırakmak için:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --delete gc-schedule

Beklenen sonuç: PBS, datastore için otomatik GC takvimini temizler.

Prune işini kaldırmak yerine saklamayı değiştirmek için:

proxmox-backup-manager prune-job update pve-longterm \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Beklenen sonuç: PBS prune işini korur, ancak sonraki prune çalıştırmalarında yeni saklama politikasını uygular.

Sorun giderme

GC alanı hemen boşaltmıyor

Neden: Prune snapshot meta verilerini kaldırdı, ancak chunk'lara hâlâ başka snapshot'lar başvuruyor veya chunk'lar GC yaşlandırma süresi içinde.
Çözüm: Yaşlandırma süresinin dolmasını bekleyin ve GC'yi daha sonra yeniden çalıştırın. Kaldırılmayı bekleyenler (pending removals) için görev günlüklerini kontrol edin.

Prune beklenenden fazla yedek tutuyor

Neden: keep-daily, keep-weekly ve keep-monthly zaman aralıklarını kullanır. Yedek alınmayan günler, haftalar veya aylar sayılmaz. Saklama kuralları ayrıca çakışır.
Çözüm: Üretimdeki saklama ayarını değiştirmeden önce PBS prune simülatörünü kullanın. Bu, değişiklikleri uygulamadan önce saklama davranışını önizlemenizi sağlar.

Datastore, prune ve GC sonrasında hâlâ büyüyor

Neden: Günlük değişen veri tahminden yüksek olabilir, yedekler yeni diskler içerebilir veya saklama datastore için çok büyük olabilir.
Çözüm: Hacim tahminini gerçek değişen veriyle yeniden hesaplayın. Saklamayı azaltın veya depolamayı genişletin.

Prune işi bir namespace'i etkilemiyor

Neden: Prune işi yanlış namespace veya yanlış namespace derinliği için yapılandırılmış olabilir.
Çözüm: Prune işi ayarlarını inceleyin ve --ns değerini doğrulayın. İşin yalnızca tek bir namespace'e uygulanmasını istiyorsanız namespace'i açıkça belirtin.

Yedekleme istemcileri yedekleri hâlâ silebiliyor

Neden: Yedekleme kimlik bilgileri silme izinlerine sahip olabilir veya saklama PBS dışında yapılandırılmış olabilir.
Çözüm: Yedekleme istemcileri için en az ayrıcalık ilkesini uygulayın. Fidye yazılımına (ransomware) karşı dayanıklılık için, yedekleme istemcilerine silme izni vermek yerine PBS tarafındaki prune işlerini tercih edin.

Sonuç

Bir prune işi oluşturarak ve garbage collection'ı zamanlayarak uzun süreli saklama için Proxmox Backup Server bakımını yapılandırdınız. Ayrıca chunk'ların neden hemen silinmediğini, GC'nin datastore temizliğini nasıl tamamladığını ve uzun süreli saklamayı uygulamadan önce depolama gereksinimlerini nasıl tahmin edeceğinizi öğrendiniz. Bu uygulamalar, depolama verimliliğini artırarak ve yedek saklamanın öngörülebilir ve yönetilebilir kalmasını sağlayarak Proxmox yedek optimizasyonunu destekler.

Sonraki adımlar olarak doğrulama işleri ekleyin, başarısız prune ve GC görevleri için bildirimler yapılandırın ve datastore büyümesini her ay gözden geçirin. Bu, yedek depolama optimizasyonunun öngörülebilir kalmasını sağlar ve saklama ayarlarının fark edilmeden tüm kullanılabilir kapasiteyi tüketmesini önler.

Doküman sürümü: 1.0
Son güncelleme: Haziran 2026
Sahibi: Teknik Dokümantasyon Ekibi