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

Berlaku untuk:SQL Server di Windows

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 para penyedia, penulis, dan pemohon dalam proses pembuatan dan penggunaan salinan bayangan.
• Menyediakan penyedia sistem default.
• Menerapkan fungsionalitas driver tingkat rendah yang diperlukan agar penyedia mana pun dapat bekerja.

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

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 difokuskan pada skenario di mana pemohon adalah aplikasi cadangan.

VSS menyediakan koordinasi antara pihak-pihak berikut:

Diagram ini menunjukkan semua komponen yang berpartisipasi dalam aktivitas rekam jepret VSS yang khas. Dalam skenario seperti itu, SQL Server (termasuk SQL writer) bertindak sebagai penulis di salah satu kotak Writer. 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 artikel ini, pemohon juga digunakan untuk menyiratkan aplikasi cadangan yang membuat rekam jepret database SQL Server.

Untuk informasi selengkapnya, lihat Layanan Salinan Bayangan Volume.

Penulis SQL

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

Peran penulis SQL dalam operasi pencadangan rekam jepret VSS:

Mengonfigurasi penulis SQL

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 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.

Penting

Pastikan bahwa layanan penulis SQL berjalan di bawah akun Sistem Lokal, dan bahwa akun SQL Server NT SERVICE\SQLWriter adalah anggota peran sysadmin .

Aktifkan kembali dan mulai layanan penulisan SQL

Secara default, layanan penulis SQL diaktifkan dan dimulai secara otomatis. Jika konfigurasi ini telah dimodifikasi, langkah-langkah berikut harus diambil untuk kembali ke pengaturan default:

Layanan penulis SQL dapat diaktifkan dengan menandai layanan ini sebagai Otomatis. Untuk membuka layanan melalui panel kontrol, pilih Mulai, pilih 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 sebelumnya.

Catatan

Dalam kasus tertentu di mana instans SQL Server Express diinstal dan aplikasi menggunakan fitur Instance Pengguna, SQL Writer mungkin akan secara otomatis dijalankan oleh SQL Server. Ini dilakukan untuk memfasilitasi enumerasi Instans Pengguna ini selama operasi pencadangan VSS.

Fitur yang didukung oleh penulis SQL

• 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 saat komponen database dipilih.

• Pencadangan dan pemulihan diferensial: Penulis SQL mendukung pencadangan dan pemulihan diferensial melalui dua mekanisme diferensial VSS:

  • File parsial: Penulis SQL menggunakan mekanisme File Parsial VSS untuk melaporkan rentang byte yang diubah dalam file databasenya.

  • File yang dibedakan berdasarkan 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 pemindahan: Penulis SQL mendukung spesifikasi Target Baru VSS selama pemulihan. Spesifikasi Target Baru 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 Server dengan nama baru, terutama jika database harus dipulihkan berdampingan dengan database asli. Penulis SQL mendukung penggantian nama database selama operasi pemulihan, selama database tetap berada dalam instans SQL asli.

• Pencadangan salinan saja: Terkadang perlu mengambil cadangan yang ditujukan untuk tujuan khusus, misalnya ketika Anda perlu membuat salinan database untuk tujuan pengujian. Pencadangan ini seharusnya tidak memengaruhi prosedur pencadangan dan pemulihan keseluruhan untuk database. Penggunaan opsi COPY_ONLY menentukan bahwa pencadangan dilakukan di luar jalur utama dan seharusnya tidak memengaruhi urutan pencadangan normal. Penulis SQL mendukung jenis cadangan khusus salinan dengan instans SQL Server.

• Pemulihan otomatis rekam jepret database: Biasanya rekam jepret database SQL Server yang diperoleh dengan menggunakan kerangka kerja VSS 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 artikel ini.

Yang tidak didukung

• Pencadangan log tidak didukung oleh penulis SQL.
• Pencadangan file dan grup file tidak didukung.
• Pemulihan halaman tidak didukung.
• Cuplikan database tidak didukung dan diabaikan pada saat pembuatan cuplikan VSS baik komponen maupun non-komponen.
• Database penutupan otomatis, atau database dengan penutupan diaktifkan.
• Linux tidak menyediakan kerangka kerja VSS dan oleh karena itu penulis SQL 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 di Windows.

