[ OK ]Çekirdek başlatılıyor...
~/im/blog
Benimle Çalışın

Konuşalım

Birlikte çalışmakla ilgileniyor ya da bir sorunuz mu var? Yeni projeleri konuşmaya her zaman açığım.

İletişime geçin

Bağlantı Kurun

Beni sosyal medyada ve profesyonel ağlarda bulabilirsiniz.

Gizlilik Politikası (KVKK)Kullanım Koşulları
© 2026 Irfan MiralGeliştirici:irfanMiral.com
AnasayfaHakkımda/ÖzgeçmişBlogİletişim
2026-04-02• 5 dakika okuma

Proxmox Snapshot'ları Backup Değildir

Cloud Proxmox Yedekleme Virtualization

Proxmox snapshot'larını seviyorum. Riskli bir upgrade'den önce, tam emin olmadığım bir config değişikliğinden önce, ya da sıfırdan rebuild etmek istemediğim bir VM'de bir dist-upgrade'den önce, snapshot almak on saniyelik bir sigorta. Bir şey ters giderse, qm rollback VM'i tam olarak olduğu yere geri döndürüyor. Bu gerçekten kullanışlı, ve sık kullanıyorum.

Problem, tam da bu snapshot'ın backup stratejisi olarak görülmeye başlamasıyla ortaya çıkıyor, çünkü ikisi farklı problemleri çözüyor, ve aralarındaki boşluk ancak en kötü anda kendini gösteriyor.

Bir snapshot gerçekte ne

Bir Proxmox snapshot'ı VM'in disk'ini kopyalamıyor. Mevcut state'i dondurup değişiklikleri bir delta olarak takip etmeye başlıyor, orijinal data tam olarak olduğu yerde kalıyor, aynı storage'da, aynı host'ta. Snapshot'ların hızlı oluşturulup anında ekstra alan kullanmamasının sebebi bu, ve o storage ya da o host'ta bir problem olduğunda işe yaramamalarının sebebi de tam olarak bu.

# Take a snapshot before a risky change
qm snapshot 101 pre-upgrade

# If it goes wrong, roll back
qm rollback 101 pre-upgrade

Upgrade VM'in içinde bir şeyi bozarsa, bu mükemmel, otuz saniye ve known-good bir state'e geri dönmüş oluyorsunuz. Host'un disk'i fail ederse, ya da host'un kendisi geri gelmezse, snapshot da her şeyle birlikte gidiyor, çünkü hiçbir zaman başka bir yerde var olmadı.

Gerçek bir backup'ın ihtiyacı

Bir backup, VM'de, host'ta, ya da storage'da olan bir problemin backup'ı da götürmeyeceği bir yerde var olmalı. Proxmox'un built-in vzdump'ı tam olarak bunu yapıyor, VM'in tam bir kopyasını ayrı bir target'a yazıyor:

vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Buradaki --mode snapshot, rollback yapacağınız bir Proxmox snapshot'ından farklı bir şey yapıyor, VM'in durdurulmasına gerek kalmasın diye kısa süreliğine snapshot mekaniklerini kullanıyor, ama çıktı backup-nfs'e yazılan tam, standalone bir archive. Bu archive, orijinal disk'in hâlâ var olmasına bağımlı değil.

Tek bir host'tan fazlası için, Proxmox Backup Server çalıştırmaya değer, bunun üstüne deduplication ve incremental backup ekliyor, yani büyük bir VM'in günlük backup'ları günlük full kopyalar anlamına gelmiyor, ve yine de source'tan bağımsız yaşayan, restore edilebilir archive'lar üretiyor.

Asıl önem taşıyan test

Database backup'larında olduğu gibi, bir Proxmox backup'ının iyi olduğunu bilmenin tek yolu onu restore etmek, ideal olarak orijinalinden farklı bir storage'a ya da farklı bir host'a:

qmrestore /mnt/backup-nfs/dump/vzdump-qemu-101-*.vma.zst 201 --storage local-lvm

Bu restore boot eden ve düzgün görünen bir VM üretiyorsa, backup gerçek. Üretmiyorsa, bunu gerçek bir recovery'de değil, şimdi öğrenmek daha iyi.

Kullandığım ayrım

Snapshot'lar, "şimdi bir şey yapmak üzereyim ve önümüzdeki on dakika içinde geri almam gerekebilir" durumu için: upgrade'ler, riskli config değişiklikleri, destructive bir şeyi test etmek. Bu iş için ucuz, hızlı, ve tam doğru. vzdump ile ayrı bir storage'a, ya da Proxmox Backup Server, "bu VM, bu host olmasa da var olmaya devam etmeli" durumu için: zamanlanmış, host'un dışında, ve arada bir gerçek bir restore ile test edilmiş.

İkisinin de bir yeri var. Hata, birincinin kolaylığının ikincinin işini sessizce devralmasına izin vermek, ta ki host seviyesinde bir problemin bu farkı çok belirgin, ve çok maliyetli hale getirdiği güne kadar.

ÖncekiVPS mi Bare Metal mi: Gerçekte Nasıl Karar VeriyorumSonraki Bir KVM VM'i CLI'dan Ayağa Kaldırmak