Veritabanı Backup, Restore ve Point-in-Time Recovery Nasıl Planlanmalı?

Bir veritabanının yedeğinin alınması, o veritabanının gerçekten korunabildiği anlamına gelmez.

Asıl soru şudur:

Gerekirse geri dönebiliyor muyuz?

Bir database backup sistemi teknik olarak başarılı görünebilir.

Ancak;

backup bozuk olabilir,

transaction log eksik olabilir,

encryption key bulunamayabilir,

restore süreci test edilmemiş olabilir,

dependency'ler hazır olmayabilir

veya kurum ihtiyaç duyduğu zamana dönemeyebilir.

Bu nedenle database backup stratejisi yalnızca:

“Yedek alınıyor mu?”

sorusuna değil;

“Hangi noktaya, ne kadar veri kaybıyla ve ne kadar sürede dönebiliyoruz?”

sorularına cevap vermelidir.

Kurumsal database recovery yaklaşımının temel bileşenleri şunlardır:

Full Backup

Incremental / Differential Backup

Transaction Log / WAL / Archive Log

Point-in-Time Recovery – PITR

RPO

RTO

Backup Encryption

Immutable Backup

Restore Testing

ve Disaster Recovery

Bu bileşenlerden biri eksik olduğunda backup süreci kağıt üzerinde çalışıyor görünse bile gerçek kriz anında yetersiz kalabilir.

Database Backup Nedir?

Database Backup, veritabanındaki verilerin ve gerektiğinde recovery için ihtiyaç duyulan yapıların ayrı bir kopyasının oluşturulmasıdır.

Amaç;

data loss,

corruption,

human error,

hardware failure,

ransomware,

application error

gibi olaylardan sonra veritabanını geri getirebilmektir.

Backup ile Restore Arasındaki Fark Nedir?

Backup:

Verinin kopyasını oluşturur.

Restore:

Bu kopyadan database'i tekrar kullanılabilir hale getirir.

Gerçek güvenlik restore başarısıyla ölçülür.

Backup Başarılıysa Restore da Başarılı mıdır?

Hayır.

Bu en sık yapılan hatalardan biridir.

Backup job:

Success

gösterebilir.

Ancak dosya;

corrupt,

eksik,

şifreli fakat key'i kayıp,

uyumsuz

olabilir.

Bu nedenle restore test gereklidir.

Recovery Nedir?

Recovery, database'in yalnızca dosyalarının geri yüklenmesi değil, tutarlı ve kullanılabilir duruma getirilmesidir.

Restore ile Recovery Aynı mı?

Tam olarak değil.

Restore backup dosyasını geri yükler.

Recovery ise transaction veya log bilgilerinin uygulanarak database'in tutarlı hale getirilmesini kapsayabilir.

Database Backup Stratejisi Neden İş Gereksiniminden Başlamalı?

Her database aynı kritik seviyede değildir.

Örneğin:

Product Catalog DB

ile

Banking Transaction DB

aynı RPO ve RTO hedeflerine sahip olmayabilir.

Kritik Database Nasıl Belirlenir?

Business Impact Analysis ile;

iş süreci,

gelir etkisi,

müşteri etkisi,

regulatory impact,

operational dependency

değerlendirilebilir.

RPO Nedir?

RPO:

Recovery Point Objective

kabul edilebilir maksimum veri kaybını ifade eder.

Örneğin:

RPO = 15 dakika

ise kurum en fazla 15 dakikalık veriyi kaybetmeyi kabul ediyor demektir.

RTO Nedir?

RTO:

Recovery Time Objective

sistemin ne kadar sürede tekrar çalışır hale gelmesi gerektiğini ifade eder.

Örneğin:

RTO = 2 saat

ise database en geç iki saat içerisinde kullanılabilir olmalıdır.

RPO ile Backup Frequency Arasında İlişki Var mı?

Evet.

Günde bir backup alan sistemin RPO'su çoğu durumda birkaç dakikalık olamaz.

Saatte Bir Backup RPO 1 Saat Demek mi?

Yaklaşık olarak olabilir ancak transaction log veya continuous log shipping kullanılıyorsa daha düşük RPO elde edilebilir.

RTO Sadece Restore Süresine mi Bağlıdır?

Hayır.

RTO;

storage,

network,

server provisioning,

DNS,

application,

identity,

key management

gibi dependency'lerden etkilenir.

Full Backup Nedir?

Database'in tamamının belirli noktadaki kopyasıdır.

Full Backup Avantajı Nedir?

Restore süreci genellikle daha basittir.

Full Backup Dezavantajı Nedir?

Büyük database'lerde;

storage,

network,

backup window

yüksek olabilir.

Differential Backup Nedir?

Son full backup'tan sonra değişen verilerin yedeklenmesidir.

Differential Backup Restore Nasıl Çalışır?

Genellikle;

Full Backup

Latest Differential Backup

kullanılır.

Incremental Backup Nedir?

Son backup'tan sonra değişen blok veya verilerin yedeklenmesidir.

