İÇİNDEKİLER
- •Felaket kurtarma planınız gerçekten çalışıyor mu?
- •Kısaca: Temel Kavramlar
- •HA, DR ve Yedekleme Birbirinin Yerini Tutmaz
- •RPO ve RTO Nasıl Belirlenir?
- •Platformlara Göre DR Seçenekleri
- •Bir DR Planı Neleri İçermeli?
- •Tatbikat: Planın Gerçekten Çalıştığını Kanıtlayın
- •Felaket Anında Sık Yapılan Hatalar
- •Düzenlemeye Tabi Sektörler
- •Aryasoft ile Felaket Kurtarma
- •Sıkça Sorulan Sorular
- •Kaynaklar
- •Planınızı tatbikatla kanıtlayın
Veritabanı felaket kurtarma (disaster recovery, DR) planı, bir veri merkezi kaybı, fidye yazılımı saldırısı, ciddi bir veri bozulması veya insan hatası sonrasında veritabanlarının hangi sürede ve en fazla ne kadar veri kaybıyla yeniden hizmete açılacağını tanımlayan ve bunun nasıl yapılacağını adım adım anlatan dokümandır. Planın iki temel ölçüsü RPO (kabul edilebilir en fazla veri kaybı) ve RTO (kabul edilebilir en uzun kesinti süresi) değerleridir. Test edilmemiş bir plan ise yalnızca bir niyet beyanıdır.
Bu rehber; SQL Server, Oracle ve PostgreSQL kullanan kurumların BT yöneticileri ve iş sürekliliğinden sorumlu ekipleri için hazırlandı.
Felaket kurtarma planınız gerçekten çalışıyor mu?
Aryasoft, veritabanlarınız için RPO ve RTO hedeflerini sizinle birlikte belirler, uygun mimariyi kurar ve planı düzenli tatbikatlarla doğrular.
Kısaca: Temel Kavramlar
| Kavram | Anlamı | Örnek soru |
|---|---|---|
| RPO (Recovery Point Objective) | Kabul edilebilir en fazla veri kaybı | “Son kaç dakikalık veriyi kaybetmeyi kabul edebiliriz?” |
| RTO (Recovery Time Objective) | Hizmetin yeniden açılması için kabul edilebilir en uzun süre | “Sistem en geç kaç saat içinde çalışır durumda olmalı?” |
| Yüksek erişilebilirlik (HA) | Tek bir sunucu veya bileşen arızasında hizmetin sürmesi | Aynı veri merkezinde otomatik failover |
| Felaket kurtarma (DR) | Bir lokasyonun tamamen kaybında hizmetin başka yerde açılması | İkinci veri merkezinde veya bulutta yedek sistem |
| Yedekleme | Verinin belirli bir andaki kopyası | Mantıksal hatalardan ve fidye yazılımından kurtulmanın son güvencesi |
HA, DR ve Yedekleme Birbirinin Yerini Tutmaz
En sık karşılaşılan yanılgı, yüksek erişilebilirlik çözümünün felaket kurtarmayı veya yedeklemeyi de karşıladığını düşünmektir.
| Senaryo | HA korur mu? | DR korur mu? | Yedek korur mu? |
|---|---|---|---|
| Sunucu donanım arızası | Evet | Evet | Evet (daha uzun sürede) |
| Veri merkezi kaybı (yangın, sel, uzun elektrik kesintisi) | Hayır (aynı lokasyondaysa) | Evet | Evet (yedek başka lokasyondaysa) |
| Yanlışlıkla silinen tablo veya hatalı UPDATE | Hayır; hata replikalara da yansır | Hayır; hata DR sistemine de yansır | Evet |
| Fidye yazılımı | Hayır | Çoğu zaman hayır | Evet, yalnızca saldırgan erişemiyorsa |
| Mantıksal veri bozulması | Hayır | Hayır | Evet |
Kritik
Fidye yazılımı saldırılarında saldırganlar önce yedekleri hedef alır. Yedekleriniz aynı etki alanı kimlik bilgileriyle erişilebilen bir disk veya paylaşımdaysa, saldırıda onlar da şifrelenir. En az bir yedek kopyası değiştirilemez (immutable) depolamada veya ağdan ayrılmış bir ortamda tutulmalıdır.
RPO ve RTO Nasıl Belirlenir?
RPO ve RTO teknik ekibin değil, iş biriminin kararıdır; teknik ekip ise her hedefin maliyetini gösterir. Sıfıra yaklaşan RPO ve RTO, katlanarak artan bir maliyet demektir. Bu yüzden her sistem için ayrı hedef belirlenmelidir:
| Sistem sınıfı | Örnek | Tipik RPO | Tipik RTO |
|---|---|---|---|
| Kritik | Ödeme, sipariş, üretim planlama | Dakikalar veya sıfır | Dakikalar – 1 saat |
| Önemli | ERP, CRM, muhasebe | 15 dakika – 1 saat | Birkaç saat |
| Standart | Raporlama, iç uygulamalar | 1 gün | 1 iş günü |
| Arşiv | Geçmiş veriler | 1 hafta | Birkaç gün |
Bu değerler örnektir. Kendi değerlerinizi belirlerken şu soruyu sorun: “Bu sistem bir saat çalışmazsa veya son bir saatlik veri kaybolursa işe maliyeti nedir?”
Platformlara Göre DR Seçenekleri
| Platform | Seçenek | RPO | Not |
|---|---|---|---|
| SQL Server | Uzak lokasyonda asenkron Always On replika | Saniyeler | Enterprise sürüm; failover kararı ve quorum tasarımı kritik |
| SQL Server | Log shipping | Dakikalar (log yedeği sıklığı) | Basit ve dayanıklı; failover manuel |
| SQL Server | Yedeklerin başka lokasyona veya buluta kopyalanması | Log yedeği sıklığı | En düşük maliyet; RTO geri yükleme süresine bağlı |
| Oracle | Data Guard (fiziksel standby) | Saniyeler veya sıfır (moda göre) | Enterprise Edition; Active Data Guard ek lisans gerektirir |
| Oracle | RMAN yedekleri ve arşiv logların başka lokasyona kopyalanması | Arşiv log sıklığı | RTO geri yükleme süresine bağlı |
| PostgreSQL | Uzak lokasyonda streaming replika | Saniyeler | Yerleşik özellik; failover için küme yöneticisi veya prosedür |
| PostgreSQL | pgBackRest deposunun başka lokasyonda tutulması (WAL arşivi ile) | Saniyeler – dakikalar | Belirli bir ana geri dönüş (PITR) imkânı |
SQL Server’ın yüksek erişilebilirlik seçeneklerini HA karşılaştırma rehberimizde, DR tasarımlarında sık yapılan quorum hatasını ise Always On yazılarımızda anlattık. PostgreSQL için yüksek erişilebilir ortam kurulumu yazımıza göz atabilirsiniz.
Bir DR Planı Neleri İçermeli?
| Bölüm | İçerik |
|---|---|
| Kapsam ve hedefler | Hangi sistemler, her biri için RPO ve RTO |
| Mimari | Birincil ve DR lokasyonları, replikasyon ve yedekleme akışları, bağımlılıklar (Active Directory, DNS, uygulama sunucuları) |
| Karar mekanizması | Felaketi kim ilan eder, hangi koşullarda DR’a geçilir |
| İletişim listesi | Teknik ekip, iş birimleri, tedarikçiler; telefonlar ve yedek iletişim kanalları |
| Adım adım prosedürler | DR’a geçiş, uygulamaların yönlendirilmesi, doğrulama, birincil lokasyona geri dönüş |
| Kimlik bilgileri | Felaket anında erişilebilir, güvenli bir kasada saklanan yönetici hesapları |
| Doğrulama kontrolleri | Veri tutarlılığı, kritik iş akışlarının testi |
| Tatbikat kayıtları | Son testin tarihi, ölçülen süreler, bulunan eksikler |
Uyarı
DR planını yalnızca birincil sistemin erişilebilir olduğu ortamda saklamayın. Felaket anında planın kendisine, kimlik bilgilerine ve iletişim listesine ulaşılamaması, sık karşılaşılan ama kolayca önlenebilen bir başarısızlık nedenidir.
Tatbikat: Planın Gerçekten Çalıştığını Kanıtlayın
| Test türü | Ne yapılır? | Sıklık |
|---|---|---|
| Yedekten geri yükleme testi | Kritik veritabanları ayrı bir sunucuya geri yüklenir, süre ölçülür. | Ayda bir veya üç ayda bir |
| Masa başı tatbikat | Ekip, bir senaryo üzerinden planı adım adım konuşarak yürütür. | Altı ayda bir |
| Kısmi DR testi | Bir veya birkaç sistem DR lokasyonunda açılır ve doğrulanır. | Yılda bir veya iki kez |
| Tam DR tatbikatı | Birincil lokasyon kapatılmış gibi tüm kritik sistemler DR’da çalıştırılır. | Yılda bir |
Her tatbikatın sonunda üç soruyu yanıtlayın: Hedeflenen RTO’ya ulaşıldı mı? Ne kadar veri kaybedildi? Plan dışında yapılması gereken ne oldu? Üçüncü sorunun yanıtları, planın bir sonraki sürümüne eklenmelidir.
Felaket Anında Sık Yapılan Hatalar
Sahada en sık gördüğümüz hatalar teknik değil, panikle verilen kararlardır: sistemi tekrar tekrar yeniden başlatmak, aynı anda birden fazla kişinin farklı müdahaleler yapması, kurtarma süreci devam ederken veritabanını başka bir sunucuya geri yüklemeye çalışmak. Kesinti anında sakin bir yol haritası için ilk 30 dakika runbook’umuza ve RECOVERY PENDING ve SUSPECT rehberimize göz atabilirsiniz.
Düzenlemeye Tabi Sektörler
Bankacılık sektöründe Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik, birincil ve ikincil sistemlerin yurt içinde bulunmasını ve sürekliliği sağlayacak yeterli personelin yurt içinde olmasını şart koşar. DR lokasyonu seçerken, özellikle bulut tabanlı çözümlerde, veri konumu gerekliliklerini mutlaka değerlendirin.
Aryasoft ile Felaket Kurtarma
Aryasoft, veritabanlarınız için RPO ve RTO hedeflerini iş birimlerinizle birlikte belirler, SQL Server, Oracle ve PostgreSQL için uygun DR mimarisini kurar, yedekleme ve saklama politikasını ve acil durum eylem planını dokümante eder ve planı düzenli tatbikatlarla doğrular. Gerçek kurtarma örneklerimiz için 1 dakikalık RPO ile kurtarma, Always On ortamında veri kaybı olmadan kurtarma ve bir ödeme kuruluşu için sıfır kesintili veri kurtarma hikâyelerimize göz atabilirsiniz. Yedekleme tarafının ayrıntılarını backup planı rehberimizde anlattık.
Sıkça Sorulan Sorular
Kaynaklar
Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki kaynaklarla karşılaştırıldı.
- Microsoft Learn: Business continuity and database recovery – SQL Server
- Microsoft Learn: About log shipping
- Oracle Data Guard Concepts and Administration
- PostgreSQL dokümantasyonu: Continuous Archiving and Point-in-Time Recovery
- PostgreSQL dokümantasyonu: Log-Shipping Standby Servers
- Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik, Resmî Gazete, 15 Mart 2020, sayı 31069
Felaket Kurtarma
Planınızı tatbikatla kanıtlayın
Aryasoft RPO ve RTO hedeflerinizi belirler, DR mimarisini kurar, planı dokümante eder ve düzenli tatbikatlarla doğrular.
