Memecahkan masalah pencadangan database SQL Server dengan menggunakan Azure Backup

Artikel ini menyediakan informasi pemecahan masalah untuk database SQL Server yang berjalan di komputer virtual Azure.

Untuk informasi selengkapnya tentang proses dan batasan cadangan, lihat Tentang pencadangan SQL Server di Azure VM.

Izin SQL Server

Untuk mengonfigurasi perlindungan untuk database SQL Server pada komputer virtual, Anda harus memasang ekstensi AzureBackupWindowsWorkload pada komputer virtual tersebut. Jika Anda mendapatkan kesalahan UserErrorSQLNoSysadminMembership, itu berarti instans SQL Server Anda tidak memiliki izin cadangan yang diperlukan. Untuk memperbaiki kesalahan ini, ikuti langkah-langkah dalam Mengatur izin VM.

Pecahkan masalah, temukan dan konfigurasi masalah

Ketika pembuatan dan konfigurasi vault Layanan Pemulihan selesai, menemukan database dan mengonfigurasi cadangan adalah proses dua langkah.

Selama konfigurasi cadangan, jika SQL VM dan instansnya tidak terlihat di DB Penemuan di VM dan Mengonfigurasi Cadangan (lihat gambar di atas) pastikan bahwa:

Langkah 1: Penemuan DB di VM

• Jika VM tidak tercantum dalam daftar VM yang ditemukan dan juga tidak terdaftar untuk cadangan SQL di kubah lain, maka ikuti langkah-langkah Pencadangan Penemuan SQL Server.

Langkah 2: Konfigurasi Cadangan

• Jika kubah tempat SQL VM terdaftar dalam kubah yang sama yang digunakan untuk melindungi database, maka ikuti langkah-langkah Konfigurasi Cadangan.

Jika SQL VM perlu didaftarkan di kubah baru, maka harus tidak terdaftar dari kubah lama. Tidak terdaftarnya SQL VM dari kubah mengharuskan semua sumber data yang dilindungi untuk dihentikan perlindungannya lalu Anda dapat menghapus data yang dicadangkan. Menghapus data yang dicadangkan adalah operasi yang merusak. Setelah Anda meninjau dan mengambil semua tindakan pencegahan untuk membatalkan pendaftaran SQL VM, lalu daftarkan VM yang sama ini dengan kubah baru dan coba lagi operasi pencadangan.

Memecahkan masalah Cadangan dan Pemulihan

Kadang-kadang, kegagalan acak dapat terjadi dalam operasi pencadangan dan pemulihan atau operasi tersebut mungkin macet. Ini mungkin disebabkan oleh program antivirus pada VM Anda. Sebagai praktik terbaik, kami menyarankan langkah-langkah berikut:

1. Kecualikan folder berikut dari pemindaian antivirus:

   C:\Program Files\Azure Workload Backup C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup.AzureBackupWindowsWorkload

   Ganti C:\ dengan huruf SystemDrive Anda.

2. Kecualikan tiga proses berikut yang berjalan dalam VM dari pemindaian antivirus:

   • IaasWLPluginSvc.exe
   • IaaSWorkloadCoordinatorService.exe
   • TriggerExtensionJob.exe

3. SQL juga menawarkan beberapa panduan tentang bekerja dengan program antivirus. Lihat artikel ini untuk detailnya.

Instans rusak dalam VM dengan beberapa instans SQL Server

Anda dapat memulihkan ke SQL VM hanya jika semua instans SQL yang berjalan dalam VM dilaporkan sehat. Jika satu atau beberapa instans "rusak", VM tidak akan muncul sebagai target pemulihan. Jadi ini bisa menjadi alasan yang mungkin mengapa VM multi-instans mungkin tidak muncul di dropdown "server" selama operasi pemulihan.

Anda dapat memvalidasi "Kesiapan Cadangan" dari semua instans SQL di VM, di bawah Konfigurasikan cadangan:

Jika Anda ingin memicu pemulihan pada instans SQL yang sehat, lakukan langkah-langkah berikut:

1. Masuk ke SQL VM dan masuk ke C:\Program Files\Azure Workload Backup\bin.

2. Membuat file JSON bernama ExtensionSettingsOverrides.json (jika belum ada). Jika file ini sudah ada pada VM, lanjutkan menggunakannya.

3. Tambahkan konten berikut dalam file JSON dan simpan file:

   {
                 "<ExistingKey1>":"<ExistingValue1>",
                   …………………………………………………… ,
             "whitelistedInstancesForInquiry": "FaultyInstance_1,FaultyInstance_2"
           }
   
           Sample content:        
           { 
             "whitelistedInstancesForInquiry": "CRPPA,CRPPB "
           }
   
   

4. Picu operasi Rediscover DB pada server yang terkena dampak dari portal Microsoft Azure (tempat yang sama di mana kesiapan cadangan dapat dilihat). VM akan mulai muncul sebagai target untuk memulihkan operasi.

   

5. Hapus entri WhitelistedInstancesForInquiry dari file ExtensionSettingsOverrides.json setelah operasi pemulihan selesai.

Pesan kesalahan

Jenis cadangan yang tidak didukung

UserErrorSQLPODoesNotSupportBackupType

OperationCancelledBecauseConflictingOperationRunningUserError

UserErrorFileManipulationIsNotAllowedDuringBackup

UserErrorSQLPODoesNotExist

UserErrorSQLLSNValidationFailure

UserErrorOpeningSQLConnection

UserErrorParentFullBackupMissing

UserErrorBackupFailedAsTransactionLogIsFull

UserErrorCannotRestoreExistingDBWithoutForceOverwrite