Incremental Backup Avantajı Nedir?

Backup süresi ve storage tüketimi azaltılabilir.

Incremental Backup Dezavantajı Nedir?

Restore chain daha karmaşık olabilir.

Transaction Log Backup Nedir?

Database üzerinde gerçekleşen transaction'ların log kayıtlarının ayrıca yedeklenmesidir.

Özellikle point-in-time recovery için önemlidir.

MSSQL Transaction Log Backup Neden Kritik?

Microsoft SQL Server'da uygun recovery model kullanıldığında transaction log backup ile database belirli zamana kadar geri getirilebilir.

PostgreSQL WAL Nedir?

WAL:

Write-Ahead Logging

PostgreSQL'in değişiklikleri önce loga yazarak consistency ve recovery sağlamasına yardımcı olan mekanizmadır.

WAL Backup İçin Kullanılabilir mi?

Evet.

Archived WAL kayıtları base backup ile birlikte Point-in-Time Recovery için kullanılabilir.

Oracle Archive Log Nedir?

Oracle redo log bilgilerinin arşivlenmiş kopyalarıdır.

Recovery için kritik öneme sahiptir.

PostgreSQL WAL, MSSQL Transaction Log ve Oracle Archive Log Aynı Şey mi?

Teknik uygulamaları farklıdır.

Ancak recovery perspektifinde ortak mantık:

Database değişikliklerinin zaman içindeki kaydını tutmaktır.

Point-in-Time Recovery – PITR Nedir?

Database'in belirli bir tarih ve saate geri getirilmesidir.

PITR Neden Gereklidir?

Örneğin bir kullanıcı saat 14:02'de yanlışlıkla kritik tabloyu sildi.

Database olaydan önceki:

14:01:59

noktasına geri döndürülebilir.

PITR Snapshot'tan Farklı mı?

Evet.

Snapshot belirli sabit noktalara döner.

PITR transaction log zinciriyle çok daha hassas recovery noktaları sağlayabilir.

PITR Her Database'te Otomatik Var mı?

Hayır.

Doğru log, archive ve backup configuration gerekir.

PITR İçin En Kritik Şey Nedir?

Backup zincirinin eksiksiz olmasıdır.

Bir log kaydı kaybolursa recovery zinciri bozulabilir.

Log Chain Break Nedir?

Transaction log dizisinin kesilmesidir.

Bu durumda belirli noktadan sonrası için recovery yapılamayabilir.

MSSQL Log Chain Neden Bozulabilir?

Yanlış backup veya recovery operasyonları zinciri etkileyebilir.

Bu nedenle backup operasyonları kontrollü olmalıdır.

PostgreSQL WAL Archive Eksik Olursa Ne Olur?

Eksik WAL segmenti nedeniyle hedef recovery noktasına ulaşılamayabilir.

Oracle Archive Log Eksik Olursa Ne Olur?

Recovery belirli noktada durabilir.

Database Backup Schedule Nasıl Tasarlanmalı?

İş gereksinimine göre tasarlanmalıdır.

Örneğin:

Haftalık Full

Günlük Differential

15 dakikalık Transaction Log

gibi kombinasyon kullanılabilir.

Her Database İçin Aynı Backup Schedule Kullanılmalı mı?

Hayır.

Criticality ve workload'a göre farklı olabilir.

Transaction-Heavy Database İçin Daha Sık Log Backup Gerekebilir mi?

Evet.

Daha düşük RPO için daha sık log capture gerekebilir.

Read-Only Database İçin Aynı Strateji Gerekir mi?

Hayır.

Değişiklik sıklığı azsa farklı backup yaklaşımı uygulanabilir.

Backup Window Nedir?

Backup işleminin production sistem üzerinde çalışabileceği zaman aralığıdır.

Backup Production Performance'ı Etkiler mi?

Evet.

IO,

CPU,

network

yükü oluşturabilir.

Backup Throttling Nedir?

Backup işleminin kaynak tüketimini sınırlandırmaya yönelik mekanizmadır.

Online Backup Nedir?

Database çalışmaya devam ederken alınan yedektir.

Offline Backup Nedir?

Database durdurulduktan sonra alınan backup'tır.

Production Sistemlerde Hangisi Kullanılır?

24x7 sistemlerde çoğunlukla online backup gerekir.

Application-Consistent Backup Nedir?

Backup'ın application ve database açısından tutarlı recovery noktası sağlamasıdır.

Crash-Consistent Backup Nedir?

Sistemin ani kapanma durumuna benzer şekilde storage snapshot alınmasıdır.

Database recovery mekanizmasıyla tutarlılık sağlanmaya çalışılır.

Crash-Consistent Backup Yeterli mi?

Platform ve workload'a göre değişir.

Critical database'lerde application/database-aware backup tercih edilebilir.

Database Snapshot Nedir?

Storage veya cloud seviyesinde database disklerinin belirli zamandaki görüntüsüdür.

Snapshot Backup mıdır?

Tek başına backup yerine geçmemelidir.

Aynı storage sistemine bağlı olabilir.

