- (0224) 322 22 90
- info@bursabilgisayar.tr
Bir işletmenin IT altyapısındaki en büyük risklerden biri sistemlerin arızalanması değil, arıza sonrasında ne yapılacağının bilinmemesidir.
Sunucunun tamamen bozulması, fidye yazılımı saldırısı, depolama sisteminin kaybedilmesi, elektrik problemi, yangın, su baskını veya fiziksel lokasyona erişilememesi durumunda kritik sistemlerin saatler hatta günler boyunca kullanılamaması işletmenin faaliyetlerini ciddi şekilde etkileyebilir.
Bursa Bilgisayar olarak Bursa felaket kurtarma ve Disaster Recovery hizmetimiz kapsamında işletmelerin kritik sunucu, veri, uygulama ve network sistemlerini analiz ediyor; olası bir felaket sonrasında sistemlerin hangi sırayla ve ne kadar sürede yeniden çalıştırılacağını planlıyoruz.
Amacımız yalnızca yedek almak değil, “Sunucu tamamen kaybolursa işletmeyi nasıl tekrar çalıştıracağız?” sorusunun teknik cevabını oluşturmaktır.
Felaket kurtarma veya Disaster Recovery (DR), işletmenin kritik IT sistemlerinin ciddi bir arıza veya felaket sonrasında yeniden çalışır hale getirilmesi için oluşturulan teknik altyapı ve prosedürlerin bütünüdür.
Felaket kurtarma kapsamında;
birlikte değerlendirilir.
Çünkü yalnızca sunucuyu geri yüklemek her zaman işletmenin tekrar çalışması için yeterli değildir.
İşletmenin mevcut altyapısına göre;
hizmetleri sunuyoruz.
Yedekleme ve felaket kurtarma birbirine bağlıdır ancak aynı şey değildir.
Yedekleme:
Verinin başka bir kopyasının oluşturulmasıdır.
Felaket Kurtarma:
Bu yedekleri ve alternatif altyapıları kullanarak işletmenin kritik sistemlerini yeniden çalışır hale getirme sürecidir.
Örneğin 5 TB sunucu yedeğiniz olabilir.
Ancak sunucu tamamen arızalandığında;
Yedeği hangi cihaza yükleyeceksiniz?
Ne kadar sürede geri yükleyeceksiniz?
Active Directory nasıl çalışacak?
Kullanıcılar ERP’ye nasıl bağlanacak?
Firewall ve VPN nasıl devreye alınacak?
sorularının cevabı yoksa yalnızca backup bulunması yeterli değildir.
Felaket yalnızca yangın veya deprem gibi fiziksel olaylar değildir.
IT açısından;
gibi olaylar da felaket senaryosu olabilir.
İş sürekliliği, bir problem yaşandığında işletmenin kritik faaliyetlerinin kabul edilebilir seviyede devam ettirilebilmesini hedefler.
Disaster Recovery ise iş sürekliliğinin IT tarafındaki önemli bileşenlerinden biridir.
Örneğin ERP sistemi tamamen durmuşsa işletmenin satış, üretim veya sevkiyat operasyonları da durabilir.
Bu nedenle hangi sistemlerin işletme için kritik olduğu önceden belirlenmelidir.
Her sistem aynı öneme sahip değildir.
Örneğin bir fabrikada;
ERP → Çok kritik
Active Directory → Çok kritik
SQL Server → Çok kritik
File Server → Kritik
Arşiv Sunucusu → Daha düşük öncelik
olabilir.
Felaket kurtarma planında sistemlerin geri dönüş sırası buna göre belirlenebilir.
RPO – Recovery Point Objective, işletmenin kabul edebileceği maksimum veri kaybını ifade eder.
Örneğin ERP veritabanının RPO değeri 1 saat ise sistemde en fazla son 1 saatlik verinin kaybedilmesi kabul edilebilir anlamına gelir.
Bu durumda günde bir kez backup almak yeterli olmayacaktır.
RPO hedefi backup ve replikasyon sıklığını doğrudan etkiler.
RTO – Recovery Time Objective, bir sistemin felaket sonrasında ne kadar sürede tekrar çalışır hale gelmesi gerektiğini ifade eder.
Örneğin;
ERP → RTO 2 saat
File Server → RTO 4 saat
Arşiv → RTO 24 saat
şeklinde farklı hedefler oluşturulabilir.
RTO ne kadar kısa olursa ihtiyaç duyulan altyapının maliyeti de genellikle artar.
Felaket kurtarma sistemi tasarlarken “verilerimiz kaybolmasın” demek tek başına yeterli değildir.
Şu iki sorunun cevaplanması gerekir:
En fazla ne kadar veri kaybedebiliriz?
En fazla ne kadar süre çalışmadan kalabiliriz?
Bu cevaplar kullanılacak backup, replikasyon, ikinci sunucu ve bulut altyapısını belirler.
Fiziksel sunucu tamamen arızalandığında işletmenin günlerce yeni donanım beklememesi için alternatif kurtarma senaryoları oluşturulabilir.
Örneğin;
Fiziksel Sunucu
↓
Günlük Image Backup
↓
NAS / Backup Server
↓
Geçici Sanal Sunucu
şeklinde bir yapı oluşturulabilir.
Donanım arızasında backup geçici sanallaştırma altyapısında çalıştırılabilir.
Hyper-V veya Proxmox kullanılan işletmelerde sanal makinelerin yedeklenmesi fiziksel sunuculara göre kurtarma sürecini kolaylaştırabilir.
VM’nin;
birlikte geri yüklenebilir.
Bu nedenle sanallaştırma doğru planlandığında Disaster Recovery açısından önemli avantaj sağlayabilir.
Hyper-V ortamındaki kritik sanal makineler düzenli olarak yedeklenebilir veya uygun altyapılarda farklı hostlara replike edilebilir.
Ana Hyper-V host arızalandığında kritik VM’lerin alternatif host üzerinde devreye alınması planlanabilir.
Ancak bunun için ikinci hostun yeterli CPU, RAM ve storage kapasitesine sahip olması gerekir.
Proxmox kullanan işletmelerde;
gibi farklı yöntemler değerlendirilebilir.
Kritik sistemlerde yalnızca aynı Proxmox host üzerindeki snapshotlara güvenilmemelidir.
Proxmox sanallaştırma altyapısında uygun projelerde Proxmox Backup Server ayrı bir backup katmanı olarak kullanılabilir.
VM ve container yedekleri farklı storage üzerinde saklanabilir.
Ana Proxmox sunucunun kaybedilmesi durumunda yedeklerden alternatif sisteme geri dönüş planlanabilir.
Active Directory kaybı işletmenin kullanıcı girişlerini ve birçok kurumsal servisi etkileyebilir.
Bu nedenle kritik yapılarda;
değerlendirilebilir.
İki Domain Controller’ın aynı fiziksel host üzerinde bulunması fiziksel host arızasına karşı gerçek yedeklilik sağlamaz.
İşletmenin yapısına göre ikinci Domain Controller farklı fiziksel veya sanal host üzerinde konumlandırılabilir.
Ana Domain Controller arızalandığında kullanıcı kimlik doğrulama ve DNS servislerinin tamamen durması önlenebilir.
Bu yapı backup’ın yerine geçmez ancak servis sürekliliğini artırabilir.
ERP sistemleri birçok işletmede en kritik uygulamalar arasındadır.
ERP Disaster Recovery planında;
birlikte değerlendirilmelidir.
Sadece ERP veritabanının yedeğinin bulunması tüm uygulamanın hemen çalışacağı anlamına gelmez.
SQL Server, PostgreSQL veya MySQL gibi kritik veritabanları için backup sıklığı veri kaybı toleransına göre belirlenmelidir.
İhtiyaca göre;
gibi yöntemler kullanılabilir.
Amaç kritik veritabanlarının mümkün olan en güncel noktaya geri getirilebilmesidir.
File Server tamamen kaybedildiğinde yalnızca dosyaların değil;
geri yüklenmesi gerekebilir.
Bu nedenle dosya sunucusu backup sistemi yetkileri de koruyacak şekilde planlanmalıdır.
NAS cihazı RAID kullanıyor olsa bile cihazın tamamı kaybedilebilir.
Örneğin;
durumunda RAID tek başına koruma sağlamaz.
Kritik NAS verileri ikinci bir sisteme yedeklenmelidir.
İki farklı NAS arasında veri replikasyonu veya yedekleme yapılabilir.
Örneğin:
Bursa Merkez NAS
↓
Şube / İkinci Lokasyon NAS
Bu yapı lokasyon bazlı felaketlere karşı veri kopyası oluşturabilir.
Ancak senkronizasyon ile backup aynı şey değildir. Silinen veya şifrelenen dosyanın karşı sisteme de aktarılabileceği dikkate alınmalıdır.
Off-site backup, yedeklerin ana sistemden farklı fiziksel lokasyonda tutulmasıdır.
Örneğin;
Ana Sunucu → Lokal NAS → Farklı Lokasyon Backup
şeklinde yapı oluşturulabilir.
Bu yöntem yangın, hırsızlık ve fiziksel tesis kaybı gibi senaryolara karşı önemlidir.
Bazı işletmelerde kritik sistemlerin backup veya replikaları bulut ortamında tutulabilir.
Ana lokasyon kaybedildiğinde bulut altyapısında geçici veya kalıcı sistemler devreye alınabilir.
Ancak bulut Disaster Recovery planında;
birlikte değerlendirilmelidir.
Kritik işletmelerde ikinci bir fiziksel lokasyon Disaster Recovery amacıyla kullanılabilir.
Örneğin;
Merkez Ofis – Bursa
↓
VPN / Replikasyon
↓
Fabrika veya Şube
İkinci lokasyonda backup NAS, sunucu veya uygun sanallaştırma kapasitesi bulunabilir.
Felaket kurtarma altyapıları hazır olma seviyelerine göre farklı modellerde planlanabilir.
Hot Site
Alternatif sistemler sürekli hazırdır. En hızlı geri dönüşü hedefler ancak maliyeti yüksektir.
Warm Site
Gerekli altyapının önemli kısmı hazırdır ancak bazı servislerin recovery sırasında devreye alınması gerekir.
Cold Site
Fiziksel veya temel altyapı bulunur ancak sistemlerin kurulması ve verilerin geri yüklenmesi gerekir.
İşletmenin RTO hedefi hangi modelin uygun olduğunu belirler.
Kritik sistemlerde backup ve replikasyon birlikte kullanılabilir.
Örneğin;
Ana VM
↓
Replika VM
Bağımsız Backup
Replikasyon hızlı devreye alma sağlarken backup geçmiş tarihlere dönüş imkânı sağlayabilir.
Bu iki sistem birbirinin yerine geçmez.
Fidye yazılımı yalnızca ana dosyaları değil erişebildiği yedekleri de etkileyebilir.
Bu nedenle backup sisteminin üretim networkünden mümkün olduğunca ayrılması önemlidir.
Örneğin;
User VLAN
↓
Server VLAN
↓
Backup VLAN
↓
Backup Server / NAS
şeklinde katmanlı yapı oluşturulabilir.
Destekleyen sistemlerde backup dosyalarının belirli süre boyunca değiştirilememesi veya silinememesi sağlanabilir.
Immutable backup özellikle fidye yazılımı ve yönetici hesabının ele geçirilmesi gibi senaryolara karşı ek koruma sağlayabilir.
Kritik işletmelerde belirli yedeklerin networkten tamamen ayrılmış şekilde tutulması değerlendirilebilir.
Bu;
gibi yöntemlerle gerçekleştirilebilir.
Offline backup özellikle siber saldırı senaryolarında önemli bir güvenlik katmanı olabilir.
Firewall arızası işletmenin internet, VPN ve şube bağlantılarının tamamını durdurabilir.
Bu nedenle firewall konfigürasyonlarının güncel yedeği tutulmalıdır.
Kritik işletmelerde ikinci firewall veya HA yapısı değerlendirilebilir.
Uygun firewall sistemlerinde iki cihaz HA olarak çalıştırılabilir.
Ana firewall arızalandığında ikinci cihazın devreye girmesi sağlanabilir.
Bu yapı özellikle internet ve VPN bağlantısının kritik olduğu işletmeler için değerlendirilebilir.
Felaket kurtarma yalnızca sunucularla ilgili değildir.
Ana internet hattının kesilmesi de birçok işletmenin faaliyetini durdurabilir.
Örneğin;
Fiber ISP 1
Fiber / 5G ISP 2
↓
Firewall
şeklinde yedek internet altyapısı oluşturulabilir.
Firewall, managed switch ve diğer network cihazlarının konfigürasyonlarının yedeklenmesi önemlidir.
Cihaz arızalandığında yeni cihaz üzerinde VLAN, routing ve güvenlik politikalarının sıfırdan oluşturulması ciddi zaman kaybına neden olabilir.
Felaket sırasında sistemi ilk kez anlamaya çalışmak ciddi zaman kaybettirir.
Bu nedenle uygun projelerde;
dokümante edilebilir.
DR planının yalnızca teknik personelin hafızasında bulunması doğru değildir.
Dokümanda örneğin;
1. Active Directory devreye alınacak
2. DNS kontrol edilecek
3. ERP database restore edilecek
4. ERP uygulama sunucusu açılacak
5. Kullanıcı bağlantıları test edilecek
gibi kurtarma sırası tanımlanabilir.
Felaket sırasında görev dağılımının önceden belirlenmesi süreci hızlandırabilir.
Örneğin;
hangi noktada devreye girecek önceden belirlenebilir.
Hiç test edilmemiş Disaster Recovery planı gerçek felaket sırasında çalışmayabilir.
Bu nedenle belirli aralıklarla;
gibi testler yapılabilir.
Kritik işletmelerde belirli dönemlerde kontrollü Disaster Recovery tatbikatları gerçekleştirilebilir.
Örneğin senaryo:
“Ana sanallaştırma hostu tamamen arızalandı.”
Backup sisteminden kritik VM’lerin alternatif altyapıya ne kadar sürede geri getirilebildiği ölçülebilir.
Bu süre gerçek RTO kapasitesini anlamaya yardımcı olur.
Felaket kurtarma sisteminin çalışabilmesi için backup sisteminin sürekli kontrol edilmesi gerekir.
Takip edilebilecek değerler;
olabilir.
Aylar önce durmuş bir backup sistemi felaket anında işe yaramaz.
Disaster Recovery analizi sırasında işletmenin tek noktaya bağımlı sistemleri belirlenmelidir.
Örneğin;
kritik single point of failure oluşturabilir.
Her sistemin yedeklenmesi gerekmez ancak işletmeyi tamamen durdurabilecek noktalar önceliklendirilmelidir.
Sunucu, NAS, firewall ve switchlerin tamamı elektrik altyapısına bağımlıdır.
UPS sistemleri kısa süreli kesintilere karşı koruma sağlayabilir.
Kritik yapılarda;
senaryoları birlikte değerlendirilebilir.
Sunucu ve backup NAS aynı rack kabinet içerisinde bulunuyorsa yangın veya fiziksel hasar durumunda ikisi birlikte kaybedilebilir.
Bu nedenle kritik verinin en az bir kopyasının farklı fiziksel lokasyonda bulunması önemlidir.
Disaster Recovery aynı zamanda siber güvenliğin son savunma katmanlarından biridir.
Firewall, endpoint security ve diğer güvenlik sistemleri saldırıyı önlemeye çalışır.
Ancak saldırı başarılı olursa işletmenin tekrar çalışabilmesi için temiz ve kullanılabilir backup gerekir.
Bu nedenle:
Önleme + Tespit + Yedekleme + Kurtarma
birlikte düşünülmelidir.
Disaster Recovery yalnızca büyük şirketlere yönelik değildir.
Örneğin 15 kullanıcılı bir işletmede tek bir sunucu üzerinde;
çalışıyorsa o sunucunun kaybedilmesi işletmenin tamamını durdurabilir.
Küçük işletmeler için daha ekonomik;
Sunucu + NAS Backup + Bulut/Off-site Backup + Restore Planı
oluşturulabilir.
Fabrikalarda IT sistemlerinin durması üretimi doğrudan etkileyebilir.
Özellikle;
için kurtarma öncelikleri belirlenebilir.
Üretimin kaç saatlik kesintiyi tolere edebileceği DR mimarisinin maliyetini ve kapsamını belirler.
Şubeler felaket kurtarma altyapısının parçası haline getirilebilir.
Örneğin;
Merkez → Backup → Şube
ve
Şube → Backup → Merkez
şeklinde karşılıklı yedekleme oluşturulabilir.
Uygun altyapıda kritik sistemlerin alternatif lokasyonda çalıştırılması da planlanabilir.
Genel olarak şu adımlarla ilerliyoruz:
Disaster Recovery çözümlerimiz özellikle;
için planlanabilir.
Bursa Bilgisayar olarak felaket kurtarmayı yalnızca “yedek alıyoruz” şeklinde değerlendirmiyoruz.
Sunucu + Sanallaştırma + Backup + NAS + Off-site Backup + Replikasyon + Network + Firewall + VPN + Monitoring + Restore Testi altyapısını birlikte ele alıyoruz.
Böylece yalnızca verilerin bir kopyasının bulunmasını değil, ciddi bir arıza veya siber saldırı sonrasında işletmenin kritik sistemlerinin hangi sırayla, hangi altyapıda ve ne kadar sürede yeniden çalıştırılacağını planlamayı hedefliyoruz.
Sunucunuz bugün tamamen arızalansa işletmenizin kaç saat içerisinde tekrar çalışabileceğini bilmiyorsanız, backup sisteminiz var ancak hiç geri yükleme testi yapılmadıysa veya tüm sunucu ve yedekleriniz aynı fiziksel lokasyonda bulunuyorsa mevcut altyapınızı birlikte değerlendirebiliriz.
Bursa Bilgisayar olarak Bursa felaket kurtarma, Disaster Recovery, iş sürekliliği, sunucu kurtarma, off-site backup, sunucu replikasyonu, RPO/RTO planlaması ve felaket kurtarma sistemi ihtiyaçlarınız için işletmenize uygun bir Disaster Recovery mimarisi oluşturuyoruz.