Operasi pencadangan dan pemulihan	Berbasis komponen	Berbasis non-komponen
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
Mengembalikan dengan memindahkan	Ya	Tidak
Penggantian nama database	Ya	Tidak
Salin hanya cadangan	Ya	Tidak
Cuplikan yang dipulihkan secara otomatis	Ya	Tidak
Pencadangan Log	Tidak	Tidak
Tampilan Sementara Database	Tidak	Tidak
Tutup otomatis database Database dengan pemadaman	Ya	Tidak
Grup database ketersediaan	Ya	Tidak pada yang sekunder

Operasi pencadangan

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

• Berbasis non-komponen
• Berbasis komponen

Dukungan versi

Penulis SQL dikirim sebagai bagian dari SQL Server dan hanya mendukung instans SQL Server. Penulis SQL menghitung instans SQL Server Express juga, termasuk instans pengguna yang diluncurkan oleh edisi SQL Server Express.

Operasi pencadangan yang tidak berbasis komponen

Cadangan yang tidak berbasis komponen secara implisit memilih database dengan menggunakan daftar volume pada set snapshot. Penulis SQL memeriksa database yang rusak dan mengeluarkan kesalahan jika ditemukan. Database yang terpecah adalah database di mana subset file dipilih berdasarkan daftar volume.

Dalam model berbasis non-komponen, hanya database dengan model pemulihan sederhana yang didukung. Peningkatan versi setelah pemulihan tidak didukung.

Operasi pencadangan berbasis komponen

Pencadangan berbasis komponen lebih disukai dan direkomendasikan dengan penulis SQL, karena aplikasi (aplikasi cadangan VSS) 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. Ini adalah tanggung jawab aplikasi cadangan untuk memastikan bahwa semua volume cadangan disertakan dalam set cuplikan. Penulis SQL mendeteksi database yang rusak (dengan volume pendukung di luar set snapshot) dan pencadangan gagal.

Bagian 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 Layanan Salinan Bayangan Volume (VSS).

Catatan

Diasumsikan bahwa Anda 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

Gambar berikut menunjukkan diagram aliran data selama operasi pembuatan/pencadangan rekam jepret berbasis komponen.

Untuk lebih memahami tugas-tugas dasar yang terlibat dalam melakukan pencadangan, bermanfaat untuk menguraikan gambaran umum tersebut ke dalam fase berikut.

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

Inisialisasi cadangan

Selama fase pencadangan ini, pemohon (aplikasi cadangan) mengikat ke antarmuka IvssBackupComponentsrekam 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 memanggil masing-masing penulis terdaftar, termasuk penulis SQL, untuk metadata penulis menggunakan peristiwa tersebut OnIdentify . Penulis SQL 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 instance basis data yang harus 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 mungkin 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 menyimpan data dari salinan bayangan, bukan volume aktual.

Pemohon biasanya menunggu penulis cadangan 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.

Persiapkan 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 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 para 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 menunjukkan bahwa pencadangan telah diselesaikan dengan sukses.

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 bukan cadangan dasar 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 proses backup

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

Dokumen metadata pembuat 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
  • Instance ID untuk 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 – cadangan diferensial
  • VSS_BS_TIMESTAMPED – Berbasis cap waktu – digunakan untuk file katalog teks lengkap.
  • VSS_BS_LAST_MODIFY –Pencadangan diferensial berdasarkan waktu modifikasi terakhir,
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – mendukung pilihan 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 (berisi informasi spesifik tingkat komponen yang disediakan oleh penulis SQL)

  • Jenis - VSS_CT_FILEGROUP
  • Nama - nama komponen (nama database)
  • Jalur logis – dari instans server (dalam bentuk "server\instance-name" untuk instans bernama dan "server" untuk instans default.)
  • Penanda Komponen
  • VSS_CF_APP_ROLLBACK_RECOVERY – menunjukkan bahwa snapshot SQL Server selalu memerlukan fase "pemulihan" untuk memastikan file tersebut konsisten dan dapat digunakan dalam skenario non-cadangan, yaitu pemulihan kembali 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 menggunakan komponen grup file VSS (VSS_CT_FILEGROUP) untuk mewakili komponen tingkat database dan file grup file untuk mewakili file database, log, dan katalog teks lengkap.

Contoh dokumen metadata penulis disediakan di akhir dokumen ini.

Memulai ambil gambar

Pemohon memulai proses rekam jepret dengan memanggil antarmuka DoSnapshotSetkerangka kerja VSS .

Membuat rekam jepret

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

