Sunucu Yedekleme ve Kurtarma: Yöntemler, 3-2-1 Kuralı ve Test Planı

Sunucu yedekleme ve kurtarma, sunucudaki verinin düzenli kopyalarını ayrı yerlerde saklamak ve bir arıza, saldırı ya da hata sonrasında sistemi belirlenmiş sürede yeniden çalışır hale getirmektir. İyi bir plan üç soruya yazılı cevap verir: ne kadar veri kaybını kaldırabilirsiniz, sistem ne kadar sürede geri dönmeli ve bu geri dönüş en son ne zaman denendi? Üçüncü sorunun cevabı yoksa elinizde bir plan değil, bir varsayım vardır.

Yedekleme ile felaket kurtarma arasındaki fark nedir?

Yedekleme verinin kopyasıdır. Felaket kurtarma ise o kopyayı kullanarak hizmeti yeniden ayağa kaldırma sürecidir: yedek hangi sunucuya kurulacak, önce veritabanı mı gelecek uygulama mı, alan adı yeni adrese nasıl yönlendirilecek, kararı kim verecek.

Sık gördüğümüz durum şu: gecelik veritabanı yedeği alınıyor ama sunucu yapılandırması, SSL sertifikaları, ortam değişkenleri, zamanlanmış görevler ve kullanıcıların yüklediği dosyalar yedeğin dışında kalıyor. Veri sağlam çıkıyor, site yine de günlerce kapalı kalıyor. Kurtarma planı yazmak, bu boşlukları yedekleme kapsamına dahil etmenin en pratik yoludur.

RPO ve RTO: planın iki ölçüsü

Microsoft'un Azure Well-Architected çerçevesi bu iki hedefi şöyle tanımlar: RPO (Recovery Point Objective) zaman cinsinden kabul edilebilir en fazla veri kaybıdır; RTO (Recovery Time Objective) bir felaketten sonra işi yeniden yürütmek için kabul edilebilir en uzun süredir.

Somut bir örnek: yalnız gece yedek alan bir e-ticaret sitesinde öğleden sonra veritabanı bozulursa, o günün siparişleri kaybolur. Bu işletmenin fiilî RPO'su 24 saattir. Bu kabul edilemiyorsa yedek sıklığı artırılır ya da veritabanının işlem günlükleri sürekli arşivlenerek belirli bir ana geri dönme (point-in-time recovery) imkânı kurulur.

RTO ise teknik değil, iş kararıdır. Kurumsal tanıtım sitesi için yarım gün kabul edilebilirken sipariş alan bir mağaza ya da ERP'ye bağlı bir bayi portalı için birkaç saatlik kesinti bile ciddi kayıptır. Hedefleri her sistem için ayrı yazın; hepsine aynı hedefi koymak ya bütçeyi boşa harcar ya da kritik sistemi korumasız bırakır.

Hangi yedekleme yöntemi ne zaman kullanılır?

Tam, artımlı ve fark yedeği

• Tam yedek: Her şeyin kopyasıdır. Geri yüklemesi en basit yöntemdir ama en çok yer ve süre ister.
• Artımlı yedek: Yalnız bir önceki yedekten bu yana değişeni alır. Hızlıdır ve az yer kaplar; geri yüklerken son tam yedek ve sonraki tüm artımlı yedekler zincir halinde gerekir.
• Fark (diferansiyel) yedeği: Son tam yedekten bu yana değişen her şeyi alır. Geri yüklemek için son tam yedek ile en son fark yedeği yeterlidir.

Yaygın düzen haftada bir tam yedek, arada günlük artımlı yedektir. restic ve Borg gibi güncel araçlar veriyi parçalara bölüp tekrar edeni yeniden saklamadığı için her yedek tam yedek gibi geri yüklenir ama artımlı yedek kadar yer kaplar.

Anlık görüntü (snapshot) yedek sayılır mı?

Bulut sağlayıcıların disk anlık görüntüleri hızlı geri dönüş için çok kullanışlıdır. Ancak çoğu zaman aynı sağlayıcıda, aynı hesapta dururlar. Hesap ele geçirilirse ya da bir ödeme sorunu yüzünden askıya alınırsa görüntüler de erişilemez olur. Snapshot'ı ilk savunma hattı olarak kullanın, tek yedeğiniz olarak değil.

Veritabanına ayrı yedek

Çalışan bir veritabanının dosyalarını düz kopyalamak tutarsız bir yedek üretebilir. MySQL ve MariaDB için mysqldump ya da benzeri araçlar, PostgreSQL için pg_dump veya sürekli arşivleme kullanın. Dosya yedeği ile veritabanı yedeğinin aynı zamana ait olmasına dikkat edin; aksi halde görseli olup kaydı olmayan ya da kaydı olup görseli kaybolan ürünlerle karşılaşırsınız.

3-2-1 kuralı ve fidye yazılımına karşı çevrimdışı kopya

3-2-1 kuralı şunu söyler: verinin üç kopyası olsun, bu kopyalar iki farklı ortamda dursun ve biri başka bir fiziksel konumda saklansın. Aynı veri merkezindeki iki disk; yangın, su baskını ya da enerji arızası gibi tek bir olayda birlikte kaybolabilir.