Snapshot Storage Arızasında Kaybolabilir mi?

Evet.

Aynı storage failure domain içerisinde ise snapshot da etkilenebilir.

Snapshot Ransomware'e Karşı Güvenli mi?

Her zaman değil.

Saldırgan storage admin yetkisi kazanırsa snapshot'ları silebilir.

Immutable Backup Nedir?

Belirli retention süresi boyunca değiştirilemeyen veya silinemeyen backup'tır.

Database Backup Immutable Olmalı mı?

Kritik database'lerde güçlü şekilde değerlendirilebilir.

Immutable Backup Neden Önemlidir?

Ransomware saldırganları recovery kabiliyetini yok etmek için backup'ları hedefleyebilir.

WORM Database Backup İçin Kullanılabilir mi?

Evet.

Write Once Read Many yaklaşımı değiştirilemez backup retention sağlayabilir.

Air-Gap Database Backup Nedir?

Backup'ın production sistemlerinden fiziksel veya mantıksal olarak ayrılmasıdır.

Air-Gap ile Immutable Aynı mı?

Hayır.

Immutable:

Değiştirilemez.

Air-Gap:

İzole edilir.

İkisi birlikte kullanılabilir.

3-2-1 Backup Kuralı Database İçin Uygulanabilir mi?

Evet.

Temel yaklaşım:

3 kopya veri,

2 farklı media,

1 offsite kopya

şeklindedir.

Modern 3-2-1-1-0 Yaklaşımı Nedir?

Ek olarak;

1 offline/immutable kopya

ve

0 doğrulanmamış recovery error

yaklaşımını hedefler.

Database Backup Encryption Neden Kritik?

Backup production verisinin tam kopyasını içerir.

Bu nedenle backup çalınması veri ihlali olabilir.

Backup Encryption at Rest Gerekli mi?

Hassas database'ler için evet.

Backup Transfer TLS Kullanmalı mı?

Network üzerinden taşınan backup trafiği de şifrelenmelidir.

Backup Encryption Key Nerede Tutulmalı?

Backup ile aynı yerde açık şekilde tutulmamalıdır.

Key Management Recovery İçin Neden Kritik?

Backup dosyası sağlam olsa bile encryption key kaybolursa restore yapılamayabilir.

Database Restore Testi Nedir?

Backup'tan gerçekten database oluşturulup kullanılabildiğinin doğrulanmasıdır.

Restore Test Ne Sıklıkla Yapılmalı?

Criticality'ye göre periyodik yapılmalıdır.

Yıllarca hiç restore edilmemiş backup güvenilir kabul edilmemelidir.

Restore Test Sadece “Database Açıldı” Demek mi?

Hayır.

Application connectivity ve data integrity de doğrulanmalıdır.

Restore Validation Neleri İçermeli?

Örneğin:

Database online mı?

Expected tables var mı?

Row count mantıklı mı?

Application bağlanabiliyor mu?

Transaction consistency doğru mu?

Checksum Kullanılabilir mi?

Backup dosyasının bozulup bozulmadığını doğrulamak için bütünlük kontrolleri kullanılabilir.

Backup Verification Restore Yerine Geçer mi?

Hayır.

Dosyanın sağlıklı görünmesi gerçek restore'un çalışacağını garanti etmez.

Isolated Restore Test Nedir?

Backup'ın production ortamından ayrı test veya recovery environment'ta restore edilmesidir.

Clean Room Nedir?

Şüpheli veya saldırı sonrası backup'ın güvenli şekilde incelenip restore edildiği izole ortamdır.

Ransomware Sonrası Backup Direkt Production'a Restore Edilmeli mi?

Her zaman hayır.

Backup'ın temiz olduğu ve persistence taşımadığı doğrulanmalıdır.

Database Backup İçinde Malware Olabilir mi?

Database backup klasik executable malware içermese bile saldırganın eklediği;

malicious data,

script,

stored procedure,

scheduled job

gibi içerikler bulunabilir.

Clean Restore Point Nedir?

Saldırgan aktivitelerinden önce alınmış ve güvenli olduğu doğrulanmış recovery noktasıdır.

Dwell Time Nedir?

Saldırganın tespit edilmeden sistem içinde kaldığı süredir.

Dwell Time Backup Retention'ı Nasıl Etkiler?

Saldırgan 40 gün sistemde kaldıysa sadece son 7 günlük backup yetersiz olabilir.

Backup Retention Nedir?

Backup kopyalarının ne kadar süre saklanacağını belirler.

Retention Nasıl Belirlenmeli?

Business,

legal,

security,

storage cost

birlikte değerlendirilmelidir.

GFS Retention Nedir?

Grandfather-Father-Son gibi günlük, haftalık ve aylık backup retention modelidir.

Database Backup Retention ile Log Retention Aynı mı?

Hayır.

Recovery logları ve security audit logları farklı amaç taşır.

Database Backup Kataloğu Nedir?

Hangi backup'ın ne zaman alındığını ve nerede bulunduğunu gösteren metadata sistemidir.

