Cloud Backup:Database backup FAQ

Veritabanı örneği sorunları

• Bir veritabanı örneği Database Backup'a kayıt olamazsa ne yapmalıyım?

• Bir veritabanı örneği için "Inactivated" durumunu nasıl çözebilirim?

• Bir veritabanı örneği için "DB Offline" durumunu nasıl çözebilirim?

• Bir veritabanı örneğini kaydettikten sonra ECS Veritabanı Örneği sekmesinde neden birden fazla veritabanı örneği görünür?

• Bir veritabanı örneğini kaydettikten sonra veritabanı durumu alınamazsa ne yapmalıyım?

İstemci sorunları

• İstemci işlemi durumunu nasıl görüntülerim, günlük yolunu nasıl bulurum ve istemciyi nasıl yeniden başlatırım?

• Bir veritabanı istemcisi için "Offline" durumunu nasıl çözebilirim?

• Yerel bir SQL Server veritabanı için yedekleme istemcisini yüklerken "Failed to run install script:exit status 4" hatasını nasıl çözebilirim?

• Yerel bir SQL Server veritabanını yedeklerken yedekleme istemcisi kurulum hatasını nasıl çözebilirim?

• Bir ECS örneğinde Database Backup istemcisi kurulum hatasını nasıl çözebilirim?

Yedekleme sorunları

• Yerel veritabanı yedekleme özelliğinin ücretsiz deneme sürümünü nasıl edinebilirim?

• Yerel bir veritabanını yedeklemek için ağ gereksinimleri nelerdir?

• Gerçek zamanlı yedekleme için minimum aralık nedir? Gerçek zamanlı yedekleme ve artımlı yedeklemeyi aynı anda yapılandırabilir miyim?

• Database Backup için kullanıcı adını ve parolayı nasıl değiştiririm?

• Veritabanı yedeklemeleri şifrelenir mi?

• Bir veritabanı yedeklemesi başarısız olursa ne yapmalıyım?

• Bir Oracle veri yedeklemesi başarısız olursa ve günlükte "Failed to get install path from registry" hatası varsa ne yapmalıyım?

• Oracle verilerinin artımlı yedeklemesi tam yedekleme kadar veya daha uzun sürerse ne yapmalıyım?

• Bir Oracle artımlı yedeklemesi sırasında "RMAN reports a non-fatal error" hatasını nasıl çözebilirim?

• Bir SQL Server 2019 veritabanını yedeklerken veritabanı ayrıntılarını görüntüleyemezsem ne yapmalıyım?

• Cloud Backup konsolunda görüntülenen kayıtlı yerel SQL Server veritabanının IP adresi gerçek IP adresiyle eşleşmezse ne yapmalıyım?

• Şeffaf Veri Şifrelemesi (TDE) etkinleştirildikten sonra bir SQL Server veritabanını Alibaba Cloud'a yedekleyebilir miyim?

• Bir SQL Server veritabanı için anti-ransomware hizmetini dağıttıktan sonra istemci çevrimdışıysa, kaldırılamıyorsa ve anti-ransomware ilkesi silinemiyorsa ne yapmalıyım?

• Bir ECS örneğini bir Alibaba Cloud hesabından diğerine aktardıktan sonra Database Backup'ı düzgün şekilde yükleyemez veya kullanamazsam ne yapmalıyım?

• Yedekleme için hangi MySQL veritabanı sürümleri ve işletim sistemleri desteklenir?

• MySQL'de yeni oluşturulan bir veritabanını nasıl yedeklerim?

• Bir veritabanı yedeklemesini nasıl iptal ederim?

• Neden yedekleme geçmişinde yinelenen veya beklenmeyen yedekleme kayıtları bulunur?

• Neden bir yedekleme başarısız olur ve yedekleme planı durumu "Error" olarak gösterilir?

• Neden uyarı saati, hatanın gerçekten oluştuğu saatten farklıdır?

• Neden bir başarısızlık uyarısı alırım ancak yedekleme geçmişi aynı zaman için hem başarılı hem de başarısız bir yedekleme kaydı gösterir?

Geri yükleme sorunları

• "View Offline Instances Only" özelliği nasıl çalışır?

• Bir SQL Server veritabanı geri yüklemesi başarısız olursa ne yapmalıyım?

• Aracı günlüğü bir dosya başlatma hatası gösterdiğinde SQL Server geri yükleme hatasını nasıl çözebilirim?

• Yerel bir veritabanı ile bir ECS örneğindeki veritabanı arasında çapraz veritabanı geri yüklemesini nasıl gerçekleştiririm?

Yedekleme kasası sorunları

• Veritabanı yedekleme kasası nedir?

• Süresi dolan veriler bir veritabanı yedekleme kavasından nasıl temizlenir?

• Yedekleme veri boyutunu ve yedekleme kasası kullanımını nasıl görüntülerim? Faturalandırma nasıl hesaplanır?

Örnek kayıt hatası

