3-2-1 Yedekleme Kuralı ve Geri Yükleme Testi Neden Şart?

Yedekleme konuşmalarında iki cümleyi çok sık duyarız: "Bizim yedeğimiz var" ve "Yedekten dönmeye hiç ihtiyacımız olmadı." İkinci cümle çoğu zaman birincisinin hiç sınanmadığı anlamına gelir. Yedekleme yazılımı her sabah "başarılı" raporu gönderirken kopyaların eksik, bozuk ya da açılamaz durumda olduğu, ne yazık ki ancak geri dönülmeye çalışıldığında anlaşılır.

Bu yazıda önce 3-2-1 kuralını, sonra kuralın bugünkü tehditlere göre genişletilmiş hâlini, en sonda da yedeğin gerçekten işe yaradığını kanıtlamanın tek yolu olan geri yükleme testini ele alıyoruz.

3-2-1 kuralı nedir?

3-2-1, veri kaybına karşı uzun zamandır kullanılan, basit ve akılda kalıcı bir kuraldır:

Üç kopya, verinin kendisi dahil toplam üç kopyanın bulunması demektir; biri bozulduğunda geriye iki seçenek kalır. İki farklı ortam, kopyaların aynı tür arızaya birlikte yakalanmaması içindir: örneğin biri yedekleme sunucusunun disklerinde, diğeri nesne depolamada ya da teypte durur. Bir dış kopya ise yangın, su baskını ya da hırsızlık gibi binayı bütünüyle etkileyen olaylara karşı korur.

RAID, senkronizasyon ve snapshot yedek değildir

3-2-1'i uyguladığını düşünen pek çok kurum, aslında yedek yerine yedekliliğe güvenir. Aradaki fark kötü günde ortaya çıkar.

• RAID bir diskin arızalanmasına karşı korur; yanlışlıkla silinen dosyaya, bozulan veritabanına ya da fidye yazılımına karşı korumaz. Silme ve şifreleme işlemi bütün disklere aynı anda yazılır.
• Bulut senkronizasyonu değişiklikleri anında karşıya taşır; şifrelenen dosyalar da şifreli hâliyle eşitlenir. Sürüm geçmişi bir ölçüde kurtarıcıdır, ama saklama süresi ve kapsamı sınırlıdır.
• Anlık görüntüler (snapshot) hızlı geri dönüş için çok değerlidir; ancak aynı depolama sistemindeyse o sistemle birlikte kaybolur. Snapshot yedeğin yerine değil, yanına konmalıdır.

Fidye yazılımı çağında 3-2-1-1-0

Bugünkü fidye yazılımı saldırıları yalnızca sunuculara değil, ağdan erişebildikleri yedeklere de yönelir. Yönetici yetkisini ele geçiren bir saldırgan, yedekleme sunucusundaki kopyaları silebilir ya da şifreleyebilir. Bu yüzden kural genişletilerek 3-2-1-1-0 biçiminde anılmaya başlandı:

• Ek "1": değişmez ya da çevrimdışı kopya. Kopyalardan en az biri ya belirli bir süre boyunca silinemez ve değiştirilemez olmalı (immutable; örneğin nesne kilitleme özellikli depolama ya da sertleştirilmiş bir yedek deposu) ya da ağdan fiziksel olarak ayrılmış olmalı (air-gapped; örneğin rafta bekleyen teyp ya da dönüşümlü çıkarılan disk).
• "0": doğrulamada sıfır hata. Yedeklerin bütünlüğü otomatik olarak kontrol edilmeli, geri yükleme testleri hatasız tamamlanmalıdır.

Değişmez kopyayı gerçekten değişmez kılan şey erişim ayrımıdır. Yedekleme sistemi için etki alanı yönetici hesabından ayrı hesaplar, çok faktörlü kimlik doğrulama ve mümkünse ayrı bir yönetim ağı kullanılmalıdır. Diğer koruma katmanlarını ransomware'e karşı 7 katmanlı savunma yazımızda anlattık.

RPO ve RTO: planı iş hedefinden başlatın

"Her gece yedek alıyoruz" bir plan değil, bir alışkanlıktır. Plan, iki soruya verilen cevaplardan çıkar:

• RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? Yalnızca gece yedeği alınan bir sistemde, öğleden sonra yaşanan bir arıza o günün bütün verisini kaybettirebilir.
• RTO (Recovery Time Objective): Sistem en geç ne kadar sürede yeniden çalışmalı? Bu süre yalnızca verinin kopyalanmasını değil; sunucunun hazırlanmasını, uygulamanın açılmasını ve kontrolleri de kapsar.