Backup Catalog Neden Kritik?

Restore için hangi chain'in kullanılacağını belirlemeye yardımcı olur.

Backup Catalog Ransomware Hedefi Olabilir mi?

Evet.

Bu nedenle backup management server da korunmalıdır.

Backup Administrator Ayrı Olmalı mı?

Kritik ortamlarda production DBA'dan ayrılması risk azaltabilir.

Separation of Duties Backup İçin Nasıl Uygulanır?

DBA database yönetir.

Backup admin backup infrastructure'ını yönetir.

Security ekibi audit eder.

DBA Tüm Backup'ları Silebilmeli mi?

Mümkünse hayır.

Production compromise durumunda saldırgan DBA credential ile recovery katmanını da yok etmemelidir.

Backup Repository Nedir?

Database yedeklerinin saklandığı storage alanıdır.

Backup Repository Internet'e Açık Olmalı mı?

Hayır.

Backup Repository Network Segmentation Gerekir mi?

Evet.

Backup network mümkün olduğunca ayrılmalıdır.

Backup Server Domain Admin Olmalı mı?

Genellikle hayır.

Backup identity mimarisi production identity'den ayrılabilir.

MFA Backup Console İçin Gerekli mi?

Kritik backup yönetim hesaplarında güçlü şekilde önerilir.

PAM Backup Administrator İçin Kullanılabilir mi?

Evet.

Database Backup Monitoring Nedir?

Backup job'larının;

success,

failure,

duration,

size,

age

gibi metriklerinin izlenmesidir.

Backup Failure Alarmı Olmalı mı?

Kesinlikle.

Son Başarılı Backup Yaşı Neden KPI'dır?

Bir database 72 saattir backup almıyorsa sistem çalışıyor görünse bile recovery riski vardır.

Backup Size Anomaly Nedir?

Normalde 500 GB olan backup'ın bir anda 10 GB olması ciddi problem göstergesi olabilir.

Backup Duration Anomaly Nedir?

Normalden çok daha kısa veya uzun backup;

configuration,

storage,

network

problemi gösterebilir.

Backup Success Rate KPI Nedir?

Planlanan backup'ların başarılı tamamlama oranıdır.

Restore Success Rate Daha mı Önemli?

Evet.

Çünkü gerçek amaç geri dönebilmektir.

Restore Time KPI Nedir?

Database'in backup'tan kullanılabilir hale getirilmesi için geçen süredir.

Actual RTO Nedir?

Test sırasında gerçekten ölçülen recovery süresidir.

Declared RTO ile Actual RTO Farkı Nedir?

Kâğıt üzerinde RTO 1 saat olabilir.

Restore testinde 6 saat sürüyorsa gerçek kapasite 1 saat değildir.

Actual RPO Nasıl Ölçülür?

Recovery sonrası son kullanılabilir transaction zamanı ile incident zamanı karşılaştırılabilir.

Database Restore Runbook Nedir?

Recovery sürecini adım adım tanımlayan operasyon dokümanıdır.

Runbook Neden Gerekli?

Kriz sırasında ekiplerin hafızaya dayanmasını önler.

Database Recovery Runbook Neleri İçermeli?

Örneğin:

Backup location

Responsible team

Key access

Restore order

Log application

Validation

Application handover

Runbook'ta Credential Yazılmalı mı?

Hayır.

Secure vault referansı kullanılabilir.

Restore Sırası Neden Önemlidir?

Bazı database'ler birbirine bağımlı olabilir.

Dependency Mapping Nedir?

Database'in hangi;

application,

identity,

DNS,

storage,

network

bileşenlerine bağlı olduğunu belirler.

Database Çalıştı Ama Uygulama Açılmıyorsa Recovery Tamamlandı mı?

Hayır.

Business service kullanılabilir değilse gerçek recovery tamamlanmamıştır.

Database Disaster Recovery Nedir?

Ana database altyapısının kullanılamadığı durumda alternatif ortamda hizmetin yeniden çalıştırılmasıdır.

Backup ile DR Aynı mı?

Hayır.

Backup veri kopyası sağlar.

DR ise tüm hizmetin alternatif ortamda çalıştırılmasını hedefler.

Replication Backup Yerine Geçer mi?

Hayır.

Yanlış DELETE işlemi replica'ya da replicate olabilir.

HA ile Backup Aynı mı?

Hayır.

High Availability hardware veya node failure'a karşı süreklilik sağlar.

Backup historical recovery sağlar.

Active-Passive Database Nedir?

Bir primary database çalışırken secondary beklemede tutulabilir.

Active-Active Database Nedir?

Birden fazla node aynı anda aktif hizmet verebilir.

HA RPO'yu Sıfır Yapar mı?

Her mimaride değil.

Replication yöntemine bağlıdır.

Synchronous Replication Nedir?

Transaction'ın tamamlanması için secondary node'un da doğrulamasının beklendiği modeldir.

Asynchronous Replication Nedir?

Primary transaction tamamlandıktan sonra secondary'ye gönderilebilir.