UserErrorRestoreFailedDatabaseCannotBeOfflined

WlExtGenericIOFaultUserError

UserErrorCannotFindServerCertificateWithThumbprint

UserErrorRestoreNotPossibleBecauseLogBackupContainsBulkLoggedChanges

FabricSvcBackupPreferenceCheckFailedUserError

VMNotInRunningStateUserError

GuestAgentStatusUnavailableUserError

AutoProtectionCancelledOrNotValid

CloudDosAbsoluteLimitReached

CloudDosAbsoluteLimitReachedWithRetry

WorkloadExtensionNotReachable

UserErrorVMInternetConnectivityIssue

UserErrorOperationNotAllowedDatabaseMirroringEnabled

UserErrorWindowsWLExtFailedToStartPluginService

Kegagalan registrasi ulang

Periksa satu atau beberapa gejala berikut sebelum Anda memicu operasi pendaftaran ulang:

• Semua operasi (seperti pencadangan, pemulihan, dan konfigurasi cadangan) gagal pada VM dengan salah satu kode kesalahan berikut: WorkloadExtensionNotReachable, UserErrorWorkloadExtensionNotInstalled, WorkloadExtensionNotPresent, WorkloadExtensionDidntDequeueMsg.

• Jika area Status Cadangan untuk item cadangan memperlihatkan Tidak dapat dijangkau, filter semua penyebab lain yang mungkin menghasilkan status yang sama:

  • Kurangnya izin untuk melakukan operasi terkait cadangan pada VM.
  • Matikan VM, sehingga cadangan tidak dapat terjadi.
  • Kesalahan jaringan

  

• Dalam kasus grup ketersediaan AlwaysOn, cadangan mulai gagal setelah Anda mengubah preferensi cadangan atau setelah adanya kegagalan.

Gejala-gejala ini dapat terjadi karena satu atau beberapa alasan berikut:

• Ekstensi telah dihapus atau dicopot pemasangannya dari portal.
• Ekstensi telah dihapus dari Panel Kontrol pada VM di bawah Copot Pemasangan atau Ubah Program.
• VM dipulihkan kembali ke masa lalu melalui pemulihan disk lokal.
• VM telah dimatikan untuk jangka waktu yang lama, sehingga konfigurasi ekstensinya kedaluwarsa.
• VM telah dihapus, dan VM lain dibuat dengan nama yang sama dan dalam grup sumber daya yang sama dengan VM yang dihapus.
• Salah satu node grup ketersediaan tidak menerima konfigurasi cadangan lengkap. Ini dapat terjadi ketika grup ketersediaan didaftarkan ke kubah atau ketika node baru ditambahkan.

Dalam skenario sebelumnya, kami menyarankan Anda memicu operasi pendaftaran ulang pada VM. Lihat di sini untuk instruksi tentang cara melakukan tugas ini di PowerShell.

Batas ukuran untuk file

Ukuran total string file tidak hanya tergantung pada jumlah file tetapi juga pada nama dan jalurnya. Untuk setiap file database, dapatkan nama file logis dan jalur fisik. Anda dapat menggunakan kueri SQL ini:

SELECT mf.name AS LogicalName, Physical_Name AS Location FROM sys.master_files mf
               INNER JOIN sys.databases db ON db.database_id = mf.database_id
               WHERE db.name = N'<Database Name>'

Sekarang susun dalam format berikut:

[{"path":"<Location>","logicalName":"<LogicalName>","isDir":false},{"path":"<Location>","logicalName":"<LogicalName>","isDir":false}]

Berikut contohnya:

[{"path":"F:\\Data\\TestDB12.mdf","logicalName":"TestDB12","isDir":false},{"path":"F:\\Log\\TestDB12_log.ldf","logicalName":"TestDB12_log","isDir":false}]

Jika ukuran string konten melebihi 20.000 byte, file database disimpan secara berbeda. Selama pemulihan, Anda tidak akan dapat mengatur jalur file target untuk pemulihan. File akan dipulihkan ke jalur SQL default yang disediakan oleh SQL Server.

Mengesampingkan jalur file pemulihan target default

Anda dapat mengambil alih jalur file pemulihan target selama operasi pemulihan dengan menempatkan file JSON yang berisi pemetaan file database ke jalur pemulihan target. Buat sebuah file database_name.json dan letakkan di lokasi C:\Program Files\Azure Workload Backup\bin\plugins\SQL*.

Konten file harus dalam format ini:

[
  {
    "Path": "<Restore_Path>",
    "LogicalName": "<LogicalName>",
    "IsDir": "false"
  },
  {
    "Path": "<Restore_Path>",
    "LogicalName": "LogicalName",
    "IsDir": "false"
  },  
]

Berikut contohnya:

[
  {
   "Path": "F:\\Data\\testdb2_1546408741449456.mdf",
   "LogicalName": "testdb7",
   "IsDir": "false"
  },
  {
    "Path": "F:\\Log\\testdb2_log_1546408741449456.ldf",
    "LogicalName": "testdb7_log",
    "IsDir": "false"
  },  
]

Dalam konten sebelumnya, Anda bisa mendapatkan nama logis file database dengan menggunakan kueri SQL berikut ini:

SELECT mf.name AS LogicalName FROM sys.master_files mf
                INNER JOIN sys.databases db ON db.database_id = mf.database_id
                WHERE db.name = N'<Database Name>'

File ini harus ditempatkan sebelum Anda memicu operasi pemulihan.

Langkah berikutnya

Untuk informasi selengkapnya tentang Azure Backup untuk komputer virtual SQL.