Kural · 01
3 kopya
Üretim + iki yedek
Üretim verisi her zaman birinci kopyadır. Yanına iki bağımsız yedek daha gerekir — biri bozulsa diğeriyle restore edersiniz. Tek yedek, yedek değildir; sadece umut.
Diskler bir gün arızalanır, bir tuş yanlış basılır, bir saldırgan içeri sızar — soru "olur mu" değil, "olduğunda kaç saatte ayağa kalkarsınız?". 3-2-1 stratejisinden RPO/RTO planlamaya, snapshot ile yedeğin farkından doğrulama runbook'larına; bu sayfa, planınızı sağlam bir zemine oturtmak için hazırlandı.
Sektörün otuz yıllık deneyiminden süzülmüş, US-CERT'in de önerdiği basit bir kural: aynı veriden üç kopya, iki farklı medya, en az biri farklı lokasyonda. Modern yorumda buna soğuk/değiştirilemez kopya da eklenir — ransomware bu kopyaya dokunamasın diye. Snapshot ile yedeğin altyapı tarafındaki farkı için Cloud & Altyapı, veritabanına özgü nokta-zaman kurtarması için Veritabanı & Depolama sayfalarına bakın.
Üretim verisi her zaman birinci kopyadır. Yanına iki bağımsız yedek daha gerekir — biri bozulsa diğeriyle restore edersiniz. Tek yedek, yedek değildir; sadece umut.
Yedekler aynı NVMe havuzundaysa, fiziksel arıza ikisini birden götürür. Blok depolama + nesne depolama (S3-uyumlu), veya disk + bant gibi farklı katmanlara yayın.
Veri merkezi yangını, sel, elektrik kesintisi — bölgesel bir olay tek lokasyondaki her şeyi siler. En az bir kopya bağımsız bir coğrafi bölgede ya da farklı bir bulut sağlayıcısında tutulmalı.
RPO ne kadar veri kaybını kabul edersiniz; RTO ne kadar süre offline kalabilirsiniz. İkisi de iş tarafının kararıdır, teknik tarafın değil — ama maliyeti birlikte ödeyeceğiniz için birlikte kararlaştırmanız gerekir.
# geçmiş ←─────── şimdi ─────────→ gelecek
son yedek FELAKET geri dönüş
│ │ │
────●────────────────●──────────────────●────►
└──── RPO ───────┘ │
└──── RTO ─────────┘
# RPO = kabul edilebilir veri kaybı süresi
# RTO = kabul edilebilir kesinti süresiYedek planı, korktuğunuz senaryoya göre şekillenir. Tek bir disk arızası ile bir bölgesel ransomware saldırısı çok farklı tedbirler gerektirir. Aşağıdaki dört kategori, planın hangi katmanını test etmeniz gerektiğini gösterir.
Yedek dosyasının var olması, geri yüklenebileceği anlamına gelmez. Bozuk dosya, eksik şema, hatalı sürüm, unutulmuş şifreleme anahtarı — restore'u ilk kez deneyenler bunları çoğu zaman felaket anında öğrenir. Düzenli tatbikat, planınızı kâğıttan canlıya çevirir.
En azından çeyrekte bir tam restore tatbikatı, aylık otomatik smoke-test önerilir. Üretimi kesintiye uğratmadan, ayrı bir hesapta veya bölgede koşturun.
Hangi veritabanları, hangi obje depoları, hangi konfigürasyon dosyaları? Yedek alınmayan bir dizinin değerini ancak silindiğinde fark edersiniz. Envanteri yılda bir gözden geçirin.
"Üretim DB'si silindi, son temiz yedekten geri al" gibi tek satırlık bir hedef yazın. Adımları runbook hâline getirin — gece 03:00'te ezbere çalışmasını beklemeyin.
Yedekleri üretim dışı bir hesapta / bölgede restore edin. Şifreleme anahtarlarına erişimi, ağ izinlerini ve bağımlılık sırasını burada öğrenin.
Sadece "servis ayağa kalktı" yetmez. Belirli kayıtların var olduğunu, raporların doğru sayıları döndürdüğünü, dosyaların açıldığını sorgulayan otomatik testler yazın.
Tatbikatın baştan sona ne kadar sürdüğünü ölçün; bu sizin gerçek MTTR'nizdir. RTO hedefinizin üstündeyse plan değişmeli — donanım, otomasyon ya da kapsamda.
Her tatbikatta bir şey kırılır: eksik kütüphane, süresi dolan sertifika, unutulmuş ortam değişkeni. Bunları derhal runbook'a, terraform'a ya da kod tabanına işleyin. Bir sonraki tatbikat aynı engele takılmasın.
Snapshot aynı depolama altyapısındaki anlık bir referanstır — donanım kaybında üretim verisiyle birlikte gider. Backup ise bağımsız bir konuma kopyalanmış veridir. Snapshot hızlı geri dönüş için, backup gerçek felaket kurtarma için tutulur. Birbirinin yerine geçmezler; ikisi de gereklidir.
RAID bir disk arızasında servisi kesintisiz tutar; kullanılabilirliği (availability) korur. Ama yanlışlıkla silinen dosyayı geri getirmez, ransomware'i durdurmaz, veri merkezi yandığında ölür. Yedek bu üç durumda da işe yarayan ayrı bir katmandır.
Replikasyon veriyi gerçek zamanlıya yakın başka bir kopyaya yansıtır — bölge kaybına karşı güçlüdür. Ama bir bozulmayı, yanlış silme işlemini ya da şifrelenmeyi de o saniye yansıtır. Yedek, zamanın belirli noktalarına geri dönebilmenizi sağlar.
High Availability küçük arızalarda (tek sunucu, tek bağlantı) servisin akmaya devam etmesini hedefler — saniyeler içinde fark ettirmeden devralan ikinci düğüm. Disaster Recovery büyük olaylarda (bölge kaybı, bütün cluster) sistemi başka bir yerde ayağa kaldırmayı planlar — dakikalar veya saatler içinde. İki ayrı disiplin, iki ayrı bütçe kalemi.
Cold yedek ortam kapalıdır; ihtiyaç anında başlatılır, restore edilir, hazırlanır — saatler sürebilir, ucuzdur. Warm ortam ayakta ama trafik almıyordur — dakikalar içinde devreye girer. Hot ise canlı trafiği paralel alır — anında devralır, en pahalısıdır. RTO'nuz hangisini seçeceğinizi belirler.
Yedekleme ve felaket kurtarma alanını tanımlayan resmi yayınlar.
Mevcut yedekleme akışınızı, RPO/RTO hedeflerinizi ve son tatbikatınızın bulgularını masaya yatıralım — eksikleri birlikte tamamlayalım.