Düşük latency sağlar ancak veri kaybı riski olabilir.

Replication Lag Nedir?

Primary ile replica arasındaki gecikmedir.

Replication Lag İzlenmeli mi?

Evet.

DR anında beklenenden fazla veri kaybına yol açabilir.

Failover Nedir?

Primary database başarısız olduğunda secondary'nin aktif hale gelmesidir.

Failback Nedir?

Ana sistem geri geldiğinde hizmetin tekrar asıl ortama taşınmasıdır.

Failover Test Edilmeli mi?

Evet.

Hiç test edilmemiş HA tasarımı güvenilir değildir.

Planned Failover Nedir?

Kontrollü bakım veya test amacıyla yapılan failover'dır.

Unplanned Failover Nedir?

Beklenmeyen arıza sonrası otomatik veya manuel failover'dır.

Split-Brain Nedir?

Birden fazla node'un aynı anda primary gibi davranması sonucu veri tutarsızlığı riskidir.

Database DR Test Ne Sıklıkla Yapılmalı?

Criticality ve iş sürekliliği planına göre periyodik yapılmalıdır.

Tabletop Test Yeterli mi?

Tek başına hayır.

Gerçek teknik restore ve failover testleri de yapılmalıdır.

Full DR Drill Nedir?

Application, database, network ve kullanıcı erişimini kapsayan uçtan uca recovery testidir.

PostgreSQL Backup ve Recovery Yaklaşımı

PostgreSQL'de temel olarak;

logical backup,

physical/base backup,

WAL archiving,

PITR

yaklaşımları değerlendirilebilir.

PostgreSQL Logical Backup Nedir?

Schema ve data'nın mantıksal formatta export edilmesidir.

Logical Backup Avantajı Nedir?

Table veya object bazlı recovery ve migration için faydalı olabilir.

Logical Backup Büyük Database İçin Yeterli mi?

Tek başına her zaman uygun olmayabilir.

Recovery süresi uzun olabilir.

PostgreSQL Physical Backup Nedir?

Database cluster dosyalarının fiziksel seviyede alınmasıdır.

PostgreSQL Base Backup + WAL Modeli Nedir?

Base backup belirli başlangıç noktası sağlar.

WAL kayıtları daha sonraki transaction'ları uygulayarak hedef zamana recovery sağlar.

PostgreSQL PITR Mantığı

Özet olarak:

Base Backup

Archived WAL

↓

Target Time

↓

Recovered Database

PostgreSQL WAL Archive Monitoring Neden Kritik?

Archive sürekli başarısızsa PITR kabiliyeti kaybolabilir.

MSSQL Backup ve Recovery Yaklaşımı

MSSQL'de;

Full Backup,

Differential Backup,

Transaction Log Backup

kombinasyonu yaygın olarak kullanılır.

MSSQL Recovery Model Neden Önemlidir?

Transaction log backup ve PITR davranışını belirler.

MSSQL Full Recovery Model Nedir?

Uygun log backup süreciyle point-in-time recovery sağlar.

MSSQL Simple Recovery Model Nedir?

Transaction log yönetimi daha basittir ancak aynı PITR yeteneğini sağlamaz.

Her MSSQL Database Full Recovery Olmalı mı?

Hayır.

Business requirement'a göre seçilmelidir.

MSSQL Transaction Log Backup Schedule Nasıl Olmalı?

Hedef RPO'ya göre belirlenmelidir.

MSSQL Restore Chain

Örneğin:

Full

↓

Differential

↓

Transaction Logs

↓

Target Time

şeklinde olabilir.

Tail-Log Backup Nedir?

Uygun durumlarda failure sonrası henüz yedeklenmemiş transaction log bölümünün alınarak veri kaybının azaltılmasına yardımcı olabilir.

Oracle Backup ve Recovery Yaklaşımı

Oracle ortamlarında;

RMAN,

backup set,

incremental backup,

archive log

gibi mekanizmalar kullanılabilir.

RMAN Nedir?

Oracle Recovery Manager, Oracle database backup ve recovery işlemleri için kullanılan temel yönetim aracıdır.

Oracle ARCHIVELOG Mode Nedir?

Online redo log'ların archive edilmesini sağlayarak daha gelişmiş recovery senaryolarını destekler.

Oracle NOARCHIVELOG Mode Nedir?

Archive log tutulmadığı için recovery seçenekleri daha sınırlıdır.

Oracle PITR Yapılabilir mi?

Doğru backup ve archive log yapısıyla evet.

Oracle RMAN Backup Encryption Kullanılabilir mi?

Uygun platform ve yapılandırmada encrypted backup uygulanabilir.

Oracle Control File Neden Recovery İçin Önemlidir?

Database yapısına ilişkin kritik metadata içerir.

Recovery stratejisinde ayrıca dikkate alınmalıdır.

PostgreSQL, MSSQL ve Oracle Recovery Ortak Mantığı

Platformlar farklı olsa da temel model aynıdır:

Base/Full Backup

Change/Transaction Logs

