Bagikan melalui

Aplikasi Cadangan SQL Server - Layanan Salinan Bayangan Volume (VSS) dan Penulis SQL

  • Artikel

Berlaku untuk: SQL Server

SQL Server menyediakan dukungan untuk Layanan Salinan Bayangan Volume (VSS) dengan menyediakan penulis (penulis SQL) sehingga aplikasi cadangan pihak ketiga dapat menggunakan kerangka kerja VSS untuk mencadangkan file database. Makalah ini menjelaskan komponen penulis SQL dan perannya dalam proses pembuatan dan pemulihan rekam jepret VSS untuk database SQL Server. Ini juga menangkap detail tentang cara mengonfigurasi dan menggunakan penulis SQL untuk bekerja dengan aplikasi cadangan dalam kerangka kerja VSS.

Infrastruktur VSS

VSS menyediakan infrastruktur sistem untuk menjalankan aplikasi VSS pada sistem Windows. Meskipun sebagian besar transparan untuk pengguna dan pengembang, VSS:

  • Mengoordinasikan aktivitas penyedia, penulis, dan pemohon dalam pembuatan dan penggunaan salinan bayangan.
  • Melengkungkan penyedia sistem default.
  • Menerapkan fungsionalitas driver tingkat rendah yang diperlukan agar penyedia mana pun dapat bekerja.

Layanan VSS dimulai sesuai permintaan; oleh karena itu, agar operasi VSS berhasil, layanan ini harus diaktifkan.

Komponen VSS

VSS mengoordinasikan aktivitas komponen yang bekerja sama berikut:

  • Penyedia memiliki data salinan bayangan dan membuat instans salinan bayangan.
  • Penulis adalah aplikasi yang mengubah data dan berpartisipasi dalam proses sinkronisasi salinan bayangan.
  • Pemohon memulai pembuatan dan penghancuran salinan bayangan. Desain kami difokuskan pada skenario di mana pemohon adalah aplikasi cadangan.

VSS menyediakan koordinasi antara pihak-pihak berikut:

Diagram memperlihatkan bagaimana VSS menyediakan koordinasi antara pihak-pihak ini.

Diagram ini menunjukkan semua komponen yang berpartisipasi dalam aktivitas rekam jepret VSS yang khas. Dalam skenario seperti itu, SQL Server (termasuk penulis SQL) bertindak sebagai penulis di salah satu kotak Penulis. Penulis lain seperti itu mungkin Server Exchange, dll.

  • Antarmuka Perangkat Virtual: SQL Server menyediakan antarmuka pemrograman aplikasi yang disebut Antarmuka Perangkat Virtual (VDI) yang membantu vendor perangkat lunak independen untuk mengintegrasikan SQL Server ke dalam produk mereka dengan memberikan dukungan untuk operasi pencadangan dan pemulihan. API ini direkayasa untuk memberikan keandalan dan performa maksimum, dan mendukung berbagai fungsi pencadangan dan pemulihan SQL Server, termasuk berbagai kemampuan pencadangan panas dan rekam jepret. Untuk informasi selengkapnya, lihat Spesifikasi Antarmuka Perangkat Cadangan Virtual SQL Server 2005.

  • Pemohon: Proses (baik otomatis atau GUI) yang meminta agar satu atau beberapa set rekam jepret diambil dari satu atau beberapa volume asli. Dalam makalah ini, pemohon juga digunakan untuk menyiratkan aplikasi cadangan yang membuat rekam jepret database SQL Server.

Lihat dokumentasi tentang Layanan Salinan Bayangan Volume untuk detailnya.

Penulis SQL

Penulis SQL adalah penulis VSS yang disediakan oleh SQL Server. Ini menangani interaksi VSS dengan SQL Server. Penulis SQL dikirim dengan SQL Server sebagai layanan mandiri dan diinstal sebagai bagian dari penginstalan SQL Server.

Peran penulis SQL dalam operasi pencadangan rekam jepret VSS:

Rekam Jepret VSS

Mengonfigurasi SQL Writer

Layanan penulis SQL diinstal dalam sistem sebagai bagian dari penginstalan SQL Server dan dikonfigurasi untuk memulai secara otomatis ketika Windows dimulai.

Akun Layanan Penulis SQL

Selama penginstalan, akun penulis SQL akan diinstal untuk menggunakan akun Sistem Lokal. Karena penulis SQL perlu berbicara dengan SQL Server menggunakan API VDI eksklusif, akun penulis SQL harus memiliki hak akses yang memadai untuk SQL Server dan VSS. Mengonfigurasi layanan sebagai akun Sistem Lokal memberikan hak yang memadai agar layanan berjalan dengan benar.

Catatan

Agar layanan penulis SQL berfungsi dengan benar, penting untuk memastikan bahwa akun Sistem Lokal tidak dihapus dari peran 'sa' instans SQL Server.

Mengaktifkan Kembali dan Memulai Penulis SQL

Secara default SQL Writer diaktifkan dan akan dimulai secara otomatis. Jika konfigurasi ini telah dimodifikasi, hal berikut harus dilakukan untuk kembali ke pengaturan default:

Layanan penulis SQL dapat diaktifkan dengan menandai layanan ini sebagai "Otomatis". Untuk membuka layanan melalui panel kontrol, klik Mulai, klik Panel Kontrol, klik dua kali Alat Administratif, lalu klik dua kali Layanan. Di panel Layanan, klik dua kali layanan penulis SQL dan ubah properti "Jenis Startup" menjadi "Otomatis".

Layanan kemudian harus dimulai dengan memilih tombol "Mulai" di bawah properti "Status Layanan" di layar properti layanan yang disebutkan di atas.

Catatan

Dalam kasus tertentu di mana instans SQL Server Express diinstal dan aplikasi menggunakan fitur Instans Pengguna, penulis SQL dapat dimulai secara otomatis oleh SQL Server. Ini dilakukan untuk memfasilitasi enumerasi Instans Pengguna ini selama operasi pencadangan VSS.

Fitur yang Didukung oleh SQL Writer

  • Teks lengkap: Penulis SQL melaporkan kontainer katalog teks lengkap dengan spesifikasi file rekursif di bawah komponen database dalam dokumen metadata penulis. Mereka secara otomatis disertakan dalam cadangan ketika komponen database dipilih
  • Pencadangan dan pemulihan diferensial: Penulis SQL mendukung pencadangan dan pemulihan diferensial melalui dua mekanisme diferensial VSS: File Parsial dan File Yang Dibedakan oleh Waktu Modifikasi Terakhir.
  • File Parsial: Penulis SQL menggunakan mekanisme File Parsial VSS untuk melaporkan rentang byte yang diubah dalam file databasenya.
  • File Yang Dibedakan menurut Waktu Modifikasi Terakhir: Penulis SQL menggunakan mekanisme VsS Differenced File by Last Mod time untuk melaporkan file yang diubah dalam katalog teks lengkap.
  • Pulihkan dengan Pindahkan: Penulis SQL mendukung spesifikasi Target Baru VSSs selama pemulihan. Spesifikasi Target Baru VSSs memungkinkan file database/log atau kontainer katalog teks lengkap untuk direlokasi sebagai bagian dari operasi Pemulihan.
  • Penggantian Nama Database: Pemohon mungkin perlu memulihkan database SQL dengan nama baru, terutama jika database akan dipulihkan berdampingan dengan database asli. Penulis SQL mendukung penggantian nama database selama operasi pemulihan, selama database tetap berada dalam instans SQL asli.
  • Cadangan Khusus Salin: Terkadang perlu untuk mengambil cadangan yang ditujukan untuk tujuan khusus, misalnya ketika Anda perlu membuat salinan database untuk tujuan pengujian. Pencadangan ini seharusnya tidak berdampak pada prosedur pencadangan dan pemulihan keseluruhan untuk database. Menggunakan opsi COPY_ONLY menentukan bahwa pencadangan dilakukan "di luar band" dan tidak boleh memengaruhi urutan cadangan normal. Penulis SQL mendukung jenis cadangan "salin-saja" dengan instans SQL Server.
  • Pemulihan Otomatis Rekam Jepret Database: Biasanya rekam jepret database SQL Server yang diperoleh dengan menggunakan kerangka kerja VSS berada dalam status tidak dipulihkan. Data dalam rekam jepret tidak dapat diakses dengan aman sebelum melalui fase pemulihan untuk mengembalikan transaksi dalam penerbangan dan menempatkan database dalam keadaan konsisten. Dimungkinkan bagi aplikasi cadangan VSS untuk meminta pemulihan otomatis rekam jepret, sebagai bagian dari proses pembuatan rekam jepret.