Öncelikle sunucunuzda (yerel bir sunucu veya bir ECS örneği) yedekleme istemcisinin yüklü olup olmadığını kontrol edin. Yüklüyse, İstemciyi kaldırın bölümündeki talimatları izleyerek istemciyi kaldırın ve yapılandırma dosyalarını silin. Ardından örneği tekrar kaydetmeyi deneyin.

Etkin olmayan örnek durumu

Çevrimdışı örnek durumu

Kayıttan sonra birden fazla örnek

Tek bir ECS örneğinde birden fazla veritabanı örneği dağıtılmışsa Cloud Backup konsolu kayıt sırasında bunların tümünü tarar ve görüntüler.

ECS database instance sekmesinde konsol, aynı ECS örneğindeki birden fazla veritabanı örneğini ayrı kayıtlar olarak görüntüler. Her kayıt farklı bir örnek adına ve bağlantı noktası numarasına karşılık gelir.

Veritabanı durumu alınamıyor

• Belirti

  Bir veritabanı örneği kaydedildikten sonra Cloud Backup konsolu durumunu alamaz.

  Konsolda veritabanı durumu sütunu sürekli olarak bir yükleme simgesi gösterir.

• Neden

  Geçerli işletim sistemi veritabanı tarafından desteklenmiyor.

• Çözüm

  Desteklenen bir işletim sistemine geçiş yapın ve tekrar deneyin.

İstemci durumunu, günlük yolunu kontrol edin ve yeniden başlatın

• Linux

  1. Yedekleme istemcisinin işlem durumunu kontrol edin.

     Veritabanı yedekleme istemcisinin işlem durumunu kontrol etmek için systemctl status dbackup3-agent veya service dbackup3-agent status komutunu çalıştırın.

     active veya dbackup3-agent is running... çıktısı, istemcinin doğru çalıştığını gösterir.

     ● dbackup3-agent.service - dbackup3 agent daemon
        Loaded: loaded (/usr/lib/systemd/system/dbackup3-agent.service; enabled; vendor preset: disabled)
        Active: active (running) since Mon 2023-12-11 13:47:34 CST; 1min 13s ago
      Main PID: 22192 (dbackup3-agent)
        CGroup: /system.slice/dbackup3-agent.service
                └─22192 /opt/scutech/dbackup3/bin/dbackup3-agent -f /etc/opt/scutech/dbackup3/agent/svc.conf.d
     
     Dec 11 13:47:34 iZbp1******gktZ systemd[1]: Started dbackup3 agent daemon.

  2. Yedekleme istemcisini yeniden başlatın.

     systemctl restart dbackup3-agent veya service dbackup3-agent restart komutunu çalıştırarak istemci işlemini yeniden başlattıktan sonra, konsoldaki veritabanı Client Status değeri Installed ise istemci durumu normale dönmüş demektir.

  İstemci günlük yolu: /var/log/dbackup3/agent.log

• Windows

  1. "Run" iletişim kutusunu açmak için Win + R tuşlarına basın.

  2. Hizmetler konsolunu açmak için services.msc yazın ve Enter tuşuna basın.

  3. Hizmet listesinde dbackup3-agent hizmetini bulun.

  4. Hizmet durumunun "Running" olup olmadığını kontrol edin. Durum "Running" değilse dbackup3-agent hizmetine sağ tıklayın ve başlatmak için "Restart" seçeneğini belirleyin.

  İstemci günlük yolu: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

"Offline" istemci durumunu çözün

• Belirti

  Veritabanının Client Status değeri Offline olarak gösterilir.

  Bu noktada İstemci Durumu Offline ve veritabanı durumu Unknown şeklindedir.

• Neden

  Offline durumu, istemciden gelen kalp atışı sinyalinin kaybedildiğini gösterir. Bu durum genellikle yetersiz bellek nedeniyle istemci işleminin sonlandırılması veya ana bilgisayar cihazının kapatılmasından kaynaklanır.

• Çözüm

  İstemci işlemi durumunu nasıl kontrol ederim, günlük yolunu nasıl bulurum ve istemciyi nasıl yeniden başlatırım? bölümünde açıklandığı şekilde istemciyi kontrol edin ve yeniden başlatın. İstemci durumu Running olarak değiştikten sonra, konsoldaki veritabanının Client Status değeri Installed olana kadar bekleyin. Bu, istemcinin normale döndüğünü gösterir.

"exit status 4" kurulum hatasını çözün

Bu hata, yerel güvenlik ilkesi ayarı olan "User Account Control: Admin Approval Mode for the Built-in Administrator account" etkinleştirilmediği için oluşur. Bu ilke Enabled olarak ayarlanmalıdır.

1. Run komutunu açmak için Win+R tuşlarına basın, Yerel Grup İlkesi Düzenleyicisi'ni çalıştırmak için gpedit.msc yazın.

2. Yerel Grup İlkesi Düzenleyicisi'nde Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options yolunu izleyin. Sağ bölmede User Account Control: Admin Approval Mode for the Built-in Administrator account öğesini bulun ve durumunu Enabled olarak değiştirin.

