Verinin Korunması
Dosya, sistem, sanal makine, veritabanı veya diğer kritik verilerin belirlenmiş zamanlarda başka bir koruma katmanına kopyalanmasıdır.
- Veri kopyaları
- Retention
- Version history
- Point-in-time restore
- Dosya veya sistem kurtarma
16 · VERİ KORUMA & İŞ SÜREKLİLİĞİ
Yedekleme & Felaket Kurtarma
Kritik verilerinizi yalnızca yedeklemek değil; donanım arızası, kullanıcı hatası, veri bozulması, ransomware, altyapı kesintisi veya tesis kaynaklı bir olay sonrasında iş süreçlerinizi kontrollü biçimde geri döndürebilecek bir kurtarma mimarisi oluşturuyoruz.
PRODUCTION
DATA
ACTIVE SYSTEMS
PROTECTION
BACKUP
RECOVERY READY
RECOVERY
DR
RESTORE
BUSINESS RESILIENCE
BACKUP ≠ RECOVERY
PROTECT · VERIFY · RESTORE
YEDEKLEME & KURTARMA
Yedeğin Olması Yetmez, Geri Dönebilmek Gerekir.
Etkin veri koruma stratejisinin başarısı yalnızca kaç adet backup job çalıştığıyla değil, ihtiyaç anında doğru verinin doğru noktaya geri getirilebilmesiyle ölçülmelidir.
Başarılı görünen ancak restore edilmemiş bir yedek, gerçek bir olay yaşanana kadar fark edilmeyen ciddi bir risk oluşturabilir.
Bu nedenle yedekleme altyapısını backup job, storage ve retention ayarlarından ibaret görmüyoruz. İş kritikliği, RPO, RTO, kurtarma sırası, erişim güvenliği, kopyaların konumu ve test mekanizmalarını birlikte değerlendiriyoruz.
Amaç yalnızca veriyi saklamak değil; işletmenin yaşanabilecek farklı kesinti senaryolarında neyi, hangi sırayla ve ne kadar sürede geri döndüreceğini önceden bilmektir.
BACKUP & DISASTER RECOVERY
Yedekleme ile Felaket Kurtarma Aynı Şey Değildir.
Hizmetin Geri Döndürülmesi
Kritik bilgi sistemlerinin ciddi bir kesinti veya felaket sonrasında yeniden kullanılabilir hale getirilmesi için oluşturulan teknik ve operasyonel plandır.
- Kurtarma sırası
- Alternatif altyapı
- Bağımlılıklar
- Failover / failback
- DR runbook
RPO & RTO
İki Kritik Soru: Ne Kadar Veri ve Ne Kadar Zaman?
Backup sıklığı ve kurtarma mimarisi belirlenmeden önce iş birimlerinin ne kadar veri kaybına ve ne kadar kesintiye tolerans gösterebildiği anlaşılmalıdır.
RPO
RECOVERY POINT OBJECTIVE
Ne Kadar Veri Kaybı Kabul Edilebilir?
RPO, bir kesinti yaşandığında verinin geçmişte hangi noktaya kadar geri döndürülebilmesinin işletme açısından kabul edilebilir olduğunu belirlemeye yardımcı olur.
BACKUP
INCIDENT
RTO
RECOVERY TIME OBJECTIVE
Sistem Ne Kadar Süre Kapalı Kalabilir?
RTO, bir kesinti sonrasında sistem veya hizmetin kabul edilemez iş etkisi oluşmadan önce ne kadar sürede geri döndürülmesi gerektiğini belirlemeye yardımcı olan kurtarma hedefidir.
INCIDENT
RECOVERY
01 · BUSINESS IMPACT ANALYSIS
Her Sistemi Aynı Öncelikle Kurtarmayın.
Dosya sunucusu, ERP, Active Directory, veritabanı, üretim uygulaması ve test sistemi işletme açısından aynı kritik seviyede olmayabilir.
İş etki analiziyle hangi süreçlerin kesintisinin ne kadar ciddi sonuç oluşturduğu değerlendirilir.
Bu çalışma yedekleme sıklığı, retention, kurtarma önceliği ve DR altyapısı için önemli bir girdi oluşturur.
BUSINESS SYSTEM
CRITICALITY
IDENTITY
CRITICAL
ERP
HIGH
FILE DATA
HIGH
TEST SYSTEM
MEDIUM
ARCHIVE
LOW
USS YEDEKLEME & DR HİZMET KAPSAMI
Veriden Kurtarmaya Uçtan Uca Koruma
Yedekleme sistemini tek ürün veya tek storage cihazı üzerinden değil, işletmenin gerçek kurtarma ihtiyacı üzerinden tasarlıyoruz.
BIA
İş Etki Analizi
Kritik süreç ve sistemlerin işletme üzerindeki etkisinin değerlendirilmesi.
- Critical processes
- Dependencies
- Business impact
- Recovery priority
OBJ
RPO & RTO Tasarımı
Veri kaybı ve kesinti toleransına göre kurtarma hedeflerinin belirlenmesi.
- RPO
- RTO
- Workload tiers
- Recovery objectives
SRV
Sunucu Yedekleme
Fiziksel sunucu ve kritik işletim sistemi altyapılarının korunması.
- Windows Server
- Linux
- System state
- Application data
VM
Sanal Makine Yedekleme
Sanallaştırma ortamındaki sanal sunucuların kontrollü biçimde korunması.
- Virtual machines
- Image-level backup
- Application consistency
- VM restore
DB
Veritabanı Yedekleme
Kritik veritabanlarının uygulama ihtiyacına uygun şekilde korunması.
- Database backups
- Transaction awareness
- Point-in-time strategy
- Restore testing
FILE
Dosya & NAS Yedekleme
Ortak klasör, kullanıcı verisi ve NAS üzerindeki önemli dosyaların korunması.
- File servers
- NAS
- Shared folders
- Archive data
M365
Microsoft 365 Veri Koruma
Microsoft 365 üzerindeki kritik iş verileri için ayrıca backup ve recovery stratejisinin değerlendirilmesi.
- Exchange Online
- SharePoint
- OneDrive
- Recovery policy
OFF
Off-Site Backup
Ana altyapıdan farklı bir lokasyon veya koruma ortamında ikinci kopya oluşturulması.
- Remote repository
- Cloud repository
- Site separation
- Replication
IMM
Immutable / Offline Kopya
Üretim ortamındaki saldırı veya yetki ihlalinin backup kopyalarını da etkileme riskinin azaltılması.
- Immutability
- Offline copies
- Isolation
- Ransomware resilience
RET
Retention Politikası
Günlük, haftalık, aylık veya uzun dönem kopyaların iş ihtiyacına göre saklanması.
- Daily
- Weekly
- Monthly
- Archive strategy
ENC
Backup Güvenliği
Backup altyapısının erişim ve veri güvenliği açısından ayrıca korunması.
- Encryption
- Access control
- Separate credentials
- Admin protection
MON
Backup Monitoring
Job ve repository durumlarının düzenli izlenerek başarısızlıkların görünür hale getirilmesi.
- Job status
- Capacity
- Alerts
- Failure review
RST
Restore Testleri
Backup kopyalarının gerçekten geri döndürülebilir olduğunun kontrollü testlerle doğrulanması.
- File restore
- VM restore
- Database restore
- Recovery exercise
DR
Disaster Recovery Planı
Büyük kesintilerde sistemlerin hangi sırayla ve nasıl geri getirileceğinin planlanması.
- Recovery sequence
- Dependencies
- Responsibilities
- Communication
RUN
DR Runbook
Kurtarma sırasında uygulanacak teknik ve operasyonel adımların dokümante edilmesi.
- Step-by-step actions
- Contacts
- Credentials process
- Validation
TEST
DR Test & Tatbikat
Felaket kurtarma planının gerçek olay yaşanmadan kontrollü senaryolarla değerlendirilmesi.
- Tabletop exercise
- Technical restore
- Recovery timing
- Lessons learned
ÇOK KATMANLI YEDEKLEME
Tek Kopyaya Güvenmeyin.
3-2-1 yaklaşımı, veri koruma mimarisi oluştururken kullanılabilecek yaygın tasarım prensiplerinden biridir. Gerçek mimari işletmenin risklerine ve teknik ihtiyaçlarına göre uyarlanmalıdır.
Veri Kopyaları
Üretim verisi dahil birden fazla bağımsız veri kopyasının bulunması hedeflenir.
MULTIPLE COPIESFarklı Ortam
Tek storage veya tek fiziksel altyapıya bağımlılığın azaltılması hedeflenir.
DIFFERENT MEDIAFarklı Konum
Ana sistemle aynı fiziksel olaydan etkilenmeyecek ayrı bir kopya planlanır.
OFF-SITE COPY
Modern saldırı senaryolarında yalnızca kopya sayısı yeterli değildir.
Backup yönetim hesaplarının ayrılması, değiştirilemeyen veya offline kopyaların bulunması ve düzenli restore testleri veri koruma mimarisinin önemli ek katmanlarıdır.
PRODUCTION
SYSTEM
→
BACKUP
REPOSITORY
→
PROTECTED
IMMUTABLE
ATTACK
✕
02 · IMMUTABLE & OFFLINE BACKUP
Saldırgan Yedeğe Ulaşırsa Backup da Kaybedilebilir.
Ransomware saldırıları yalnızca üretim verisini değil, erişebildikleri backup repository ve yedek kopyalarını da hedefleyebilir.
Bu nedenle backup altyapısında üretim sistemlerinden ayrıştırılmış erişimler, offline kopyalar veya desteklenen platformlarda immutable repository yaklaşımları değerlendirilmelidir.
Hangi modelin uygulanacağı kullanılan backup ürünü, storage yapısı, mevcut altyapı ve kurtarma hedeflerine göre belirlenir.
03 · KORUNACAK İŞ YÜKLERİ
Tek Backup Politikası Her Sistem İçin Uygun Olmayabilir.
Identity Services
Active Directory ve kimlik altyapısının iş sürekliliğindeki rolü değerlendirilir.
- Domain services
- DNS dependency
- Authentication
- Recovery sequence
Virtual Infrastructure
Sanal sunucuların iş kritikliği ve uygulama bağımlılıklarına göre yedeklenmesi.
- VM workloads
- Host dependency
- Application consistency
- Full VM recovery
Databases
Veritabanı sistemlerinin veri tutarlılığı ve geri dönüş gereksinimleriyle birlikte korunması.
- Database backup
- Transaction data
- Consistency
- Point-in-time needs
Business Applications
ERP ve diğer kritik iş uygulamalarının veri, uygulama ve bağımlılıklarıyla korunması.
- Application
- Database
- File dependencies
- Configuration
File & NAS
Departman paylaşımları ve kritik dosyaların farklı veri kaybı senaryolarına karşı korunması.
- Shared folders
- Documents
- User data
- Archive
Microsoft 365
Bulut servislerindeki iş verileri için retention ve backup ihtiyaçlarının ayrıca değerlendirilmesi.
- Exchange Online
- SharePoint
- OneDrive
- Recovery requirements
04 · MICROSOFT 365 VERİ KORUMA
Bulutta Olması Backup Stratejisini Gereksiz Kılmaz.
Microsoft 365 platformu yüksek erişilebilirlik ve çeşitli veri koruma mekanizmaları sunsa da kuruluşun ihtiyaç duyduğu historical recovery, operasyonel geri dönüş ve backup politikası ayrıca değerlendirilmelidir.
Exchange Online, SharePoint ve OneDrive gibi servisler için kullanılacak backup yaklaşımı; veri kritikliği, retention ihtiyacı ve kurtarma beklentileri üzerinden planlanmalıdır.
Microsoft'un kendi Microsoft 365 Backup çözümü veya ihtiyaca uygun diğer backup platformları proje kapsamında değerlendirilebilir.
M365
EXO
SP
OD
RECOVERY
BACKUP
05 · RETENTION POLİTİKASI
Kaç Yedek Değil, Hangi Noktaya Dönebileceğiniz Önemli.
DAILY
Günlük
Kısa dönem
→
WEEKLY
Haftalık
Orta dönem
→
MONTHLY
Aylık
Uzun dönem
→
ARCHIVE
Arşiv
İş ihtiyacına göre
Veri Değişim Hızı
Gün içerisinde sık değişen sistemler daha farklı backup sıklığı gerektirebilir.
İş Kritikliği
Kritik verilerin daha fazla recovery point ihtiyacı olabilir.
Depolama Kapasitesi
Retention süresi backup storage ihtiyacını doğrudan etkiler.
Kurumsal Gereksinimler
İş, sözleşme ve uygulanabilir kayıt saklama ihtiyaçları değerlendirilir.
06 · BACKUP GÜVENLİĞİ
Backup Sistemi Kendisi de Korunmalıdır.
Ayrı Yönetim Hesapları
Backup yönetiminde günlük kullanıcı hesaplarından ayrıştırılmış yönetim modeli değerlendirilir.
Güçlü Kimlik Doğrulama
Backup platformunun desteklediği uygun authentication kontrolleri kullanılır.
Encryption
Veri aktarımı ve backup kopyaları için uygun şifreleme seçenekleri değerlendirilir.
Network Isolation
Backup altyapısının üretim network'üyle ilişkisi güvenlik açısından değerlendirilir.
Immutability
Desteklenen ortamlarda yedeklerin belirli süre değiştirilmesini veya silinmesini zorlaştıran mekanizmalar kullanılır.
Audit & Monitoring
Backup yönetim faaliyetleri ve kritik olayların izlenebilir olması hedeflenir.
BACKUP MONITOR
STATUS
DOMAIN-01
SUCCESS
ERP-DB
SUCCESS
FILE-01
WARNING
APP-02
SUCCESS
OFFSITE
VERIFY
07 · İZLEME & ALARM
Başarısız Backup'ı Aylar Sonra Fark Etmeyin.
Backup job tanımlandıktan sonra sistemin kendi haline bırakılması önemli risklerden biridir.
Job başarısızlıkları, repository kapasitesi, bağlantı problemleri ve beklenmeyen çalışma süreleri düzenli olarak izlenmelidir.
Monitoring sayesinde kritik bir restore ihtiyacı oluşmadan önce backup altyapısındaki sorunların görünür hale gelmesi hedeflenir.
08 · RESTORE TEST
Backup Başarılı. Peki Restore?
Başarılı job sonucu yedeğin işletme ihtiyacını karşılayacak şekilde geri döndürülebileceğini tek başına garanti etmez.
Dosya Restore
Belirli dosya veya klasörün yedekten kurtarılması.
GRANULARVM Restore
Sanal sunucunun uygun test ortamına geri döndürülmesi.
MACHINEDatabase Restore
Veritabanının belirlenen kurtarma senaryosuna göre geri alınması.
DATABASEApplication Recovery
Uygulamanın yalnızca dosya değil bağımlılıklarıyla birlikte çalışmasının kontrolü.
SERVICEDR Exercise
Birden fazla sistemin planlanan kurtarma sırasıyla test edilmesi.
EXERCISE
09 · RANSOMWARE RECOVERY
Ransomware Sonrası Temiz Bir Dönüş Planı Gerekir.
Ransomware olayında hedef yalnızca şifrelenmiş dosyayı geri getirmek değildir.
Saldırının hangi sistemleri etkilediğinin belirlenmesi, uygun temiz recovery point'in seçilmesi ve geri döndürülen ortamın yeniden enfekte edilmemesi gerekir.
Bu nedenle olay müdahalesi, backup güvenliği ve felaket kurtarma süreçleri birbirinden tamamen bağımsız düşünülmemelidir.
01
ISOLATE
Etkiyi sınırlandır
→
02
INVESTIGATE
Olayı değerlendir
→
03
CLEAN POINT
Güvenilir kopya seç
→
04
RESTORE
Sistemi geri getir
→
05
VALIDATE
Kontrol ederek aç
10 · DISASTER RECOVERY MİMARİSİ
Ana Sistem Kaybolduğunda B Planı Hazır mı?
PRIMARY SITE
Production
Servers · Applications · Data
BACKUP / REPLICATION
CONTROLLED DATA FLOW
RECOVERY SITE
DR Environment
Recovery Capacity
Alternatif Ortam
Felaket kurtarma ortamının lokasyon ve kapasite ihtiyaçları değerlendirilir.
Network
Recovery ortamına geçildiğinde bağlantı ve erişim yöntemleri planlanır.
Name Resolution
Uygulamaların recovery sonrasında doğru sistemlere yönlenmesi değerlendirilir.
Application Dependencies
Uygulamaların çalışabilmesi için gerekli diğer servis ve sistemler belirlenir.
Data Recovery
Kurtarma ortamında kullanılacak veri kopyalarının güncelliği ve bütünlüğü kontrol edilir.
Kullanıcı Erişimi
Recovery sonrasında kullanıcıların kritik uygulamalara nasıl erişeceği planlanır.
11 · RECOVERY SEQUENCE
Yanlış Sırada Kurtarma Sistemleri Çalıştırmayabilir.
Bir uygulamanın kendisi geri dönmüş olsa bile bağımlı olduğu DNS, identity, database veya network servisi çalışmıyorsa hizmet kullanılamayabilir.
Bu nedenle kritik sistemlerin bağımlılık haritasını çıkararak teknik kurtarma sırası önceden belirlenmelidir.
01
INFRA
Temel altyapı
02
IDENTITY
Kimlik & DNS
03
DATABASE
Veri katmanı
04
APPLICATION
İş uygulaması
05
USERS
Kullanıcı erişimi
06
VERIFY
İş doğrulaması
12 · FAILOVER & FAILBACK
DR Ortamına Geçmek Kadar Geri Dönmek de Planlanmalıdır.
Primary → Recovery
Ana ortamın hizmet veremediği senaryoda kritik sistemlerin planlanan recovery ortamına alınması sürecidir.
- Incident decision
- Recovery activation
- Service startup
- Connectivity
- Validation
Recovery → Primary
Ana altyapı yeniden kullanılabilir olduğunda hizmetin kontrollü biçimde asıl ortama geri taşınmasıdır.
- Primary readiness
- Data synchronization
- Change window
- Return migration
- Final validation
DR RUNBOOK
EXECUTION PLAN
STEP 01
INCIDENT CONFIRMATION
STEP 02
DR ACTIVATION
STEP 03
INFRASTRUCTURE RECOVERY
STEP 04
APPLICATION RECOVERY
STEP 05
BUSINESS VALIDATION
STEP 06
COMMUNICATION
13 · DR RUNBOOK
Kriz Anında Hafızaya Güvenmeyin.
Normal zamanda kolay görünen bir işlem, ciddi kesinti sırasında zaman baskısı ve belirsizlik nedeniyle zorlaşabilir.
DR runbook içerisinde teknik kurtarma adımları, sorumlular, iletişim yöntemleri, doğrulamalar ve gerekli karar noktaları dokümante edilir.
Runbook statik bir doküman olarak bırakılmamalı; altyapı değişiklikleri ve yapılan testlerden sonra güncellenmelidir.
14 · DR TEST & TATBİKAT
Felaket Kurtarma Planı Test Edilmeden Tamamlanmış Sayılmaz.
Tabletop Exercise
Ekiplerin senaryo üzerinden rollerini, karar noktalarını ve iletişim adımlarını değerlendirmesi.
Teknik Restore
Belirli sistemlerin kontrollü ortamda gerçek yedekten geri döndürülmesi.
Recovery Time
Gerçek kurtarma süresinin belirlenen hedeflerle karşılaştırılması.
Bağımlılık Kontrolü
Sistemler arası dependency problemlerinin kurtarma sırasında tespit edilmesi.
İş Birimi Doğrulaması
Teknik olarak açılan sistemin iş fonksiyonlarını gerçekten yerine getirip getirmediğinin kontrolü.
İyileştirme
Test sırasında tespit edilen eksikliklerin plana ve altyapıya yansıtılması.
SIK GÖRÜLEN YEDEKLEME HATALARI
Backup Var Görünür, Ama Kurtarma Yine Başarısız Olabilir.
Tek Kopya
Üretim sistemiyle aynı storage üzerinde bulunan tek backup kopyasına güvenilmesi.
Restore Testi Yok
Yedekler düzenli çalışıyor görünmesine rağmen hiçbir zaman geri yükleme denenmemesi.
Aynı Yetkiler
Üretim ve backup yönetiminin aynı geniş yetkili hesaplara bağımlı olması.
Off-Site Yok
Yangın, fiziksel hasar veya tesis kaybında bütün kopyaların aynı olaydan etkilenmesi.
Alarm Takibi Yok
Başarısız backup job'larının uzun süre fark edilmeden devam etmesi.
DR Dokümanı Yok
Sistemlerin hangi sırada ve kim tarafından kurtarılacağının önceden belirlenmemesi.
Kapasite Planı Yok
Veri büyümesi nedeniyle repository kapasitesinin beklenmedik şekilde tükenmesi.
Eski Sistemler
Backup kapsamına yeni sistemlerin eklenmemesi veya kaldırılan sistemlerin temizlenmemesi.
USS BACKUP & DR PROJE MODELİ
Veri Koruma Projesinde 14 Kontrollü Adım
Discovery
Mevcut altyapı, servisler ve iş ihtiyaçları anlaşılır.
ÇIKTI: PROJECT SCOPEInventory
Sunucu, VM, veritabanı ve veri envanteri çıkarılır.
ÇIKTI: WORKLOAD INVENTORYCriticality
İş yükleri kritik seviyelerine göre sınıflandırılır.
ÇIKTI: BIARPO / RTO
Veri kaybı ve kurtarma süresi hedefleri belirlenir.
ÇIKTI: OBJECTIVESArchitecture
Backup repository ve kopya mimarisi tasarlanır.
ÇIKTI: BACKUP DESIGNRetention
Veri saklama ve recovery point yapısı belirlenir.
ÇIKTI: RETENTION POLICYSecurity
Yetki, şifreleme ve backup izolasyonu planlanır.
ÇIKTI: SECURITY MODELImplementation
Backup job ve repository yapılandırmaları uygulanır.
ÇIKTI: BACKUP SYSTEMOff-Site
İkinci lokasyon veya koruma kopyası devreye alınır.
ÇIKTI: SECONDARY COPYMonitoring
Job durumları ve kapasite izlemesi oluşturulur.
ÇIKTI: MONITORINGRestore Test
Backup kopyalarının geri döndürülebilirliği test edilir.
ÇIKTI: RESTORE RESULTSDR Planning
Kurtarma sırası ve sorumluluklar dokümante edilir.
ÇIKTI: DR PLANDR Exercise
Plan kontrollü senaryolarla test edilir.
ÇIKTI: EXERCISE REPORTImprovement
Değişiklik ve test sonuçlarına göre yapı geliştirilir.
ÇIKTI: CONTINUOUS IMPROVEMENT
SIK SORULAN SORULAR
Yedekleme & DR Hakkında
Yedek alınıyorsa felaket kurtarma planına neden ihtiyaç var? +
Backup verinin bir kopyasını sağlar. Felaket kurtarma ise kritik sistemlerin hangi sırayla, hangi altyapıda ve kim tarafından geri döndürüleceğini de kapsar. Büyük kesintilerde yalnızca backup dosyasının bulunması yeterli olmayabilir.
RPO ile RTO arasındaki fark nedir? +
RPO kabul edilebilir veri kaybı açısından hangi geçmiş noktaya kadar geri dönülmesi gerektiğini ifade eder. RTO ise sistem veya hizmetin ne kadar sürede yeniden kullanılabilir hale gelmesi gerektiğini belirleyen hedefi ifade eder.
3-2-1 backup kuralı nedir? +
Yaygın 3-2-1 yaklaşımı, üretim verisi dahil üç veri kopyası, iki farklı depolama ortamı ve bir farklı lokasyon kopyası bulunmasını hedefleyen genel bir veri koruma prensibidir. Gerçek mimari kuruluşun riskine göre uyarlanmalıdır.
Immutable backup nedir? +
Desteklenen backup veya storage platformlarında yedek verisinin belirli koşullar altında değiştirilmesini veya silinmesini kısıtlayan koruma yaklaşımıdır. Ransomware ve yetki ihlallerine karşı ek dayanıklılık sağlayabilir.
NAS cihazı backup için yeterli midir? +
NAS backup mimarisinin bir parçası olabilir ancak tek başına tüm riskleri ortadan kaldırmaz. Aynı network ve aynı fiziksel lokasyonda bulunan tek bir NAS, saldırı veya tesis kaybından etkilenebilir.
Buluta backup almak yeterli midir? +
Bulut farklı lokasyonda kopya oluşturmak açısından faydalı olabilir ancak retention, erişim güvenliği, şifreleme, recovery süresi ve veri hacmi yine değerlendirilmelidir.
Microsoft 365 için ayrıca backup gerekir mi? +
Kuruluşun veri kaybı, historical recovery ve retention ihtiyaçlarına göre Microsoft 365 verileri için ayrıca backup stratejisi değerlendirilmelidir. Microsoft 365 Backup veya uygun diğer çözümler proje kapsamında ele alınabilir.
Backup başarılı görünüyorsa neden restore testi yapmalıyız? +
Backup job'ın tamamlanması dosyanın, sanal makinenin veya uygulamanın ihtiyaç duyulduğunda doğru şekilde geri dönebileceğini tek başına garanti etmez. Restore testi kurtarma zincirini gerçek uygulamayla doğrular.
Yedekler ne kadar süre saklanmalı? +
Tek bir doğru süre yoktur. Veri değişim hızı, RPO, iş gereksinimleri, storage kapasitesi ve uygulanabilir saklama yükümlülükleri birlikte değerlendirilerek retention politikası oluşturulmalıdır.
Ransomware sonrası en son backup'a mı dönülür? +
Her zaman değil. En son backup olaydan etkilenmiş veya saldırganın sisteme girdiği dönemden sonraki verileri içeriyor olabilir. Olay analizi yapılarak güvenilir recovery point seçilmesi gerekebilir.
DR ortamı sürekli açık olmak zorunda mı? +
Hayır. Tasarım; işletmenin RTO hedefi, bütçesi ve iş kritikliği doğrultusunda sıcak, daha hazır veya daha düşük maliyetli kurtarma modellerinden biri olabilir. Mimari işletme ihtiyacına göre tasarlanmalıdır.
Felaket kurtarma testi üretimi etkiler mi? +
Test yöntemi kontrollü planlanmalıdır. Bazı testler izole bir ortamda yapılabilir, bazıları tabletop exercise şeklinde yürütülebilir. Üretimi etkileyebilecek senaryolar ise önceden planlanmış değişiklik pencerelerinde gerçekleştirilmelidir.
Backup sistemini bir kez kurmak yeterli mi? +
Hayır. Yeni sunucular, yeni uygulamalar, artan veri hacmi, değişen riskler ve çalışan ayrılıkları backup kapsamını etkileyebilir. Yapının düzenli izlenmesi, test edilmesi ve güncellenmesi gerekir.
USS TEKNOLOJİ VE DANIŞMANLIK
Backup & DR Analizi Talep Et
→
Verinizi Yedeklemekten Fazlasını Yapalım: Geri Dönüşünüzü Planlayalım.
Sunucularınızı, sanal makinelerinizi, veritabanlarınızı, dosya sistemlerinizi ve bulut verilerinizi birlikte değerlendirelim; RPO ve RTO hedeflerinize uygun, izlenen, test edilen ve felaket senaryolarında gerçekten kullanılabilir bir backup & recovery mimarisi oluşturalım.