Fitur baru ini dan penggunaannya dijelaskan secara lebih rinci dalam Detail Opsi Pencadangan dan Pemulihan dalam topik ini.

Apa yang Tidak Didukung

  • Pencadangan log tidak didukung oleh penulis SQL.
  • Pencadangan File/Grup file tidak didukung.
  • Pemulihan halaman tidak didukung.
  • Rekam jepret database tidak didukung dan diabaikan saat membuat rekam jepret VSS komponen dan non-komponen.
  • Otomatiskan database, atau database dengan pematian diaktifkan.
  • Linux tidak menyediakan kerangka kerja VSS dan oleh karena itu SQL Writer tidak tersedia di Linux

Tabel berikut mencantumkan jenis cadangan rekam jepret yang didukung oleh penulis SQL/SQL Server yang bekerja dengan kerangka kerja VSS untuk semua edisi SQL Server.

Operasi pencadangan dan pemulihan Berbasis Komponen Berbasis Nonkomponen
Pencadangan
Data Lengkap (Termasuk katalog teks lengkap)		 Ya Ya
Pemulihan Penuh Ya Ya
Pemulihan Penuh (Tidak ada pemulihan) Ya Tidak
Pencadangan Diferensial Ya Tidak
Pemulihan Diferensial Ya Tidak
Pulihkan Dengan Pemindahan Ya Tidak
Ganti Nama Database Ya Tidak
Salin Hanya Cadangan Ya Tidak
Rekam Jepret yang Dipulihkan Otomatis Ya Tidak
Pencadangan Log Tidak Tidak
Snapshot database Tidak Tidak
Otomatiskan Database database
dengan matikan		 Ya Tidak
Database grup ketersediaan Ya Tidak pada sekunder

Operasi Pencadangan

SQL Server (menggunakan penulis SQL) akan mendukung mode operasi pencadangan berbasis VSS berikut:

  • Berbasis nonkomponen
  • Berbasis komponen

Dukungan Versi

Penulis SQL dikirim sebagai bagian dari SQL Server dan hanya mendukung instans SQL Server. Penulis SQL juga akan menghitung instans SQL Server Express. Instans pengguna yang diluncurkan oleh SQL Server Express juga akan dijumlahkan oleh penulis SQL.

Operasi Pencadangan Berbasis Nonkomponen

Cadangan berbasis nonkomponen secara implisit memilih database dengan menggunakan daftar volume dalam set rekam jepret. Penulis SQL memeriksa database yang robek, meningkatkan kesalahan jika ditemukan. Database robek adalah database di mana subset file dipilih oleh daftar volume.

Dalam model berbasis nonkomponen, hanya database dengan model Simple Recovery yang didukung. Roll forward setelah pemulihan tidak didukung.

Operasi Pencadangan Berbasis Komponen

Cadangan berbasis komponen lebih disukai dan direkomendasikan dengan penulis SQL, karena aplikasi (aplikasi cadangan VSS) akan secara eksplisit memilih database dari metadata yang dikembalikan dari penulis SQL. Kumpulan rekam jepret harus mencakup semua volume yang diperlukan untuk mencadangkan database tersebut. Infrastruktur VSS tidak secara otomatis menambahkan volume yang diperlukan untuk kumpulan database yang dipilih. Semua volume cadangan harus disertakan dalam kumpulan rekam jepret volume. Adalah tanggung jawab aplikasi cadangan untuk memastikan bahwa semua volume pendukung disertakan dalam set rekam jepret. Penulis SQL akan mendeteksi database yang robek (dengan volume pendukung di luar set rekam jepret) dan gagal pencadangan.

Topik lainnya mengasumsikan bahwa cadangan berbasis komponen digunakan sebagai bagian dari proses pembuatan rekam jepret VSS untuk SQL Server.

Proses Pembuatan Rekam Jepret

Kerangka kerja VSS mengoordinasikan aktivitas pemohon (aplikasi cadangan) dan penulis SQL selama pembuatan rekam jepret SQL Server. Untuk mengaktifkan koordinasi ini, kerangka kerja VSS mendefinisikan antarmuka pemohon dan penulis. Antarmuka ini harus diimplementasikan oleh aplikasi pemohon dan penulis yang berpartisipasi. Penulis SQL mengimplementasikan antarmuka penulis yang diperlukan. Sebagai bagian dari proses pembuatan rekam jepret, antarmuka penulis SQL dipanggil oleh kerangka kerja VSS. Penulis SQL berinteraksi dengan instans SQL Server pada sistem untuk memfasilitasi pembuatan rekam jepret.

Kerangka kerja VSS mendefinisikan sekumpulan API untuk penggunaan oleh aplikasi pemohon/cadangan. Pengembang aplikasi cadangan perlu mengikuti pola panggilan API ini untuk bekerja dengan proses pembuatan rekam jepret kerangka kerja VSS. Bagian berikutnya menjelaskan proses pembuatan rekam jepret dari sudut pandang penulis SQL. Mereka juga merinci beberapa interaksi internal antara pemohon, kerangka kerja VSS, penulis SQL, dan instans SQL Server. Untuk informasi selengkapnya tentang langkah-langkah ini dan untuk detail antarmuka kerangka kerja VSS, lihat dokumentasi tentang Layanan Salinan Bayangan Volume.

Catatan

Diasumsikan bahwa pembaca terbiasa dengan kerangka kerja VSS dan proses pembuatan cadangan secara umum. Bagian ini disediakan sebagai informasi tambahan tentang bagaimana penulis SQL berpartisipasi dalam proses pembuatan cadangan VSS.

Alur Kerja Pembuatan Rekam Jepret

Aliran data

Gambar menunjukkan diagram aliran data selama operasi pembuatan/pencadangan rekam jepret berbasis komponen. Untuk lebih memahami tugas dasar yang terlibat dalam melakukan pencadangan, berguna untuk memecah gambaran umum ini ke dalam fase berikut:

  • Inisialisasi cadangan
  • Fase penemuan cadangan
  • Tugas pra-pemulihan
  • Pencadangan file aktual
  • Penghentian pencadangan

Inisialisasi Pencadangan

Selama fase pencadangan ini, pemohon (aplikasi cadangan) mengikat ke antarmuka IvssBackupComponents rekam jepret dan menginisialisasinya sebagai persiapan untuk pencadangan. Ini juga memanggil VSS API IVssGatherWriterMetadata untuk memberi tahu kerangka kerja VSS untuk mengumpulkan metadata dari semua penulis.

Kerangka kerja VSS akan memanggil masing-masing penulis terdaftar termasuk penulis SQL untuk metadata penulis menggunakan peristiwa OnIdentify . Penulis SQL akan meminta instans SQL Server untuk mendapatkan informasi metadata cadangan untuk setiap database dan membuat Dokumen Metadata Penulis. Fase ini juga disebut sebagai Enumerasi Metadata.