Aşağıdaki tablo, hedeflerin sisteme göre nasıl farklılaşabileceğini göstermek için hazırlanmış bir örnektir. Değerler her işletmenin kendi ihtiyacına göre belirlenmelidir.

Hedefler belirlendikten sonra yedek sıklığı, saklama süresi ve kurtarma yöntemi bu hedeflere göre seçilir. RTO'su birkaç saat olan bir sistemi, internet üzerinden yavaşça indirilen bir arşivden geri getirmeye çalışmak hedefi kendiliğinden aşar. Bu hedefleri sistem sistem nasıl belirlediğimizi yedekleme ve felaket kurtarma sayfamızda anlattık.

Saklama süresi ve şifreleme

Saklama (retention), geriye doğru kaç noktaya dönebileceğinizi belirler. Yaygın yöntem; günlük, haftalık ve aylık kopyaların farklı sürelerle tutulduğu döngüdür (GFS, büyükbaba–baba–oğul). Böylece hem dünkü hem de aylar önceki duruma dönülebilir. Bu önemlidir, çünkü bir dosyanın bozulduğu ya da bir saldırganın sisteme girdiği an, fark edildiği andan çok önce olabilir.

Saklama süresini uzatmak her zaman iyi değildir. Yedekler de kişisel veri içerir ve 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındaki saklama ve imha yükümlülükleri açısından yedekler de değerlendirmeye dahildir. Saklama sürelerini kurumunuzun kişisel veri saklama ve imha politikasıyla uyumlu hâle getirin.

Bina dışına çıkan her yedek şifrelenmelidir. Burada sık atlanan bir nokta vardır: şifreleme anahtarı ya da parolası yedekle aynı yerde tutulursa koruma anlamsızlaşır; hiçbir yerde güvenle saklanmazsa yedek açılamaz. Anahtarın nerede ve kimde durduğu yazılı olmalıdır.

Geri yükleme testi neden şart?

Yedekleme yazılımının "başarılı" demesi, yalnızca kopyalama işinin hatasız bittiğini gösterir. Geri dönüşü engelleyen sorunlar ise genellikle başka yerdedir:

• Sonradan eklenen bir sunucu ya da klasör yedek kapsamına alınmamıştır.
• Veritabanı, uygulama tutarlılığı sağlanmadan kopyalanmıştır; dosyalar yerindedir ama veritabanı açılmaz.
• Yedek dosyaları ya da medyası zamanla bozulmuştur.
• Şifreleme parolası, lisans dosyası ya da yedekleme sunucusunun yapılandırması kayıptır.
• Geri dönüş beklenenden çok uzun sürer; örneğin terabaytlarca verinin internetten indirilmesi günler alabilir.
• Sistem tek başına geri gelir, ama bağlı olduğu kimlik doğrulama, DNS ya da lisans sunucusu ortada yoktur.

Bunların hiçbiri yedekleme raporunda görünmez. Yalnızca gerçek bir geri yükleme denemesi gösterir.

Geri yükleme testi nasıl yapılır?

Testin amacı "dosya açılıyor mu?" sorusundan ibaret değildir; RTO hedefinin tutup tutmadığını ölçmek ve süreci ekipçe prova etmektir. Aşağıdaki sıklıklar bir başlangıç önerisidir; kritik sistemlerde test daha sık yapılabilir.

1. Kapsamı değiştirin. Her testte farklı bir sistem ve farklı bir tarih seçin. Hep aynı küçük klasörü geri yüklemek bir şey kanıtlamaz.
2. Yalıtılmış ortam kullanın. Tam sunucu geri yüklemelerini canlı ağdan ayrılmış bir ortamda yapın; geri gelen sunucu canlı sistemle çakışmamalıdır.
3. Süreyi ölçün. Başlangıç ve bitiş saatini kaydedin, sonucu RTO hedefiyle karşılaştırın.
4. Uygulama düzeyinde doğrulayın. Veritabanı açılıyor mu, uygulamaya giriş yapılabiliyor mu, son kayıtlar beklenen tarihte mi? Bu kontrolü sistemi kullanan birim de yapsın.
5. Belgeleyin ve düzeltin. Her test; tarih, kapsam, süre, karşılaşılan sorunlar ve alınan önlemlerle kısa bir kayda dönüşmeli. Başarısız bir test kayıp değildir; gerçek bir felaketten önce bulunmuş bir açıktır.

Sık sorulan sorular