Recovery Target

=

Point-in-Time Recovery

Cloud Managed Database Backup Nedir?

Cloud provider'ın database servisinin native backup ve PITR yeteneklerini sunmasıdır.

Managed Backup Kullanıyorsak Sorumluluk Bitti mi?

Hayır.

Customer;

retention,

restore testing,

access control,

encryption,

cross-region strategy

konularını yönetmelidir.

Cloud Database Automated Backup Güvenilir mi?

Teknik olarak güçlü olabilir.

Ancak restore test edilmelidir.

Cloud PITR Nedir?

Managed database'in transaction log veya engine mekanizmasıyla belirli zamana recovery yapabilmesidir.

Cross-Region Backup Neden Kullanılır?

Region-level disaster riskine karşı ek koruma sağlar.

Cross-Account Backup Nedir?

Backup'ın production cloud account'tan farklı security boundary'de tutulmasıdır.

Cross-Account Backup Ransomware Riskini Azaltır mı?

Evet.

Aynı credential compromise ile hem production hem backup'ın silinmesini zorlaştırabilir.

Cloud Backup Object Lock Kullanılabilir mi?

Uygun object storage servislerinde immutable retention sağlanabilir.

Database Backup Identity Nasıl Korunmalı?

Backup service account minimum yetkiyle çalışmalıdır.

Backup Service Account Production DBA Olmalı mı?

Mümkün olduğunca hayır.

Backup Credential Rotation Neden Önemlidir?

Statik uzun ömürlü credential riskini azaltır.

Backup Secret Kaybolursa Ne Olur?

Backup jobs durabilir.

Bu nedenle secret lifecycle ve monitoring gerekir.

Backup Job Failure Security Event midir?

Uzun süreli veya açıklanamayan failure security riski olarak değerlendirilmelidir.

Saldırgan Backup Job'u Kapatabilir mi?

Privileged access elde ederse evet.

Bu nedenle backup policy changes audit edilmelidir.

Backup Deletion Alarm Üretmeli mi?

Kritik backup'ların toplu silinmesi yüksek severity security event olabilir.

Retention Policy Change İzlenmeli mi?

Evet.

Retention'ın bir anda 90 günden 1 güne düşürülmesi şüpheli olabilir.

Immutable Mode Disabled Alarm Olmalı mı?

Evet.

Backup Repository Authentication Failure İzlenmeli mi?

Evet.

Brute-force veya credential abuse göstergesi olabilir.

Backup Management Server EDR ile Korunmalı mı?

Uyumluluk doğrulanarak kritik security control'larla korunmalıdır.

Backup System SIEM'e Log Göndermeli mi?

Kritik olaylar gönderilebilir.

Database Backup için SIEM Use Case'leri

Örnekler:

Backup Job Disabled

Mass Backup Deletion

Retention Changed

New Backup Administrator

Unexpected Restore

Immutable Policy Disabled

Restore İşlemi Neden Security Event Olabilir?

Saldırgan backup'ı farklı sisteme restore edip veriyi okuyabilir.

Unauthorized Restore Nasıl Tespit Edilebilir?

Backup management ve database audit event'leri izlenebilir.

Restore Approval Gerekli mi?

Kritik production data için kontrollü süreç kullanılabilir.

Database Backup ve KVKK

Kişisel veri backup içerisinde de kişisel veridir.

Bu nedenle backup dosyalarının erişim, saklama ve güvenliği ayrıca ele alınmalıdır.

Backup'ı Şifrelemek KVKK Uyumunu Otomatik Sağlar mı?

Hayır.

Access control, retention, secure deletion ve incident management gibi diğer kontroller de gereklidir.

Database Backup ve ISO/IEC 27001

Backup, availability, information security continuity ve recovery süreçleri risk bazlı olarak yönetilmelidir.

Database Recovery ve ISO 22301

Business continuity açısından kritik database'lerin RPO ve RTO hedefleri iş etki analiziyle ilişkilendirilebilir.

Database Backup ve PCI DSS

Kart verisi içeren backup'lar production data kadar hassas kabul edilmeli ve sıkı şekilde korunmalıdır.

Database Backup Risk Assessment

Her kritik database için şu riskler değerlendirilmelidir:

Backup failure

Restore failure

Backup deletion

Backup theft

Encryption key loss

Log chain break

Ransomware

Storage failure

Backup Single Point of Failure Nedir?

Tüm backup'ların tek storage veya tek credential'a bağımlı olmasıdır.

Single Backup Repository Riskli mi?

Evet.

Repository failure tüm recovery kabiliyetini etkileyebilir.

Backup Copies Farklı Failure Domain'lerde Olmalı mı?

Kritik sistemlerde evet.

Recovery Dependency Single Point of Failure Olabilir mi?

Evet.

Örneğin tüm backup encrypted ve tek KMS'ye bağlıysa KMS failure recovery'yi durdurabilir.

Database Recovery Test Senaryoları

Kurum farklı senaryolar test etmelidir.

Örneğin:

Single table loss