Dokumen Metadata Penulis adalah dokumen yang berisi informasi yang diteruskan dari penulis ke pemohon (aplikasi cadangan). Dokumen Metadata Penulis berisi informasi berikut:

  • ID aplikasi dan nama yang mudah diingat.
  • Di mana file dan komponen ada.
  • File mana yang perlu disertakan dan dikecualikan dalam cadangan.
  • Opsi apa yang harus digunakan pada waktu pemulihan.
  • Ini diteruskan kembali ke pemohon melalui kerangka kerja VSS.

Penemuan Cadangan

Dalam fase ini, pemohon memeriksa Dokumen Metadata Penulis dan membuat dan mengisi Dokumen Komponen Cadangan dengan setiap komponen yang perlu dicadangkan. Ini juga menentukan opsi dan parameter cadangan yang diperlukan sebagai bagian dari dokumen ini. Untuk penulis SQL, setiap instans database yang perlu dicadangkan adalah komponen terpisah.

Dokumen Komponen Cadangan

Ini adalah dokumen XML yang dibuat oleh pemohon (menggunakan IVssBackupComponents antarmuka) dalam rangka menyiapkan operasi pemulihan atau pencadangan. Dokumen Komponen Cadangan berisi daftar komponen yang disertakan secara eksplisit, dari satu atau beberapa penulis, yang berpartisipasi dalam operasi pencadangan atau pemulihan. Ini tidak berisi informasi komponen yang disertakan secara implisit. Sebaliknya, Dokumen Metadata Penulis hanya berisi komponen penulis yang dapat berpartisipasi dalam cadangan. Detail struktural dokumen komponen cadangan dijelaskan dalam dokumentasi VSS API.

Tugas Pra-pemulihan

Tugas pra-pemulihan di bawah VSS difokuskan pada pembuatan salinan bayangan volume yang berisi data untuk cadangan. Aplikasi cadangan akan menyimpan data dari salinan bayangan, bukan volume aktual.

Pemohon biasanya menunggu penulis selama persiapan untuk pencadangan dan saat salinan bayangan sedang dibuat. Jika penulis SQL berpartisipasi dalam operasi pencadangan, penulis SQL perlu mengonfigurasi filenya dan juga dirinya sendiri untuk siap untuk cadangan dan salinan bayangan.

Bersiap untuk pencadangan

Pemohon perlu mengatur jenis operasi pencadangan yang perlu dilakukan IVssBackupComponents::SetBackupState dan kemudian memberi tahu penulis melalui VSS, untuk mempersiapkan operasi pencadangan menggunakan IVssBackupComponents::PrepareForBackup.

Penulis SQL diberikan akses ke Dokumen Komponen Cadangan, yang merinci database apa yang perlu dicadangkan. Semua volume cadangan harus disertakan dalam kumpulan rekam jepret volume. Penulis SQL akan mendeteksi database yang robek (dengan volume pendukung di luar set rekam jepret) dan gagal pencadangan selama peristiwa PostSnapshot.

Pencadangan File Aktual

Dalam fase ini, pemohon dapat memindahkan data ke media cadangan, jika diperlukan. Interaksi dalam tahap ini adalah antara pemohon dan kerangka kerja VSS. Penulis SQL tidak terlibat.

  1. Dapatkan status penulis. Mengembalikan status penulis. Pemohon mungkin perlu menangani kegagalan apa pun di sini.
  2. Lakukan pencadangan.

Pemohon dapat memindahkan data ke media cadangan jika diperlukan saat ini.

Pencadangan selesai

Kejadian ini akan menunjukkan bahwa pencadangan berhasil diselesaikan.

Ini juga adalah waktu di mana penulis SQL dapat melakukan pencadangan sebagai basis diferensial, jika cadangan saat ini adalah cadangan penuh database (dan bukan cadangan hanya salinan).

Catatan

Pemohon harus mengirim peristiwa ini (Peristiwa Pencadangan Selesai) secara eksplisit untuk memungkinkan penulis SQL melakukan pencadangan dasar diferensial. Jika kejadian ini tidak diterima, cadangan yang dibuat tidak akan menjadi cadangan "basis diferensial" yang memenuhi syarat.

Simpan metadata penulis

Pemohon harus menyimpan Dokumen Komponen Cadangan dan setiap metadata cadangan komponen bersama dengan data yang didukung dari rekam jepret. Metadata penulis ini diperlukan oleh penulis SQL/SQL Server untuk operasi pemulihan.

Penghentian Pencadangan

Pemohon mengakhiri salinan bayangan dengan merilis IVssBackupComponents antarmuka atau dengan memanggil IVssBackupComponents::DeleteSnapshots.

Dokumen Metadata Penulis SQL

Ini adalah dokumen XML yang dibuat oleh penulis (penulis SQL dalam hal ini) menggunakan IVssCreateWriterMetadata antarmuka, dan berisi informasi tentang status dan komponen penulis. Detail struktural Dokumen Metadata Penulis dijelaskan dalam dokumentasi VSS API. Berikut adalah beberapa detail Dokumen Metadata Penulis SQL.

  • Informasi Identifikasi Penulis
    • Nama penulis - L"SqlServerWriter"
    • ID kelas penulis - 0xa65faa63 , 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
    • ID instans penulis - L"SQL Server:SQLWriter"
    • VSSUsageType - VSS_UT_USERDATA
    • VSSSourceType - VSS_ST_TRANSACTEDDB
  • Informasi Tingkat Penulis - VSS_APP_BACK_END
  • Spesifikasi Metode Pemulihan – VSS_RME_RESTORE_IF_CAN_REPLACE.
  • Skema Cadangan yang Didukung (IVssCreateWriterMetadata::SetBackupSchema API)
    • VSS_BS_DIFFERENTIAL – pencadangan diferensial
    • VSS_BS_TIMESTAMPED – Berbasis tanda waktu – untuk file katalog teks lengkap.
    • VSS_BS_LAST_MODIFY –Pencadangan diferensial berdasarkan waktu modifikasi terakhir,
    • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – mendukung opsi lokasi target baru.
    • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – mendukung pemulihan "dengan pemindahan"
    • VSS_BS_COPY – mendukung opsi pencadangan "hanya salin".
  • Informasi Tingkat Komponen Ini berisi informasi spesifik tingkat komponen yang disediakan oleh penulis SQL.
    • Jenis - VSS_CT_FILEGROUP
    • Nama - nama komponen (nama database)
    • Jalur logis – dari instans server (Akan dalam bentuk "server\instance-name" untuk instans bernama dan "server" untuk instans default.)
    • Bendera Komponen
    • VSS_CF_APP_ROLLBACK_RECOVERY – menunjukkan bahwa rekam jepret SQL Server selalu memerlukan fase "pemulihan" untuk membuat file konsisten dan dapat digunakan untuk skenario non-cadangan (yaitu, pembatalan aplikasi).
    • Dapat dipilih - Benar
    • Dapat dipilih untuk Pemulihan - Benar
    • Metode pemulihan yang didukung - VSS_RME_RESTORE_IF_CAN_REPLACE

Satu-satunya ekstensi struktur set komponen di SQL Server adalah pengenalan katalog teks lengkap. Katalog teks lengkap adalah direktori kontainer, yang tidak dapat dinyatakan sebagai database VSS atau file log, mengingat bahwa database VSS dan file log tidak memiliki spesifikasi rekursif. Oleh karena itu, penulis SQL akan menggunakan komponen grup file VSS (VSS_CT_FILEGROUP) untuk mewakili komponen tingkat database dan filegrup untuk mewakili file database, log, dan katalog teks lengkap.

Contoh Dokumen Metadata Penulis disediakan di akhir dokumen ini.

Memulai pemohon rekam jepret akan memulai proses rekam jepret dengan memanggil antarmuka kerangka kerja VSS DoSnapshotSet.

