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

Bir günde bir zamanlamaya tam yedekleme ve birden çok isteğe bağlı yedekleme yapabilirsiniz.

Günümüzde 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 nasıl kullanacağınızı öğrenin .

Yedeklemelerinizin durumunu (zamanlanan/isteğe bağlı) aşağıdaki konumlardan herhangi birinden denetleyebilirsiniz:

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

   

   

2. Yedekleme uyarıları: uyarılar SAP HANA veritabanlarının yedeklerini izlemenize yardımcı olur. Bunlar gerekli olaylara odaklanmanızı sağlar, böylece bir yedeklemenin oluşturduğu çok sayıda olayı sık sık denetleme çabaları ortadan kaldırır. Daha fazla ayrıntı 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ın nasıl yapılandırılacağıhakkında bilgi edinin.

4. Yerel istemci SAP HANA: SAP HANA müşteriyseniz, en yaygın Hana istemcilerinden bırı olan Hana Studio 'yu da kullanabilirsiniz. Bu istemcide yedekleme durumunu görmek için yedekleme konsolu -> Yedekleme kataloğu ' na gidin .

   

Yedekleme Işi menüsü yalnızca sürmekte olan, başarılı veya başarısız olan isteğe bağlı yedekleme işlerini gösterir. Zamanlanan işler için Azure izleyici'yi kullanın.

Azure Backup, otomatik olarak tam yedeklemelerde açık bir saklama süresi yapmaz. Bu yedekleme, bağımlı Delta (fark veya artımlı) ve günlük yedeklemeleri elde ettiğiniz zamana kadar tutulur. Bu otomatik yedekleme yedeğine yönelik son bağımlı yedeklemeyi sildikten sonra Otomatik Heal yedeklemesi de silinir.

Hayır, bu şu anda desteklenmiyor.

Bir veritabanı SAP HANA örneğinden bırakılırsa, veritabanı yedeklemeleri yine de denenir. Bu, silinen veritabanının yedekleme öğeleri altında sağlıksız olarak gösterilmeye başladığı ve hala korunduğu anlamına gelir. Bu veritabanını korumayı durdurmanın doğru yolu, bu veritabanındaki silme verileriyle Yedeklemeyi Durdur gerçekleştirmektir.

Yeniden adlandırılmış bir veritabanı yeni bir veritabanı olarak değerlendirilir. Bu nedenle, hizmet bu durumu veritabanı bulunmazsa ve yedeklemelerle başarısız olacak şekilde değerlendirir. 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şlamak üzere adım adım kılavuz için öğreticiye bakın. Ayrıca, yedeklemeleri yapılandırmak ve yönetmek için CLI de kullanabilirsiniz.

SAP HANA Azure Backup kullanımı için önkoşulları inceleyin.

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

Sorun giderme kılavuzunda Bu bölüme bakın.

Şu anda çözümü bir sanal IP veya proxy 'ye karşı ayarlama yeteneği yoktur. Çözümü yürütebilmemiz için bir sanal makineye ihtiyacımız var.

