Genel Bakış
SAP HANA veritabanı, in-memory mimarisi nedeniyle geleneksel veritabanı yedekleme yaklaşımlarından farklı bir strateji gerektirir. HANA veri ve log yedeklemeleri, savepoint mekanizması ve delta backup yapısıyla düzenlenir. Doğru yapılandırılmamış yedekleme politikası; log alanının dolmasına, sistem arızasına veya felaket anında beklenen kurtarma süresinin aşılmasına yol açar.
SAP Backint interface, üçüncü taraf yedekleme çözümlerini HANA ile entegre etmek için tasarlanmış standart bir arayüzdür. Commvault, Veeam ve NetBackup gibi enterprise yedekleme platformları Backint aracılığıyla HANA yedeklemelerini doğrudan nesne depolama veya tape'e yazabilir. Bu entegrasyon; yedekleme yönetimini mevcut kurumsal yedekleme platformuyla konsolide eder, ayrı araç yönetimi gereksinimini ortadan kaldırır.
Point-in-time recovery (PITR), SAP HANA'nın kritik kurtarma yeteneklerinden biridir. Log yedekleri sayesinde belirli bir zaman noktasına (dakika veya saniye hassasiyetiyle) geri dönmek mümkündür. Bu özellik; insan hatası, yanlış DML işlemi veya uygulama hatası nedeniyle oluşan veri kaybının minimum kayıpla telafi edilmesini sağlar. PITR etkinliği, log yedekleme sıklığı ve saklama süresiyle doğru orantılıdır.
Fidye yazılımı tehdidi SAP yedekleme stratejisini siber güvenlik perspektifinden yeniden şekillendirmiştir. Üretim sistemine erişimi olan fidye yazılımı, bağlı yedekleme hedefini de şifreleyebilir. Immutable storage hedefi ve air-gapped kopya stratejisi, SAP yedeklemelerini fidye yazılımı saldırısına karşı korumak için zorunlu bileşenler haline gelmiştir.
SAP dünyasında yedekleme konusu çoğu zaman altyapı ekibinin operasyonel görevi gibi görülür; oysa gerçekte bu başlık iş sürekliliğinin en kritik güvencesidir. Çünkü SAP sistemleri yalnızca veri tutmaz; finansal kayıtlar, üretim planları, sevkiyat bilgileri, müşteri hareketleri ve regülasyon açısından kritik geçmiş veriyi taşır. Dolayısıyla bir SAP kurtarma başarısızlığı, teknik sorun olmanın çok ötesinde kurumsal itibar, hukuki risk ve operasyonel duruş anlamına gelir. Bu yüzden SAP Backup & Recovery, gündelik yedek alma işinden ayrı ve daha disiplinli bir yaklaşımla ele alınmalıdır.
HANA'nın in-memory yapısı, klasik veritabanı alışkanlıklarıyla yönetilemeyecek kadar farklıdır. Bellekte çalışan veri motoru, log akışının sürekliliğine, savepoint davranışına ve depolama katmanının tutarlılığına çok daha duyarlıdır. Yedekleme politikası yanlış tasarlandığında yalnızca kurtarma süreleri uzamaz; operasyon sırasında log taşması, performans düşüşü veya başarısız backup zinciri gibi sorunlar da yaşanabilir. Bu nedenle Indexline yedekleme tasarımını yalnızca saklama süresi açısından değil, HANA davranışını merkeze alarak planlar.
Bir başka kritik başlık, yedeklemenin kurumun genel felaket kurtarma ve siber güvenlik stratejisinden bağımsız düşünülememesidir. Yedekler tek başına değerli değildir; ne kadar sürede geri dönüleceği, hangi zaman noktasına kadar geri dönüş yapılabileceği, hangi ortamda test edileceği ve saldırı sonrası temiz olduğunun nasıl doğrulanacağı da aynı derecede önemlidir. Özellikle fidye yazılımı saldırılarında kuruma gerçek güvence veren unsur, yedek almış olmak değil; saldırıdan etkilenmemiş, test edilmiş ve güvenle ayağa kaldırılabilir yedeklere sahip olmaktır.
SAP Backup & Recovery hizmetinde yönetişim boyutu da önemlidir. Hangi sistemin hangi sıklıkla yedekleneceği, ne kadar süre saklanacağı, hangi verinin yasal saklama kapsamına girdiği, hangi ekiplerin kurtarma onayı vereceği ve restore testlerinin ne zaman yapılacağı önceden tanımlanmalıdır. Bu yapı kurulmadığında yedekler vardır ama kimse gerçekten neyi, ne kadar sürede ve hangi doğrulukla geri döndürebileceğini bilmez. Indexline bu belirsizliği kaldırmak için teknik planı süreç planı ile birlikte kurgular.
Kurumsal ölçekte SAP yedekleme maliyeti de önemli bir parametredir. Tüm veriyi aynı hız ve aynı saklama politikasıyla tutmak çoğu zaman gereksiz pahalıdır. Sık erişilen kısa dönem yedekler, daha yavaş ama ekonomik uzun dönem saklama katmanları ve immutable hedefler birlikte kullanıldığında hem güvenli hem rasyonel bir model kurulabilir. Bu sayede maliyet baskısı altında dahi koruma seviyesinden taviz vermeden sürdürülebilir yedekleme mimarisi oluşturulur.
Sonuçta SAP Backup & Recovery, kurumun “en kötü gün” hazırlığının somut karşılığıdır. Doğru tasarlanmış bir strateji, olağan günlerde görünmez olabilir; ancak bir veri kaybı, yanlış işlem veya güvenlik olayı yaşandığında kurumun ne kadar hazır olduğunu dakikalar içinde ortaya koyar. Indexline bu yüzden yedeklemeyi pasif bir arka plan görevi değil, aktif olarak doğrulanan ve sürekli iyileştirilen bir güvence katmanı olarak yönetir.
Nasıl Çalışır?
Yedekleme Strateji Tasarımı: RPO hedefi, saklama süresi, yedekleme penceresi ve depolama kapasitesi analiz edilerek yedekleme politikası tasarlanır.
Backint Entegrasyonu: HANA Backint arayüzü üçüncü taraf yedekleme platformuyla entegre edilir.
Data & Log Yedekleme: Tam, artımlı ve diferansiyel data yedek programı kurulur. Log backup sıklığı RPO hedefine göre ayarlanır.
Depolama Yapılandırması: Hızlı kurtarma için disk, uzun dönem saklama için tape/nesne depolama katmanlı yapılandırılır.
Immutable Backup: Fidye yazılımı koruması için değiştirilemez yedek hedefi yapılandırılır.
Restore Testi: Üretimden yalıtılmış ortamda periyodik restore testi gerçekleştirilir ve RTO doğrulanır.
İzleme: Yedekleme başarı/başarısızlık durumu, süre ve boyut metrikleri izlenir. Başarısız yedekler alarmla raporlanır.
Temel Özellikler
HANA Backint Entegrasyonu
Endüstri standardı Backint arayüzüyle enterprise yedekleme platformlarına sorunsuz entegrasyon sağlanır.
Artımlı Yedekleme
Artımlı ve diferansiyel yedekleme stratejisiyle yedekleme penceresi ve depolama kullanımı optimize edilir.
Log Yedekleme Otomasyonu
Log backup sıklığı RPO hedefine göre otomatik yapılandırılır. Log alanı yönetimi otomatikleştirilir.
Point-in-Time Recovery
Dakika hassasiyetiyle belirli bir zaman noktasına kurtarma imkânı. İnsan hatası ve yanlış DML sonrası hızlı kurtarma.
Immutable Backup
Değiştirilemez yedek hedefi ile fidye yazılımı saldırısında yedekler korunmuş kalır.
Multi-Tier Depolama
Sık erişilen yeni yedekler disk, eski yedekler ekonomik nesne depolama veya tape'e otomatik taşınır.
Otomatik Restore Testi
Periyodik restore tatbikatı gerçekleştirilir; kurtarma zamanı ölçülür ve RTO hedefiyle karşılaştırılır.
SAP HANA Cockpit Entegrasyonu
Yedekleme durumu SAP HANA Cockpit ve merkezi izleme platformundan tek konsolda izlenir.
Faydalar ve Avantajlar
SAP verisi arıza veya saldırı senaryosunda RPO/RTO hedefleri çerçevesinde eksiksiz kurtarılır.
Immutable backup fidye yazılımı saldırısında SAP verisi için güvenilir kurtarma noktası garantiler.
PITR ile insan hatası kaynaklı veri kayıpları dakikalar içinde ve minimum veri kaybıyla kurtarılır.
Yedekleme yönetiminin mevcut enterprise platforma entegrasyonu ayrı araç yönetimi yükünü kaldırır.
Periyodik restore testi, yedek alındığını değil kurtarılabildiğini kanıtlar.
Multi-tier depolama ile uzun dönem yedekleme maliyeti optimize edilir.
Kurtarma senaryoları önceden test edildiği için kriz anında belirsizlik ve karar baskısı azalır.
Yasal saklama, denetim ve iç kontrol ihtiyaçları için daha izlenebilir bir veri koruma yapısı oluşur.
HANA'ya özgü log ve veri koruma davranışı dikkate alındığından operasyonel riskler azalır.
Siber saldırı sonrası temiz kurtarma noktası bulma ve doğrulama süreci hızlanır.
Sektörel Kullanım Senaryoları
Üretim
SAP ERP yanlış veri girişi sonrası PITR ile 45 dakika önceki temiz duruma getirildi; sıfır iş kesintisi yaşandı.
Perakende
Fidye yazılımı saldırısında immutable backup ile SAP sistemi temiz kurtarma noktasından 2 saat içinde restore edildi.
Lojistik
SAP TM günlük yedek stratejisi saatlik log backup ile güçlendirildi; RPO 24 saatten 1 saate indi.
Finans
SAP FI-CO yedekleme tatbikatı yapıldı; restore süresinin hedefin 2 katında olduğu tespit edilerek altyapı optimize edildi.
Enerji
SAP IS-U kritik müşteri veri tablosunun silinmesi PITR ile 30 dakika içinde kurtarıldı; müşteri kesintisi minimize edildi.
Kamu
Kurumsal SAP yedekleme altyapısı HANA geçişiyle modernize edildi; yasal saklama süreleri immutable hedefle karşılandı.
Indexline Yaklaşımı
SAP yedekleme en sık gözden kaçırılan ama en kritik BT operasyonu alanlarından biridir. "Yedek alıyoruz" ile "yedekten kurtarabiliyoruz" arasındaki fark sadece periyodik restore testiyle kapanır. Indexline, her müşteri için restore tatbikatını zorunlu hizmet bileşeni olarak tanımlar.
HANA log alanı yönetimi dikkat gerektiren bir konudur. Log backup sıklığı az olduğunda log alanı dolar ve sistem çalışmayı durdurabilir. Otomatik log backup ve log alan izlemesi bu riski önler.
SAP yedekleme stratejisi SAP DR stratejisiyle birlikte planlanmalıdır. HANA System Replication ile sağlanan HA, yedeklemenin yerini tutmaz; veri koruması için tamamlayıcıdır.
Indexline yaklaşımında backup başarısı yalnızca job durumuna bakılarak ölçülmez; restore edilebilirlik, süre hedefi ve veri bütünlüğü kanıtıyla değerlendirilir.
Kritik SAP sistemlerinde tek katmanlı koruma yeterli değildir. Yerel hızlı kurtarma, uzak kopya, immutable hedef ve düzenli test kombinasyonu ile çok katmanlı güvence modeli kuruyoruz.
Yedekleme politikalarını teknik ekip dilinden çıkarıp iş etkisiyle ilişkilendiriyoruz. Böylece yönetim, hangi veri kaybı seviyesinin kabul edilebilir olduğunu daha net görebiliyor ve yatırım kararları daha bilinçli alınıyor.
Sık Sorulan Sorular
HANA yedekleme ne sıklıkla yapılmalı?
Data backup günlük (full veya artımlı), log backup ise 15-60 dakika aralıklarla yapılmalıdır. RPO hedefi log backup sıklığını belirler. Kritik üretim sistemleri için 15 dakika log backup aralığı yaygın yaklaşımdır.
Yedekleme süresi çok uzun, ne yapabiliriz?
Artımlı yedeklemeye geçiş, yedekleme parallelism ayarı ve yüksek bant genişlikli depolama bağlantısı yedekleme süresini kısaltır. HANA "save only delta" seçeneği de daha hızlı artımlı yedek alımı sağlar.
Log alanı dolduğunda ne olur?
Log alanı dolduğunda HANA yeni yazma işlemlerini reddeder ve sistem durabilir. Bu durumu önlemek için log backup otomasyonu, log alan izlemesi ve otomatik log temizleme politikası zorunludur.
HANA System Replication yedeklemenin yerini tutar mı?
Hayır. HANA System Replication HA (yüksek erişilebilirlik) sağlar; ancak kasıtlı veri silme veya bozulma durumunda replika da aynı hasarı yansıtır. Yedekleme bu tür senaryolarda geri dönüşü mümkün kılar.
Tenant veritabanı yedekleme farklı mı?
HANA MDC (Multi-Datacenter Container) ortamında sistem veritabanı ve tenant veritabanları ayrı ayrı yedeklenir. Her tenant için bağımsız yedekleme politikası tanımlanabilir.
Yedek boyutu nasıl küçültülür?
HANA native compression, yedekleme sırasında uygulanır. Üçüncü taraf yedekleme platformlarının deduplikasyon ve sıkıştırma özellikleri ek tasarruf sağlar. SAP Data Tiering ile sık erişilmeyen veriyi warm/cold katmana taşımak da etkin alan kullanımını artırır.
SAP tablespace yedeklemesi gerekiyor mu?
HANA'da klasik tablespace kavramı yoktur; tüm veriler HANA volume yapısında tutulur. Yedekleme HANA backup katalog ve data snapshot mekanizmasıyla yapılır. SAP ABAP uygulama sunucusunun ayrı yedeklenmesi de gereklidir.
Yedekten kurtarma testi ne sıklıkla yapılmalı?
En az üç ayda bir restore testi yapılması önerilir. SAP kritik sistemler için aylık test uygundur. Test; yalıtılmış bir ortamda gerçek kurtarma yapılarak RTO ölçülmesini içermelidir.