Buat rekam jepret Fase ini melibatkan serangkaian interaksi antara kerangka kerja VSS dan penulis SQL.

  1. Bersiap untuk rekam jepret. Penulis SQL akan memanggil SQL Server untuk mempersiapkan pembuatan rekam jepret.
  2. Bekukan. Penulis SQL akan memanggil SQL Server untuk membekukan semua I/O database untuk setiap database yang dicadangkan dalam rekam jepret. Setelah peristiwa pembekuan kembali ke kerangka kerja VSS, VSS akan membuat rekam jepret.
  3. Menenggak. Pada kejadian ini, penulis SQL akan memanggil instans SQL Server untuk "men-thaw" atau melanjutkan operasi I/O normal.

Fase pembuatan rekam jepret cepat (kurang dari 60 detik), untuk mencegah pemblokiran semua penulisan ke database.

Pasca-rekam jepret Jika pemulihan otomatis diperlukan untuk rekam jepret, penulis SQL akan melakukan pemulihan otomatis untuk setiap database yang telah dipilih untuk berada dalam rekam jepret. Untuk penjelasan terperinci, lihat Rekam Jepret yang Dipulihkan Otomatis.

Pulihkan Proses

Bagian ini menjelaskan alur kerja operasi pemulihan dan berbagai langkah yang terlibat.

Pulihkan Alur Kerja Operasi

Gambar berikut menunjukkan diagram aliran data selama operasi pemulihan VSS. Untuk lebih memahami tugas dasar yang terlibat dalam melakukan pemulihan, berguna untuk memecah gambaran umum ini ke dalam topik berikut:

  • Pulihkan Inisialisasi
  • Mempersiapkan Pemulihan
  • Pemulihan File Aktual
  • Pulihkan Pembersihan dan Penghentian

Pulihkan alur proses

Dalam semua skenario pemulihan berbasis komponen VSS, pemulihan database ditangani oleh penulis SQL dalam dua fase yang berbeda.

  • PreRestore: Penulis SQL menangani validasi, penutupan handel file, dll.
  • Pasca Pemulihan: Penulis SQL melampirkan database dan melakukan pemulihan crash jika diperlukan.

Di antara kedua fase ini, aplikasi cadangan bertanggung jawab untuk memindahkan data yang relevan di bawah SQL.

Pulihkan Inisialisasi

Selama fase inisialisasi pemulihan, pemohon harus memiliki akses ke Dokumen Komponen Cadangan yang disimpan.

Dokumen Komponen Cadangan yang dihasilkan selama operasi pencadangan, disimpan sebagai bagian dari data cadangan. Aplikasi cadangan perlu meneruskan data ini kembali ke kerangka kerja VSS. Penulis SQL mendapatkan akses ke data ini di awal proses pemulihan.

Bersiap untuk Pemulihan

Dalam mempersiapkan pemulihan, pemohon menggunakan Dokumen Komponen Cadangan yang disimpan untuk menentukan apa yang harus dipulihkan dan caranya. Pemohon akan memilih komponen yang akan dipulihkan dan mengatur opsi pemulihan yang sesuai kebutuhan.

Jika aplikasi cadangan ingin menerapkan pencadangan diferensial atau log di atas operasi pemulihan saat ini (yaitu, "Pulihkan dengan norecovery" diperlukan), opsi berikut harus diatur sebagai bagian dari pembuatan komponen untuk setiap database yang sedang dipulihkan.

IVssBackupComponents::SetAdditionalRestores(true)

Setelah semua detail yang diperlukan diatur dalam Dokumen Komponen Cadangan, pemohon melakukan IVssBackupComponents::PreRestore panggilan untuk menghasilkan peristiwa PreRestore melalui VSS yang akan ditangani oleh penulis.

Penulis SQL akan memeriksa Dokumen Komponen Cadangan yang disediakan untuk mengidentifikasi database yang sesuai, menghapus file tambahan yang dibuat sejak waktu pencadangan. Ini juga memeriksa ruang disk dan menutup handel file database yang dibuka sehingga pemohon dapat menyalin data yang diperlukan selama fase Pemulihan. Fase ini memungkinkan kondisi kesalahan awal terdeteksi sebelum pemohon melakukan penyalinan file aktual. SQL Server juga akan menempatkan database dalam status pemulihan. Mulai saat ini, database tidak dapat dimulai hingga pemulihan berhasil.

Memulihkan File

Ini murni tindakan khusus pemohon. Pemohon (aplikasi cadangan) bertanggung jawab untuk menyalin file database yang diperlukan (atau menyalin rentang data yang relevan untuk pemulihan diferensial) ke tempat yang sesuai. Penulis SQL tidak terlibat dalam operasi ini.

Pembersihan dan Penghentian

Setelah semua data dipulihkan ke tempat yang tepat, panggilan dari pemohon yang memberi tahu bahwa operasi pemulihan telah selesai IvssBackupComponents::PostRestore, akan memberi tahu penulis SQL bahwa tindakan Pasca Pemulihan dapat dimulai. Penulis SQL pada saat ini akan melakukan fase Pengulangan pemulihan crash. Jika pemulihan tidak diminta (yaitu, SetAdditionalRestores(true) tidak ditentukan oleh pemohon), fase pembatalan langkah pemulihan juga dilakukan selama fase ini.

Detail Opsi Pencadangan dan Pemulihan

Bagian ini menjelaskan secara rinci semua opsi pencadangan dan pemulihan yang didukung oleh SQL Writer.

Pemohon Membuat Salinan Bayangan Volume

Penulis SQL dapat terlibat dalam proses pembuatan salinan bayangan volume (di luar konteks pencadangan dan pemulihan) karena volume pencadangan file db telah ditambahkan ke dalam kumpulan rekam jepret volume. Dalam hal ini, penulis SQL hanya berpartisipasi dalam enumerasi metadata, Bekukan, Pencairan, PrepareForSnapshot, dan koordinasi PostSnapshot (lihat diagram aliran data untuk detailnya).

Pencadangan dan Pemulihan Penuh

Penulis SQL mendukung operasi pencadangan dan pemulihan penuh dalam mode berbasis nonkomponen dan mode berbasis komponen.

Pencadangan dan Pemulihan Berbasis Nonkomponen

Dalam pencadangan dan pemulihan berbasis nonkomponen, pemohon menentukan volume atau pohon folder yang akan dicadangkan dan dipulihkan. Semua data dalam volume dan folder yang ditentukan dicadangkan dan dipulihkan.

Cadangan

Dalam cadangan berbasis nonkomponen, penulis SQL secara implisit memilih database dengan menggunakan daftar volume dalam kumpulan rekam jepret. Penulis memeriksa database yang robek, meningkatkan kesalahan jika ditemukan. Database robek adalah database di mana subset file dipilih oleh daftar volume. Roll forward (pemulihan diferensial atau log) setelah pemulihan tidak didukung melalui penulis SQL.

Pulihkan

Pemohon memulihkan database yang telah dicadangkan dalam mode berbasis nonkomponen. Pemulihan tersebut tidak dapat ditindaklanjuti oleh pemulihan rollforward, seperti pemulihan log atau pemulihan diferensial.

Untuk operasi pemulihan berbasis nonkomponen, pemulihan harus dilakukan dengan instans SQL Server offline atau database target dihilangkan/dilepas untuk memastikan bahwa file offline. File disalin di tempat dan kemudian database dilampirkan. Semua ini terjadi di luar cakupan penulis SQL.

Pencadangan dan Pemulihan Berbasis Komponen

Dalam cadangan berbasis komponen, pemohon secara eksplisit memilih komponen database (dari metadata yang dikembalikan penulis SQL ke klien) untuk dicadangkan/dipulihkan.

Cadangan

Dalam cadangan berbasis komponen, semua volume pendukung untuk database yang dipilih harus disertakan dalam kumpulan rekam jepret volume. Jika tidak, penulis SQL akan mendeteksi database yang robek (dengan volume pendukung di luar set rekam jepret) dan gagal pencadangan. Pencadangan penuh mencadangkan data database dan semua file log yang diperlukan untuk memunculkan database ke status konsisten secara transaksional pada waktu pemulihan.