Full database loss

Storage failure

Ransomware

Regional disaster

Human error

Single Table Recovery Nedir?

Tüm database yerine belirli tablo veya objenin geri getirilmesidir.

Her Platform Single Table Restore Destekler mi?

Yöntem ve yetenek DBMS'e göre değişebilir.

Bazı durumlarda database ayrı ortama restore edilip tablo çıkarılır.

Accidental DELETE Senaryosu

Kullanıcı 14:00'te kritik veriyi siliyor.

Recovery seçenekleri:

PITR

veya

alternate restore + data extraction

olabilir.

Data Corruption Senaryosu

Database fiziksel veya logical corruption yaşarsa integrity check ve clean backup gerekir.

Logical Corruption Nedir?

Database teknik olarak çalışır ancak içindeki veriler yanlış veya tutarsızdır.

Backup Logical Corruption'ı da Kopyalar mı?

Evet.

Bu nedenle uzun retention ve multiple restore points önemlidir.

Ransomware Senaryosu

Primary database ve online backup'lar etkilenebilir.

Immutable/offline backup recovery için kritik hale gelir.

Regional Disaster Senaryosu

Primary data center tamamen erişilemez olabilir.

Offsite veya cloud DR gerekir.

Backup Test Sonuçları Dokümante Edilmeli mi?

Evet.

Restore Test Raporu Neleri İçermeli?

Backup ID

Restore Start

Restore Finish

Result

Actual RTO

Recovered Point

Actual RPO

Errors

Failed Restore Test Ne Anlama Gelir?

Backup sistemi için kritik finding'dir.

Restore Test Failure Hızla Çözülmeli mi?

Evet.

Çünkü gerçek incident anında recovery yapılamayabilir.

Database Backup KPI'ları

Örneğin:

Backup Success Rate

Restore Success Rate

Last Successful Backup Age

Actual RPO

Actual RTO

Immutable Backup Coverage

Encrypted Backup Coverage

Backup Success Rate %100 ise Sistem Güvenli mi?

Hayır.

Restore success bilinmiyorsa eksik metriktir.

Restore Test Coverage Nedir?

Database'lerin ne kadarının belirli dönem içinde restore testinden geçtiğini ölçer.

PITR Coverage Nedir?

Kritik database'lerin yüzde kaçında point-in-time recovery yeteneği bulunduğunu gösterebilir.

Immutable Backup Coverage Nedir?

Kritik database backup'larının yüzde kaçının immutable olarak korunduğunu gösterir.

Database Backup Dashboard Neler Göstermeli?

Failed Jobs

Last Backup

Last Restore Test

RPO Status

RTO Status

Immutable Coverage

Encryption Coverage

Backup Aging Nedir?

Son başarılı backup üzerinden geçen süredir.

Backup Gap Nedir?

Beklenen backup'lar arasında olması gerekenden uzun boşluk oluşmasıdır.

RPO Breach Nedir?

Gerçek backup/recovery durumu hedeflenen RPO'yu karşılayamıyorsa breach oluşur.

Örnek RPO Breach

RPO hedefi:

15 dakika.

Son log backup:

2 saat önce.

Gerçek durumda RPO hedefi karşılanmıyor.

RTO Breach Nedir?

Restore işleminin hedef süreden uzun sürmesidir.

Database Recovery Maturity Model

Seviye 1 – Backup Var

Backup job'ları çalışıyor.

Seviye 2 – Monitoring Var

Backup başarıları izleniyor.

Seviye 3 – Restore Test Var

Periyodik restore doğrulanıyor.

Seviye 4 – PITR + Immutable

Gelişmiş recovery ve ransomware dayanıklılığı var.

Seviye 5 – Cyber Recovery

Clean room, otomatik orchestration ve düzenli DR exercise uygulanıyor.

Database Backup İçin En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• Backup alıp restore test etmemek
• Snapshot'ı backup sanmak
• Replication'ı backup sanmak
• RPO ve RTO tanımlamamak
• Transaction log backup almamak
• WAL/archive log zincirini izlememek
• Backup'ı production ile aynı storage'da tutmak
• Backup'ı şifresiz saklamak
• Encryption key recovery test etmemek
• Immutable backup kullanmamak
• Backup administrator'ı aşırı yetkili yapmak
• Backup deletion olaylarını izlememek
• DR database'lerini test etmemek
• Yıllarca gerçek restore yapmamak
• Backup retention'ı dwell time dikkate almadan belirlemek

Database Backup Checklist

Kurumsal bir database backup kontrol listesi:

• Criticality belirlendi mi?
• RPO tanımlandı mı?
• RTO tanımlandı mı?
• Full backup var mı?
• Log/WAL/archive backup var mı?
• PITR mümkün mü?
• Backup farklı failure domain'de mi?
• Backup encrypted mı?
• Immutable copy var mı?
• Offsite copy var mı?
• Backup access minimum mu?
• MFA var mı?
• Backup deletion audit ediliyor mu?
• Restore test yapılıyor mu?
• Encryption key recovery test edildi mi?
• Actual RPO ölçülüyor mu?
• Actual RTO ölçülüyor mu?
• DR failover test edildi mi?

