DevOps mühendisleri, Veritabanı Yöneticileri (DBA’ler) ve BT sistem mimarları için Kurtarma Zamanı Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO), iş sürekliliği ile ilgili moda sözcüklerden çok daha fazlasıdır; bunlar katı mühendislik kısıtlamalarıdır. Görev açısından kritik veritabanlarını yönetirken, bu metrikleri doğru bir şekilde hesaplamamak, bunlar için mimari oluşturmamak ve doğrulamamak, felaket niteliğinde veri kaybına ve uzun süreli kesintilere yol açabilir.
Modern kurumsal ortamlarda RTO ve RPO’yu hesaplamak; veritabanı iç işleyişi, depolama G/Ç’si, ağ verimi ve işlem günlüğü mekanizmaları hakkında derin bir anlayış gerektirir. Bu kılavuz, üretim veritabanı sistemleri için RTO ve RPO’yu hesaplama, test etme ve optimize etmeye yönelik teknik yöntemleri incelemektedir.
Veritabanı Sistemlerinde RPO’yu (Kurtarma Noktası Hedefi) Çözümleme
RPO, zaman cinsinden ölçülen kabul edilebilir maksimum veri kaybı miktarını tanımlar. RPO’nuz 15 dakikaysa, saat 12:00’de meydana gelen bir felaket, en az 11:45’e kadar olan tüm onaylanmış işlemleri kurtarabilmeniz gerektiği anlamına gelir.
Veritabanları için RPO, işlem günlüğü yönetimi stratejiniz (PostgreSQL’de WAL, Oracle’da Redo Günlükleri, SQL Server’da İşlem Günlükleri) tarafından belirlenir.
Veri Kaybı ve Günlük Oluşturmanın Mekanikleri
Elde edilebilir RPO’yu hesaplamak için öncelikle veritabanınızın işlem günlüğü oluşturma hızını anlamanız gerekir. Günlükleri her 15 dakikada bir yedekleme deposuna gönderiyorsanız ancak ağınız bu süre zarfında 15 dakikalık günlükleri aktaramıyorsa, gerçek RPO’nuz sürekli olarak kötüleşecektir.
Günlük oluşturma hızınızı yerel SQL komutlarını kullanarak temel alabilirsiniz. Örneğin, PostgreSQL’de (sürüm 10+) belirli bir aralıkta Yazma Öncesi Günlük (WAL) oluşturma hızını ölçebilirsiniz:
-- Bunu T=0 anında çalıştırın
SELECT pg_current_wal_lsn() AS start_lsn;
-- Tam 5 dakika (300 saniye) bekleyin, ardından şunu çalıştırın:
SELECT pg_current_wal_lsn() AS end_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;
Bu sorgu, yoğun yük altında 50 MB/s WAL verisi oluşturduğunuzu ortaya koyuyorsa, 15 dakikalık bir RPO, yedekleme depolama alanınıza 45 GB günlük verisi aktarmanızı gerektirir. Ağınız ve depolama hedefleriniz, bu RPO’yu korumak için 50 MB/s’yi aşan sürekli yazma hızlarını desteklemelidir.
Senkron ve Asenkron Çoğaltmanın (Replication) Etkisi
Birçok DBA, RPO’yu karşılamak için Yüksek Erişilebilirlik (HA) çoğaltmasına güvenir. Ancak çoğaltma bir yedekleme değildir. Silinen bir tablo (DROP TABLE users;) anında çoğaltılır.
Felaket Kurtarma (DR) için çoğaltma kullanıldığında, çoğaltma modu doğrudan RPO’yu etkiler:
* Senkron Çoğaltma: Sıfır RPO (RPO=0) garantisi verir. Birincil veritabanı, beklemedeki (standby) veritabanı alımı onaylayana kadar bir işlemi onaylamaz. Bunun karşılığındaki ödünleşim, birincil yazma işlemlerinde artan gecikmedir.
* Asenkron Çoğaltma: Çoğaltma gecikmesi yaratır. RPO’nuz etkili bir şekilde mevcut çoğaltma gecikmenize eşittir.
PostgreSQL’de asenkron çoğaltma gecikmesini izlemek için şunu kullanın:
SELECT application_name,
client_addr,
state,
sync_state,
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;
Büyük Ölçekli Veritabanları için RTO’yu (Kurtarma Zamanı Hedefi) Çözümleme
RTO, tolere edilebilir maksimum kesinti süresidir. Veritabanı RTO’sunu hesaplamak oldukça karmaşıktır çünkü bu sadece dosyaları bir sunucuya geri kopyalamak için geçen süre değildir.
RTO Hesaplaması için Matematiksel Model
Gerçekçi bir veritabanı RTO hesaplaması dört farklı aşamayı hesaba katmalıdır:
RTO = T(altyapı) + T(aktarım) + T(geri yükleme) + T(kurtarma)
- T(altyapı) – Altyapı Hazırlama: Yedek bilgi işlem ve depolama alanını ayağa kaldırma süresi. (Önceden hazırlanmış DR siteleri veya Kod Olarak Altyapı hatları ile sıfıra yakın olabilir).
- T(aktarım) – Veri Aktarımı: Yedekleme yükünü depodan veritabanı sunucusuna taşıma süresi.
- T(geri yükleme) – Fiziksel Geri Yükleme: Veri dosyalarını hedef diske yazma süresi.
- T(kurtarma) – Veritabanı Çökme Kurtarma: Veritabanı motorunun işlem günlüklerini yeniden oynatması, onaylanmış işlemleri ileri alması ve onaylanmamış olanları geri alması için geçen süre.
Aktarım ve Geri Yükleme Sürelerini Hesaplama
T(aktarım) ve T(geri yükleme) sürelerini hesaplamak için ağ bant genişliğinizi ve disk IOPS/veriminizi temel almalısınız. Teorik maksimumlara güvenmeyin; gerçek altyapınızı test edin.
Yedekleme deponuz ile veritabanı sunucunuz arasındaki ağ verimini test etmek için iperf3 kullanın:
# Yedekleme deposunda (sunucu)
iperf3 -s
# Veritabanı sunucusunda (istemci)
iperf3 -c <backup_repo_ip> -t 60 -P 4
Veritabanı geri yükleme işlemini simüle ederek veritabanı depolama birimlerinizin sıralı yazma performansını test etmek için fio kullanın:
fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile
Veritabanınız 5 TB ise ve fio testleriniz 500 MB/s’lik maksimum sürekli yazma hızı gösteriyorsa, mutlak minimum T(geri yükleme) süreniz yaklaşık 2,8 saattir. İşletme SLA’nız 1 saatlik bir RTO talep ediyorsa, geleneksel akışlı geri yüklemeler başarısız olacaktır. Mimarınızı depolama düzeyi anlık görüntülerine (snapshot) veya blok düzeyi çoğaltmaya yönlendirmeniz gerekir.
Gizli Tuzak: T(kurtarma)
En sık hafife alınan değişken T(kurtarma)‘dır. Haftalık tam bir yedeği geri yüklerseniz ve RPO’nuza ulaşmak için 6 günlük işlem günlüğünü uygulamanız gerekirse, veritabanı motoru her işlemi sırayla yeniden oynatmalıdır.
500 GB’lık işlem günlüğünü yeniden oynatmak, tek iş parçacıklı CPU performansı ve depolama IOPS’si nedeniyle ciddi şekilde darboğaza girerek saatler sürebilir. T(kurtarma) süresini en aza indirmek için tam veya farklı yedeklemelerinizin sıklığını artırın.
Boşluğu Kapatmak: RTO ve RPO’yu Doğrulamak İçin Pratik Adımlar
Teorik RTO ve RPO’yu hesaplamak sadece ilk adımdır. Görev açısından kritik ortamlar sürekli doğrulama gerektirir.
1. Adım: Sürekli Arşivlemeyi Uygulayın
Senkron çoğaltmanın performans cezası olmadan dakika altı RPO’lara ulaşmak için sürekli günlük arşivlemeyi uygulayın. Bir günlük dosyasının dolmasını beklemek yerine (düşük trafik dönemlerinde saatler sürebilir), günlük geçişlerini düzenli aralıklarla zorlayın.
SQL Server’da, sık İşlem Günlüğü yedeklemelerini otomatikleştirebilirsiniz:
BACKUP LOG [MissionCriticalDB]
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'MissionCriticalDB-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
En İyi Uygulama: Bu işi RPO gereksinimlerinize bağlı olarak her 1-5 dakikada bir çalışacak şekilde zamanlayın.
2. Adım: Geri Yükleme Testini Otomatikleştirin
Test edilmemiş bir yedekleme sadece teorik bir kavramdır. Hesaplanan RTO’nuzu garanti etmek için otomatik geri yükleme testleri yapmalısınız.
CloudSave gibi kurumsal yedekleme platformları, otomatik, yalıtılmış kurtarma testi sağlayarak bunu basitleştirir. CloudSave, otomatik olarak bir korumalı alan (sandbox) ortamı oluşturabilir, en son yedeği bağlayabilir, tam bir veritabanı kurtarma işlemi gerçekleştirebilir ve tam RTO’yu ölçmek ve veri bütünlüğünü sağlamak için özel doğrulama komut dosyaları (örneğin, SQL Server için DBCC CHECKDB) çalıştırabilir. Bu, RTO’yu hesaplanmış bir tahminden kanıtlanmış, raporlanabilir bir metriğe dönüştürür.
3. Adım: SLA İhlallerini İzleyin ve Uyarı Verin
İzleme yığınınız (Prometheus, Datadog, Zabbix) RTO/RPO SLA’larınızı tehdit eden metrikleri aktif olarak takip etmelidir. Uyarı kuralları şunlar için yapılandırılmalıdır:
* Yedekleme İşi Hataları: RPO için acil tehdit.
* Günlük Gönderme Gecikmesi: Günlük aktarımı, oluşturma aralığından uzun sürerse.
* Depolama IOPS Kısıtlaması: Bulut sağlayıcıları (AWS EBS gibi), ani artış kredileri tükenirse IOPS’yi kısıtlar; bu, gerçek bir acil durumda RTO’nuzu sessizce yok edecektir.
Katı SLA’ları Karşılamak İçin Veritabanı Yedekleme Mimarisini Optimize Etme
Matematiksel hesaplamalar mevcut mimarinizin iş SLA’larını karşılayamayacağını ortaya koyduğunda, yedekleme stratejinizi optimize etmelisiniz.
1. Blok Düzeyinde Artımlı Yedeklemelerden Yararlanın
Geleneksel veritabanı dökümleri (pg_dump veya mysqldump gibi mantıksal yedeklemeler), görev açısından kritik RTO’lar için çok yavaştır. Fiziksel, blok düzeyinde yedeklemeler kullanın. Blok düzeyinde artımlı yedeklemeler, yalnızca son yedeklemeden bu yana değişen disk bloklarını kopyalar ve T(aktarım) ile ağ yükünü önemli ölçüde azaltır.
2. Depolama Anlık Görüntülerini (Snapshot) Kullanın
15 dakikadan kısa bir RTO gerektiren çok terabaytlık veritabanları için geleneksel dosya kopyalama, standart ağlar üzerinden fiziksel olarak imkansızdır. SAN veya bulut yerel depolama anlık görüntüleri (örneğin, AWS EBS Snapshots, Pure Storage) ile entegrasyon, neredeyse anlık T(geri yükleme) sağlar. Veritabanı motorunun daha sonra anlık görüntü üzerinde yalnızca çökme kurtarma işlemi yapması gerekir.
3. Paralelliği Uygulayın
Yedekleme ve geri yükleme araçlarınızın çoklu iş parçacığı (multi-threading) kullandığından emin olun. pgbackrest kullanarak bir PostgreSQL veritabanını veya bir SQL Server veritabanını geri yüklerken, mevcut ağ ve disk bant genişliğinizi doyurmak için paralel çalışan iş parçacıklarını açıkça tanımlayın.
# pgBackRest'te paralel geri yükleme örneği
pgbackrest --stanza=prod_db --process-max=8 restore
Sonuç
Görev açısından kritik veritabanları için RTO ve RPO hesaplamak, sistem mühendisliğinde titiz bir egzersizdir. DBA’lerin varsayılan yedekleme yapılandırmalarının ötesine geçmelerini ve depolama G/Ç’lerini, ağ kapasitelerini ve veritabanı kurtarma mekaniklerini matematiksel olarak modellemelerini gerektirir.
Günlük oluşturma hızlarını temel alarak, veritabanı kurtarmanın farklı aşamalarını anlayarak ve CloudSave gibi sağlam platformlar aracılığıyla otomatik testleri uygulayarak, BT ekipleri felaket kurtarma SLA’larını güvenle garanti edebilirler. Unutmayın: veritabanı yönetimi alanında umut bir strateji değildir ve test edilmemiş yedeklemeler bir yükümlülüktür.
DevOps mühendislerinin ve DBA’lerin gelişmiş kurtarma mekanikleri, CLI araçları ve otomatik testleri kullanarak görev açısından kritik veritabanları için RTO ve RPO’yu nasıl doğru bir şekilde hesaplayabileceklerini, test edebileceklerini ve optimize edebileceklerini öğrenin.