1. Bersiap untuk rekam jepret. Penulis SQL memanggil SQL Server untuk mempersiapkan pembuatan rekam jepret.

2. Bekukan. Penulis SQL memanggil SQL Server untuk membekukan semua input/output database dari setiap database yang dicadangkan dalam snapshot. Setelah peristiwa pembekuan kembali ke kerangka kerja VSS, VSS membuat rekam jepret.

3. Menenggak. Pada kejadian ini, penulis SQL memanggil instans SQL Server untuk melepaskan pembekuan atau melanjutkan operasi I/O normal.

Fase pembuatan rekam jepret membutuhkan waktu kurang dari 60 detik, untuk mencegah pemblokiran semua penulisan ke database.

Pasca-jepretan

Jika pemulihan otomatis diperlukan untuk rekam jepret, penulis SQL melakukan pemulihan otomatis untuk setiap database yang telah dipilih untuk berada di rekam jepret. Untuk penjelasan terperinci, lihat Rekam jepret yang dipulihkan secara otomatis.

Proses pemulihan

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 bagian berikut:

• Pulihkan inisialisasi
• Mempersiapkan pemulihan
• Pemulihan file sesungguhnya
• Memulihkan pembersihan dan penghentian

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

• Pra-pemulihan: Penulis SQL menangani validasi, penutupan handle berkas, dan sebagainya.
• Post-restore: Penulis skenario SQL mengaitkan database dan melakukan pemulihan dari 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

Ketika pemohon bersiap untuk pemulihan, pemohon menggunakan dokumen komponen cadangan yang disimpan untuk menentukan apa yang harus dipulihkan dan bagaimana. Pemohon memilih komponen yang akan dipulihkan dan mengatur opsi pemulihan yang sesuai sesuai kebutuhan.

Jika aplikasi cadangan bermaksud menerapkan pencadangan diferensial atau log di atas pemulihan yang sedang berlangsung (artinya, diperlukan pemulihan dengan norecovery), maka opsi berikut harus diatur sebagai bagian dari pembuatan komponen untuk setiap database yang dipulihkan.

IVssBackupComponents::SetAdditionalRestores(true)

Setelah semua detail yang dibutuhkan diatur dalam dokumen komponen cadangan, pemohon melakukan IVssBackupComponents::PreRestore panggilan untuk menghasilkan event pemulihan awal melalui VSS yang ditangani oleh penulis.

Penulis SQL 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 handle 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 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, memberi tahu penulis SQL bahwa tindakan pasca-pemulihan dapat dimulai. Penulis SQL pada saat ini melakukan fase tulis ulang pemulihan dari kegagalan sistem. Jika pemulihan tidak diminta (yaitu, SetAdditionalRestores(true) tidak ditentukan oleh pemohon), langkah pembatalan dari pemulihan juga dilakukan selama fase ini.

Detail-detail terkait opsi pencadangan dan pemulihan

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

Pemohon membuat salinan bayangan volume

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

Pencadangan dan pemulihan penuh

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

Pencadangan dan pemulihan berbasis non-komponen

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

Backup

Dalam cadangan berbasis non-komponen, penulis SQL secara implisit memilih database dengan menggunakan daftar volume dalam kumpulan rekam jepret. Penulis memeriksa database yang rusak, menghasilkan kesalahan jika ditemukan. Database yang terpecah adalah database di mana subset file dipilih berdasarkan daftar volume. Roll-forward (pemulihan diferensial atau log) setelah pemulihan tidak didukung melalui SQL Writer.

Pulihkan

Pemohon memulihkan database yang telah dicadangkan dalam mode berbasis non-komponen. Pemulihan tersebut tidak dapat ditindaklanjuti oleh pemulihan roll-forward, seperti pemulihan log atau pemulihan diferensial.

Untuk operasi pemulihan yang bukan berbasis komponen, pemulihan harus dilakukan dengan instans SQL Server offline atau database target diambil/dilepas agar file menjadi 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.

Backup

Dalam cadangan berbasis komponen, semua volume penunjang untuk database yang dipilih harus disertakan dalam set cuplikan volume. Jika tidak, penulis SQL mendeteksi database yang rusak (dengan volume pendukung di luar set snapshot) dan pencadangan gagal. 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 roll-forward

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

Tidak ada metadata/tanpa roll-forward

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

Metadata ada tetapi tidak ada roll-forward tambahan yang diperlukan

