Çözüm Seçimi Hakkında Sıkça Sorulan Sorular

MLPS uyumluluğu, fidye yazılımı koruması, yerli teknoloji uyarlaması ve felaket kurtarma mimarisi hakkında sıkça sorulan sorular

MLPS 2.0 Seviye 3'ün veri yedekleme ve felaket kurtarma için özel teknik gereksinimleri nelerdir?

MLPS 2.0 Seviye 3'ün yedekleme gereksinimleri «veri yedekleme ve geri yükleme», «artık bilgi koruması», «ağ güvenliği», «ana makine güvenliği» gibi birden fazla kontrol noktasına dağılmıştır ve özünde dört maddeye indirgenebilir: yerel veri yedekleme ve geri yükleme, önemli verilerin uzak konumda yedeklenmesi, yedek verilerin şifrelenerek gizliliğinin sağlanması, düzenli geri yükleme tatbikatları. En sık puan kaybettiren durumlar yalnızca yerel yedekleme olup uzak yedekleme bulunmaması ve geri yükleme doğrulamasının hiç yapılmamasıdır. Uyumluluğu sağlayan teknik yöntemler genellikle CDP, değiştirilemez depolama ve iki konum üç veri merkezi içerir.

Fidye yazılımı üretim verilerini şifrelerse, yedek veriler hâlâ geri yüklenebilir mi? Nasıl önlenir?

Geri yüklenip yüklenemeyeceği, yedek verilerin de şifrelenip şifrelenmediğine bağlıdır. Fidye yazılımı koruması genellikle üç katmanlı savunmaya dayanır: birincisi, değiştirilemez depolama (WORM) sayesinde yedek veriler yazıldıktan sonra değiştirilemez; ikincisi, mavi lazer disk depolamanın fiziksel hava boşluğu izolasyonu ile çevrimdışı verilere fidye yazılımı erişemez; üçüncüsü, güvenlik yetenekleriyle bütünleşerek yedekleme öncesi kötü amaçlı yazılım otomatik olarak tespit edilir. Rebei Cloud yedekleme cihazı bu üç katmanlı mekanizmayı kullanarak «yedekleyebilmek»ten «yedekleme yani güvenlik» seviyesine yükselir.

Yerli teknoloji ekosisteminde felaket kurtarma nasıl yapılır?

Xinchuang ortamında felaket kurtarmanın anahtarı, üreticinin yerli CPU, işletim sistemi ve veritabanlarında orijinal üretici sertifikalı uyumluluğu olup olmadığını doğrulamaktır; "bağlanabiliyorsa destekliyor sayılır" anlayışı değil. Sıcak yedekleme bulut, Kunpeng, Phytium, Hygon, Loongson, Zhaoxin, Sunway olmak üzere 6 tür yerli CPU, 10 tür yerli işletim sistemi (Kylin Software, NeoKylin, UOS, openEuler, Zhongke Fangde, Ningsi, Puhua, Deepin, Red Flag, Anolis OS) ve DM, Kingbase, GBase, ShenTong, HighGo, Yunhe Enmo, CS&S, EsgynDB, Wanli olmak üzere 9 tür yerli veritabanının uyumluluk sertifikasyonunu tamamlamıştır.

Felaket kurtarma merkezi aynı şehirde mi yoksa farklı şehirde mi kurulmalı? Mesafe nasıl belirlenir?

MLPS standardı «kaç kilometre olmalı» diye bir kural koymaz, yalnızca «farklı konum» şartını arar. Değerlendirme pratiği ve sektör geleneği genellikle iki noktaya bakar: yedekleme merkezi ile üretim merkezi aynı fiziksel konumda olmamalıdır ki aynı yangın, elektrik kesintisi veya doğal afetin etkisinden kaçınılabilsin; mesafe açısından sektör pratiği genellikle aynı şehirde onlarca kilometreden başlamayı, kritik sistemler için şehirler arası yüzlerce kilometre ve üzerini önerir. Aynı şehir «hızı», farklı şehir «mesafeyi» çözer; ikisi birlikte kullanılır.