Pemulihan penuh tanpa rollforward

Pemulihan penuh cadangan database terkadang dilakukan tanpa melakukan roll forward tambahan apa pun. Ini mungkin karena tidak ada metadata untuk memfasilitasi rollforward atau, dalam beberapa kasus, roll forward tidak diperlukan. Bagian ini mencakup dua situasi ini secara singkat.

Tidak ada metadata/tidak ada rollforward

Jika tidak ada metadata penulis (metadata cadangan berbasis komponen) yang disimpan selama operasi pencadangan, maka pemulihan harus dilakukan dengan instans SQL Server offline atau database target dihilangkan/dilepas untuk memastikan bahwa file offline. File disalin di tempat dan kemudian database dilampirkan. Semua ini terjadi di luar cakupan penulis SQL.

Metadata ada tetapi tidak ada rollforward tambahan yang diperlukan

Pemohon memulihkan database yang telah dicadangkan dalam mode berbasis komponen tetapi tidak ada roll forward yang diminta. Dalam hal ini SQL Server akan melakukan pemulihan crash pada database sebagai bagian dari pemulihan.

Pemulihan penuh dengan roll forward tambahan

Pemohon dapat mengeluarkan pemulihan yang menentukan opsi SetAdditionalRestores(true). Opsi ini menunjukkan bahwa pemohon akan menindaklanjuti dengan pemulihan yang lebih rollforward (seperti pemulihan log, pemulihan diferensial, dll.). Ini menginstruksikan SQL Server untuk tidak melakukan langkah pemulihan di akhir operasi pemulihan.

Ini hanya dimungkinkan jika metadata penulis disimpan selama pencadangan dan tersedia untuk penulis SQL pada saat pemulihan. Layanan SQL Server harus berjalan sebelum pemohon mengarahkan VSS untuk melakukan aktivitas pemulihan.

Penulis SQL mengharapkan urutan berikut:

  1. Persiapan untuk memulihkan setiap database. Aktivitas ini melibatkan penutupan semua handel file sehingga memungkinkan file database disalin/dipasang oleh aplikasi pemohon.
  2. File disalin/dipasang oleh aplikasi pemohon.
  3. Menyelesaikan pemulihan (dengan NORECOVERY). Database dibawa secara online, tetapi ke status "Memulihkan".

Pencadangan, diferensial, atau log SQL konvensional, kemudian dapat digunakan untuk meneruskan database melalui VDI/T-SQL, atau dengan menerapkan pemulihan diferensial menggunakan kerangka kerja VSS.

Dukungan Teks Lengkap

Penulis SQL melaporkan kontainer katalog teks lengkap dengan spesifikasi file rekursif di bawah komponen database dalam Dokumen Metadata Penulis. Mereka secara otomatis disertakan dalam cadangan ketika komponen database dipilih

Pencadangan dan pemulihan diferensial

Operasi pencadangan diferensial hanya mencadangkan data yang telah berubah sejak pencadangan penuh dasar terbaru. Cadangan diferensial hanya berisi bagian file database yang telah berubah. Untuk melakukan pencadangan seperti itu, aplikasi cadangan, atau pemohon akan memerlukan informasi tentang lokasi perubahan dalam file database, sehingga bagian file yang sesuai dapat dicadangkan. Selama operasi pencadangan diferensial, penulis SQL menyediakan informasi ini dalam format seperti yang ditentukan oleh "informasi file parsial VSS." Informasi ini dapat digunakan untuk mencadangkan hanya bagian file database yang diubah.

Cadangan

Pemohon dapat mengeluarkan cadangan diferensial dengan mengatur opsi DIFERENSIAL VSS_BT_DIFFERENTIAL di Dokumen IVssBackupComponents::SetBackupState Komponen Cadangan saat memulai operasi pencadangan dengan VSS. Penulis SQL akan meneruskan informasi file parsial (dikembalikan oleh SQL Server) ke VSS. Pemohon dapat memperoleh informasi file ini dengan memanggil VSS API IVssComponent::GetPartialFile. Informasi file parsial ini memungkinkan pemohon untuk memilih hanya rentang byte yang diubah untuk mencadangkan file database.

Selama fase Tugas Pra-Pencadangan, penulis SQL akan memastikan bahwa satu basis diferensial untuk setiap database yang dipilih ada.

Selama peristiwa PostSnapshot, penulis SQL akan mendapatkan informasi file parsial dari SQL Server dan menambahkannya ke Dokumen Komponen Cadangan menggunakan IVssComponent::AddPartialFile panggilan.

Catatan

Penulis SQL hanya mendukung satu garis besar diferensial untuk cadangan diferensial. Multi-garis besar tidak didukung.

Format informasi file parsial

Untuk setiap database yang dicadangkan selama pencadangan diferensial, penulis SQL akan menyimpan informasi file parsial untuk setiap file database. Informasi ini digunakan oleh pemohon atau aplikasi cadangan untuk menyalin hanya bagian file yang relevan ke media cadangan selama pencadangan file yang sebenarnya. Untuk informasi selengkapnya tentang format untuk informasi file parsial ini, lihat dokumentasi untuk Layanan Salinan Bayangan Volume.

Pemohon dapat menentukan file-file ini dengan memanggil IVssComponent::GetPartialFileCount dan IVssComponent::GetPartialFile. IVssComponent::GetPartialFile akan mengembalikan jalur dan nama file yang menunjuk ke file, dan string rentang yang menunjukkan apa yang perlu dicadangkan dalam file.

Untuk informasi selengkapnya tentang pengambilan informasi file parsial, lihat dokumentasi VSS.

Mencadangkan file

Selama fase ini, aplikasi cadangan harus melihat metadata penulis yang disimpan dalam Dokumen Komponen Cadangan dan mencadangkan hanya bagian file yang relevan. (Untuk file katalog teks lengkap, pencadangan ini harus dilakukan berdasarkan tanda waktu file. Ini dijelaskan nanti dalam dokumen ini).

Cadangan diferensial akan selalu berkaitan dengan cadangan dasar terbaru yang ada untuk database. Pada waktu pemulihan, SQL Server akan mendeteksi pencadangan dasar dan diferensial yang tidak cocok. Jadi, adalah tanggung jawab aplikasi cadangan atau administrator sistem untuk memastikan bahwa diferensial relatif terhadap cadangan penuh yang diharapkan. Jika beberapa prosedur di luar band telah membuat cadangan penuh lainnya, aplikasi cadangan mungkin tidak dapat memulihkan diferensial, karena tidak "memiliki" cadangan dasar.

Saat ini jika informasi rentang byte (informasi file parsial) terlalu besar (melebihi 64 K byte dalam ukuran buffer), SQL Server akan melemparkan kesalahan yang menginstruksikan pengguna untuk melakukan pencadangan penuh.

Pemecahan Masalah

File add/drop/shrink/growth/logical-rename/physical-rename membuat kasus menarik dalam pencadangan.

File yang baru ditambahkan setelah basis diambil

File-file ini disertakan dalam spesifikasi parsial karena setiap header file database SQL harus dalam spesifikasi parsial. Selain halaman header, semua halaman yang dialokasikan perlu disertakan dalam spesifikasi parsial.

File dihilangkan setelah basis diambil

Setelah basis diambil, file data dapat dihilangkan. File tersebut tidak disertakan dalam Dokumen Metadata Penulis selama pencadangan diferensial. Selain itu, tidak akan ada informasi parsial yang terkait dengan file yang dihilangkan.

File menyusut setelah basis diambil

Informasi parsial tidak dikumpulkan dari file hingga penyusutan file dinonaktifkan di server. Ini memastikan bahwa kami tidak akan pernah menyertakan informasi parsial yang sesuai dengan wilayah penyusutan file data.

File tumbuh setelah basis diambil