Pemohon memulihkan basis data yang telah dicadangkan dalam mode berbasis komponen, tetapi tidak meminta proses roll-forward. Dalam hal ini SQL Server melakukan pemulihan crash pada database sebagai bagian dari pemulihan.

Pemulihan penuh dengan roll-forward tambahan

Pemohon dapat mengeluarkan perintah pemulihan dengan menentukan opsi SetAdditionalRestores(true). Opsi ini menunjukkan bahwa pemohon akan menindaklanjuti dengan lebih banyak pemulihan berkelanjutan (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 dihidupkan, tetapi dalam status pemulihan.

Pencadangan, diferensial, atau log SQL Server konvensional, kemudian dapat digunakan untuk meneruskan database melalui VDI atau Transact-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 saat 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, pemohon (aplikasi cadangan) 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 yang telah diubah dari file database.

Backup

Pemohon dapat melakukan pencadangan diferensial dengan mengatur opsi DIFFERENTIALVSS_BT_DIFFERENTIAL dalam dokumen komponen cadangan IVssBackupComponents::SetBackupState, saat memulai operasi pencadangan dengan VSS. Penulis SQL 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 melakukan pencadangan hanya pada rentang byte yang telah mengalami perubahan untuk file database.

Selama fase tugas pra-cadangan, penulis SQL memastikan bahwa satu basis diferensial untuk setiap database yang dipilih ada.

Selama acara PostSnapshot, penulis SQL mendapatkan informasi file parsial dari SQL Server dan menambahkannya dalam dokumen komponen cadangan dengan menggunakan panggilan IVssComponent::AddPartialFile.

Catatan

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

Format informasi file parsial

Untuk setiap database yang dicadangkan selama pencadangan diferensial, penulis SQL 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 Layanan Salinan Bayangan Volume (VSS).

Pemohon dapat menentukan file-file ini dengan memanggil IVssComponent::GetPartialFileCount dan IVssComponent::GetPartialFile. IVssComponent::GetPartialFile mengembalikan jalur file dan nama file yang menunjuk ke file, serta string rentang yang menunjukkan bagian 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 artikel ini).

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

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

Pemecahan Masalah

Penambahan, penghapusan, pengecilan, pertumbuhan, penggantian nama logis, dan penggantian nama fisik pada berkas membuat kasus menarik dalam pemecahan masalah pencadangan.

File yang baru ditambahkan setelah basis diambil

File-file ini disertakan dalam spesifikasi parsial karena setiap header file database 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-file tersebut tidak disertakan dalam dokumen metadata penulis selama pencadangan diferensial. Selain itu, tidak ada informasi parsial yang terkait dengan file yang dihapus.

File menyusut setelah basis diambil

Informasi parsial tidak dikumpulkan dari file sampai penyusutan file dinonaktifkan pada server. Ini memastikan bahwa VSS tidak pernah menyertakan informasi yang sebagian yang sesuai dengan bagian yang diperkecil dari sebuah file data.

File-file berkembang setelah salinan dasar 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 ini, Anda akan melihat bahwa perubahan tersebut dipulihkan oleh penerusan 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 dalam dokumen komponen cadangan.

Untuk informasi selengkapnya, lihat Dokumen metadata penulis: Contoh nanti di artikel ini.

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 pengisi SQL berisi informasi tentang jenis cadangan. Oleh karena itu, tidak ada perlakuan khusus dari penulis SQL yang diperlukan. SQL Server mengetahui bahwa ini 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 pemulihan awal

Selama fase ini, SQL Server mengubah ukuran semua file ke ukuran yang sesuai berdasarkan metadata file cadangan diferensial. Jika file diperbesar, SQL Server menjadikan nol bagian yang diperbesar. Jika file baru harus dibuat (dibuat setelah basis diambil), SQL Server menginisialisasi file baru ke nol. 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 dengan tindakan tambah/hapus/bertambah/mengecil/ganti nama logis/ganti nama fisik kembali menjadi kasus pemecahan masalah yang menarik saat pemulihan.

Jika file database telah ditambahkan setelah basis penuh diambil

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

Jika file database telah dihilangkan setelah basis penuh diambil