PostgreSQL Backup Checklist

• Base backup düzenli mi?
• WAL archiving çalışıyor mu?
• Archive failure alarmı var mı?
• PITR test edildi mi?
• Logical backup ihtiyaca göre kullanılıyor mu?
• Backup encrypted mı?
• Restore test yapıldı mı?

MSSQL Backup Checklist

• Recovery model doğru mu?
• Full backup var mı?
• Differential backup ihtiyaca uygun mu?
• Transaction log backup düzenli mi?
• Log chain sağlıklı mı?
• Backup encryption kullanılıyor mu?
• PITR test edildi mi?
• Restore süresi ölçüldü mü?

Oracle Backup Checklist

• RMAN backup sağlıklı mı?
• ARCHIVELOG ihtiyaca uygun aktif mi?
• Archive log'lar korunuyor mu?
• Control file recovery planı var mı?
• Backup encryption uygulanıyor mu?
• Recovery test edildi mi?
• PITR senaryosu doğrulandı mı?

Yönetimin Sorması Gereken Database Recovery Soruları

Yönetim şu soruların cevaplarını alabilmelidir:

Kritik database'lerimizin RPO'su nedir?

RTO'su nedir?

Son başarılı backup ne zaman?

Son gerçek restore testi ne zaman yapıldı?

Backup'larımız immutable mı?

Backup'larımız şifreli mi?

Transaction log/WAL/archive zinciri sağlıklı mı?

Ransomware durumunda temiz backup'ımız var mı?

Database'i başka data center'a ne kadar sürede kaldırabiliriz?

Encryption key kaybolursa recovery yapabilir miyiz?

Sık Sorulan Sorular

Database backup nedir?

Veritabanının veri kaybı veya sistem arızası sonrasında geri getirilebilmesi için oluşturulan güvenli kopyadır.

Restore nedir?

Backup'tan database'in tekrar kullanılabilir hale getirilmesidir.

Point-in-Time Recovery nedir?

Database'in belirli tarih ve saate geri döndürülmesidir.

RPO nedir?

Kurumun kabul edebileceği maksimum veri kaybı süresidir.

RTO nedir?

Sistemin kabul edilebilir maksimum geri dönüş süresidir.

Snapshot backup yerine geçer mi?

Tek başına genellikle hayır. Aynı storage failure veya ransomware etkisine maruz kalabilir.

Replication backup yerine geçer mi?

Hayır. Yanlış veya kötü niyetli veri değişikliği replica'ya da taşınabilir.

PostgreSQL WAL ne işe yarar?

Transaction değişikliklerini kayıt altına alır ve uygun yapılandırmada PITR için kullanılabilir.

MSSQL transaction log backup neden önemlidir?

Point-in-time recovery ve düşük RPO hedefleri için önemli bir recovery bileşenidir.

Oracle archive log neden gereklidir?

Database değişikliklerinin recovery sırasında tekrar uygulanabilmesini sağlayan önemli log kayıtlarıdır.

Immutable backup nedir?

Belirli süre boyunca değiştirilemeyen veya silinemeyen backup'tır.

Backup başarılıysa restore testi gerekli mi?

Kesinlikle. Başarılı backup job gerçek recovery başarısını garanti etmez.

Sonuç: Backup'ın Değeri Alındığı Gün Değil, Geri Dönüldüğü Gün Anlaşılır

Database backup süreçlerinde en sık yapılan hata backup job başarı oranını gerçek güvenlik metriği olarak kabul etmektir.

Oysa asıl amaç backup almak değildir.

Amaç:

database'i geri getirebilmektir.

Gerçek database recovery kabiliyeti şu bileşenlerin birlikte çalışmasını gerektirir:

Backup

Transaction Log / WAL / Archive Log

PITR

Encryption

Immutable Storage

Restore Testing

RPO / RTO

Bir backup'ın değeri ancak restore edildiğinde anlaşılır.

Bu nedenle kurumların:

“Backup alıyor muyuz?”

sorusu yerine şu soruları sorması gerekir:

“Hangi zamana kadar dönebiliyoruz?”

“Ne kadar veri kaybedebiliriz?”

“Ne kadar sürede ayağa kalkabiliriz?”

“Backup'ımız saldırgandan korunuyor mu?”

“Encryption key'imiz gerçekten kullanılabilir mi?”

“Son restore testimiz ne zaman başarılı oldu?”

PostgreSQL için WAL,

MSSQL için Transaction Log,

Oracle için Archive Log

farklı teknolojiler olsa da aynı amaca hizmet eder:

Database'in yalnızca son backup noktasına değil, mümkün olduğunca ihtiyaç duyulan doğru zamana döndürülebilmesini sağlamak.

Gerçek recovery olgunluğu:

Backup Success

değil;

Verified Recoverability

ile ölçülmelidir.

Yani:

Doğrulanmış geri dönüş kabiliyeti.