Sık sorulan sorular – Azure VM'lerinde SAP HANA veritabanlarını yedekleme

Bir günde tek bir zamanlama tam yedeklemesi ve birden çok isteğe bağlı yedeklemeniz olabilir.

Bugün, başarılı yedekleme işleri uyarı oluşturmaz. Uyarılar yalnızca başarısız olan yedekleme işleri için oluşturulur. Yedekleme uyarılarını görüntülemek için Azure portalını kullanmayı öğrenin.

Yedeklemelerinizin durumunu (zamanlanmış/isteğe bağlı) aşağıdaki konumlardan herhangi birinden de kontrol edebilirsiniz:

1. Yedekleme işleri: Azure Backup, el ile tetiklenen tüm işleri Azure portalının Yedekleme işleri bölümünde gösterir.
   
   Azure portalında gördüğünüz işler veritabanı bulma ve kaydetme işlemlerini, yedekleme ve geri yükleme işlemlerini içerir. Günlük yedeklemeleri de dahil olmak üzere zamanlanmış işler bu bölümde gösterilmez. SAP HANA yerel istemcilerinden (Studio/Cockpit/DBA Cockpit) el ile tetiklenen yedeklemeler de burada gösterilmez.

   

   

2. Yedekleme uyarıları: Uyarılar, SAP HANA veritabanlarının yedeklemelerini izlemenize yardımcı olur. Bunlar gerekli olaylara odaklanmanıza yardımcı olur ve bu sayede yedeklemenin oluşturduğu çok sayıda olayı sık sık denetleme çabasını ortadan kaldırır. Diğer ayrıntılar için bkz . Yedekleme uyarılarını görüntüleme.

3. Yedekleme Raporları: Raporlar, yedekleme işlerinizin durumunu görüntülemenin başka bir yoludur. Raporlarınız aşağıdaki gibi olacaktır:

   

   

   Azure Backup raporlarını yapılandırma hakkında bilgi edinin.

4. SAP HANA Yerel istemcileri: SAP HANA müşterisiyseniz, en yaygın HANA istemcilerinden biri olan HANA Studio'yu da kullanabilirsiniz. Yedekleme durumunu görmek için bu istemcide Yedekleme Konsolu ->Yedekleme Kataloğu'na gidin.

   

Yedekleme İşi menüsü yalnızca devam eden, başarılı veya başarısız olan isteğe bağlı yedekleme işlerini gösterir. Zamanlanmış işler için Azure İzleyici'yi kullanın.

Azure Backup, otomatik düzeltme tam yedeklemelerinde açık bir saklama süresi ayarlamaz. Bu yedekleme, bağımlı Delta (fark veya artımlı) ve Günlük yedeklemelerini koruduğusunuz zamana kadar korunur. Bu Otomatik düzeltme yedeklemesinde son bağımlı yedeklemeyi sildiğinizde, Otomatik düzeltme yedeklemesi de silinir.

Evet, tam yedekleme ve günlük yedeklemesi aynı anda çalıştırılabilir. Bu örnek aşağıdaki yollardan biriyle oluşur:

• Tam yedekleme devam ediyor ve günlük yedekleme tetikleniyor: Günlük yedeklemesi, devam eden tam yedeklemeden bağımsız olarak başarılı olmalıdır. Tetiklenen tam yedekleme, herhangi bir LSN zincir sonunu işlemek için bir düzeltme dolu değilse.
• Günlük yedeklemesi devam ediyor ve tam yedekleme tetikleniyor: Her iki yedekleme de aynı anda çalışmalı ve başarılı olmalıdır.

Hayır, bu şu anda desteklenmiyor.

Bir veritabanı SAP HANA örneğinden bırakılırsa veritabanı yedeklemeleri denenmeye devam eder. Bu, silinen veritabanının Yedekleme Öğeleri altında iyi durumda değil olarak görünmeye başladığını ve hala korunduğunu gösterir. Bu veritabanını korumayı durdurmanın doğru yolu, bu veritabanında verileri sil özelliğiyle Yedeklemeyi Durdur işlemini gerçekleştirmektir.

Yeniden adlandırılan bir veritabanı yeni bir veritabanı olarak değerlendirilir. Bu nedenle, hizmet bu durumu veritabanı bulunamadı gibi ele alır ve yedeklemelerde başarısız olur. Yeniden adlandırılan veritabanı yeni bir veritabanı olarak görünür ve koruma için yapılandırılması gerekir.