Son yıllarda bu kurala bir katman daha eklendi. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), fidye yazılımı rehberinde kritik verinin çevrimdışı ve şifreli yedeklerinin tutulmasını ve bu yedeklerin bir felaket senaryosunda düzenli olarak test edilmesini öneriyor. Gerekçesi açık: birçok fidye yazılımı erişebildiği yedekleri arayıp siliyor ya da şifreliyor. Pratikte bu şu anlama gelir:

• Sunucu, yedek hedefine yalnız yazma yetkisiyle erişsin; silme yetkisi sunucudaki hesapta bulunmasın.
• Mümkünse değiştirilemez (immutable, nesne kilitli) depolama kullanın.
• En az bir kopyanın canlı ortamla ağ bağlantısı sürekli açık olmasın.
• Yedekleri şifreleyin ve şifre anahtarını yedekle aynı yerde saklamayın.

CISA aynı rehberde, bulut yedeklerinde tek sağlayıcıdaki tüm hesapların birlikte etkilenme ihtimaline karşı birden fazla bulut kullanılmasını da öneriyor.

Felaket kurtarma planı nasıl yazılır?

1. Sistemleri listeleyin ve önceliklendirin. Web sitesi, veritabanı, e-posta, CRM/ERP bağlantıları, ödeme entegrasyonu. Her biri için RPO ve RTO yazın.
2. Bağımlılıkları çıkarın. Uygulama veritabanı olmadan açılmaz. Önce veritabanı, sonra uygulama, en son DNS gibi net bir sıra belirleyin.
3. Geri yükleme adımlarını komut düzeyinde yazın. Hangi yedek nerede, hangi anahtarla açılıyor, hangi sunucuya kuruluyor? Belge, sistemi hiç görmemiş bir teknik kişinin uygulayabileceği açıklıkta olmalı.
4. Rolleri belirleyin. Felaketi kim ilan eder, müşteriye kim bilgi verir, hosting sağlayıcıyla kim konuşur?
5. Planı sistemin dışında saklayın. Kurtarma belgesi, erişim bilgileri ve betikler çöken sunucunun içindeyse işe yaramaz. Microsoft da bu belgelerin kesinti sırasında erişilebilir kalmasını ve en kötü senaryo için çevrimdışı ya da basılı kopya tutulmasını öneriyor.
6. Asıl ortama dönüşü de planlayın. Yedek sunucuya geçtikten sonra eski ortama dönmek ayrı bir süreçtir; onun adımlarını da yazın.

Kurtarma testi ne sıklıkla yapılmalı?

Test edilmemiş yedek, çalışıp çalışmayacağı bilinmeyen yedektir. En az iki test türü öneririz:

• Düzenli geri yükleme testi: Örneğin ayda bir, rastgele seçtiğiniz bir yedeği ayrı bir test ortamına geri yükleyin. Site açılıyor mu, son siparişler yerinde mi, bakın ve geçen süreyi not edin. Bu süre sizin gerçek RTO'nuzdur.
• Masa başı tatbikat: Yılda birkaç kez ekip bir senaryo üzerinden (sunucu fidye yazılımıyla şifrelendi, veri merkezine erişilemiyor) planı adım adım konuşur. Eksik bir parola ya da eskimiş bir adım genellikle burada ortaya çıkar.

Microsoft'un çerçevesi de planın canlı bir belge olarak ele alınmasını ve ideal olarak altı ayda bir ilgili ekiplerle gözden geçirilmesini öneriyor. Yeni sunucu, yeni entegrasyon ya da hosting değişikliği gibi her mimari değişiklik de planı güncellemek için bir işarettir.

Otomasyon unutmayı önler ama sessiz arızayı önlemez. Yedekleme görevi başarısız olduğunda uyarı gelmeli; ayrıca yedek boyutu beklenmedik biçimde küçüldüğünde de alarm verilmeli. Boş bir yedek dosyası da kayıtlarda başarılı iş gibi görünebilir.

Paylaşımlı hosting, VPS ve bulut: sorumluluk kimde?

Paylaşımlı hostingde sağlayıcının aldığı yedek çoğu zaman sağlayıcının kendi altyapısını korumak içindir; saklama süresi ve geri yükleme koşulları hizmet sözleşmesinde yazar. Bu yedeğe güvenmekle yetinmeyin, kendi dış kopyanızı ayrıca tutun. VPS ve bulut sunucuda ise yedekleme büyük ölçüde sizin ya da hizmet aldığınız ekibin sorumluluğundadır: sağlayıcı donanımı korur, verinizi değil.

Kişisel veri içeren yedekler de kişisel veridir. Yedeklerin şifrelenmesi, erişimin kısıtlanması ve ne kadar süre saklanacağının tanımlanması, KVKK'nın veri güvenliği yükümlülüğü açısından da dikkat edilmesi gereken noktalardır.

Kısaca: kontrol listesi

• Her sistem için RPO ve RTO yazılı mı?
• Veritabanı, dosyalar ve sunucu yapılandırması yedeğin içinde mi?
• En az bir kopya başka bir konumda ve sunucudan silinemez durumda mı?
• Yedekler şifreli mi, anahtar ayrı bir yerde mi?
• Son geri yükleme testi ne zaman yapıldı ve ne kadar sürdü?
• Kurtarma belgesi sunucunun dışında erişilebilir mi?

Altyapınızın bu listede nerede eksik kaldığını birlikte gözden geçirmek isterseniz sunucu ve altyapı hizmetimize göz atabilir ya da doğrudan bizimle iletişime geçebilirsiniz.