Informasi parsial yang telah 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 bertambah besar sejak cadangan 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 menempatkan data bahkan di wilayah yang sudah berkembang sesuai spesifikasi parsial. Jika ukuran file bertambah setelah informasi parsial diambil, perubahan di bagian file yang bertambah ukurannya dipulihkan dengan menjalankan kembali 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 memengaruhi pemulihan, karena nama logis tidak muncul di dokumen metadata penulis atau dokumen komponen cadangan. Perubahan nama logis 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, pergantian nama belum berlaku, klien masih akan memulihkan data ke lokasi lama. Memulai ulang database setelah pemulihan memicu perubahan nama fisik mulai berlaku. Jika pada saat pencadangan diferensial, perubahan nama file fisik sudah berlaku, maka sebagian data, jika ada, dicadangkan dari jalur fisik baru.

Pasca pemulihan

Selama peristiwa pemulihan pasca, penulis SQL melakukan operasi pengulangan dan pemulihan normal (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 ada basis yang berbeda untuk kontainer yang berbeda. Untuk pencadangan katalog teks lengkap VSS, ini berarti untuk semua kontainer katalog teks lengkap, cadangan diferensial berbasis tanda waktu tunggal, tidak seperti kasus cadangan diferensial SQL Server asli, di mana ada satu basis tanda waktu per kontainer katalog teks lengkap.

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

OnIdentify

Dalam 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 ditetapkan selama pencadangan penuh. Dalam OnPostSnapshot(), penulis memanggil IVssComponent::SetBackupStamp() untuk menyimpan cap waktu bersama komponen dalam dokumen cadangan.

Pencadangan diferensial

Aplikasi cadangan 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 setiap file (seluruh file) yang cap waktu modifikasi terakhirnya lebih besar dari cap waktu yang ditentukan oleh waktu modifikasi terakhir untuk file yang ditetapkan 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.

• Memperbesar ukuran file sebelum memasukkan 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 hanya salinan

Terkadang perlu mengambil cadangan yang ditujukan untuk tujuan khusus. Misalnya, Anda mungkin perlu membuat salinan database untuk tujuan pengujian. Pencadangan ini seharusnya tidak memengaruhi prosedur pencadangan dan pemulihan keseluruhan untuk database. Penggunaan opsi COPY_ONLY menentukan bahwa pencadangan dilakukan di luar jalur utama dan seharusnya tidak memengaruhi urutan pencadangan normal. Penulis SQL mendukung jenis cadangan khusus salinan dengan instans SQL Server.

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

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

Mengembalikan dengan memindahkan

VSS memungkinkan pemohon (aplikasi cadangan) 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 test.mdf file aktual 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.

Penggantian nama database

Pemohon mungkin perlu memulihkan database SQL Server 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 wszRestoreOptions parameter).

Penulis SQL mengambil seluruh konten nilai Nama Komponen Baru dan menggunakannya sebagai nama baru untuk database yang dipulihkan. Jika tidak ada opsi yang ditentukan, SQL Server 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.

Cuplikan yang dipulihkan secara 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 cuplikan berstatus baca-saja, cuplikan tidak dapat dipulihkan melalui proses normal menghubungkan database.

Dimungkinkan untuk pemulihan otomatis cuplikan sebagai bagian dari proses pembuatannya. Sebagai bagian dari dokumen metadata writer, SQL writer menentukan flag komponen VSS_CF_APP_ROLLBACK_RECOVERY untuk menunjukkan bahwa pemulihan perlu dilakukan pada database dalam cuplikan sebelum database dapat diakses. Ketika menentukan set cuplikan, pemohon dapat menunjukkan bahwa cuplikan harus menjadi cuplikan rollback aplikasi (artinya, semua file database dalam cuplikan dimaksudkan untuk berada dalam status konsisten untuk penggunaan aplikasi) atau cuplikan cadangan (cuplikan yang digunakan untuk mencadangkan data agar dapat dipulihkan nanti jika terjadi kegagalan sistem).

Pemohon harus mengatur VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY untuk menunjukkan bahwa komponen ini ditetapkan untuk tujuan selain pencadangan. VSS kemudian berkorelasi VSS_CF_APP_ROLLBACK_RECOVERY dengan penulis SQL yang ditentukan pada komponen yang dipilih dengan VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, dan menentukan bahwa pemulihan otomatis sedang terjadi. VSS membuat rekam jepret dapat ditulis untuk jangka waktu terbatas dan secara otomatis menambahkan VSS_VOLSNAP_ATTR_AUTORECOVERY bit ke konteks rekam jepret.

