Sunucunuzun Çökmesi İşinizi Durdurmasın: Verilerinizi Koruyun, İş Sürekliliğinizi Güvence Altına Alın.
Bir sabah ofise geldiğinizde şirket sunucusunun açılmadığını, çalışanların dosyalara erişemediğini, muhasebe programının çalışmadığını ve müşteri kayıtlarının görüntülenemediğini düşünün. İşletmeniz faaliyetlerine ne kadar sürede devam edebilir?
Şirketlerin günlük operasyonlarında kullandığı sunucular; müşteri bilgileri, muhasebe kayıtları, kurumsal dosyalar, e-posta sistemleri, web siteleri ve iş uygulamaları gibi kritik verileri barındırabilir. Bu sistemlerde meydana gelen bir arıza, yalnızca teknik bir sorun değildir. İş süreçlerinin aksamasına, müşteri kaybına, gelir kaybına ve operasyonel problemlere yol açabilir.
Üstelik sunucu arızası yaşandığında tek risk donanımın bozulması değildir. Siber saldırılar, fidye yazılımları, yanlışlıkla silinen dosyalar, elektrik kesintileri, yangın, su baskını ve yazılım hataları da şirket verilerinin erişilemez hâle gelmesine neden olabilir.
Bu nedenle işletmelerin yalnızca düzenli yedekleme yapması yeterli değildir. Yedeklerin güvenli biçimde saklanması, gerektiğinde geri yüklenebilmesi ve iş süreçlerinin hangi sürede yeniden başlatılacağının önceden planlanması gerekir.
Şirket Sunucusu Çökerse İşletmenizi Neler Bekler?
Sunucu arızasının işletmeye etkisi, kullanılan sistemlere ve sunucu üzerinde tutulan verilere göre değişir. Bazı işletmeler yalnızca belirli dosyalara erişemezken bazıları sipariş, satış, üretim veya muhasebe süreçlerini tamamen durdurmak zorunda kalabilir.
Örneğin:
- Muhasebe ve finans: Fatura, cari hesap, ödeme ve tahsilat kayıtlarına erişim kesilebilir.
- Satış ve müşteri yönetimi: CRM sistemleri çalışmadığında müşteri geçmişi ve satış süreçleri aksayabilir.
- E-ticaret: Siparişler, stok bilgileri ve ödeme süreçleri etkilenebilir.
- Üretim ve operasyon: Üretim planları, iş emirleri ve şirket içi uygulamalar kullanılamayabilir.
- Kurumsal iletişim: E-posta, dosya paylaşımı ve şirket içi iletişim sistemleri kesintiye uğrayabilir.
- Web sitesi ve dijital hizmetler: Şirketin çevrim içi hizmetleri erişilemez hâle gelebilir.
Burada önemli olan, sunucunun kaç saatte tamir edileceğinden çok, işletmenin kritik faaliyetlerine ne zaman devam edebileceğidir.
Bir donanım parçasının değiştirilmesi birkaç saat sürebilir. Ancak işletim sisteminin kurulması, uygulamaların yapılandırılması, veritabanlarının geri yüklenmesi ve sistemlerin test edilmesi çok daha uzun sürebilir.
Bu nedenle felaket kurtarma planı, arıza meydana geldikten sonra düşünülmemeli; önceden hazırlanmalıdır.
3-2-1 Yedekleme Kuralı Nedir?
3-2-1 yedekleme kuralı, işletmelerin verilerini tek bir cihazda veya tek bir konumda tutmaması için kullanılan temel veri koruma yaklaşımlarından biridir.
Kuralın mantığı oldukça basittir:
3 kopya, 2 farklı depolama türü, 1 farklı konum.
3 Kopya: Verilerinizin Üç Ayrı Kopyası Bulunsun
Önemli verilerinizin bir aslı ve en az iki yedek kopyası bulunmalıdır.
Örneğin şirketin ana sunucusunda bulunan verilerin:
- Birinci yedeği şirket içindeki ayrı bir depolama cihazında,
- İkinci yedeği ise farklı bir fiziksel konumda veya güvenli bir bulut depolama alanında tutulabilir.
Böylece ana sunucuda meydana gelen bir arıza, diğer kopyaların da kaybolduğu anlamına gelmez.
2 Farklı Depolama Türü: Bütün Yedekleri Aynı Yerde Tutmayın
Yedeklerin farklı depolama türlerinde bulunması, aynı türdeki bir arızanın bütün kopyaları etkileme ihtimalini azaltır.
Örneğin:
- Ağ bağlantılı depolama sistemi (NAS),
- Harici disk veya farklı bir fiziksel depolama ortamı,
- Güvenli bulut yedekleme hizmeti.
Burada amaç yalnızca farklı cihazlar kullanmak değil, ortak arıza noktalarını azaltmaktır. Aynı sunucuya bağlı iki disk, her durumda birbirinden bağımsız iki güvenli yedek anlamına gelmez.
1 Farklı Konum: Bir Yedek Şirket Dışında Bulunsun
Şirket binasında yangın, su baskını, hırsızlık veya fiziksel hasar yaşanması durumunda aynı binada bulunan bütün yedekler de kaybedilebilir.
Bu nedenle yedeklerden en az birinin farklı bir fiziksel konumda tutulması önemlidir.
Bu konum:
- Güvenli bir bulut depolama hizmeti,
- Başka bir veri merkezi,
- Şirketin ana lokasyonundan bağımsız güvenli bir depolama alanı olabilir.
Önemli: 3-2-1 kuralını uygulamak tek başına tam güvenlik sağlamaz. Yedeklerin şifrelenmesi, yetkisiz erişime karşı korunması, mümkünse değiştirilemez (immutable) veya çevrim dışı tutulması ve düzenli olarak test edilmesi de gerekir.
3-2-1 Yedekleme Kuralı Şirketinizi Fidye Yazılımlarından Korur mu?
Fidye yazılımları, işletmelerin dosyalarını ve sistemlerini şifreleyerek erişilemez hâle getirebilir. Saldırganlar bazı durumlarda yalnızca ana sunucuyu değil, ağa bağlı yedekleme sistemlerini de hedef alabilir.
Bu nedenle yedekleme sisteminin ana sunucudan tamamen bağımsız olduğunu varsaymak doğru değildir.
Daha güvenli bir yapı için şu önlemler değerlendirilmelidir:
- Yedekleme hesapları için güçlü ve ayrı erişim bilgileri kullanılmalı.
- Yönetici hesaplarında çok faktörlü kimlik doğrulama (MFA) etkinleştirilmeli.
- Yedekleme sistemlerine erişim yetkileri sınırlandırılmalı.
- Kritik yedekler mümkünse çevrim dışı veya değiştirilemez depolama alanlarında saklanmalı.
- Yedekleme ve geri yükleme işlemleri kayıt altına alınmalı.
- Yedekler belirli aralıklarla zararlı yazılım ve bütünlük kontrollerinden geçirilmeli.
Buradaki temel hedef, saldırganın ana sisteme erişmesi durumunda yedekleri de kolayca silememesi veya değiştirememesidir.
Felaket Kurtarma Planı Nedir?
Felaket kurtarma planı (Disaster Recovery Plan - DRP), bir işletmenin sunucu arızası, siber saldırı, veri kaybı veya fiziksel felaket gibi durumlarda bilgi teknolojileri altyapısını yeniden çalışır hâle getirmek için izleyeceği adımları belirleyen plandır.
Bu plan yalnızca yedeklerin nerede tutulduğunu açıklamaz. Hangi sistemin önce kurtarılacağını, kimin hangi sorumluluğu üstleneceğini, verilerin nasıl geri yükleneceğini ve işletmenin faaliyetlerine nasıl devam edeceğini de tanımlar.
İyi hazırlanmış bir felaket kurtarma planında şu başlıklar bulunmalıdır:
- Kritik sistemlerin belirlenmesi: İşletmenin çalışması için zorunlu olan sunucu, uygulama, veritabanı ve dosyalar listelenmelidir.
- Yedekleme politikasının oluşturulması: Hangi verinin ne sıklıkta yedekleneceği ve ne kadar süre saklanacağı belirlenmelidir.
- Alternatif altyapının hazırlanması: Ana sunucu kullanılamadığında sistemlerin hangi sunucu veya ortamda çalışacağı planlanmalıdır.
- Kurtarma sırasının belirlenmesi: Önce hangi sistemlerin devreye alınacağı tanımlanmalıdır.
- Görev ve sorumlulukların dağıtılması: Teknik ekip, yönetim ve ilgili çalışanların görevleri açıkça belirlenmelidir.
- Test ve kontrol süreçleri: Yedeklerin gerçekten geri yüklenebildiği düzenli olarak doğrulanmalıdır.
Unutulmaması gereken nokta şudur: Felaket kurtarma planı, yalnızca teknik ekibin bildiği bir doküman olarak kalmamalıdır. İlgili kişilerin ihtiyaç duyduklarında erişebileceği ve uygulayabileceği şekilde hazırlanmalıdır.
RTO ve RPO Nedir? İşletmeniz Kaç Saatlik Kesintiyi Kaldırabilir?
Felaket kurtarma planında iki önemli kavram bulunur: RTO ve RPO.
Bu iki kavram, işletmenin ne kadar süre kesintiye dayanabileceğini ve ne kadar veri kaybını kabul edebileceğini belirlemeye yardımcı olur.
RTO: Sistemleriniz Ne Kadar Sürede Açılmalı?
RTO (Recovery Time Objective), bir sistemin kesintiye uğramasından sonra kabul edilebilir en uzun geri dönüş süresini ifade eder.
Örneğin işletmenizin muhasebe sistemine yönelik RTO hedefi 4 saat olarak belirlenmişse, kesinti sonrasında bu sistemin en geç 4 saat içinde yeniden kullanılabilir hâle getirilmesi hedeflenir.
RTO belirlenirken şu sorular sorulmalıdır:
- İşletme bu sistem olmadan kaç saat çalışabilir?
- Sistemin kapalı kalması hangi süreçleri etkiler?
- Alternatif bir çalışma yöntemi var mı?
- Sistemin yeniden çalışması için hangi teknik kaynaklara ihtiyaç var?
RPO: En Fazla Ne Kadar Veri Kaybını Kabul Edebilirsiniz?
RPO (Recovery Point Objective), bir kesinti sonrasında kabul edilebilecek en fazla veri kaybı süresini ifade eder.
Örneğin RPO hedefiniz 2 saat ise, bir arıza meydana geldiğinde son kurtarma noktasına göre en fazla 2 saatlik veri kaybını kabul edebilecek şekilde bir yedekleme veya veri çoğaltma sistemi planlamanız gerekir.
RPO hedefi, yedekleme sıklığının belirlenmesinde önemli rol oynar.
Örneğin:
- 24 saatlik RPO: Günlük yedekleme yaklaşımı yeterli olabilir.
- 4 saatlik RPO: Daha sık yedekleme gerekir.
- 15 dakikalık RPO: Daha sık yedekleme veya sürekli veri çoğaltma gibi çözümler değerlendirilebilir.
Bunlar örnek hedeflerdir. Gerçek yedekleme sıklığı; veri değişim hızı, sistem mimarisi, iş ihtiyaçları ve kurtarma teknolojisine göre belirlenmelidir.
RTO ile RPO arasındaki farkı unutmayın: RTO sistemin ne kadar sürede yeniden çalışacağını, RPO ise ne kadar geriye dönük verinin kaybedilebileceğini ifade eder.
İşletmeler İçin Örnek Felaket Kurtarma Senaryosu
Bir şirketin ana sunucusunun gece saatlerinde donanımsal arıza nedeniyle tamamen devre dışı kaldığını düşünelim.
Bu sunucuda muhasebe programı, müşteri kayıtları, şirket dosyaları ve bazı iş uygulamaları çalışıyor olsun.
Önceden hazırlanmış bir kurtarma planı kapsamında süreç şu şekilde ilerleyebilir:
1. Arızanın Tespit Edilmesi
Teknik ekip sunucudaki arızayı tespit eder. Sorunun donanımdan mı, yazılımdan mı yoksa siber saldırıdan mı kaynaklandığı incelenir.
2. Etki Analizi ve Önceliklendirme
Hangi sistemlerin kullanılamadığı ve hangi iş süreçlerinin etkilendiği belirlenir. Kritik sistemler öncelik sırasına alınır.
3. Yedeklerin Kontrol Edilmesi
Yedekleme kayıtları incelenir. Son başarılı yedekleme zamanı, yedeklerin bütünlüğü ve kullanılabilirliği kontrol edilir.
4. Alternatif Ortamın Hazırlanması
Önceden planlanmış kurtarma ortamı veya uygun alternatif sunucu hazırlanır. İşletim sistemi, gerekli uygulamalar, ağ bağlantıları ve güvenlik ayarları yapılandırılır.
5. Verilerin Geri Yüklenmesi
Öncelikli veritabanları, dosyalar ve uygulama verileri yedeklerden geri yüklenir. Geri yükleme işleminin ardından veri tutarlılığı kontrol edilir.
6. Sistemlerin Test Edilmesi
Uygulamaların açılması tek başına yeterli değildir. Kullanıcı girişleri, veri erişimi, bağlantılar ve kritik iş akışları kontrol edilir.
7. İş Süreçlerinin Yeniden Başlatılması
Kritik sistemlerin kullanılabilir olduğu doğrulandıktan sonra çalışanlar bilgilendirilir ve operasyonlar kontrollü biçimde yeniden başlatılır.
Bu örnekte kurtarma süresinin birkaç saat mi yoksa birkaç gün mü olacağı; yedeklerin durumuna, altyapıya, veri miktarına ve önceden yapılan hazırlıklara bağlıdır. Önceden test edilmemiş bir yedekten hızlı ve sorunsuz geri dönüş beklemek gerçekçi değildir.
Şirketiniz İçin Felaket Kurtarma Planı Nasıl Hazırlanmalı?
Her işletmenin altyapısı ve iş öncelikleri farklıdır. Bu nedenle her şirkete aynı yedekleme sıklığını veya aynı kurtarma süresini önermek doğru değildir.
İlk olarak işletmenin hangi sistemler olmadan faaliyetlerini sürdüremeyeceği belirlenmelidir.
Aşağıdaki kontrol listesi başlangıç için kullanılabilir:
- Şirketin kritik verileri ve sistemleri listelendi mi?
- Sunucu, veritabanı ve dosyalar düzenli olarak yedekleniyor mu?
- 3-2-1 yedekleme yaklaşımı uygulanıyor mu?
- Yedeklerden biri farklı bir fiziksel konumda tutuluyor mu?
- Yedekler şifreleniyor ve yetkisiz erişime karşı korunuyor mu?
- Çevrim dışı veya değiştirilemez yedek kopyası bulunuyor mu?
- Yedeklerin geri yüklenmesi düzenli olarak test ediliyor mu?
- RTO ve RPO hedefleri belirlendi mi?
- Sunucu devre dışı kaldığında kullanılacak alternatif altyapı hazır mı?
- Teknik ekip ve yönetimin sorumlulukları tanımlandı mı?
- Acil durumda ulaşılacak teknik destek ve hizmet sağlayıcı bilgileri mevcut mu?
Bu maddelerin tamamına olumlu yanıt veremiyorsanız işletmenizin mevcut yedekleme ve kurtarma süreçlerini yeniden değerlendirmeniz faydalı olacaktır.
Yedekleme Yapmak ile Felaket Kurtarma Planına Sahip Olmak Aynı Şey Değildir
Yedekleme, verilerin kaybolması durumunda kullanılabilecek kopyalar oluşturur. Felaket kurtarma ise sistemleri, uygulamaları ve iş süreçlerini yeniden çalışır hâle getirmek için gereken bütün adımları kapsar.
Örneğin şirketinizin veritabanı her gece yedekleniyor olabilir. Ancak sunucunuz tamamen bozulduğunda yeni bir sunucuya işletim sistemi kurulması, uygulamaların yapılandırılması, lisansların hazırlanması ve verilerin geri yüklenmesi gerekebilir.
Dolayısıyla yalnızca yedekleme yapılması, işletmenin kısa sürede faaliyete döneceği anlamına gelmez.
İş sürekliliği için yedekleme, güvenlik, alternatif altyapı, teknik destek ve düzenli kurtarma testleri birlikte değerlendirilmelidir.
Sıkça Sorulan Sorular
3-2-1 yedekleme kuralı zorunlu mudur? ▼
3-2-1 kuralı, verilerin korunması için yaygın olarak önerilen bir en iyi uygulamadır. Her işletme için aynı şekilde uygulanması zorunlu değildir; ancak birden fazla kopya bulundurmak, farklı depolama ortamlarından yararlanmak ve bir kopyayı farklı konumda tutmak veri kaybı riskini azaltmaya yardımcı olur.
Şirket sunucusu çökerse veriler tamamen kaybolur mu? ▼
Hayır. Sunucu arızası her zaman veri kaybı anlamına gelmez. Verilerin kurtarılması; disklerin fiziksel durumuna, arızanın türüne, yedeklerin bulunup bulunmadığına ve yedeklerin bütünlüğüne bağlıdır. Güncel ve test edilmiş yedekler kurtarma ihtimalini artırır.
Bulut yedekleme yapmak tek başına yeterli midir? ▼
Her durumda yeterli değildir. Bulut yedekleme, farklı konumda kopya bulundurmak açısından faydalı olabilir. Ancak erişim güvenliği, şifreleme, saklama politikası, silinmeye karşı koruma ve geri yükleme testleri de değerlendirilmelidir.
Yedekler ne sıklıkla alınmalıdır? ▼
Yedekleme sıklığı, işletmenin veri kaybına ne kadar dayanabileceğine göre belirlenmelidir. Gün içinde sürekli veri üreten bir işletmenin ihtiyaçları ile haftada birkaç kez dosya güncelleyen bir işletmenin ihtiyaçları aynı değildir. RPO hedefi bu sıklığın belirlenmesine yardımcı olur.
Felaket kurtarma testi neden önemlidir? ▼
Bir yedeğin başarılı şekilde oluşturulmuş olması, gerektiğinde sorunsuz geri yükleneceğini garanti etmez. Kurtarma testi; yedeklerin kullanılabilirliğini, teknik adımların doğruluğunu ve hedeflenen RTO/RPO değerlerine ulaşılıp ulaşılamadığını görmeye yardımcı olur.
Küçük işletmelerin de felaket kurtarma planına ihtiyacı var mı? ▼
Evet. Küçük işletmeler de müşteri bilgileri, muhasebe kayıtları, siparişler ve kurumsal dosyalar gibi kritik veriler kullanır. Büyük ölçekli bir kurtarma altyapısı her zaman gerekli olmayabilir; ancak işletmenin ihtiyaçlarına uygun, uygulanabilir bir yedekleme ve kurtarma planı bulunmalıdır.
Sonuç: İşletmenizin Verileri Kadar İş Sürekliliğini de Koruyun
Şirket sunucusunun ne zaman arızalanacağını veya bir siber saldırının ne zaman gerçekleşeceğini önceden bilmek mümkün değildir. Ancak böyle bir durum yaşandığında işletmenin nasıl hareket edeceğini önceden planlamak mümkündür.
3-2-1 yedekleme kuralı, verilerin birden fazla kopyayla korunmasına yardımcı olur. RTO ve RPO hedefleri, kabul edilebilir kesinti ve veri kaybı sınırlarını belirler. Felaket kurtarma planı ise bu hedeflere ulaşmak için uygulanacak teknik ve operasyonel adımları ortaya koyar.
İnotek olarak işletmenizin sunucu altyapısını, veri yedekleme ihtiyaçlarını ve bilgi teknolojileri güvenliğini birlikte değerlendirerek daha sürdürülebilir bir iş sürekliliği yaklaşımı oluşturmanıza destek olabiliriz.
Sunucu altyapınızın olası bir arıza karşısında ne kadar sürede yeniden çalışabileceğini öğrenmek ve işletmenize uygun yedekleme ve felaket kurtarma seçeneklerini değerlendirmek için İnotek ile iletişime geçin.