Jika pertumbuhan terjadi sebelum informasi parsial dikumpulkan, maka informasi parsial seharusnya menyertakan halaman yang dialokasikan di wilayah yang tumbuh. Jika pertumbuhan terjadi setelah informasi parsial dikumpulkan, maka informasi parsial tidak menyertakan perubahan di wilayah yang tumbuh. Di bagian berikut, kita akan melihat bahwa perubahan tersebut akan dipulihkan oleh roll-forward log.

File secara logis diganti namanya setelah basis diambil

Penggantian nama logis file tidak memengaruhi pencadangan atau pemulihan, karena nama logis file tidak direferensikan di mana pun dalam Dokumen Metadata Penulis atau di Dokumen Komponen Cadangan. (Lihat dokumen Metadata Penulis: Contoh untuk detail selengkapnya.)

File berganti nama secara fisik setelah basis diambil

Penggantian nama file database fisik tidak berlaku hingga database dimulai ulang. Oleh karena itu, informasi konfigurasi database atau informasi jalur file dalam buffer informasi parsial masih didasarkan pada jalur fisik lama, yang merupakan satu-satunya jalur yang valid ke file database tersebut pada rekam jepret.

Pulihkan

Selama pemulihan diferensial, metadata cadangan yang diberikan pemohon kembali ke penulis SQL memiliki informasi jenis cadangan. Oleh karena itu, tidak ada perlakuan khusus dari penulis SQL yang diperlukan. SQL Server akan mencari tahu bahwa itu adalah pemulihan diferensial dengan sendirinya. SQL Server menangani pemulihan diferensial seperti itu dengan cara yang sama seperti terhadap pemulihan diferensial asli yang tidak dilakukan melalui VSS.

Fase prerestore

Selama fase ini, SQL Server akan mengubah ukuran semua file ke ukuran yang sesuai berdasarkan metadata file cadangan diferensial. Jika file ditumbuhkan, SQL Server nol dari bagian yang tumbuh. Jika file baru harus dibuat (dibuat setelah basis diambil), SQL Server nol keluar dari file baru. Ini juga menutup semua handel file sehingga aplikasi cadangan dapat menimpa file dengan data yang dipulihkan dari media cadangan.

Memulihkan file

Klien harus memulihkan file berdasarkan spesifikasi file parsial. Data harus dipulihkan ke offset/rentang file database yang sama seperti yang ditentukan dalam spesifikasi file parsial yang disimpan dalam metadata penulis.

File database add/drop/growth/shrink/logical-rename/physical-rename kembali membuat kasus menarik pada waktu pemulihan.

Jika file database telah ditambahkan setelah basis penuh diambil

File tersebut harus telah dibuat sebelumnya oleh SQL Server selama fase persiapan pemulihan. Mereka seharusnya diperluas ke ukuran yang tepat dan ditolak. Klien hanya perlu meletakkan data sesuai spesifikasi parsial (spesifikasi parsial mencakup semua tingkat yang dialokasikan).

Jika file database telah dihilangkan setelah basis penuh diambil

Informasi parsial yang disediakan SQL Server tidak menyertakan informasi pelacakan apa pun untuk penurunan file tersebut. SQL Server bertanggung jawab untuk mendeteksi file yang akan dihapus, dengan membandingkan metadata file yang dipulihkan dengan kontainer yang ada, dan benar-benar menghapusnya. Ini dilakukan sebelum pemulihan sebagai langkah persiapan.

Jika file database telah tumbuh sejak basis penuh diambil

File tersebut harus diperluas ke ukuran yang tepat oleh SQL Server selama fase persiapan pemulihan. Wilayah yang diperluas juga harus di-nol oleh SQL Server. Oleh karena itu, klien dapat dengan aman meletakkan data bahkan di wilayah yang tumbuh sesuai spesifikasi parsial. Jika file ditumbuhkan setelah informasi parsial diambil, perubahan di wilayah yang tumbuh akan dipulihkan dengan memutar ulang log yang dicadangkan bersama dengan cadangan diferensial.

Jika file database telah menyusut sejak basis penuh diambil

SQL Server bertanggung jawab untuk memotong file ke ukuran yang diperlukan sesuai metadata. Ini dilakukan sebelum pemulihan sebagai langkah persiapan.

Jika file database telah diganti namanya secara logis sejak basis penuh diambil

Ini tidak akan memengaruhi pemulihan karena nama logis tidak muncul di Dokumen Metadata Penulis atau Dokumen Komponen Cadangan. Perubahan nama logis akan dipulihkan ketika klien menerapkan perubahan ke file database utama, yang berisi informasi katalog sistem.

Jika file database telah diganti namanya secara fisik sejak basis penuh diambil.

Jika pada saat pencadangan diferensial, penggantian nama tidak berlaku, maka klien masih memulihkan data ke lokasi lama. Mulai ulang database pasca-pemulihan akan menyebabkan perubahan nama fisik berlaku. Jika pada saat pencadangan diferensial, nama file fisik telah berlaku, maka data parsial, jika ada, dicadangkan dari jalur fisik baru.

Pasca pemulihan

Selama peristiwa pemulihan pasca, penulis SQL akan melakukan operasi pengulangan normal dan pemulihan (jika SetAdditionalRestores() diatur ke False) database.

Pencadangan dan Pemulihan Diferensial untuk Katalog Teks Lengkap

Katalog teks lengkap SQL Server adalah bagian dari sumber daya database yang perlu dicadangkan atau dipulihkan bersama dengan file database lainnya. Cadangan diferensial berbasis tanda waktu untuk katalog teks lengkap. Pencadangan dan pemulihan diferensial SQL Server VSS memiliki satu cadangan dasar. Dengan kata lain, tidak akan ada basis yang berbeda untuk kontainer yang berbeda. Untuk pencadangan katalog teks lengkap VSS, ini berarti untuk semua kontainer katalog teks lengkap, cadangan diferensial akan berbasis tanda waktu tunggal, tidak seperti kasus cadangan diferensial SQL asli, di mana ada satu basis tanda waktu per kontainer katalog teks lengkap.

Dalam VSS, tanda waktu ini dinyatakan sebagai properti di seluruh komponen yang diatur selama pencadangan penuh, dan digunakan selama pencadangan diferensial berikutnya.

OnIdentify

Di OnIdentify, penulis SQL memanggil IVssCreateWriterMetadata::SetBackupSchema() untuk mengatur nilai VSS_BS_TIMESTAMPED. Ini menunjukkan aplikasi cadangan bahwa penulis SQL memiliki manajemen basis diferensial.

Mengatur tanda waktu dasar

Tanda waktu dasar diatur selama pencadangan penuh. Dalam OnPostSnapshot(), penulis memanggil IVssComponent::SetBackupStamp() untuk menyimpan tanda waktu dengan komponen dalam dokumen cadangan.

Pencadangan diferensial

Aplikasi cadangan akan mengambil tanda waktu ini dari cadangan penuh dasar, dan membuat tanda waktu tersedia untuk penulis dengan memanggil IVssComponent::GetBackupStamp() untuk mengambil stempel dasar dari cadangan dasar sebelumnya. Kemudian membuatnya tersedia untuk penulis dengan memanggil IVssBackupComponent::SetPreviousBackupStamp(). Penulis kemudian mengambil stempel dengan memanggil IVssComponent::GetPreviousBackupStamp() dan menerjemahkannya ke dalam tanda waktu yang digunakan untuk IVssComponent::AddDifferencedFilesByLastModifyTime().

Tanggung jawab aplikasi cadangan selama pencadangan diferensial Selama pencadangan diferensial, aplikasi cadangan bertanggung jawab untuk:

  • Mencadangkan file apa pun (seluruh file) yang tanda waktu terakhir diubah lebih besar dari tanda waktu yang ditentukan oleh "waktu modifikasi terakhir" untuk file yang diatur dalam komponen.
  • Melacak dan mendeteksi file yang dihapus.