Di SQL Server, pemulihan otomatis hanya boleh diterapkan pada snapshot pembatalan aplikasi tetapi tidak untuk backup snapshot. Untuk cuplikan rollback aplikasi, proses pemulihan otomatis dibuat oleh penulis SQL selama PostSnapShotevent. Proses ini melakukan hal berikut untuk setiap database SQL Server yang dipilih secara eksplisit (oleh pemohon) dalam kumpulan 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").

• Mengecilkan file log.

  Ini mengurangi jumlah operasi copy-on-write yang tidak perlu yang harus dilakukan oleh framework 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 mungkin digunakan untuk mengekspor data dari halaman tertentu (pada titik waktu tertentu) dari log untuk memperbaiki masalah dalam database online.

• Lepaskan database.

Sekarang ada gambar snapshot yang konsisten dan dipulihkan yang dapat dilampirkan untuk pencarian.

Transaksi multi-database

Dalam versi SQL Server yang lebih lama, database rekam jepret terkadang berisi beberapa transaksi multi-database dalam penerbangan. Selama operasi pemulihan, penulis SQL 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 mungkin 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 dilakukan dalam database A dan digulung balik dalam database B. Ini mungkin menyebabkan beberapa inkonsistensi dalam set rekam jepret.

Versi Windows yang lebih baru memiliki komponen Koordinator Transaksi Terdistribusi Microsoft (MS DTC) yang ditingkatkan yang memperbaiki masalah inkonsistensi ini untuk transaksi yang mencakup database di seluruh instans SQL Server. Versi SQL Server yang lebih baru 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 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 dapat melampirkan database. Klien yang meminta lampiran file database pada rekam jepret harus menjadi anggota Builtin/Administrators atau akun SQL Server.

Basis data pengguna dengan model pemulihan sederhana

Jika database master dipulihkan bersama dengan database pengguna yang menggunakan model pemulihan sederhana, database pengguna dapat dipulihkan menggunakan teknik yang sama dengan database master: dengan mematikan instans, cukup salin atau mount volume. Ketika instans SQL dimulai, semuanya pulih.

Memajukan basis data pengguna

Jika database pengguna harus dipulihkan dan digulirkan ke depan bersama dengan pemulihan database master, instans tidak boleh memulai dan memulihkan database master dan database pengguna secara bersamaan.

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 pada saat yang sama (yaitu, database pengguna dalam model pemulihan sederhana) melalui salinan file, atau pemasangan volume, melalui VSS.

      • Jika database pengguna yang akan digulirkan ke depan tidak berada pada volume yang sama dengan database sistem, volume tersebut tidak boleh dibawa kembali saat ini. Skenario ini memerlukan perencanaan sebelum membuat cadangan.

      • Jika database pengguna berada pada volume yang sama dengan database sistem, database pengguna perlu disembunyikan dari SQL Server.

   2. Mulai instans SQL Server menggunakan -f parameter . (Saat menggunakan opsi startup -f, hanya database master yang dapat dipulihkan.)

      1. Terbitkan ALTER DATABASE <database> SET OFFLINE (atau copot database) agar setiap database digulirkan ke depan.

      2. Matikan server 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, sebagaimana dijelaskan dalam WITH NORECOVERY.

Dokumen metadata penulis: Contoh

Database bernama DB1, milik instans Instance1 SQL Server di komputer Server1, 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 kelompok 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

Database file 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 berkas 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

File teks lengkap foo:

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 menu 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.

Tutup otomatis database

Untuk cadangan berbasis non-komponen, penutupan otomatis basis data dilakukan saat memeriksa kondisi cacat, tetapi basis data yang ditutup otomatis tidak dibekukan secara eksplisit selama operasi cadangan.

Skenario yang diharapkan di sini adalah bahwa banyak database tertutup mungkin ada, dan Anda 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. Meskipun skenario ini tidak mungkin, 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 masterdatabase , , modeldan 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.

Konten terkait

• Pencatatan Penulis VSS SQL Server
• BACKUP (Transact-SQL)
• Pernyataan RESTORE (Transact-SQL)
• Mencadangkan dan Memulihkan Database SQL Server
• Pencadangan hanya salin
• Pencadangan log transaksi (SQL Server)
• Menerapkan Pencadangan Log Transaksi (SQL Server)
• Arsitektur dan panduan manajemen log transaksi SQL Server