Yerel SQL Server için istemci kurulum hatalarını çözün

1. Sunucuda oturum açın ve yedekleme günlüğünü kontrol edin.

   Windows istemci günlük yolu: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Günlükte, görevin başarısız olduğu zamandaki girdileri kontrol edin.

   Yedekleme günlüğünde Failed to install dbackup3-agent service, errno=1783, The stub received bad data hata mesajı varsa sistem kurulumu reddetmiş olabilir. Herhangi bir antivirüs veya güvenlik yazılımının kurulumu engelleyip engellemediğini kontrol edin ve engel kayıtlarını gözden geçirin. Yükleyiciyi izin listesine ekleyin veya güvenlik yazılımını geçici olarak devre dışı bırakın, ardından kurulumu tekrar deneyin.

ECS'de istemci kurulum hatalarını çözün

Başarılı bir kurulum sağlamak için aşağıdakileri kontrol edin:

1. Cloud Assistant durumu: ECS örneğinde Cloud Assistant'ın yüklü olduğunu ve düzgün çalıştığını doğrulayın.

   Kurulum başarısız olursa genellikle Cloud Assistant konsolunda başarısız bir komut kaydı bulabilirsiniz. Komutu kopyalayın ve ECS ana bilgisayarında manuel olarak çalıştırın. Manuel kurulum sırasında ağ veya betik yürütme hataları oluşursa belirli hata mesajları görünür. Sorunları çözmek için bu mesajları kullanın; örneğin ağ ayarlarını düzenleyin.

   Sorunları çözdükten ve betik başarıyla çalıştıktan sonra istemci yüklenir. Ardından işlemi tamamlamak için konsoldan kurulumu yeniden tetikleyin.

2. C sürücüsü alanı: C sürücüsünde yeterli boş alan olduğundan emin olun. Yetersiz alan istemci kurulumunu engeller.

Yerel veritabanı yedeklemesi için ücretsiz deneme

Yerel veritabanı yedeklemesi için ücretsiz deneme süreci, ECS veritabanı yedeklemesiyle aynıdır. Ayrıntılar için bkz. 30 günlük ücretsiz deneme.

Ağ gereksinimleri

Şirket içi veritabanı sunucunuzu bir kiralık hat veya VPN aracılığıyla bir Alibaba Cloud sanal özel cloud (VPC) bağlamanız gerekir. Ayrıca şirket içi ağınızdan cloud içindeki aşağıdaki CIDR bloklarına yönlendirme yapılandırmanız gerekir: 100.64.0.0/10 ve 100.96.0.0/11.

Gerçek zamanlı yedekleme aralığı ve artımlı yedekleme

Gerçek zamanlı yedekleme, saniye düzeyinde bir RPO (Recovery Point Objective) sağlayabilir ve şu anda MySQL ile Oracle veritabanlarını destekler. Gerçek zamanlı yedeklemeyi etkinleştirdikten sonra ayrı bir geleneksel günlük yedeklemesi yapılandıramazsınız. Ancak veri korumanızı iyileştirmek amacıyla bu özelliği artımlı yedekleme ile birlikte kullanabilirsiniz.

Veritabanı yedekleme kimlik bilgilerini değiştirme

Parola süresi dolduğunda olduğu gibi yedekleme kimlik bilgilerini değiştirmek için Reactivate seçeneğini kullanın. Yeniden etkinleştirme mevcut yedekleme planlarını etkilemez ancak devam eden yedekleme işlerini etkiler. Etkiyi en aza indirmek için aşağıdakileri yapın:

1. Backup Plans sekmesinde gerçek zamanlı günlük yedeklemelerini duraklatın.

2. Veritabanının actions sütununda More > Reactivate seçeneklerini belirleyin.

Veritabanı yedekleme şifrelemesi

Evet, verilerinizi güvenlik risklerinden korumak için veritabanı yedeklemeleri şifrelenir. Bu kapsamda hem aktarım sırasında hem de depolama sırasında şifreleme uygulanır.

• Aktarım sırasında şifreleme: Veriler varsayılan olarak secure sockets layer/transport layer security (SSL/TLS) tabanlı HTTPS kullanılarak aktarım sırasında şifrelenir. SSL/TLS, iletişim kuran uygulamalar arasında gizliliği ve veri bütünlüğünü sağlar.

• Depolama sırasında şifreleme: Cloud Backup, yedekleme kasasında AES-256 algoritması ve provider-managed anahtarları kullanarak yedekleme verilerinizi şifreler.

Veritabanı yedekleme hatalarını giderme

Oracle yedekleme hatası: Failed to get install path from registry