SAP HANA veritabanları için Azure Backup'ı kullanmaya başlamaya yönelik adım adım kılavuz için öğreticiye bakın. Yedeklemeleri yapılandırmak ve yönetmek için CLI'yi de kullanabilirsiniz.

SAP HANA ile Azure Backup'ı kullanma önkoşullarına bakın.

Sorun giderme kılavuzunun bu bölümüne bakın.

Sorun giderme kılavuzundaki bu bölüme bakın.

Şu anda çözümü bir sanal IP veya Ara Sunucuya göre ayarlama özelliğine sahip değilim. Çözümü yürütmek için bir sanal makineye ihtiyacımız var.

Backint yerine yerel dosya sistemine SAP HANA yerel istemcilerini kullanarak isteğe bağlı yedekleme tetikleyebilirsiniz. SAP yerel istemcilerini kullanarak işlemleri yönetme hakkında daha fazla bilgi edinin.

BACKUP CATALOG DELETE deyimleri veya HANA Studio/Cockpit gibi SAP tarafından önerilen yöntemleri kullanarak HANA kataloğunu ayıklayabilirsiniz. SAP yerel istemcilerini kullanarak işlemleri yönetme hakkında daha fazla bilgi edinin.

Şu anda Azure Backup'ın HSR kurulumunu anlama özelliği yoktur. Bu, HSR'nin birincil ve ikincil düğümlerinin bağımsız, ilişkisiz iki VM olarak ele alınacağı anlamına gelir. Öncelikle birincil düğümde yedeklemeyi yapılandırmanız gerekir. Yük devretme gerçekleştiğinde yedeklemenin ikincil düğümde yapılandırılması gerekir (artık birincil düğüm haline gelir). Yedeklemenin diğer düğüme otomatik olarak yük devretmesi yoktur.

Belirli bir noktada etkin (birincil) düğümden verileri yedeklemek için, korumayı yük devretme sonrasında birincil düğüm haline gelen ikincil düğüme geçirebilirsiniz.

Bu anahtar korumasını gerçekleştirmek için şu adımları izleyin:

• Birincilde korumayı durdurma (verileri saklama ile)
• İkincil düğümde ön kayıt betiğini çalıştırma
• İkincil düğümdeki veritabanlarını keşfedin ve bu veritabanlarında yedeklemeleri yapılandırın

Bu adımlar her yük devretmeden sonra el ile gerçekleştirilmelidir. Bu adımları Azure portalına ek olarak komut satırı / HTTP REST aracılığıyla da gerçekleştirebilirsiniz. Bu adımları otomatikleştirmek için bir Azure runbook'u kullanabilirsiniz.

Aşağıda anahtar korumasının nasıl gerçekleştirilmesi gerektiğine ilişkin ayrıntılı bir örnek verilmişti:

Bu örnekte, HSR kurulumunda düğüm 1 (birincil) ve Düğüm 2 (ikincil) olmak üzere iki düğüm vardır. Yedeklemeler Düğüm 1'de yapılandırılır. Yukarıda belirtildiği gibi, Node 2'de yedeklemeleri yapılandırmayı henüz denemeyin.

İlk yük devretme gerçekleştiğinde, Düğüm 2 birincil olur. Ardından

1. Verileri saklama seçeneğiyle Node 1'in (önceki birincil) korumasını durdurun.
2. Düğüm 2'de (artık birincil olan) ön kayıt betiğini çalıştırın.
3. Node 2'de veritabanlarını keşfedin, yedekleme ilkesi atayın ve yedeklemeleri yapılandırın.

Ardından Node 2'de ilk tam yedekleme tetikleniyor ve bu tamamlandıktan sonra günlük yedeklemeleri başlatılıyor.

Bir sonraki yük devretme gerçekleştiğinde Düğüm 1 yeniden birincil duruma gelir ve Düğüm 2 ikincil duruma gelir. Şimdi işlemi tekrarlayın:

1. Verileri koru seçeneğiyle Node 2'nin korumasını durdurun.
2. Düğüm 1'de ön kayıt betiğini çalıştırın (yeniden birincil haline geldi)
3. Ardından Gerekli ilkeyle Node 1'de yedeklemeyi sürdür (yedeklemeler Daha önce Node 1'de durdurulduğu gibi).

Ardından Düğüm 1'de tam yedekleme yeniden tetiklenir ve bu işlem tamamlandıktan sonra günlük yedeklemeleri başlatılır.