Tanggung jawab aplikasi cadangan selama pemulihan diferensial Selama pemulihan diferensial, aplikasi cadangan bertanggung jawab untuk:

  • Memulihkan semua file yang telah dicadangkan, baik dengan membuat file baru jika belum ada, atau dengan menimpa file yang ada jika sudah ada.
  • Menumbuhkan file sebelum meletakkan konten jika file yang dipulihkan lebih besar dari file yang ada.
  • Memotong file ke ukuran yang sama dengan file yang dipulihkan jika file yang dipulihkan lebih kecil dari file yang ada.
  • Menghapus semua file yang harus dihapus; artinya, file-file yang seharusnya tidak ada pada titik waktu pencadangan diferensial.

Pencadangan Salin-Saja

Terkadang perlu mengambil cadangan yang ditujukan untuk tujuan khusus. Misalnya, Anda mungkin perlu membuat salinan database untuk tujuan pengujian. Pencadangan ini seharusnya tidak berdampak pada prosedur pencadangan dan pemulihan keseluruhan untuk database. Menggunakan opsi COPY_ONLY menentukan bahwa pencadangan dilakukan "di luar band" dan tidak boleh memengaruhi urutan cadangan normal. Penulis SQL mendukung jenis cadangan "salin-saja" dengan instans SQL Server.

Selama fase penemuan cadangan, penulis SQL akan menunjukkan kemampuannya untuk melakukan pencadangan khusus salinan dengan mengatur opsi skema cadangan yang didukung VSS_BS_COPY menggunakan IVssCreateWriterMetadata::SetBackupSchema panggilan. Pemohon dapat mengatur jenis cadangan sebagai cadangan hanya salin dengan mengatur opsi VSS_BACKUP_TYPE sebagai VSS_BT_COPY dengan panggilan IVssBackupComponents::SetBackupState.

Ketika cadangan khusus salinan dipilih, diasumsikan bahwa file pada disk akan disalin ke media cadangan (oleh pemohon) terlepas dari status riwayat pencadangan setiap file. SQL Server tidak akan memperbarui riwayat pencadangan. Jenis cadangan ini tidak akan merupakan cadangan dasar untuk operasi pencadangan diferensial lebih lanjut dan juga tidak mengganggu riwayat cadangan diferensial sebelumnya.

Pulihkan dengan Pindahkan

VSS memungkinkan aplikasi cadangan (pemohon) untuk menentukan target pemulihan baru menggunakan IVssComponent::SetNewTarget panggilan. Dalam dan PreRestore() PostRestore(), penulis SQL memeriksa apakah setidaknya ada satu target baru yang ditentukan. Aplikasi cadangan bertanggung jawab untuk menyalin file secara fisik ke lokasi baru selama waktu pemulihan/penyalinan file yang sebenarnya.

Aplikasi cadangan hanya diizinkan untuk menentukan target baru untuk jalur fisik, tetapi bukan spesifikasi file. Misalnya, untuk file database yang terletak di c:\data\test.mdf, nama file aktual, test.mdf, tidak dapat diubah. Hanya jalur c:\data yang dapat diubah. Untuk kontainer katalog teks lengkap yang terletak di c:\ftdata\foo, karena spesifikasi file di VSS adalah "*" dan spesifikasi jalur di VSS adalah c:\ftdata\foo, seluruh jalur dapat diubah.

Ganti Nama Database

Pemohon mungkin perlu memulihkan database SQL dengan nama baru, terutama jika database harus dipulihkan berdampingan dengan database asli. Opsi ini dapat ditentukan oleh pemohon selama operasi pemulihan dengan mengatur opsi pemulihan kustom sebagai "Nama Komponen Baru" = <"Nama Baru"> menggunakan panggilan IVssBackupComponents::SetRestoreOptions() VSS (dalam parameter wszRestoreOptions).

Penulis SQL akan mengambil seluruh konten nilai Nama Komponen Baru dan menggunakannya sebagai nama baru untuk database yang dipulihkan. Jika tidak ada opsi yang ditentukan, SQL akan memulihkan database dengan nama aslinya (nama komponen).

Catatan

Penulis SQL saat ini tidak mendukung "Ganti Nama di seluruh Instans" untuk memindahkan database ke instans baru.

Rekam Jepret yang Dipulihkan Otomatis

Biasanya rekam jepret database SQL Server yang diperoleh dengan menggunakan kerangka kerja VSS dalam keadaan tidak dipulihkan. Data dalam rekam jepret tidak dapat diakses dengan aman sebelum melalui fase pemulihan untuk mengembalikan transaksi dalam penerbangan dan menempatkan database dalam keadaan konsisten. Karena rekam jepret dalam status baca-saja, rekam jepret tidak dapat dipulihkan oleh proses normal melampirkan database.