• Belirti

  Bir Oracle veri yedeklemesi başarısız olur ve günlükte aşağıdaki hata iletisi yer alır:

  Failed to get install path from registry.
  Failed import $APPDATA\scutech\dbackup3\common\conf/config.ini: No such file or directory
  (Failed to open '$APPDATA\ scutech\dbackup3\common\conf/config ini' as default global config.

• Neden

  Oracle 12c ve sonraki sürümler Oracle hizmetinin sanal bir kullanıcı olarak çalıştırılmasını destekler. Ancak Cloud Backup istemcisi sistem kullanıcısı olarak çalışır. Bu durum, Oracle'ın yedekleme yazılımı tarafından oluşturulan dizinlere erişmesini engelleyen bir izin çatışmasına neden olabilir.

• Çözüm

  Users grubuna manuel olarak Full Control izni verin. Aşağıdaki adımları uygulayın:

  1. Kayıt Defteri Düzenleyicisi'ni açın. HKEY_LOCAL_MACHINE\SOFTWARE\scutech\dbackup3 konumuna gidin, agent anahtarına sağ tıklayın ve ardından Permissions seçeneğini belirleyin.

  2. Permissions for agent iletişim kutusunda Users grubunu seçin, Full Control için Allow onay kutusunu işaretleyin ve OK seçeneğine tıklayın.

Artımlı yedekleme tam yedekleme kadar yavaş

• Belirti

  Artımlı veya günlük yedeklemesi tam yedekleme ile neredeyse aynı sürede veya daha uzun sürede tamamlanır.

• Çözüm

  Oracle veritabanınızda Block Change Tracking (BCT) özelliğini etkinleştirin. BCT, veri bloğu değişikliklerini izleyerek yedekleme süresini azaltır ve RMAN artımlı yedeklemelerini hızlandırır. Bu özellik varsayılan olarak devre dışıdır ve manuel olarak etkinleştirilmesi gerekir.

  BCT'nin avantajları ve dezavantajları

  Avantajlar

  Dezavantajlar

  RMAN artımlı yedeklemelerini hızlandırır BCT dosyası veri bloklarındaki değişiklikleri kaydeder. Bir RMAN artımlı yedeklemesi sırasında RMAN, tüm veritabanını taramak yerine BCT dosyasını okuyarak değiştirilen blokları bulur. Büyük veritabanları için bu durum artımlı yedekleme süresini %90'dan fazla azaltabilir. Örneğin, 1 TB'lık bir veritabanının tam taraması bir saat sürebilirken BCT kullanan bir artımlı yedekleme yalnızca birkaç dakika sürer. G/Ç yükünü azaltır Fiziksel okumaları azaltır. Bir yedekleme sırasında BCT dosyası doğrudan okunur; bu da tam tablo taramasını önler ve üretim ortamı üzerindeki etkiyi azaltır. Düşük kaynak tüketimi Neredeyse hiç bellek ek yükü gerektirmez. BCT dosyası tipik olarak yalnızca birkaç yüz megabayttır. Örneğin, 1 TB'lık bir veritabanı için BCT dosyası yaklaşık 100 MB ila 200 MB arasındadır. Uyumluluk 10g R2'den başlayarak tüm Oracle sürümlerini destekler. Oracle 12c ve sonraki sürümler hata toleransını artırmak için birden çok BCT dosyası kopyasıyla yedekli yapılandırmaları destekler.

  Ek depolama alanı gerektirir Dosya boyutu: Dosya yalnızca birkaç yüz megabayt olsa da depolama yolunda yeterli alan olduğundan emin olmanız gerekir. Yedekli yapılandırma: Örneğin REDUNDANCY 2 ile birden çok kopya yapılandırırsanız gereken depolama alanı iki katına çıkar. Küçük performans etkisi Yazma işlemi ek yükü: Bir veri bloğu değiştirildiğinde BCT dosyasının da güncellenmesi gerekir. Bu durum, yüksek yazma yüküne sahip sistemlerde performansı hafifçe etkileyebilir. Örnek senaryo: Saniyede on binlerce işlem gerçekleştiren bir çevrimiçi işlem işleme (OLTP) sisteminde BCT'nin performans etkisi genellikle ihmal edilebilir düzeydedir. Ancak aşırı yüksek eşzamanlılık senaryolarında performansı izlemeniz gerekir. Dosya bozulması riski Tek noktadan arıza: BCT dosyası bozulursa ve yedeklilik yapılandırılmazsa artımlı yedeklemeler başarısız olabilir. Onarım karmaşıklığı: BCT'yi yeniden etkinleştirmeniz ve dosyayı yeniden oluşturmanız gerekebilir; bu da kısa süreli kesinti gerektirebilir.

  BCT'yi etkinleştirmek için önerilen senaryolar:

  • Günlük veya saatlik RMAN artımlı yedeklemeleri gerçekleştiren sistemler.

  • Daha hızlı artımlı yedeklemeler gerektiren terabayt ölçekli veritabanları.

  • Yüksek kullanılabilirlik ve hızlı kurtarma gerektiren ve artımlı yedeklemelere dayanan üretim ortamları.

  Aşağıdaki senaryolarda BCT'yi etkinleştirirken dikkatli olun:

  • BCT'nin faydalarının minimal olduğu 1 GB'ın altındaki gibi çok küçük veritabanları.

  • Saniyede on binlerce işlem gibi son derece yüksek yazma yüküne sahip OLTP sistemleri; burada potansiyel performans etkisini tartmanız gerekir.

  • BCT dosyasının depolama gereksinimlerini değerlendirmeniz gereken sınırlı depolama alanına sahip ortamlar.

Oracle artımlı yedeklemesi sırasında RMAN fatal olmayan hatası

• Belirti

  Oracle veritabanınızın tam yedeklemesi başarılı olur ancak artımlı yedeklemeler sürekli olarak başarısız olur. Aşağıdakine benzer bir hata iletisi alırsınız:

  oracle.phxxdb.18472|RMAN reports a non-fatal error:
  ORA-19505: failed to identify file "/arch/1_5137021_976544044.dbf"
  ORA-27037: unable to obtain file status
  Linux-x86_64 Error: 2: No such file or directory
  Additional information: 3

• Neden

  Bu sorun eksik arşiv günlüklerinden kaynaklanır. Başka bir yedekleme betiği veya yedekleme görevi günlükleri taşımış olabilir; bu da Cloud Backup'ın artımlı yedekleme için gereken dosyaları bulmasını engeller.

• Çözüm

  Cloud Backup'ı diğer yedekleme yazılımları veya yedekleme betikleriyle eş zamanlı olarak kullanmayın. Birden çok yedekleme aracının eş zamanlı çalıştırılması çakışmalara neden olabilir; bu da yedekleme hatalarına veya başarılı geri yüklemelerin engellenmesine yol açar.

SQL Server 2019 veritabanı ayrıntıları listelenemedi

• Belirti

  SQL Server 2019 için bir yedekleme planı oluştururken veya düzenlerken bir veritabanı örneği seçtiğinizde konsol "Failed to list unibackup instance detail" hata iletisini görüntüler.

• Neden

  Bu hata, bir yedekleme planı oluştururken veya düzenlerken başka bir yedekleme yazılımı veya betiği SQL Server 2019 üzerinde eş zamanlı bir yedekleme gerçekleştiriyorsa oluşur.

  Konsol daha sonra "Failed to list unibackup instance detail" iletisini içeren bir hata iletişim kutusu görüntüler.

• Çözüm

  1. C:\ProgramData\scutech\dbackup3\agent\mssql\(local)\data.db dosyasını kaldırın.

  2. Hizmetler konsolunda (services.msc) dbackup3-agent hizmetini bulun ve yeniden başlatın.

Yerel SQL Server IP adresi yanlış

• Belirti

  Yerel bir SQL Server veritabanını Cloud Backup ile kaydettirdikten sonra Cloud Backup konsolundaki IP adresi ana bilgisayarın yerel IP adresiyle eşleşmez. Yerel istemci normal çalışıyor ve IP adresi değiştirilmemiş olsa bile bu sorun oluşur.

  Local Database Instance sekmesinde Client IP address sütunundaki IP adresi 169.x.x.x aralığındadır ve yerel IP adresinden farklıdır.

• Neden

  Çok NIC'li bir ortamda Cloud Backup ana bilgisayardaki kullanılmayan bir ağ arabiriminin IP adresini alır.

• Çözüm

  Bu sorunu çözmek için kullanılmayan ağ arabirimini devre dışı bırakın ve ardından istemciyi yeniden yükleyin.

SQL Server TDE yedeklemesi

Hayır, bu desteklenmez.

Çevrimdışı olan ve kaldırılamayan bir istemcide sorun giderme

• Belirti

  Bir SQL Server örneği için anti-ransomware hizmetini dağıttıktan sonra istemci çevrimdışı görünür, anti-ransomware ilkesini silme denemeleri başarısız olur ve istemciyi kaldıramazsınız.

  Konsoldaki anti-ransomware yönetim sayfasında SQL Server örneği için istemci durumu Offline olarak görüntülenir ve anti-ransomware ilkesini silemezsiniz.

  Windows Görev Yöneticisi'nde dbackup3-agent hizmeti durdurulmuş durumdadır ve agent günlüğü "Stopping all jobs" benzeri girdiler içerir.

  Attempting to connect database ...
  ...
  Stopping all jobs

• Neden

  Antivirüs yazılımı istemciyi engellemiştir. Antivirüs yazılımınızda o sıralara ait ilgili engelleme kayıtlarını kontrol edin.

• Çözüm

  İstemciyi antivirüs yazılımınızın izin listesine ekleyin ve istemci hizmetini yeniden başlatın (veya istemciyi yeniden yükleyin).

Bir ECS örneği aktarıldıktan sonra veritabanı yedekleme sorunları

Bir ECS örneği orijinal Alibaba Cloud hesabından yeni bir hesaba aktarıldığında ECS meta verileri otomatik olarak Cloud Backup hizmetine senkronize edilmez. Veritabanı yedekleme özelliğini yükleyip kullanabilmeniz için Cloud Backup hizmetinin arka ucunda ECS meta verilerini senkronize etmeniz gerekir. Ayrıntılı adımlar için Cloud Backup Desteği ile iletişime geçin veya Cloud Backup Çevrimiçi Destek DingTalk grubuna katılın.

• Cloud Backup Technical Support Group

  Fiyatlandırma, özellikler ve kullanım hakkındaki sorularınıza hızlı yanıtlar alın. Cloud Backup Çevrimiçi Desteğe Katılmak İçin Tıklayın (Chrome önerilir). DingTalk ID 88650005148 kullanarak genel grubu arayın ve gruba katılın.

• Cloud Backup Expert Support

  Teknik uzmanlar ürün sorunlarını hızla çözmek için canlı analiz sağlar. Cloud Backup desteğiyle iletişime geçmek için tıklayın (Chrome önerilir). d37_g935gslgo ID'sini kullanarak kişiyi DingTalk'ta ekleyin.

MySQL sürüm ve işletim sistemi sınırlamaları

Desteklenen veritabanı sürümleri, işletim sistemleri ve yedekleme özellikleri konusunda sınırlamalar vardır. Örneğin, Windows üzerinde dağıtılan MySQL veritabanları desteklenmez. Daha fazla bilgi için bkz. Uyumluluk listesi ve sınırlar.

Yeni bir veritabanını yedekleme

MySQL yedeklemeleri örnek düzeyinde gerçekleştirildiğinden yeni veritabanları manuel yapılandırma gerekmeden sonraki yedekleme döngüsünde otomatik olarak dahil edilir.

Veritabanı yedeklemesini iptal etme

Yinelenen veya beklenmeyen yedekleme kayıtları

Bu durum, veritabanı yedekleme istemcisi yüklü olan bir sunucuyu (yerel sunucu veya ECS örneği) klonladığınızda ya da aynı istemciyi içeren bir görüntüden yeni bir ECS örneği veya yerel sunucu oluşturduğunuzda meydana gelir. Klonlanan sunucu, orijinal sunucudan bazı istemci bilgilerini korur ve bu durum yinelenen yedekleme kayıtlarına neden olur. Sorunu çözmek için klonlanan sunucuda oturum açın ve istemciyi kaldırın. Veritabanı yedekleme istemcisini kaldırmak için aşağıdaki ilgili talimatları izleyin.

Yedekleme planı hatası

Bir yedekleme başarısız olursa ve yedekleme planı durumu "Hata" olarak görünürse öncelikle istemcinin yüklü olduğu sunucunun (yerel sunucu veya ECS örneği) klonlanıp klonlanmadığını, işletim sisteminin yeniden yüklenip yüklenmediğini veya sistem diskinin sıfırlanıp sıfırlanmadığını kontrol edin. Bu işlemler yedekleme planı ile istemci arasındaki ilişkiyi bozabilir. Sorunu çözmek için şu adımları izleyin:

1. Klonlanan sunucudan istemciyi kaldırın ve yapılandırma dosyasını silin. Daha fazla bilgi için bkz. İstemciyi kaldırma.

2. Geçerli sunucudaki istemci durumunun "Yüklü" olduğunu doğrulayın.

3. Konsolda orijinal yedekleme planını silin ve yeni bir yedekleme planı oluşturun.

Uyarı zamanı tutarsızlığı

Gece saatlerinde baskılama özelliği etkinleştirildiğinde 20:00 ile 08:00 arasında tetiklenen SMS uyarıları 08:00'e kadar gönderilmez. Buna karşılık e-posta uyarıları anında gönderilir.

Başarılı ve başarısız yinelenen yedekleme kayıtları

Bu durum, veritabanı yedekleme istemcisi yüklü olan bir sunucuyu (yerel sunucu veya ECS örneği) klonladığınızda ya da aynı istemciyi içeren bir görüntüden yeni bir ECS örneği veya yerel sunucu oluşturduğunuzda meydana gelir. Klonlanan sunucu, orijinal sunucudan bazı istemci bilgilerini korur ve bu durum yinelenen yedekleme kayıtlarına neden olur. Sorunu çözmek için klonlanan sunucuda oturum açın ve istemciyi kaldırın. Veritabanı yedekleme istemcisini kaldırmak için aşağıdaki ilgili talimatları izleyin.

Yalnızca Çevrimdışı Örnekleri Görüntüle özelliği

View Offline Instances Only özelliği, bir istemcinin orijinal örneğine artık bağlanamadığı ve verilerin yedekten geri yüklenmesinin gerekli olduğu senaryolar için geçerlidir. İstemcideki işletim sistemi yeniden yüklendiğinde veya kötü amaçlı bir program tarafından istemci işlemi ve yapılandırması silindiğinde bu durum ortaya çıkabilir. Böyle durumlarda yeni bir istemci yüklerseniz sistem, çevrimdışı örnekten ayırt etmek ve karışıklığı önlemek için ona farklı bir örnek ID'si atar. Ardından verileri çevrimdışı örnekten yeni örneğe geri yükleyebilirsiniz. Ayrıntılı talimatlar için bkz. MySQL'i Geri Yükleme, Oracle'ı Geri Yükleme ve SQL Server'ı Geri Yükleme.

SQL Server geri yükleme hatalarının çözülmesi

1. Sunucuda oturum açın ve yedekleme günlüğünü görüntüleyin.

   Windows istemci günlük yolu: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Günlükte görevin başarısız olduğu zamana yakın girdileri kontrol edin.

   Yedekleme günlüğünde RestoreContainer::ValidateTargetForCreation anahtar kelimesi varsa geri yükleme işleminin veritabanı yolunu değiştirdiğiniz ancak veritabanı adını değiştirmediğiniz için bir ad çakışmasından dolayı başarısız olduğu anlamına gelir. Veritabanını başarıyla geri yüklemek için hem veritabanı adını hem de yolu değiştirin.

SQL Server geri yükleme hatası: Dosya başlatma hatası

• Belirti

  Bir SQL Server geri yüklemesi başarısız olduğunda aracı günlüğü bir dosyanın doğru şekilde başlatılamadığını gösterir. Günlük aşağıdaki çıktıyı içerir:

  2025-11-10 11:25:53.967@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: 100 percent processed.
  2025-11-10 11:25:53.968@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 51595000 pages for database 'xxx', file 'xxx' on file 1.
  2025-11-10 11:25:53.985@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 3865 pages for database 'xxx', file 'xxx_log' on file 1.
  2025-11-10 11:25:53.987@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: File "xxx_log" failed to initialize correctly. See the error log for details.
  2025-11-10 11:25:53.989@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: RESTORE DATABASE is terminating abnormally.

  Ek olarak SQL Server ErrorLog the file "xxx_log" failed to initialize correctly mesajını bildirir.

• Neden

  Bu hata daha önce şifrelenmiş bir SQL Server 2008 R2 veritabanının yedeği geri yüklenirken ortaya çıkabilir. Şifreleme devre dışı bırakıldıktan sonra bile yedek kümesinde kalan bilgiler dosya başlatma hatasına neden olabilir. Analiz süreci aşağıdaki gibidir.

  Not

  Kaynak veritabanı SQL Server 2008 R2 ise ve şeffaf veri şifreleme (TDE) etkinleştirilmişse hedef örnek SQL Server 2014 gibi daha yeni bir sürüm olsa bile geri yükleme işlemi başarısız olur. Geri yükleme "Sertifika bulunamadı" hatasıyla sonlanır. Geri yüklemeyi tamamlamak için sertifikayı ve özel anahtarı manuel olarak geri yüklemeniz gerekir.

  1. SQL Server ErrorLog'dan veritabanı sürümünü onaylayın.

     Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)

  2. Bu sorun genellikle şeffaf veri şifreleme (TDE) ile ilgilidir. Kaynak veritabanında TDE'nin şu anda devre dışı bırakılmış olsa bile daha önce etkinleştirilip etkinleştirilmediğini onaylayın.

     Veritabanında aşağıdaki SQL ifadesini çalıştırın. Sorgu sonucunda veritabanınız için key_algorithm ve key_length sütunları NULL değilse veritabanı daha önce şifrelenmiş demektir.

     USE master;
     SELECT 
         d.name,
         d.is_encrypted,
         drs.database_id,
         drs.encryption_state,
         drs.percent_complete,
         drs.key_algorithm,
         drs.key_length
     FROM sys.databases AS d
     LEFT JOIN sys.dm_database_encryption_keys AS drs
         ON d.database_id = drs.database_id;

     Örnek bir sorgu sonucu aşağıdadır.

     Sorgu sonuçlarında bir veritabanı için key_algorithm ve key_length alanlarının değerleri NULL değilse bu veritabanı için TDE şifrelemenin etkinleştirildiği anlamına gelir.