1. HANA sistem çoğaltması (HSR) için ikincil düğüm hiçbir bağlantıyı kabul etmez. Yedekleme yapılandırıldıktan sonra Azure Backup hizmeti düzenli aralıklarla ping işlemi yapıp başarısız olur. Bazen bu başarısız girişimler birincil düğüme yansır. Birden çok hatadan sonra kullanıcı kilitlenir ve ardından birincil düğüm ODBC Bağlan ionError ile başarısız olur.
   
   Tüm kullanıcıların bu sorunla karşılaşmadığını gözlemledik. İkincil düğümde kullanıcı bağlantısı başarısız olduğunda kullanıcıların birincil düğümde kilitlenme nedenini araştırmanızı/SAP'yi kullanmanızı öneririz.

2. Ön kayıt betiğini çalıştırdığınızda, kullanıcı bilgileri birincil düğümde yeni parolayla güncelleştirilir. Ardından yedeklemeyi deneme bağlantısı yeniden kurulur. Ancak aynı senaryoyu tekrar yaşayabilirsiniz.

3. Ayrıca, ikincil düğümde başarısız olan yedeklemeler (tam yedeklemeler) uyarılar oluşturur.

Yukarıdaki sorunlardan kaçınmak için, bir düğüm ikincil duruma geldikten sonra (bağlantıların denenmemesi ve kullanıcının kilitlenmemesi için) korumayı durdurmanızı ve birincil duruma geldikten sonra korumayı sürdürmenizi öneririz. HSR kurulumlarında bu kilitleme durumuyla karşılaşıyorsanız ve uyarıların tetiklenmesinden memnunsanız, hizmetin devralma ve yeniden çalışma işlemlerini gerçekleştirmesi için her iki düğümde de yedeklemeleri yapılandırabilirsiniz.

Azure Backup'ın HANA iş yükleri için sağladığı yedekleme ve geri yükleme aktarım hızı performansına bakın.

HANA sisteminizi geliştirilmiş performansdan yararlanacak şekilde ayarlamak için aşağıdaki kaynakları kullanın:

• Azure IaaS VM'leri için bir disk türü seçme - yönetilen diskler
• Azure yönetilen diskleri için performans katmanları
• M serisi
• SAP HANA Azure sanal makine depolama yapılandırmaları

Şu anda SAP HANA için Azure Backup, parallel_backup_using_backint özelliğinin değeri olarak 1 değerini kabul eder. Ancak Azure Backup, daha iyi performans için bu tek akışı birden çok akışta böler.

Şu anda HSR için yalnızca Backint tabanlı yedeklemeler desteklenmektedir. Anlık görüntüler henüz değil.

Durumunu güncelleştirmek için "Hazır Değil" olarak işaretlenmiş sunucuda örneği yeniden algılamayı çalıştırmanız gerekir.

Bir günde HANA sistemi veya örneği başına en fazla 10 geri yükleme gerçekleştirebilirsiniz. Geri yükleme iptal edilirse veya başarısız olursa, geri yükleme girişimi olarak da kabul edilir.

Hedef SAP HANA örneğine geri yükleme için tüm önkoşulların karşılandığından emin olun. Daha fazla bilgi için bkz . Önkoşullar - Azure VM'de SAP HANA veritabanlarını geri yükleme.

Geri yükleme sırasında Üzerine Yazmaya Zorla seçeneğinin belirlendiğinden emin olun.

Şu anda hangi geri yükleme türlerinin desteklendiğine bakmak için SAP HANA Not 1642148 bakın.

Evet, bir RHEL HANA sistemine geri yüklemek için SLES üzerinde çalışan bir HANA veritabanında tetiklenen akış yedeklemelerini kullanabilirsiniz. Diğer bir ifadeyle, akış yedeklemeleri kullanılarak çapraz işletim sistemi geri yüklemesi mümkündür. Ancak, geri yüklemek istediğiniz HANA sisteminin ve geri yükleme için kullanılan HANA sisteminin SAP'ye göre geri yükleme için uyumlu olduğundan emin olmanız gerekir. Hangi geri yükleme türlerinin uyumlu olduğunu görmek için SAP HANA Not 1642148 bakın.

Evet, dosyaları burada belgelendiği gibi kısmen indirebilirsiniz.

