Yedek var mı? Geri yükleme provası yoksa yok

"Yedek var mı?" sorusunun en sık cevabı "var, kurulu"dur. Ama bir yedekleme aracının kurulu olması, yedek alındığı anlamına gelmez. Arayüzü yeşil görünen, lisansı olan ama tek bir yedekleme politikası tanımlanmamış kurulumlar şaşırtıcı derecede yaygındır.

Bu yazı, "kurulu" noktasından "bir namespace'i silip geri getirebiliyoruz" noktasına giden yolu anlatıyor.

1. Neyi kaybedebilirsiniz?

Kubernetes'te "yedek" tek bir şey değildir. Üç ayrı kayıp senaryosu vardır ve her biri ayrı bir yedek ister:

Veritabanları cluster dışındaysa onlar da ayrı bir katmandır (PostgreSQL için WAL arşivi ile zamana dönük geri dönüş, PITR).

2. Kurulum: üç katman, tek hedef

• Velero, bütün Kubernetes nesnelerini yedekler ve disklerin CSI snapshot'ını tetikler.
• Longhorn backup target, bu snapshot'ları S3 uyumlu bir depoya (MinIO) taşır. Velero'nun VolumeSnapshotClass'ı Longhorn'un yedek tipini (type: bak) kullanır.
• RKE2 etcd snapshot'ları 12 saatte bir hem yerel diske hem S3'e yazılır.

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: velero-gunluk
  namespace: velero
spec:
  schedule: "0 2 * * *"      # her gece 02:00
  template:
    ttl: 336h0m0s            # 14 gün
    excludedNamespaces: [velero]
    snapshotMoveData: false

Yedek hedefi ayrı bir lokasyonda olmalı. Aynı veri merkezindeki bir disk, o veri merkezi gittiğinde işe yaramaz.

En az yetki

Her cluster'ın yedek kullanıcısı S3'te yalnız kendi klasörüne yazabilir. Bir cluster ele geçirilirse diğer cluster'ların yedeklerini silemez. Silme yetkisi sadece eski snapshot'ları temizlemesi gereken yere verilir.

3. Asıl iş: geri yükleme provası

Kurulumdan sonra yedek listesi dolmaya başlar ve herkes rahatlar. Ama bir yedeğin çalıştığını gösteren tek kanıt, ondan geri dönebilmektir.

Prova basit ve tekrarlanabilir olmalı:

# 1. Deneme namespace'i: küçük bir PVC ve içinde rastgele bir dosya
kubectl create ns velero-deneme
# ... PVC + pod, dosyanın md5'i not edilir

# 2. Yedek al
velero backup create deneme-1 --include-namespaces velero-deneme --wait

# 3. Namespace'i sil
kubectl delete ns velero-deneme

# 4. Geri yükle ve dosyanın md5'ini karşılaştır
velero restore create --from-backup deneme-1 --restore-volumes=true --wait

Dosyanın md5'i aynı çıktıysa iki katman (nesne + disk) birlikte çalışıyor demektir. Bu provayı her cluster'da ayrı ayrı yapın; bir cluster'da çalışması diğerinde çalışacağını göstermez.

4. Provada neler çıkabilir?

Prova yapılmasa görülmeyecek iki örnek:

• Velero bellek limiti: Cluster'da çok sayıda özel kaynak (ör. güvenlik tarama raporları) birikirse Velero varsayılan bellek limitine takılıp OOM olabilir. Yedek "kurulu" görünür, ama o gece alınmamıştır. Yedek işlerinin sonucu için mutlaka alarm kurun.
• Geri yükleme için gereken sırlar: etcd snapshot'ından dönmek için RKE2 server token'ı, şifreli Rancher yedeğinden dönmek için şifreleme anahtarı gerekir. Bunlar sunucunun dışında, parola kasasında durmalı. Sunucuyla birlikte kaybolan anahtar, yedeği de kullanılmaz yapar.

5. "Hangi yedek, hangi ihtiyaç" tablosu

Gece 03:00'te bir şey bozulduğunda kimse doküman okumak istemez. Devir dokümanına tek bir tablo koyun:

Henüz prova edilmemiş satırların yanına açıkça "prova edilmedi" yazın. Dürüst bir tablo, iyimser bir tablodan daha değerlidir.

Ders

Yedekleme aracı kurmak işin yarısı bile değildir. Politika, alarm, ayrı lokasyon, kasadaki anahtarlar ve en önemlisi düzenli geri yükleme provası. Provası yapılmamış yedek, sadece umut verir.