• Çözüm

  • Kaynak veritabanını daha yeni bir sürüme yükseltin ve yeni bir yedek oluşturun. Geri yükleme işlemini gerçekleştirmek için yeni yedek kümesini kullanın. Önceki yedek kümeleri geçersizdir.

  • Özel anahtarı ve sertifikayı kaynak örnekten hedef örneğe geri yükleyin ve ardından geri yükleme işlemini gerçekleştirin.

    Geri yükleme tamamlandıktan sonra hedef örnekten TDE sertifikasını ve veritabanı şifreleme anahtarını silin. Ardından hedef örneği yedekleyin. Hedef örnekteki sonraki yedekleme ve geri yükleme işlemleri düzgün çalışacaktır.

    Not

    Veri yedeği TDE devre dışı bırakıldıktan sonra oluşturulmuş olsa bile geri yükleme işlemi yine de özel anahtarı ve sertifikayı gerektirir. Bunlar yedekteki kalan şifreli meta verileri işlemek için gereklidir. Ancak geri yüklenen veritabanı kendisi şifrelenmemiştir ve bundan sonra sertifika olmadan normal şekilde çalışabilir.

    # On the source instance, run the following commands.
    USE master;
    
    # 1. Query the certificate name for the TDE-encrypted database.
    SELECT d.name AS DatabaseName,
           k.encryption_state,
           c.name AS CertificateName
    FROM sys.dm_database_encryption_keys AS k
    JOIN sys.certificates AS c
        ON k.encryptor_thumbprint = c.thumbprint
    JOIN sys.databases AS d
        ON k.database_id = d.database_id
    
    # Assume the CertificateName in the result is TDECert. Back up the TDE certificate and private key to a custom path.
    BACKUP CERTIFICATE TDECert
       TO FILE = 'C:\Backup\TDECert.cer'  -- Specify a custom file path.
       WITH PRIVATE KEY (
            FILE = 'C:\Backup\TDECert_PrivateKey.pvk',    -- Specify a custom file path.
            ENCRYPTION BY PASSWORD = 'Strong_Password_123!'    -- Remember this password.
       );
    
    -- Copy the certificate and private key from the preceding path to the target instance.
    
    # 2. On the target instance, run the following commands.
    USE master;
    
    # Restore the master key. If you receive the message 'The master key already exists in the database. Drop the master key before you perform this statement.', skip this step.
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Another_Strong_Password_456!';
    
    # Restore the TDE certificate.
    CREATE CERTIFICATE TDECert -- Specify a custom certificate name. You will use it later for deletion.
        FROM FILE = 'C:\TDE_Test\TDECert.cer' -- The path where the copied files are located.
        WITH PRIVATE KEY (
            FILE = 'C:\TDE_Test\TDECert_PrivateKey.pvk',
            DECRYPTION BY PASSWORD = 'Strong_Password_123!'  -- The password used when backing up the private key.
        );
    
    # 3. Perform the restore in the Cloud Backup console as usual.
    
    # 4. After the restore, delete the database encryption key.
    USE TDE_TestDB_Restore -- The name of the target database.
    DROP DATABASE ENCRYPTION KEY;
    
    # 5. Delete the certificate.
    USE master;
    DROP CERTIFICATE TDECert;