Evet, hedef sistemde HANA Sistem Çoğaltması'nı (HSR) devre dışı bırakmanız ve ardından geri yükleme gerçekleştirmeniz gerekir. SAP'ye göre HSR özellikli bir sistemi geri yükleyemezsiniz.

İlke oluşturmadan önce RPO ve RTO gereksinimleri ve ilgili maliyet etkileri konusunda net olmanız gerekir.

RPO (Kurtarma noktası hedefi), kullanıcı/müşteri için ne kadar veri kaybının kabul edilebilir olduğunu gösterir. Bu, günlük yedekleme sıklığı tarafından belirlenir. Daha sık yapılan günlük yedeklemeleri daha düşük RPO'yu ve Azure Backup hizmeti tarafından desteklenen en düşük değerin 15 dakika olduğunu gösterir. Bu nedenle günlük yedekleme sıklığı 15 dakika veya daha uzun olabilir.

RTO (Kurtarma süresi hedefi), bir veri kaybı senaryosundan sonra verilerin kullanılabilir son noktaya ne kadar hızlı geri yüklenmesi gerektiğini gösterir. Bu, HANA tarafından kullanılan kurtarma stratejisine bağlıdır ve bu strateji genellikle geri yükleme için kaç dosya gerekli olduğuna bağlıdır. Bunun da maliyet etkileri vardır ve aşağıdaki tablo tüm senaryoları ve bunların etkilerini anlamanıza yardımcı olmalıdır.

Bu nedenle, RPO ve RTO hedeflerine ve maliyetle ilgili dikkat edilmesi gerekenlere göre ilke değişkenini seçebilirsiniz.

Yedekleme öğesinin ilkesini İlke 1'den (P1) İlke 2'ye (P2) veya İlke 1'i (P1) düzenlemenin etkisini belirlerken birkaç ilke göz önünde bulundurulmalıdır.

• Tüm değişiklikler geriye dönük olarak da uygulanır. En son yedekleme ilkesi, daha önce alınan kurtarma noktalarına da uygulanır. Örneğin, günlük tam saklamanın 30 gün olduğunu ve şu anda etkin olan ilkeye göre 10 kurtarma noktasının alındığını varsayalım. Günlük tam saklama süresi 10 gün olarak değiştirilirse, önceki noktanın bitiş süresi de başlangıç saati + 10 gün olarak yeniden hesaplanır ve süresi dolduysa silinir.
• Değişikliğin kapsamı yedekleme gününü, yedekleme türünü ve saklamayı da içerir. Örneğin: bir ilke pazar günleri günlük dolu olandan haftalık doluya değiştirilirse, Pazar günleri olmayan tüm önceki dolumlar silinmek üzere işaretlenir.
• Alt öğe etkin/süresi dolmayana kadar üst öğe silinmez. Her yedekleme türünün geçerli etkin ilkeye göre bir süre sonu süresi vardır. Ancak tam yedekleme türü sonraki 'farklar', 'artımlı değerler' ve 'günlükler' için üst öğe olarak kabul edilir. 'Diferansiyel' ve 'log' başka kimsenin ebeveyni değildir. 'Artımlı', sonraki 'artımlı' öğesinin üst öğesi olabilir. Bir 'üst' silinmek üzere işaretlenmiş olsa bile, çocuğun 'farkları' veya 'günlükleri' süresi dolmadıysa aslında silinmez. Örneğin, bir ilke pazar günleri günlük doludan haftalık doluya değiştirilirse, Pazar günleri olmayan tüm önceki dolumlar silinmek üzere işaretlenir. Ancak daha önce günlük alınan günlüklerin süresi dolana kadar bunlar aslında silinmez. Başka bir deyişle, en son günlük süresine göre korunurlar. Günlüklerin süresi dolduktan sonra hem günlükler hem de bu dolumlar silinir.

Bu ilkelerle, bir ilke değişikliğinin etkilerini anlamak için aşağıdaki tabloyu okuyabilirsiniz.

Aşağıdaki seçeneklerden birini kullanarak kök klasördeki alanı yönetebilirsiniz:

• /opt/msawb için kendi LV'sini oluşturun.
• Aynı/farklı disk üzerindeki başka bir konuma/klasöre geçici bağlantı/bağlantısı oluşturun.
• Kök bölümdeki alanı artırın.

Sonraki adımlar

• Azure VM'lerinde çalışan SAP HANA veritabanlarını yedeklemeyi öğrenin.
• SAP HANA veritabanı yedekleme sorunlarını gidermeyi öğrenin.