1. Şu anda çalışmakta olan yedeklemenin istenen veritabanında tamamlanmasını bekleyin (Studio 'nun tamamlanmasını denetleyin).
2. Aşağıdaki adımları kullanarak, günlük yedeklemelerini devre dışı bırakın ve istenen VERITABANı için Katalog yedeklemesini dosya sistemine ayarlayın:
3. SystemDB -> yapılandırma -> veritabanı -> filtresi Seç (günlük) öğesine çift tıklayın
   1. Enable_auto_log_backup Hayır olarak ayarlayın.
   2. Catalog_backup_using_backint false olarak ayarlayın.
4. İstenen veritabanında isteğe bağlı bir yedekleme (tam/değişiklik/artımlı) yapın ve yedekleme ve Katalog yedeklemesinin tamamlanmasını bekleyin.
5. Günlük yedeklemelerini de dosya sistemine taşımak istiyorsanız, enable_auto_log_backup Evet olarak ayarlayın.
6. Yedeklemelerin Azure kasasına akmasını sağlamak için önceki ayarlara geri dönün:
   1. Enable_auto_log_backup Evet olarak ayarlayın.
   2. Catalog_backup_using_backint true olarak ayarlayın.

Şu anda Azure Backup bir HSR kurulumunu anlama yeteneği yoktur. Bu, HSR 'nin birincil ve ikincil düğümlerinin iki bireysel, ilişkisiz VM olarak kabul edildiği anlamına gelir. Öncelikle birincil düğümde yedekleme 'yi yapılandırmanız gerekir. Yük devretme gerçekleştiğinde, ikincil düğümde (şimdi birincil düğüm haline gelir) yedeklemenin yapılandırılması gerekir. Diğer düğüme yedeklemenin otomatik olarak devredilme işlemi yapılmaz.

Belirli bir zaman noktasında etkin (birincil) düğümden verileri yedeklemek için korumayı yük devretme sonrasında birincil olan ikincil düğüme geçirebilirsiniz .

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

• Birincil üzerinde Korumayı Durdur (verileri koruyun)
• İkincil düğümde ön kayıt betiğini çalıştırma
• İkincil düğümdeki veritabanlarını bulun ve bunların üzerinde yedeklemeleri yapılandırın

Bu adımların her yük devretme sonrasında el ile gerçekleştirilmesi gerekir. Bu adımları, Azure portal ek olarak komut satırı/HTTP REST aracılığıyla gerçekleştirebilirsiniz. Bu adımları otomatik hale getirmek için bir Azure runbook 'u kullanabilirsiniz.

Aşağıda, anahtar korumasının nasıl gerçekleştirilmesi gerektiğini gösteren ayrıntılı bir örnek verilmiştir:

Bu örnekte, HSR kurulumu 'nda 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, henüz Düğüm 2'de yedeklemeleri yapılandırmayı denemeyin.

İlk yük devretme gerçekleşirken Düğüm 2 birincil olur. Sonra

1. Verileri koruma seçeneğiyle Düğüm 1'in (önceki birincil) korumasını durdurun.
2. Düğüm 2'de (artık birincil olan) ön kayıt betiği çalıştırın.
3. Düğüm 2'de veritabanlarını bulma, yedekleme ilkesi atama ve yedeklemeleri yapılandırma.

Ardından Düğüm 2'de ilk tam yedekleme tetiklenir ve bu tamamlandıktan sonra günlük yedeklemeleri başlar.

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

1. Verileri koruma seçeneğiyle Düğüm 2'nin korumasını durdurun.
2. Düğüm 1'de kayıt öncesi betiği çalıştırın (bu betik yeniden birincil hale geldi)
3. Ardından, gerekli ilkeyle (yedeklemeler düğüm 1'de daha önce durdurulmuş olduğu için) 1. Düğümde yedeklemeyi sürdürün.

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

1. HANA sistem çoğaltması (HSR) için ikincil düğüm hiçbir bağlantı kabul etmez. Yedekleme yapılandırıldığında, Azure Backup hizmeti düzenli aralıklarla ping atarak başarısız olur. Bazen, bu başarısız denemeler birincil düğüme yansır. Birden çok hatadan sonra kullanıcı kilitlenir ve birincil düğüm ODBCConnectionError ile başarısız olur.
   
   Tüm kullanıcıların bu sorunu yaşamalarını gözlemleyeme. İkincil düğümde kullanıcı bağlantısı başarısız olduğunda birincil düğümde kullanıcıların kilitlenme nedenini araştırmanız önerilir.

2. Kayıt öncesi betiği çalıştırdıktan sonra, kullanıcı bilgileri birincil düğümde yeni parolayla güncelleştirilir. Ardından yedeklemeyi deneme bağlantısı yeniden kurulur. Ancak yine aynı senaryoyla karşı karşılarına çıktı.

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

Yukarıdaki sorunlardan kaçınmak için, bir düğüm ikincil duruma geldikten sonra korumayı durdurmayı (bağlantıların denenip kullanıcı kilitlenmemek için) ve birincil duruma geldikten sonra korumayı sürdürmenizi öneririz. HSR kurulumlarında bu kilitleme durumuyla karşılaşmazsanız ve uyarıların tetikleniyor olması konusunda rahatsanız, her iki düğümde de yedeklemeleri yapılandırarak hizmetin yük devretmeyi ve yeniden çalışma durumunu işlemesini sebilirsiniz.

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

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

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

Hedef örnek için geri yüklemenin tüm önkoşullarını SAP HANA olup olamayr. Daha fazla bilgi için bkz. Önkoşullar - Azure VM'SAP HANA veritabanlarını geri yükleme.

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

Hangi geri yükleme türlerinin SAP HANA görmek 1642148 not defterine 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 olmak gerekir. Hangi geri SAP HANA uyumlu 1642148 görmek için not defterine bakın.

İlke oluşturmadan önce RPO ve RTO gereksinimlerini ve ilgili maliyet etkilerini net bir şekilde anlamanı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ığına göre belirlenir. Daha sık günlük yedeklemeleri daha düşük RPO'ya işaret ediyor ve hizmet tarafından Azure Backup minimum değer 15 dakikadır. Bu nedenle günlük yedekleme sıklığı 15 dakika veya daha yüksek olabilir.

RTO (Kurtarma süresi hedefi), bir veri kaybı senaryosundan sonra verilerin son kullanılabilir noktaya ne kadar hızlı geri yükleneceklerini gösterir. Bu, HANA tarafından kullanılan kurtarma stratejisine bağlıdır ve bu strateji genellikle geri yükleme için gereken dosya sayısına bağlıdır. Bunun da maliyet üzerinde etkileri vardır ve aşağıdaki tablo tüm senaryoların ve etkilerinin anlaşılmasına yardımcı olacaktır.

Bu nedenle, RPO ve RTO hedeflerine ve maliyetle ilgili dikkat edilmesi gerekenlere göre ilke çeşidini seçin.

Yedekleme öğesinin ilkesi İlke 1'den (P1) İlke 2'ye (P2) geçişin veya İlke 1'in (P1) düzenlenmesinin etkisini belirlerken bazı ilkeler de tutulmalı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ı alınmaktadır. Günlük tam saklama süresi 10 gün olarak değiştirilirse, önceki noktanın sona erme zamanı da başlangıç saati + 10 gün olarak yeniden hesaplanır ve süresi dolduğunda silinir.
• Değişiklik kapsamı yedekleme günlerini, yedekleme türünü ve bekletmeyi de içerir. Örneğin: İlke Pazar günleri günlük doludan haftalık doluya değiştirilirse, Pazar günleri olmayan tüm eski dolumlar silinmek üzere işaretlenir.
• Alt öğe etkin olana/süresi dolmadan üst öğe silinmez. Her yedekleme türünün geçerli etkin ilkeye göre bir sona erme zamanı vardır. Ancak tam yedekleme türü sonraki 'farklar', 'artımlılar' ve 'günlükler' için üst olarak kabul edilir. 'Değişiklik' ve 'günlük' başka birinin ebeveynleri değil. 'Artımlı' sonraki 'artımlı' öğenin üst öğesi olabilir. 'Üst' öğe silinmek üzere işaretlenmiş olsa bile alt 'değişiklik' veya 'günlük' süresi dolmazsa bu öğe silinmez. Örneğin, bir ilke Pazar günleri günlük doludan haftalık doluya değiştirilirse, Pazar günleri olmayan tüm eski dolumlar silinmek üzere işaretlenir. Ancak daha önce alınan günlüklerin süresi dolana kadar bunlar silinmez. Başka bir deyişle, bunlar en son günlük süresine göre korunur. Günlüklerin süresi dolsa, 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.

Sonraki adımlar

Azure VM'leri üzerinde SAP HANA veritabanlarını yedeklemeyi öğrenin.