Çapraz veritabanı geri yükleme: Yerel ve ECS

Bu iki ortam arasında doğrudan geri yükleme desteklenmez. Önce ECS örneğindeki veritabanını yerel bir veritabanı örneği olarak kaydetmeniz gerekir. Kayıt işleminden sonra farklı yerel veritabanı örnekleri arasında veri geri yükleyebilirsiniz.

Veritabanı yedekleme kasası nedir?

Veritabanı yedekleme planı oluşturabilmeniz için önce bir veritabanı yedekleme kasası oluşturmanız gerekir.

Veritabanı yedekleme kasası veritabanı yedeklerinizi depolayan bir depodur. Kasa kira ücreti ve kasa kapasitesi veritabanı yedeklemenizin maliyetini belirler. Daha fazla bilgi için bkz. Faturalandırma yöntemleri ve faturalandırılabilir öğeler.

Süresi dolan yedeklerin temizlenmesi

Artımlı yedekler kümülatif artımlı yedekler ve günlük yedeklerinin tümü eksiksiz bir yedekleme zincirine bağlıdır. Bu zincir ilk tam yedeklemeyi ve sonraki tüm artımlı kümülatif artımlı ve günlük yedeklerini içerir. Bir yedekleme zincirinde bağımlı tüm yedekler zincirdeki son yedek süresi dolana kadar saklanır ve depolama alanı tüketir. Depolama maliyetlerini yönetmek için yedekleme döngünüzü ve süre sonu zamanınızı dikkatlice yapılandırmalısınız.

Örneğin 1 Eylül'de tam yedekleme yaparsanız ve 2-7 Eylül arasında her gün artımlı yedekleme alırsanız ayrıca bekletme süresi yedi gün olarak ayarlanmışsa 1-7 Eylül arasında oluşturulan yedi yedek yalnızca tüm zincir 14 Eylül'de süresi dolduğunda otomatik olarak silinir.

Veri boyutu kullanım ve faturalandırma

Source Data Size yedeklediğiniz toplam veri miktarını temsil eder. Örneğin 1 TB'lık bir dosyayı iki kez yedeklerseniz Cloud Backup iki bağımsız kopya saklar ve Source Data Size 2 TB olarak hesaplanır. Cloud Backup yedeklerinizin tükettiği depolama alanını azaltmak için çoğaltma kaldırma ve sıkıştırma kullanarak maliyet tasarrufu sağlar. Faturalandırma gerçek Storage Vault Data Size üzerinden yapılır. Bir veritabanı yedekleme kasası için Source Data Size ve Storage Vault Data Size değerlerini Kasa Yönetimi sayfasında görüntüleyebilirsiniz.