Yedekleme cihazı ile saf yazılım yedekleme çözümü arasında kuruluşlar nasıl seçim yapmalı?

İkisi arasındaki temel fark kurulum ve işletim sorumluluğundadır. Yedekleme cihazı donanım ve yazılımı bir arada sunar, fabrika çıkışı önceden kuruludur, kurulum süresi saat düzeyindedir ve işletim tek bir üreticinin sorumluluğundadır; saf yazılım çözümü ise sunucunun kendisinin tedarik edilmesini gerektirir, kurulum günler sürer, yazılım ve donanım sorumluluğu ayrıdır ve işletim karmaşıklığı yüksektir. Seçim yaparken yalnızca başlangıç satın alma fiyatına değil, 3-5 yıllık toplam sahip olma maliyetine (donanım + yazılım lisansı + işletim + bakım) bakılmalıdır. Üretimdeki kritik veriler için genellikle yedekleme cihazı daha uygundur.

MLPS değerlendirmesinde felaket kurtarma bölümünde en çok puan kaybettiren yer neresidir?

MLPS Seviye 3'te en sık puan kaybettiren şey «yedekleme cihazı alınmamış olması» değil, üç durumdur: yalnızca yerel yedekleme olup uzak yedekleme bulunmaması; geri yükleme tatbikatının hiç yapılmaması ve yedeklemenin «ölü yedekleme» hâline gelmesi; yedek verilerin düz metin olarak saklanması ve şifrelenmemesi. Ayrıca yedekleme ortamının üretim verileriyle aynı odada bulunması, yedekleme işlem yetkilerinin en aza indirilmemiş olması ve yanlışlıkla silme ile değiştirmeye karşı mekanizmaların eksikliği de sık görülen puan kaybı noktalarıdır.

İki konum üç veri merkezi mimarisi somut olarak nasıl hayata geçirilir? KOBİ'ler için basitleştirilmiş bir sürümü var mı?

İki konum üç veri merkezi, iki coğrafi bölge ve üç veri merkezi anlamına gelir: üretim merkezi, aynı şehirdeki felaket kurtarma merkezi (veri merkezi düzeyindeki arızalara karşı) ve farklı şehirdeki felaket kurtarma merkezi (şehir düzeyindeki felaketlere karşı). Hayata geçirmede kilit nokta, önce RPO/RTO hedeflerini belirleyip mimariyi buna göre geriye doğru kurgulamaktır; veri senkronizasyonunda aynı şehirde senkron replikasyon, farklı şehirde asenkron replikasyon kullanılır ve saniye düzeyinde RPO için CDP devreye girer. Maliyetin büyük kısmı farklı şehir bağlantı bant genişliği ve felaket kurtarma merkezi kurulumundadır; felaket kurtarma merkezinin düşük yapılandırmayla kurulması, farklı şehirde bulut kaynaklarının kiralanması ve işletim gerektirmeyen entegre cihazların seçilmesiyle maliyet kontrol altına alınabilir.

Yedek veriler denetim gereksinimlerini karşılayacak şekilde nasıl şifrelenir ve değiştirilmeye karşı korunur?

Genellikle iki yönden ele alınır: şifreleme tarafında, yedek veriler uçtan uca AES-256 ile şifrelenir ve şifreli olarak saklanır, böylece MLPS'in yedekleme gizliliği gereksinimi karşılanır; değiştirmeye karşı koruma tarafında, değiştirilemez depolama (WORM, bir kez yazılır birden çok kez okunur) kullanılır, yedek veriler yazıldıktan sonra değiştirilemez ve buna mavi lazer disk depolamanın fiziksel hava boşluğuyla çevrimdışı arşivlemesi eklenerek fidye yazılımına karşı son savunma katmanı oluşturulur.