Dimungkinkan untuk mengotomatiskan pemulihan rekam jepret sebagai bagian dari proses pembuatan rekam jepret. Sebagai bagian dari Dokumen Metadata Penulis, penulis SQL akan menentukan bendera VSS_CF_APP_ROLLBACK_RECOVERY komponen untuk menunjukkan bahwa pemulihan perlu dilakukan untuk database pada rekam jepret sebelum database dapat diakses saat menentukan set rekam jepret, pemohon dapat menunjukkan bahwa rekam jepret harus menjadi rekam jepret pemutaran kembali aplikasi (artinya, semua file database dalam rekam jepret dimaksudkan dalam status konsisten untuk penggunaan aplikasi) atau rekam jepret cadangan (yaitu, semua file database dalam rekam jepret dimaksudkan dalam status konsisten untuk penggunaan aplikasi) atau rekam jepret cadangan (rekam jepret cadangan (yaitu, semua file database dalam rekam jepret dimaksudkan dalam status konsisten untuk penggunaan aplikasi) atau rekam jepret cadangan (rekam jepret cadangan ( rekam jepret yang digunakan untuk mencadangkan data akan dipulihkan nanti jika ada kegagalan sistem).

Pemohon harus diatur VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY untuk menunjukkan bahwa komponen ini sedang dicadangkan untuk tujuan non-cadangan. VSS kemudian akan menghubungkan VSS_CF_APP_ROLLBACK_RECOVERY bahwa penulis SQL yang ditentukan pada komponen yang dipilih dengan VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, dan menentukan bahwa pemulihan otomatis sedang terjadi. VSS akan membuat rekam jepret dapat ditulis untuk jangka waktu terbatas dan secara otomatis menambahkan VSS_VOLSNAP_ATTR_AUTORECOVERY bit ke konteks rekam jepret.

SQL Server pemulihan otomatis harus diterapkan hanya ke rekam jepret pemutaran kembali aplikasi tetapi tidak untuk rekam jepret cadangan. Untuk rekam jepret pembatalan aplikasi, proses pemulihan otomatis dimulai oleh penulis SQL selama PostSnapShotevent. Proses ini akan melakukan hal berikut untuk setiap database SQL Server yang dipilih secara eksplisit (oleh pemohon) dalam set rekam jepret:

  • Lampirkan database rekam jepret ke instans SQL Server asli (yaitu, instans tempat database asli dilampirkan).

  • Pulihkan database (ini terjadi sebagai bagian dari operasi "lampirkan").

  • Menyusutkan file log.

    Ini mengurangi jumlah "copy-on-write" yang tidak perlu yang perlu dilakukan oleh kerangka kerja VSS, jika penyedia VSS adalah "Penyedia Perangkat Lunak". Menyusutkan file log adalah perilaku default. Ini dapat dinonaktifkan dengan mengatur nilai ke kunci registri berikut ke 1.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\ Settings\DisableLogShrink

    Ini mungkin berguna dalam skenario di mana rekam jepret dapat digunakan untuk mengekspor data dari halaman tertentu (pada titik waktu tertentu) dari log untuk memperbaiki masalah dalam database online.

  • Lepaskan database.

Sekarang kita memiliki rekam jepret yang konsisten dan dipulihkan yang dapat dilampirkan untuk kueri.

Transaksi multi-database

Dalam beberapa kasus, database rekam jepret mungkin berisi beberapa transaksi multi-database dalam penerbangan. Selama operasi pemulihan, penulis SQL akan melampirkan database pada rekam jepret dengan opsi Pembatalan yang Diduga. Ini akan mengembalikan transaksi multi-database apa pun yang belum dilakukan (termasuk transaksi apa pun yang dalam status Disiapkan untuk Diterapkan). Ini dapat menyebabkan beberapa inkonsistensi antara database dalam kumpulan rekam jepret. Misalnya, pertimbangkan dua database A dan B. Ada transaksi terdistribusi antara kedua database ini dan transaksi ini dalam status Berkomitmen dalam database A dan dalam status Disiapkan untuk Diterapkan dalam database B. Sebagai bagian dari proses pemulihan otomatis, transaksi ini akan dilakukan dalam database A dan digulung balik dalam database B. Ini dapat menyebabkan beberapa inkonsistensi dalam set rekam jepret.

Komponen Koordinator Transaksi Terdistribusi Microsoft (MS DTC) yang akan dirilis dalam jangka waktu Longhorn oleh kerangka kerja VSS akan memperbaiki masalah inkonsistensi ini untuk transaksi yang mencakup database di seluruh instans SQL Server. Versi SQL Server berikutnya akan memperbaiki inkonsistensi ini untuk transaksi yang mencakup database dalam instans SQL Server.

Implikasi keamanan untuk rekam jepret yang dipulihkan otomatis

Untuk rekam jepret VSS, setelah pemulihan otomatis, file akan diamankan menggunakan Daftar Kontrol Akses (ACL) untuk mengizinkan akses hanya ke grup bawaan khusus tempat akun SQL Server berada. Ini menyiratkan bahwa anggota admin kotak atau grup khusus tersebut akan dapat melampirkan database. Klien yang meminta lampiran file database pada rekam jepret harus menjadi anggota Bawaan/Administrator atau akun SQL Server.

Database pengguna model Pemulihan Sederhana

Jika database Master dipulihkan bersama dengan database pengguna yang menggunakan model Simple Recovery, database pengguna dapat dipulihkan dengan teknik yang sama dengan database master: dengan instans dimatikan, cukup salin atau pasang volume. Ketika instans SQL dimulai, semuanya pulih.

Meneruskan database pengguna

Jika database pengguna harus dipulihkan dan digulirkan bersama dengan pemulihan database master, instans tidak boleh memulai dan memulihkan database master dan pengguna bersama-sama.

Prosedurnya adalah sebagai berikut:

  1. Pastikan instans SQL Server dihentikan.
  2. Lakukan pemulihan dalam dua fase.
    1. Pulihkan database sistem dan database pengguna yang harus dipulihkan secara bersamaan (yaitu, database pengguna dalam model pemulihan sederhana) melalui salinan file /volume-mount melalui VSS.
      1. Jika database pengguna yang akan digulirkan ke depan tidak berada pada volume yang sama dengan database sistem, maka volume tersebut tidak boleh dibawa kembali saat ini. Skenario ini memerlukan perencanaan sebelum mencadangkan.
      2. Jika database pengguna berada pada volume yang sama dengan database sistem, database pengguna perlu disembunyikan dari SQL Server.
    2. Mulai instans SQL Server menggunakan parameter -f. (Saat menggunakan opsi startup -f, hanya database master yang dapat dipulihkan.)
      1. Terbitkan ALTER DATABASE <x> SET OFFLINE untuk setiap database yang akan digulirkan ke depan. (Melepaskan database adalah alternatif)
      2. Hentikan instans SQL Server.
      3. Mulai instans SQL Server (file untuk database pengguna yang akan digulirkan ke depan tidak terlihat oleh SQL Server).

Gunakan VSS untuk memulihkan database pengguna DENGAN NORECOVERY, seperti yang dijelaskan dalam "Pemulihan Penuh dengan rollforward".

Dokumen Metadata Penulis: Contoh

Database bernama DB1, milik instans SQL Server Instance1 di komputer Server1, dan berisi file database/log berikut:

  • File database bernama "primer" disimpan di c:\db\DB1.mdf
  • File database bernama "sekunder" disimpan di c:\db\DB1.ndf
  • File log database bernama "log" disimpan di c:\db\DB1.ldf
  • Katalog teks lengkap bernama "foo" disimpan di bawah direktori c:\db\ftdata\foo
  • Katalog teks lengkap bernama "bar" disimpan di bawah direktori c:\db\ftdata\bar.

Berikut ini adalah metadata penulis database:

Komponen grup file tingkat database

File database utama:

ComponentType: VSS_CT_FILEGROUP
LogicalPath: "Server1\Instance1"
ComponentName: "DB1"
Caption: NULL
pbIcon: NULL
cbIcon: 0
bRestoreMetadata: FALSE
NotifyOnBackupComplete: TRUE
Selectable: TRUE
SelectableForRestore: TRUE
ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

File database sekunder:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.mdf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ndf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Log file teks lengkap:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ldf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Foo file teks lengkap:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\foo"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Bilah file teks lengkap:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\bar"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Jika instans server adalah instans default pada komputer, jalur logis menjadi satu bagian - "Server1".

Kasus Khusus

Bagian ini menjelaskan beberapa kasus khusus yang ditemui selama operasi pencadangan dan pemulihan berbasis penulis SQL.

Otomatiskan database

Untuk pencadangan berbasis nonkomponen, pencadangan otomatis database dilakukan, saat memeriksa kondisi robek, tetapi database yang diklasifikasikan otomatis tidak secara eksplisit dibekukan selama operasi pencadangan.

Skenario yang diharapkan di sini adalah bahwa banyak database tertutup mungkin ada dan kami ingin meminimalkan biaya rekam jepret. Database yang diapit otomatis biasanya digunakan dalam konfigurasi low-end di mana sumber daya langka.

Daftar file

Daftar file untuk setiap database ditentukan selama langkah enumerasi sebelum peristiwa Persiapan Pencadangan. Jika daftar file database berubah antara enumerasi dan pembekuan, maka database bisa robek, kecuali aplikasi mencentang ulang daftar file. Kami tidak mengharapkan ini menjadi masalah, tetapi itu adalah sesuatu yang perlu diperhatikan vendor.

Instans yang dihentikan

Jika instans SQL Server tidak berjalan pada saat langkah enumerasi terjadi, maka tidak ada database untuk instans tersebut yang dapat dipilih.

Jika instans berhenti dalam interval antara enumerasi dan peristiwa Persiapan Pencadangan, database apa pun dalam instans yang dihentikan diabaikan.

Database Sistem dan Pengguna

Database sistem di SQL Server mencakup database master, model, dan msdb yang dikirim dan diinstal sebagai bagian dari SQL Server. Bagian ini menjelaskan bagaimana database ini ditangani dalam proses pencadangan rekam jepret VSS.

Database master hanya dapat dipulihkan dengan menghentikan instans, mengganti file database (dilakukan oleh aplikasi cadangan), lalu memulai ulang instans. Tidak ada roll forward yang dimungkinkan.

Penulis SQL mendukung pemulihan database model dan msdb secara online, tanpa mematikan instans.

Lihat Juga

Aplikasi Pencadangan SQL Server - Pengelogan SQL Writer
BACKUP (Transact-SQL)
RESTORE (Transact-SQL)
Mencadangkan dan Memulihkan Database SQL Server
Pencadangan Khusus Salin (SQL Server)
Pencadangan Log Transaksi (SQL Server)
Menerapkan Pencadangan Log Transaksi (SQL Server)
Arsitektur dan Panduan Manajemen Log Transaksi SQL Server