BACKUP (Transact-SQL)

Mencadangkan database SQL.

Pilih produk

Di baris berikut, pilih nama produk yang Anda minati, dan hanya informasi produk tersebut yang ditampilkan.

Untuk informasi selengkapnya tentang konvensi sintaks, lihat Konvensi Sintaks T-SQL.

* SQL Server *  

 

SQL Server

Mencadangkan database SQL Server lengkap untuk membuat cadangan database, atau satu atau beberapa file atau grup file database untuk membuat cadangan file (DATABASE CADANGAN). Selain itu, di bawah model pemulihan penuh atau model pemulihan yang dicatat secara massal, mencadangkan log transaksi database untuk membuat cadangan log (BACKUP LOG).

Sintaks

--Back up a whole database
BACKUP DATABASE { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up specific files or filegroups
BACKUP DATABASE { database_name | @database_name_var }
 <file_or_filegroup> [ ,...n ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Create a partial backup
BACKUP DATABASE { database_name | @database_name_var }
 READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up the transaction log (full and bulk-logged recovery models)
BACKUP LOG
  { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | \<log-specific_optionspec> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

<backup_device>::=
 {
  { logical_device_name | @logical_device_name_var }
 | {   DISK
     | TAPE
     | URL } =
     { 'physical_device_name' | @physical_device_name_var | 'NUL' }
 }

<MIRROR TO clause>::=
 MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=
 {
   FILE = { logical_file_name | @logical_file_name_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 }

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::=
--Backup Set Options
   COPY_ONLY
 | [ COMPRESSION [ ALGORITHM = { MS_XPRESS | accelerator_algorithm } ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--Media Set Options
   { NOINIT | INIT }
 | { NOSKIP | SKIP }
 | { NOFORMAT | FORMAT }
 | MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Tape Options
   { REWIND | NOREWIND }
 | { UNLOAD | NOUNLOAD }

--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   `SERVER CERTIFICATE` = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

Argumen

DATABASE

Menentukan pencadangan database lengkap. Jika daftar file dan grup file ditentukan, hanya file dan grup file yang dicadangkan. Selama pencadangan database penuh atau diferensial, SQL Server mencadangkan cukup log transaksi untuk menghasilkan database yang konsisten saat cadangan dipulihkan.

Saat Anda memulihkan cadangan yang dibuat oleh BACKUP DATABASE ( cadangan data), seluruh cadangan dipulihkan. Hanya cadangan log yang dapat dipulihkan ke waktu atau transaksi tertentu dalam cadangan.

Catatan

Hanya pencadangan database lengkap yang dapat dilakukan pada master database.

LOG

Menentukan cadangan log transaksi saja. Log dicadangkan dari cadangan log terakhir yang berhasil dijalankan ke akhir log saat ini. Sebelum dapat membuat cadangan log pertama, Anda harus membuat cadangan penuh.

Anda dapat memulihkan cadangan log ke waktu atau transaksi tertentu dalam cadangan dengan menentukan WITH STOPAT, , STOPATMARKatau STOPBEFOREMARK dalam pernyataan RESTORE LOG Anda.

Catatan

Setelah pencadangan log umum, beberapa catatan log transaksi menjadi tidak aktif, kecuali Jika Anda menentukan WITH NO_TRUNCATE atau COPY_ONLY. Log dipotok setelah semua rekaman dalam satu atau beberapa file log virtual menjadi tidak aktif. Jika log tidak dipotok setelah pencadangan log rutin, mungkin ada sesuatu yang menunda pemotokan log. Untuk informasi selengkapnya, lihat Faktor-faktor yang dapat menunda pemotongan log.

GROUP (<database>,... n)

Diperkenalkan pada SQL Server 2022 (16.x).

Mencadangkan sekelompok database. Menggunakan cadangan rekam jepret. Membutuhkan WITH METADATA_ONLY. Lihat Membuat cadangan rekam jepret Transact-SQL.

SERVER

Diperkenalkan pada SQL Server 2022 (16.x).

Cadangkan semua database pada instans SQL Server. Menggunakan cadangan rekam jepret. Membutuhkan WITH METADATA_ONLY. Lihat Membuat cadangan rekam jepret Transact-SQL.

METADATA_ONLY

Diperkenalkan pada SQL Server 2022 (16.x).

Diperlukan untuk pencadangan rekam jepret. BACKUP SERVER, atau BACKUP GROUP... Lihat Membuat cadangan rekam jepret Transact-SQL.

METADATA_ONLY identik dengan SNAPSHOT. Antarmuka perangkat virtual (VDI) menggunakan SNAPSHOT. Untuk informasi tentang VDI, lihat Referensi antarmuka perangkat virtual (VDI).

{ database_name | @database_name_var }

Apakah database tempat log transaksi, database parsial, atau database lengkap dicadangkan. Jika disediakan sebagai variabel (@database_name_var), nama ini dapat ditentukan baik sebagai konstanta string (@database_name_var=nama database) atau sebagai variabel jenis data string karakter, kecuali untuk jenis data ntext atau teks .

Catatan

Database cermin dalam kemitraan pencerminan database tidak dapat dicadangkan.

<> file_or_filegroup [ , ...n ]

Hanya digunakan dengan DATABASE CADANGAN, menentukan file database atau grup file untuk disertakan dalam cadangan file, atau menentukan file baca-saja atau grup file untuk disertakan dalam cadangan parsial.

FILE = { logical_file_name | @logical_file_name_var }

Adalah nama logis file atau variabel yang nilainya sama dengan nama logis file yang akan disertakan dalam cadangan.

GRUP FILE = { logical_filegroup_name | @logical_filegroup_name_var }

Adalah nama logis dari grup file atau variabel yang nilainya sama dengan nama logis grup file yang akan disertakan dalam cadangan. Di bawah model pemulihan sederhana, cadangan grup file hanya diizinkan untuk grup file baca-saja.

Catatan

Pertimbangkan untuk menggunakan cadangan file saat ukuran database dan persyaratan performa membuat cadangan database tidak praktis. Perangkat NUL dapat digunakan untuk menguji performa cadangan, tetapi tidak boleh digunakan di lingkungan produksi.

n
Adalah tempat penampung yang menunjukkan bahwa beberapa file dan grup file dapat ditentukan dalam daftar yang dipisahkan koma. Jumlahnya tidak terbatas.

Untuk informasi selengkapnya, lihat Pencadangan File Lengkap dan File Cadangan dan Grup File.

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,... n ] ]

Menentukan cadangan parsial. Cadangan parsial mencakup semua file baca/tulis dalam database: grup file utama dan grup file sekunder baca/tulis, dan juga file atau grup file baca-saja yang ditentukan.

READ_WRITE_FILEGROUPS

Menentukan bahwa semua grup file baca/tulis dicadangkan dalam pencadangan parsial. Jika database bersifat baca-saja, READ_WRITE_FILEGROUPS hanya menyertakan grup file utama.

Penting

Secara eksplisit mencantumkan grup file baca/tulis dengan menggunakan FILEGROUP alih-alih READ_WRITE_FILEGROUPS membuat cadangan file.

GRUPFILE = { logical_filegroup_name | @logical_filegroup_name_var }

Adalah nama logis dari grup file baca-saja atau variabel yang nilainya sama dengan nama logis grup file baca-saja yang akan disertakan dalam cadangan parsial. Untuk informasi selengkapnya, lihat "<file_or_filegroup>," sebelumnya di artikel ini.

n
Adalah tempat penampung yang menunjukkan bahwa beberapa grup file baca-saja dapat ditentukan dalam daftar yang dipisahkan koma.

Untuk informasi selengkapnya tentang pencadangan parsial, lihat Pencadangan Parsial.

UNTUK <backup_device> [ , ...n ]

Menunjukkan bahwa set perangkat cadangan yang menyertainya adalah set media yang tidak disarankan atau yang pertama dari cermin dalam set media yang dicerminkan (di mana satu atau beberapa klausul MIRROR TO dinyatakan).

<backup_device>
Menentukan perangkat pencadangan logis atau fisik yang akan digunakan untuk operasi pencadangan.

{ logical_device_name | @logical_device_name_var }

Berlaku untuk: SQL Server
Adalah nama logis perangkat cadangan tempat database dicadangkan. Nama logis harus mengikuti aturan untuk pengidentifikasi. Jika disediakan sebagai variabel (@logical_device_name_var), nama perangkat cadangan dapat ditentukan sebagai konstanta string (@logical_device_name_var= nama perangkat cadangan logis) atau sebagai variabel jenis data string karakter apa pun kecuali untuk tipe data ntext atau teks .

{ DISK | tape | URL} = { 'physical_device_name'physical_device_name_var | @ | 'NUL' }

Berlaku untuk: SQL Server (URL yang dimulai dengan SQL Server 2012 (11.x) SP1 CU2)

Menentukan file disk atau perangkat pita, atau URL.

Format URL digunakan untuk membuat cadangan ke penyimpanan objek yang kompatibel dengan Microsoft Azure Blob Storage atau S3. Untuk informasi dan contoh selengkapnya, lihat:

Catatan

Perangkat disk NUL akan membuang semua informasi yang dikirim ke dalamnya dan hanya boleh digunakan untuk pengujian. Ini bukan untuk penggunaan produksi.

Penting

Dimulai dengan SQL Server 2012 (11.x) SP1 CU2 hingga SQL Server 2014 (12.x), Anda hanya dapat mencadangkan ke satu perangkat saat mencadangkan ke URL untuk Azure Blob Storage. Untuk mencadangkan ke beberapa perangkat saat mencadangkan ke URL, Anda harus menggunakan SQL Server 2016 (13.x) dan yang lebih baru dan Anda harus menggunakan token Tanda Tangan Akses Bersama (SAS). Untuk contoh pembuatan Tanda Tangan Akses Bersama, lihat SQL Server Pencadangan ke URL dan Menyederhanakan pembuatan Kredensial SQL dengan token Tanda Tangan Akses Bersama (SAS) di Azure Storage dengan Powershell.

Perangkat disk tidak harus ada sebelum ditentukan dalam pernyataan BACKUP. Jika perangkat fisik ada dan opsi INIT tidak ditentukan dalam pernyataan BACKUP, cadangan ditambahkan ke perangkat.

Catatan

Perangkat NUL akan membuang semua input yang dikirim ke file ini, namun cadangan masih akan menandai semua halaman sebagai dicadangkan.

Untuk informasi selengkapnya, lihat Perangkat Cadangan.

Catatan

Opsi TAPE akan dihapus dalam versi SQL Server mendatang. Hindari menggunakan fitur ini dalam pekerjaan pengembangan baru, dan rencanakan untuk memodifikasi aplikasi yang saat ini menggunakan fitur ini.

n
Adalah tempat penampung yang menunjukkan bahwa hingga 64 perangkat cadangan dapat ditentukan dalam daftar yang dipisahkan koma.

CERMIN KE <backup_device> [ , , ... n ]

Menentukan satu set hingga tiga perangkat cadangan sekunder, yang masing-masing mencerminkan perangkat cadangan yang ditentukan dalam klausa TO. Klausa MIRROR TO harus menentukan jenis dan jumlah perangkat cadangan yang sama dengan klausa TO. Jumlah maksimum klausa MIRROR TO adalah tiga.

Opsi ini hanya tersedia di edisi Enterprise SQL Server.

Catatan

Untuk MIRROR TO = DISK, BACKUP secara otomatis menentukan ukuran blok yang sesuai untuk perangkat disk berdasarkan ukuran sektor disk. Jika disk MIRROR TO diformat dengan ukuran sektor yang berbeda dari disk yang ditentukan sebagai perangkat cadangan utama, perintah cadangan akan gagal. Untuk mencerminkan cadangan ke perangkat yang memiliki ukuran sektor yang berbeda, parameter BLOCKSIZE harus ditentukan, dan harus diatur ke ukuran sektor tertinggi di antara semua perangkat target. Untuk informasi selengkapnya tentang ukuran blok, lihat "BLOCKSIZE" nanti dalam topik ini.

<backup_device>
Lihat "<backup_device>", sebelumnya di bagian ini.

n
Adalah tempat penampung yang menunjukkan bahwa hingga 64 perangkat cadangan dapat ditentukan dalam daftar yang dipisahkan koma. Jumlah perangkat dalam klausa MIRROR TO harus sama dengan jumlah perangkat dalam klausa TO.

Untuk informasi selengkapnya, lihat "Keluarga Media di Set Media Cermin" di bagian Keterangan , nanti di artikel ini.

[ next-mirror -to ]
Adalah tempat penampung yang menunjukkan bahwa satu pernyataan BACKUP dapat berisi hingga tiga klausa MIRROR TO, selain klausa TO tunggal.

Opsi WITH

Menentukan opsi yang akan digunakan dengan operasi pencadangan.

INFORMASI MASUK

Berlaku untuk: SQL Server (dimulai dengan SQL Server 2012 (11.x) SP1 CU2).

Digunakan hanya saat membuat cadangan ke microsoft Azure Blob Storage.

FILE_SNAPSHOT

Berlaku untuk: SQL Server (dimulai dengan SQL Server 2016 (13.x)).

Digunakan untuk membuat rekam jepret Azure dari file database saat semua file database SQL Server disimpan menggunakan Azure Blob Storage. Untuk informasi selengkapnya, lihat SQL Server File Data di Microsoft Azure. SQL Server Snapshot Backup mengambil rekam jepret Azure dari file database (file data dan log) dalam keadaan konsisten. Sekumpulan rekam jepret Azure yang konsisten membentuk cadangan dan direkam dalam file cadangan. Satu-satunya perbedaan antara BACKUP DATABASE TO URL WITH FILE_SNAPSHOT dan BACKUP LOG TO URL WITH FILE_SNAPSHOT adalah bahwa yang terakhir juga memotong log transaksi sementara yang pertama tidak. Dengan SQL Server Snapshot Backup, setelah pencadangan penuh awal yang diperlukan oleh SQL Server untuk membuat rantai cadangan, hanya satu cadangan log transaksi yang diperlukan untuk memulihkan database ke titik waktu pencadangan log transaksi. Selain itu, hanya dua cadangan log transaksi yang diperlukan untuk memulihkan database ke titik waktu antara waktu dua pencadangan log transaksi.

DIFERENSIAL

Hanya digunakan dengan DATABASE CADANGAN, menentukan bahwa database atau cadangan file hanya boleh terdiri dari bagian database atau file yang diubah sejak pencadangan penuh terakhir. Pencadangan diferensial biasanya membutuhkan lebih sedikit ruang daripada pencadangan penuh. Gunakan opsi ini sehingga semua pencadangan log individual yang dilakukan sejak pencadangan penuh terakhir tidak harus diterapkan.

Catatan

Secara default, BACKUP DATABASE membuat pencadangan penuh.

Untuk informasi selengkapnya, lihat Pencadangan Diferensial.

ENKRIPSI

Digunakan untuk menentukan enkripsi untuk cadangan. Anda dapat menentukan algoritma enkripsi untuk mengenkripsi cadangan dengan atau menentukan NO_ENCRYPTION agar cadangan tidak dienkripsi. Enkripsi disarankan untuk membantu mengamankan file cadangan. Daftar algoritma yang dapat Anda tentukan adalah:

  • AES_128
  • AES_192
  • AES_256
  • TRIPLE_DES_3KEY
  • NO_ENCRYPTION

Jika Anda memilih untuk mengenkripsi, Anda juga harus menentukan enkripsi menggunakan opsi enkripsi:

  • SERVER CERTIFICATE = Encryptor_Name
  • SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATE dan SERVER ASYMMETRIC KEY adalah sertifikat dan kunci asimetris yang dibuat dalam master database. Untuk informasi selengkapnya, lihat CREATE CERTIFICATE dan CREATE ASYMMETRIC KEY masing-masing.

Peringatan

Ketika enkripsi digunakan bersama dengan FILE_SNAPSHOT argumen, file metadata itu sendiri dienkripsi menggunakan algoritma enkripsi yang ditentukan dan sistem memverifikasi bahwa Enkripsi Data Transparan (TDE) telah selesai untuk database. Tidak ada enkripsi tambahan yang terjadi untuk data itu sendiri. Pencadangan gagal jika database tidak dienkripsi atau jika enkripsi tidak selesai sebelum pernyataan cadangan diterbitkan.

Opsi Set Cadangan

Opsi ini beroperasi pada set cadangan yang dibuat oleh operasi pencadangan ini.

Catatan

Untuk menentukan kumpulan cadangan untuk operasi pemulihan, gunakan FILE = <backup_set_file_number> opsi . Untuk informasi selengkapnya tentang cara menentukan kumpulan cadangan, lihat "Menentukan Kumpulan Cadangan" di Argumen RESTORE.

COPY_ONLY

Menentukan bahwa cadangan adalah cadangan khusus salinan, yang tidak memengaruhi urutan cadangan normal. Cadangan khusus salinan dibuat secara independen dari pencadangan konvensional Anda yang dijadwalkan secara teratur. Pencadangan khusus salinan tidak memengaruhi prosedur pencadangan dan pemulihan keseluruhan untuk database.

Cadangan khusus salin harus digunakan dalam situasi di mana cadangan diambil untuk tujuan khusus, seperti mencadangkan log sebelum pemulihan file online. Biasanya, cadangan log hanya salin digunakan sekali lalu dihapus.

  • Saat digunakan dengan BACKUP DATABASE, COPY_ONLY opsi membuat cadangan lengkap yang tidak dapat berfungsi sebagai basis diferensial. Bitmap diferensial tidak diperbarui, dan cadangan diferensial bersifat seolah-olah cadangan hanya salin tidak ada. Cadangan diferensial berikutnya menggunakan cadangan penuh konvensional terbaru sebagai basisnya.

    Penting

    Jika DIFFERENTIAL dan COPY_ONLY digunakan bersama-sama, COPY_ONLY diabaikan, dan cadangan diferensial dibuat.

  • Saat digunakan dengan BACKUP LOG, COPY_ONLY opsi membuat cadangan log hanya salin, yang tidak memotong log transaksi. Cadangan log hanya salin tidak berpengaruh pada rantai log, dan cadangan log lainnya berulah seolah-olah cadangan hanya salin tidak ada.

Untuk informasi selengkapnya, lihat Pencadangan Khusus Salin.

[ KOMPRESI [ ALGORITMA = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

Menentukan apakah kompresi cadangan dilakukan pada cadangan ini, menggantikan default tingkat server.

Saat penginstalan, perilaku default bukanlah kompresi cadangan. Tetapi default ini dapat diubah dengan mengatur opsi konfigurasi server default kompresi cadangan . Untuk informasi tentang menampilkan nilai saat ini dari opsi ini, lihat Menampilkan atau Mengubah Properti Server.

Untuk informasi tentang menggunakan kompresi cadangan dengan database yang diaktifkan Transparent Data Encryption (TDE ), lihat bagian Keterangan .

PEMADATAN
Secara eksplisit memungkinkan kompresi cadangan.

NO_COMPRESSION
Secara eksplisit menonaktifkan kompresi cadangan.

SQL Server 2022 (16.x) memperkenalkan ALGORITHM, yang mengidentifikasi algoritma kompresi untuk operasi. Defaultnya adalah MS_XPRESS. Jika Anda telah mengonfigurasi akselerasi dan offloading terintegrasi, Anda dapat menggunakan akselerator yang disediakan oleh solusi. Misalnya, jika Anda telah mengonfigurasi Intel® QuickAssist Technology (QAT) untuk SQL Server, contoh berikut menyelesaikan pencadangan dengan solusi akselerator, dengan pustaka QATzip menggunakan QZ_DEFLATE dengan tingkat kompresi 1.

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE) 

DESKRIPSI = { 'text'text_variable | @ }

Menentukan teks bentuk bebas yang menjelaskan kumpulan cadangan. String dapat memiliki maksimal 255 karakter.

NAMA = { backup_set_name | @backup_set_var }

Menentukan nama kumpulan cadangan. Nama dapat memiliki maksimal 128 karakter. Jika NAME tidak ditentukan, nama tersebut kosong.

{ EXPIREDATE ='date' | HARI RETAINDAYS =}

Menentukan kapan kumpulan cadangan untuk cadangan ini dapat ditimpa. Jika kedua opsi ini digunakan, RETAINDAYS lebih diutamakan daripada EXPIREDATE.

Jika tidak ada opsi yang ditentukan, tanggal kedaluwarsa ditentukan oleh pengaturan konfigurasi mediaretensi . Untuk informasi selengkapnya, lihat Opsi Konfigurasi Server.

Penting

Opsi ini hanya mencegah SQL Server menimpa file. Pita dapat dihapus menggunakan metode lain, dan file disk dapat dihapus melalui sistem operasi. Untuk informasi selengkapnya tentang verifikasi kedaluwarsa, lihat SKIP dan FORMAT dalam topik ini.

EXPIREDATE = { 'date'date_var | @ }
Menentukan kapan set cadangan kedaluwarsa dan dapat ditimpa. Jika disediakan sebagai variabel (@date_var), tanggal ini harus mengikuti format tanggalwaktu sistem yang dikonfigurasi dan ditentukan sebagai salah satu dari berikut ini:

  • Konstanta string (@date_var= tanggal)
  • Variabel jenis data string karakter (kecuali untuk jenis data ntext atau teks )
  • Waktu smalldatetime
  • Variabel tanggalwaktu

Contohnya:

  • 'Dec 31, 2020 11:59 PM'
  • '1/1/2021'

Untuk informasi tentang cara menentukan nilai tanggalwaktu , lihat Jenis Tanggal dan Waktu.

Catatan

Untuk mengabaikan tanggal kedaluwarsa, gunakan SKIP opsi .

RETAINDAYS = { days | @days_var }
Menentukan jumlah hari yang harus berlalu sebelum set media cadangan ini dapat ditimpa. Jika disediakan sebagai variabel (@days_var), variabel harus ditentukan sebagai bilangan bulat.

{ METADATA_ONLY | SNAPSHOT }

Berlaku untuk: SQL Server 2022 (16.x)

METADATA_ONLY dan SNAPSHOT adalah sinonim.

Opsi Set Media

Opsi ini beroperasi pada set media secara keseluruhan.

{ NOINIT | INIT }

Mengontrol apakah operasi pencadangan ditambahkan ke atau menimpa set cadangan yang ada pada media cadangan. Defaultnya adalah menambahkan ke kumpulan cadangan terbaru di media (NOINIT).

Catatan

Untuk informasi tentang interaksi antara { NOINIT | INIT } dan { NOSKIP | SKIP }, lihat Komentar nanti dalam topik ini.

NOINIT
Menunjukkan bahwa kumpulan cadangan ditambahkan ke set media yang ditentukan, mempertahankan set cadangan yang ada. Jika kata sandi media ditentukan untuk set media, kata sandi harus disediakan. NOINIT adalah default.

Untuk informasi selengkapnya, lihat Set Media, Keluarga Media, dan Kumpulan Cadangan.

INIT
Menentukan bahwa semua set cadangan harus ditimpa, tetapi mempertahankan header media. Jika INIT ditentukan, kumpulan cadangan yang ada pada perangkat tersebut akan ditimpa, jika kondisi memungkinkan. Secara default, BACKUP memeriksa kondisi berikut dan tidak menimpa media cadangan jika ada salah satu kondisi:

  • Kumpulan cadangan apa pun belum kedaluwarsa. Untuk informasi selengkapnya, lihat EXPIREDATE opsi dan RETAINDAYS .
  • Nama set cadangan yang diberikan dalam pernyataan BACKUP, jika disediakan, tidak cocok dengan nama pada media cadangan. Untuk informasi selengkapnya, lihat opsi NAME, sebelumnya di bagian ini.

Untuk mengambil alih pemeriksaan ini, gunakan SKIP opsi .

Untuk informasi selengkapnya, lihat Set Media, Keluarga Media, dan Kumpulan Cadangan.

{ NOSKIP | SKIP }

Mengontrol apakah operasi pencadangan memeriksa tanggal kedaluwarsa dan waktu set cadangan pada media sebelum menimpanya.

Catatan

Untuk informasi tentang interaksi antara { NOINIT | INIT } dan { NOSKIP | SKIP }, lihat "Remarks," nanti dalam topik ini.

NOSKIP
Menginstruksikan pernyataan BACKUP untuk memeriksa tanggal kedaluwarsa semua set cadangan di media sebelum memungkinkannya ditimpa. Ini adalah perilaku default.

SKIP
Menonaktifkan pemeriksaan kedaluwarsa set cadangan dan nama yang biasanya dilakukan oleh pernyataan BACKUP untuk mencegah penimpaan set cadangan. Untuk informasi tentang interaksi antara { INIT | | NOINIT } dan { NOSKIP SKIP }, lihat "Remarks," nanti di artikel ini. Untuk menampilkan tanggal kedaluwarsa kumpulan cadangan, kueri kolom expiration_date tabel riwayat set cadangan .

{ NOFORMAT | FORMAT }

Menentukan apakah header media harus ditulis pada volume yang digunakan untuk operasi pencadangan ini, menimpa header media dan set cadangan yang ada.

NOFORMAT
Menentukan bahwa operasi pencadangan mempertahankan header media dan kumpulan cadangan yang ada pada volume media yang digunakan untuk operasi pencadangan ini. Ini adalah perilaku default.

FORMAT
Menentukan bahwa set media baru dibuat. FORMAT menyebabkan operasi pencadangan menulis header media baru pada semua volume media yang digunakan untuk operasi pencadangan. Isi volume yang ada menjadi tidak valid, karena header media dan kumpulan cadangan yang ada ditimpa.

Penting

Gunakan FORMAT dengan hati-hati. Memformat volume apa pun dari set media membuat seluruh set media tidak dapat digunakan. Misalnya, jika Anda menginisialisasi satu pita milik set media bergaris yang ada, seluruh set media dirender tidak berguna.

Menentukan FORMAT menyiratkan SKIP; SKIP tidak perlu dinyatakan secara eksplisit.

MEDIADESCRIPTION = { text | @text_variable }

Menentukan deskripsi teks bentuk bebas, maksimal 255 karakter, dari set media.

MEDIANAME = { media_name | @media_name_variable }

Menentukan nama media untuk seluruh set media cadangan. Nama media tidak boleh lebih dari 128 karakter. Jika MEDIANAME ditentukan, nama media tersebut harus cocok dengan nama media yang ditentukan sebelumnya yang sudah ada pada volume cadangan. Jika tidak ditentukan, atau jika opsi SKIP ditentukan, tidak ada pemeriksaan verifikasi nama media.

BLOCKSIZE = { blocksize | @blocksize_variable }

Menentukan ukuran blok fisik, dalam byte. Ukuran yang didukung adalah 512, 1024, 2048, 4096, 8192, 16384, 32768, dan 65536 (64 KB) byte. Defaultnya adalah 65536 untuk perangkat pita dan 512 sebaliknya. Biasanya, opsi ini tidak perlu karena BACKUP secara otomatis memilih ukuran blok yang sesuai dengan perangkat. Secara eksplisit menyatakan ukuran blok mengambil alih pilihan otomatis ukuran blok.

Jika Anda mengambil cadangan yang Anda rencanakan untuk disalin dan dipulihkan dari CD-ROM, tentukan BLOCKSIZE=2048.

Catatan

Opsi ini biasanya memengaruhi performa hanya saat menulis ke perangkat pita.

Opsi transfer data

BUFFERCOUNT = { buffercount | @buffercount_variable }

Menentukan jumlah total buffer I/O yang akan digunakan untuk operasi pencadangan. Anda dapat menentukan bilangan bulat positif apa pun; namun, sejumlah besar buffer dapat menyebabkan kesalahan "kehabisan memori" karena ruang alamat virtual yang tidak memadai dalam proses Sqlservr.exe.

Total ruang yang digunakan oleh buffer ditentukan oleh: BUFFERCOUNT * MAXTRANSFERSIZE.

Catatan

Untuk informasi penting tentang menggunakan opsi ini BUFFERCOUNT , lihat opsi transfer data BufferCount yang salah dapat menyebabkan blog kondisi OOM .

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Menentukan unit transfer terbesar dalam byte yang akan digunakan antara SQL Server dan media cadangan. Nilai yang mungkin adalah kelipatan 65536 byte (64 KB) berkisar hingga 4194304 byte (4 MB).

Saat membuat cadangan dengan menggunakan Layanan Penulis SQL, jika database telah mengonfigurasi FILESTREAM, atau menyertakan grup file yang dioptimalkan memori, maka MAXTRANSFERSIZE pada saat pemulihan harus lebih besar dari atau sama dengan MAXTRANSFERSIZE yang digunakan saat cadangan dibuat.

Untuk database yang diaktifkan Transparent Data Encryption (TDE) dengan satu file data, defaultnya MAXTRANSFERSIZE adalah 65536 (64 KB). Untuk database terenkripsi non-TDE, defaultnya MAXTRANSFERSIZE adalah 1048576 (1 MB) saat menggunakan cadangan ke DISK, dan 65536 (64 KB) saat menggunakan VDI atau TAPE. Untuk informasi selengkapnya tentang menggunakan kompresi cadangan dengan database terenkripsi TDE, lihat bagian Keterangan .

Opsi manajemen kesalahan

Opsi ini memungkinkan Anda menentukan apakah checksum cadangan diaktifkan untuk operasi pencadangan dan apakah operasi berhenti mengalami kesalahan.

{ | NO_CHECKSUM CHECKSUM }

Mengontrol apakah checksum cadangan diaktifkan.

NO_CHECKSUM
Secara eksplisit menonaktifkan pembuatan checksum cadangan (dan validasi checksum halaman). Ini adalah perilaku default.

CHECKSUM
Menentukan bahwa operasi pencadangan memverifikasi setiap halaman untuk halaman checksum dan torn, jika diaktifkan dan tersedia, dan menghasilkan checksum untuk seluruh cadangan.

Menggunakan checksum cadangan dapat memengaruhi beban kerja dan throughput cadangan.

Untuk informasi selengkapnya, lihat Kemungkinan Kesalahan Media Selama Pencadangan dan Pemulihan.

{ | STOP_ON_ERROR CONTINUE_AFTER_ERROR }

Mengontrol apakah operasi pencadangan berhenti atau berlanjut setelah mengalami kesalahan checksum halaman.

STOP_ON_ERROR
Menginstruksikan BACKUP gagal jika checksum halaman tidak memverifikasi. Ini adalah perilaku default.

CONTINUE_AFTER_ERROR
Menginstruksikan BACKUP untuk melanjutkan meskipun mengalami kesalahan seperti checksum yang tidak valid atau halaman yang robek.

Jika Anda tidak dapat mencadangkan ekor log menggunakan opsi NO_TRUNCATE saat database rusak, Anda dapat mencoba pencadangan log log ekor dengan menentukan CONTINUE_AFTER_ERROR alih-alih NO_TRUNCATE.

Untuk informasi selengkapnya, lihat Kemungkinan Kesalahan Media Selama Pencadangan dan Pemulihan.

Opsi kompatibilitas

RESTART

Dimulai dengan SQL Server 2008, tidak berpengaruh. Opsi ini diterima oleh versi untuk kompatibilitas dengan versi SQL Server sebelumnya.

Opsi pemantauan

STATS [ =persentase ]

Menampilkan pesan setiap kali persentase lain selesai, dan digunakan untuk mengukur kemajuan. Jika persentase dihilangkan, SQL Server menampilkan pesan setelah setiap 10 persen selesai.

Opsi STATS melaporkan persentase selesai pada ambang batas untuk melaporkan interval berikutnya. Ini sekitar persentase yang ditentukan; misalnya, dengan STATS=10, jika jumlah yang diselesaikan adalah 40 persen, opsi mungkin menampilkan 43 persen. Untuk set cadangan besar, ini bukan masalah, karena persentase selesai bergerak sangat lambat antara panggilan I/O yang selesai.

Opsi pita

Opsi ini hanya digunakan untuk perangkat TAPE. Jika perangkat nontape sedang digunakan, opsi ini diabaikan.

{ GULUNG BALIK | NOREWIND }

MUNDUR
Menentukan bahwa SQL Server melepaskan dan memutar balik pita. REWIND adalah default.

NOREWIND
Menentukan bahwa SQL Server akan tetap membuka pita setelah operasi pencadangan. Anda dapat menggunakan opsi ini untuk membantu meningkatkan performa saat melakukan beberapa operasi pencadangan ke pita.

NOREWIND menyiratkan NOUNLOAD, dan opsi ini tidak kompatibel dalam satu pernyataan BACKUP.

Catatan

Jika Anda menggunakan NOREWIND, instans SQL Server mempertahankan kepemilikan drive pita hingga pernyataan BACKUP atau RESTORE yang berjalan dalam proses yang sama menggunakan opsi atau UNLOAD , atau instans REWIND server dimatikan. Menjaga pita terbuka mencegah proses lain mengakses pita. Untuk informasi tentang cara menampilkan daftar pita terbuka dan menutup pita terbuka, lihat Perangkat Cadangan.

{ UNLOAD | NOUNLOAD }

Catatan

UNLOAD dan NOUNLOAD adalah pengaturan sesi yang bertahan selama masa pakai sesi atau hingga direset dengan menentukan alternatif.

MEMBONGKAR
Menentukan bahwa pita secara otomatis disusun ulang dan dibongkar ketika cadangan selesai. UNLOAD adalah default saat sesi dimulai.

NOUNLOAD
Menentukan bahwa setelah operasi BACKUP, pita tetap dimuat pada drive pita.

Catatan

Untuk cadangan ke perangkat cadangan pita, BLOCKSIZE opsi untuk memengaruhi performa operasi pencadangan. Opsi ini biasanya memengaruhi performa hanya saat menulis ke perangkat pita.

Opsi khusus log

Opsi ini hanya digunakan dengan BACKUP LOG.

Catatan

Jika Anda tidak ingin mengambil cadangan log, gunakan model pemulihan sederhana. Untuk informasi selengkapnya, lihat Model Pemulihan.

{ NORECOVERY | undo_file_name SIAGA = }

NORECOVERY
Mencadangkan ekor log dan meninggalkan database dalam status PEMULIHAN. NORECOVERY berguna saat melakukan failover ke database sekunder atau saat menyimpan ekor log sebelum operasi RESTORE.

Untuk melakukan pencadangan log upaya terbaik yang melompati pemotokan log lalu mengambil database ke status PEMULIHAN secara atomik, gunakan NO_TRUNCATE opsi dan NORECOVERY bersama-sama.

standby_file_name SIAGA =
Mencadangkan ekor log dan meninggalkan database dalam status baca-saja dan SIAGA. Klausa STANDBY menulis data siaga (melakukan pembatalan, tetapi dengan opsi pemulihan lebih lanjut). Menggunakan opsi STANDBY setara dengan BACKUP LOG WITH NORECOVERY diikuti dengan RESTORE WITH STANDBY.

Menggunakan mode siaga memerlukan file siaga, ditentukan oleh standby_file_name, yang lokasinya disimpan dalam log database. Jika file yang ditentukan sudah ada, Mesin Database akan menimpanya; jika file tidak ada, Mesin Database akan membuatnya. File siaga menjadi bagian dari database.

File ini menyimpan perubahan yang digulung balik, yang harus dibalik jika operasi RESTORE LOG kemudian akan diterapkan. Harus ada cukup ruang disk agar file siaga tumbuh sehingga dapat berisi semua halaman berbeda dari database yang dimodifikasi dengan mengembalikan transaksi yang tidak dilakukan.

NO_TRUNCATE

Menentukan bahwa log transaksi tidak boleh dipotok dan menyebabkan Mesin Database mencoba pencadangan terlepas dari status database. Akibatnya, cadangan yang diambil dengan NO_TRUNCATE mungkin memiliki metadata yang tidak lengkap. Opsi ini memungkinkan pencadangan log transaksi dalam situasi di mana database rusak.

Opsi NO_TRUNCATE LOG BACKUP setara dengan menentukan COPY_ONLY dan CONTINUE_AFTER_ERROR.

NO_TRUNCATE Tanpa opsi , database harus dalam status ONLINE. Jika database dalam status SUSPENDED, Anda mungkin dapat membuat cadangan dengan menentukan NO_TRUNCATE. Tetapi jika database berada dalam status OFFLINE atau DARURAT, BACKUP tidak diizinkan bahkan dengan NO_TRUNCATE. Untuk informasi tentang status database, lihat Status Database.

Tentang bekerja dengan cadangan SQL Server

Bagian ini memperkenalkan konsep pencadangan penting berikut:

Jenis PencadanganPemotongan Log TransaksiMemformat Media CadanganBekerja dengan Perangkat Cadangan dan Set MediaMemulihkan Cadangan SQL Server

Catatan

Untuk pengenalan pencadangan di SQL Server, lihat Gambaran Umum Pencadangan.

Tipe Microsoft Azure Backup

Jenis cadangan yang didukung bergantung pada model pemulihan database, sebagai berikut

  • Semua model pemulihan mendukung pencadangan data penuh dan diferensial.

    Cakupan pencadangan Tipe Microsoft Azure Backup
    Seluruh database Pencadangan database mencakup seluruh database.

    Secara opsional, setiap cadangan database dapat berfungsi sebagai dasar dari serangkaian satu atau beberapa cadangan database diferensial.
    Database parsial Cadangan parsial mencakup grup file baca/-tulis dan, mungkin, satu atau beberapa file baca-saja atau grup file.

    Secara opsional, setiap cadangan parsial dapat berfungsi sebagai dasar dari serangkaian satu atau beberapa cadangan parsial diferensial.
    File atau grup file Cadangan file mencakup satu atau beberapa file atau grup file, dan hanya relevan untuk database yang berisi beberapa grup file. Di bawah model pemulihan sederhana, cadangan file pada dasarnya dibatasi untuk grup file sekunder baca-saja.
    Secara opsional, setiap cadangan file dapat berfungsi sebagai dasar dari serangkaian satu atau beberapa cadangan file diferensial.
  • Di bawah model pemulihan penuh atau model pemulihan yang dicatat secara massal, cadangan konvensional juga menyertakan cadangan log transaksi berurutan (atau cadangan log), yang diperlukan. Setiap cadangan log mencakup bagian dari log transaksi yang aktif ketika cadangan dibuat, dan mencakup semua catatan log yang tidak dicadangkan dalam cadangan log sebelumnya.

    Untuk meminimalkan paparan kehilangan kerja, dengan biaya overhead administratif, Anda harus menjadwalkan pencadangan log yang sering. Menjadwalkan pencadangan diferensial antara pencadangan penuh dapat mengurangi waktu pemulihan dengan mengurangi jumlah cadangan log yang harus Anda pulihkan setelah memulihkan data.

    Kami menyarankan agar Anda menempatkan cadangan log pada volume terpisah daripada cadangan database.

    Catatan

    Sebelum dapat membuat cadangan log pertama, Anda harus membuat cadangan penuh.

  • Cadangan khusus salinan adalah cadangan penuh tujuan khusus atau cadangan log yang independen dari urutan normal cadangan konvensional. Untuk membuat cadangan khusus salinan, tentukan opsi COPY_ONLY dalam pernyataan BACKUP Anda. Untuk informasi selengkapnya, lihat Pencadangan Khusus Salin.

Pemotongan Log Transaksi

Untuk menghindari pengisian log transaksi database, pencadangan rutin sangat penting. Di bawah model pemulihan sederhana, pemotongan log terjadi secara otomatis setelah Anda mencadangkan database, dan di bawah model pemulihan penuh, setelah Anda mencadangkan log transaksi. Namun, terkadang proses pemotongan dapat tertunda. Untuk informasi tentang faktor-faktor yang dapat menunda pemotongan log, lihat Log Transaksi.

Catatan

Opsi BACKUP LOG WITH NO_LOG dan WITH TRUNCATE_ONLY telah dihentikan. Jika Anda menggunakan pemulihan model pemulihan penuh atau dicatat secara massal dan Anda harus menghapus rantai cadangan log dari database, beralihlah ke model pemulihan sederhana. Untuk informasi selengkapnya, lihat Menampilkan atau Mengubah Model Pemulihan Database.

Memformat Media Cadangan

Media cadangan diformat oleh pernyataan BACKUP jika dan hanya jika salah satu hal berikut ini benar:

  • Opsi FORMAT ditentukan.
  • Media kosong.
  • Operasi ini menulis pita kelanjutan.

Bekerja dengan perangkat cadangan dan set media

Mencadangkan perangkat dalam set media bergaris (set garis)

Set stripe adalah sekumpulan file disk tempat data dibagi menjadi blok dan didistribusikan dalam urutan tetap. Jumlah perangkat cadangan yang digunakan dalam set garis harus tetap sama (kecuali media diinisialisasi ulang dengan FORMAT).

Contoh berikut menulis cadangan database AdventureWorks2012 ke set media bergaris baru yang menggunakan tiga file disk.

BACKUP DATABASE AdventureWorks2012
TO DISK = 'X:\SQLServerBackups\AdventureWorks1.bak',
DISK = 'Y:\SQLServerBackups\AdventureWorks2.bak',
DISK = 'Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
  MEDIANAME = 'AdventureWorksStripedSet0',
  MEDIADESCRIPTION = 'Striped media set for AdventureWorks2012 database';
GO

Setelah perangkat cadangan didefinisikan sebagai bagian dari set stripe, perangkat tersebut tidak dapat digunakan untuk cadangan satu perangkat kecuali FORMAT ditentukan. Demikian pula, perangkat cadangan yang berisi cadangan yang tidak terputus tidak dapat digunakan dalam set stripe kecuali FORMAT ditentukan. Untuk membagi kumpulan cadangan bergaris, gunakan FORMAT.

Jika tidak ada MEDIANAME atau MEDIADESCRIPTION yang ditentukan saat header media ditulis, bidang header media yang sesuai dengan item kosong kosong.

Bekerja dengan set media cermin

Biasanya, cadangan tidak disarankan, dan pernyataan BACKUP hanya menyertakan klausa TO. Namun, total empat cermin dimungkinkan per set media. Untuk set media cermin, operasi pencadangan menulis ke beberapa grup perangkat cadangan. Setiap grup perangkat cadangan terdiri dari satu cermin dalam set media yang dicerminkan. Setiap cermin harus menggunakan jumlah dan jenis perangkat cadangan fisik yang sama, yang semuanya harus memiliki properti yang sama.

Untuk mencadangkan ke set media cermin, semua cermin harus ada. Untuk mencadangkan ke set media cermin, tentukan TO klausa untuk menentukan cermin pertama, dan tentukan MIRROR TO klausa untuk setiap cermin tambahan.

Untuk set media cermin, setiap MIRROR TO klausa harus mencantumkan angka dan jenis perangkat yang sama dengan klausa TO. Contoh berikut menulis ke set media cermin yang berisi dua cermin dan menggunakan tiga perangkat per cermin:

BACKUP DATABASE AdventureWorks2012
TO DISK = 'X:\SQLServerBackups\AdventureWorks1a.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2a.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2b.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3b.bak';
GO

Penting

Contoh ini dirancang untuk memungkinkan Anda mengujinya pada sistem lokal Anda. Dalam praktiknya, mencadangkan ke beberapa perangkat pada drive yang sama akan merusak performa dan akan menghilangkan redundansi di mana set media cermin dirancang.

Keluarga media dalam set media cermin

Setiap perangkat cadangan yang ditentukan dalam TO klausul pernyataan BACKUP sesuai dengan keluarga media. Misalnya, jika klausul mencantumkan TO tiga perangkat, BACKUP menulis data ke tiga keluarga media. Dalam set media cermin, setiap cermin harus berisi salinan setiap keluarga media. Inilah sebabnya mengapa jumlah perangkat harus identik di setiap cermin.

Ketika beberapa perangkat dicantumkan untuk setiap cermin, urutan perangkat menentukan keluarga media mana yang ditulis ke perangkat tertentu. Misalnya, di setiap daftar perangkat, perangkat kedua sesuai dengan keluarga media kedua. Untuk perangkat dalam contoh di atas, korespondensi antara perangkat dan keluarga media ditampilkan dalam tabel berikut.

Cermin Keluarga media 1 Keluarga media 2 Keluarga media 3
0 Z:\AdventureWorks1a.bak Z:\AdventureWorks2a.bak Z:\AdventureWorks3a.bak
1 Z:\AdventureWorks1b.bak Z:\AdventureWorks2b.bak Z:\AdventureWorks3b.bak

Keluarga media harus selalu dicadangkan ke perangkat yang sama dalam cermin tertentu. Oleh karena itu, setiap kali Anda menggunakan set media yang ada, cantumkan perangkat setiap cermin dalam urutan yang sama seperti yang ditentukan saat set media dibuat.

Untuk informasi selengkapnya tentang set media yang dicerminkan, lihat Kumpulan Media Cadangan Cermin. Untuk informasi selengkapnya tentang set media dan keluarga media secara umum, lihat Set Media, Keluarga Media, dan Kumpulan Cadangan.

Memulihkan cadangan SQL Server

Untuk memulihkan database dan, secara opsional, memulihkannya untuk membuatnya online, atau memulihkan file atau grup file, gunakan pernyataan Transact-SQL RESTOREatau tugas pemulihan SQL Server Management Studio. Untuk informasi selengkapnya, lihat Gambaran Umum Pemulihan dan Pemulihan.

Pertimbangan tambahan tentang opsi BACKUP

Interaksi SKIP, NOSKIP, INIT, dan NOINIT

Tabel ini menjelaskan interaksi antara { NOINIT | INIT } dan { NOSKIP | OPSI SKIP } .

Catatan

Jika media pita kosong atau file cadangan disk tidak ada, semua interaksi ini menulis header media dan melanjutkan. Jika media tidak kosong dan tidak memiliki header media yang valid, operasi ini memberikan umpan balik yang menyatakan bahwa ini bukan media MTF yang valid, dan mereka menghentikan operasi pencadangan.

Opsi Lewati NOINIT INIT
NOSKIP Jika volume berisi header media yang valid, verifikasi bahwa nama media cocok dengan yang diberikan MEDIANAME, jika ada. Jika cocok, tambahkan kumpulan cadangan, mempertahankan semua set cadangan yang ada.
Jika volume tidak berisi header media yang valid, terjadi kesalahan.
Jika volume berisi header media yang valid, lakukan pemeriksaan berikut:
  • Jika MEDIANAME ditentukan, verifikasi bahwa nama media yang diberikan cocok dengan nama media header media. 1
  • Memverifikasi bahwa tidak ada set cadangan yang belum kedaluwarsa di media. Jika ada, menghentikan pencadangan.

Jika pemeriksaan ini lolos, timpa set cadangan apa pun di media, hanya mempertahankan header media.
Jika volume tidak berisi header media yang valid, buat dengan menggunakan yang ditentukan MEDIANAME dan MEDIADESCRIPTION, jika ada.
SKIP Jika volume berisi header media yang valid, tambahkan kumpulan cadangan, mempertahankan semua set cadangan yang ada. Jika volume berisi2 header media yang valid, timpa set cadangan apa pun di media, hanya mempertahankan header media.
Jika media kosong, menghasilkan header media menggunakan yang ditentukan MEDIANAME dan MEDIADESCRIPTION, jika ada.

1 Pengguna harus termasuk dalam database tetap atau peran server yang sesuai untuk melakukan operasi pencadangan.

2 Validitas mencakup nomor versi MTF dan informasi header lainnya. Jika versi yang ditentukan tidak didukung atau nilai yang tidak terduga, kesalahan terjadi.

Kompatibilitas

Perhatian

Cadangan yang dibuat oleh versi SQL Server yang lebih baru tidak dapat dipulihkan di versi SQL Server sebelumnya.

BACKUP mendukung RESTART opsi untuk memberikan kompatibilitas mundur dengan versi SQL Server sebelumnya. Tetapi RESTART tidak berpengaruh.

Pernyataan umum

Pencadangan database atau log dapat ditambahkan ke disk atau perangkat pita apa pun, memungkinkan database dan log transaksinya disimpan dalam satu lokasi fisik.

Pernyataan BACKUP tidak diizinkan dalam transaksi eksplisit atau implisit.

Operasi pencadangan lintas platform, bahkan di antara jenis prosesor yang berbeda, dapat dilakukan selama kolase database didukung oleh sistem operasi.

Dimulai dengan SQL Server 2016 (13.x), pengaturan MAXTRANSFERSIZEyang lebih besar dari 65536 (64 KB) memungkinkan algoritma kompresi yang dioptimalkan untuk database terenkripsi Transparent Data Encryption (TDE) yang pertama kali mendekripsi halaman, memadatkannya, dan kemudian mengenkripsinya lagi. Jika MAXTRANSFERSIZE tidak ditentukan, atau jika MAXTRANSFERSIZE = 65536 (64 KB) digunakan, kompresi cadangan dengan database terenkripsi TDE secara langsung memadatkan halaman terenkripsi, dan mungkin tidak menghasilkan rasio kompresi yang baik. Untuk informasi selengkapnya, lihat Kompresi Cadangan untuk Database yang mendukung TDE.

Dimulai dengan SQL Server 2019 (15.x) CU5, pengaturan MAXTRANSFERSIZE tidak lagi diperlukan untuk mengaktifkan algoritma kompresi yang dioptimalkan ini dengan TDE. Jika perintah cadangan ditentukan WITH COMPRESSION atau konfigurasi server default kompresi cadangan diatur ke 1, MAXTRANSFERSIZE akan secara otomatis ditingkatkan menjadi 128 K untuk mengaktifkan algoritma yang dioptimalkan. Jika MAXTRANSFERSIZE ditentukan pada perintah cadangan dengan nilai > 64 K, nilai yang disediakan akan dihormati. Dengan kata lain, SQL Server tidak akan pernah secara otomatis mengurangi nilai, itu hanya akan meningkatkannya. Jika Anda perlu mencadangkan database terenkripsi TDE dengan MAXTRANSFERSIZE = 65536, Anda harus menentukan WITH NO_COMPRESSION atau memastikan bahwa konfigurasi server default kompresi cadangan diatur ke 0.

Catatan

Ada beberapa kasus di mana default MAXTRANSFERSIZE lebih besar dari 64K:

  • Ketika database memiliki beberapa file data yang dibuat, database menggunakan MAXTRANSFERSIZE> 64K.
  • Saat melakukan pencadangan ke URL ke Azure Blob Storage, defaultnya MAXTRANSFERSIZE = 1048576 (1 MB).
  • Saat melakukan pencadangan ke URL ke sotrage objek yang kompatibel dengan S3, defaultnya MAXTRANSFERSIZE = 10485760 (10 MB).

Bahkan jika salah satu kondisi ini berlaku, Anda harus secara eksplisit mengatur MAXTRANSFERSIZE lebih besar dari 64K dalam perintah cadangan Anda untuk mendapatkan algoritma kompresi cadangan yang dioptimalkan, kecuali Anda berada di SQL Server 2019 (15.x) CU5 atau yang lebih baru.

Secara default, setiap operasi pencadangan yang berhasil menambahkan entri di log kesalahan SQL Server dan di log peristiwa sistem. Jika Anda mencadangkan log dengan sangat sering, pesan keberhasilan ini terakumulasi dengan cepat, yang mengakibatkan log kesalahan besar yang dapat menyulitkan menemukan pesan lain. Dalam kasus seperti itu Anda dapat menekan entri log ini dengan menggunakan bendera pelacakan 3226, jika tidak ada otomatisasi atau pemantauan Anda tergantung pada entri tersebut. Untuk informasi selengkapnya, lihat Bendera Pelacakan.

Interoperabilitas

SQL Server menggunakan proses pencadangan online untuk memungkinkan pencadangan database saat database masih digunakan. Selama pencadangan, sebagian besar operasi dimungkinkan; misalnya, pernyataan INSERT, UPDATE, atau DELETE diizinkan selama operasi pencadangan.

Operasi yang tidak dapat berjalan selama database atau pencadangan log transaksi meliputi:

  • Operasi manajemen file seperti ALTER DATABASE pernyataan dengan ADD FILE opsi atau REMOVE FILE .

  • Menyusutkan database atau menyusutkan operasi file. Ini termasuk operasi penyusutan otomatis.

Jika operasi pencadangan tumpang tindih dengan manajemen file atau operasi penyusutan, konflik muncul. Terlepas dari operasi mana yang bertentangan dimulai terlebih dahulu, operasi kedua menunggu kunci yang ditetapkan oleh operasi pertama ke waktu habis (periode waktu habis dikendalikan oleh pengaturan batas waktu sesi). Jika kunci dilepaskan selama periode waktu habis, operasi kedua berlanjut. Jika waktu penguncian habis, operasi kedua gagal.

Metadata

SQL Server menyertakan tabel riwayat cadangan berikut yang melacak aktivitas pencadangan:

Ketika pemulihan dilakukan, jika kumpulan cadangan belum direkam dalam msdb database, tabel riwayat cadangan mungkin dimodifikasi.

Keamanan

Dimulai dengan SQL Server 2012 (11.x), PASSWORD opsi dan MEDIAPASSWORD dihentikan untuk membuat cadangan. Masih dimungkinkan untuk memulihkan cadangan yang dibuat dengan kata sandi.

Izin

BACKUP DATABASE dan BACKUP LOG izin default untuk anggota peran server tetap sysadmin dan peran database tetap db_owner dan db_backupoperator .

Masalah kepemilikan dan izin pada file fisik perangkat cadangan dapat mengganggu operasi pencadangan. Pastikan akun startup SQL Server harus memiliki izin baca dan tulis ke perangkat cadangan dan folder tempat file cadangan ditulis. Namun, sp_addumpdevice, yang menambahkan entri untuk perangkat cadangan dalam tabel sistem, tidak memeriksa izin akses file. Masalah tersebut pada file fisik perangkat cadangan mungkin tidak muncul sampai sumber daya fisik diakses ketika pencadangan atau pemulihan dicoba.

Contoh

Bagian ini berisi contoh-contoh berikut:

Catatan

Topik cara pencadangan berisi contoh tambahan. Untuk informasi selengkapnya, lihat Gambaran Umum Pencadangan.

J. Mencadangkan database lengkap

Contoh berikut mencadangkan database AdventureWorks2012 ke file disk.

BACKUP DATABASE AdventureWorks2012
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
    WITH FORMAT;
GO

B. Mencadangkan database dan log

Contoh berikut mencadangkan AdventureWorks2019 database sampel, yang menggunakan model pemulihan sederhana secara default. Untuk mendukung pencadangan log, AdventureWorks2019 database dimodifikasi untuk menggunakan model pemulihan penuh.

Selanjutnya, contoh menggunakan sp_addumpdevice untuk membuat perangkat cadangan logis untuk mencadangkan data, AdvWorksData, dan membuat perangkat cadangan logis lain untuk mencadangkan log, AdvWorksLog.

Contoh kemudian membuat cadangan database lengkap ke AdvWorksData, dan setelah periode aktivitas pembaruan, mencadangkan log ke AdvWorksLog.

-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks2012
    SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2012 database.
BACKUP DATABASE AdventureWorks2012 TO AdvWorksData;
GO
-- Back up the AdventureWorks2012 log.
BACKUP LOG AdventureWorks2012
    TO AdvWorksLog;
GO

Catatan

Untuk database produksi, cadangkan log secara teratur. Pencadangan log harus cukup sering untuk memberikan perlindungan yang memadai terhadap kehilangan data.

C. Membuat cadangan file lengkap dari grup file sekunder

Contoh berikut membuat cadangan file lengkap dari setiap file di kedua grup file sekunder.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck';
GO

D. Membuat cadangan file diferensial dari grup file sekunder

Contoh berikut membuat cadangan file diferensial dari setiap file di kedua grup file sekunder.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
    WITH
      DIFFERENTIAL;
GO

E. Membuat dan mencadangkan ke set media cermin satu keluarga

Contoh berikut membuat set media cermin yang berisi satu keluarga media dan empat cermin dan mencadangkan database AdventureWorks2012 kepada mereka.

BACKUP DATABASE AdventureWorks2012
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet0';

F. Membuat dan mencadangkan ke set media cermin multifaktor

Contoh berikut membuat set media cermin di mana setiap cermin terdiri dari dua keluarga media. Contohnya kemudian mencadangkan database AdventureWorks2012 ke kedua cermin.

BACKUP DATABASE AdventureWorks2012
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet1';

G. Mencadangkan ke set media cermin yang ada

Contoh berikut menambahkan kumpulan cadangan ke set media yang dibuat dalam contoh sebelumnya.

BACKUP LOG AdventureWorks2012
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    NOINIT,
    MEDIANAME = 'AdventureWorksSet1';

Catatan

NOINIT, yang merupakan default, ditampilkan di sini untuk kejelasan.

H. Membuat cadangan terkompresi dalam set media baru

Contoh berikut memformat media, membuat set media baru, dan melakukan pencadangan penuh terkompresi dari database AdventureWorks2012 .

BACKUP DATABASE AdventureWorks2012 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
    FORMAT,
    COMPRESSION;

i. Mencadangkan ke microsoft Azure Blob Storage

Contoh ini melakukan pencadangan Sales database lengkap ke microsoft Azure Blob Storage. Nama Akun penyimpanan adalah mystorageaccount. Kontainer disebut myfirstcontainer. Kebijakan akses tersimpan telah dibuat dengan hak baca, tulis, hapus, dan daftar. Kredensial SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, dibuat menggunakan Tanda Tangan Akses Bersama yang terkait dengan Kebijakan Akses Tersimpan. Untuk informasi tentang pencadangan SQL Server ke microsoft Azure Blob Storage, lihat SQL Server Pencadangan dan Pemulihan dengan Microsoft Azure Blob Storage dan pencadangan SQL Server ke URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5;

j. Mencadangkan ke penyimpanan objek yang kompatibel dengan S3

Berlaku untuk: SQL Server 2022 (16.x)

Contoh ini melakukan database Sales cadangan lengkap database ke platform penyimpanan objek yang kompatibel dengan S3. Nama kredensial tidak diperlukan dalam pernyataan atau untuk mencocokkan jalur URL yang tepat, tetapi akan melakukan pencarian untuk kredensial yang tepat pada URL yang disediakan. Untuk informasi selengkapnya, lihat SQL Server pencadangan dan pemulihan dengan pratinjau penyimpanan objek yang kompatibel dengan S3.

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

K. Melacak kemajuan pernyataan pencadangan

Kueri berikut mengembalikan informasi tentang pernyataan pencadangan yang sedang berjalan:

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%'

Langkah berikutnya

* SQL Managed Instance *  

 

Instans Terkelola Azure SQL

Mencadangkan database SQL di Azure SQL Managed Instance. Azure SQL Managed Instance memiliki cadangan otomatis. Anda dapat membuat cadangan database COPY_ONLY lengkap. Cadangan diferensial, log, dan rekam jepret file tidak didukung.

Juga berlaku untuk SQL Managed Instance dengan dukungan Azure Arc.

Sintaks

BACKUP DATABASE { database_name | @database_name_var }
  TO URL = { 'physical_device_name' | @physical_device_name_var }[ ,...n ]
  WITH COPY_ONLY [, { <general_WITH_options> } ]
[;]

<general_WITH_options> [ ,...n ]::=

--Media Set Options
   MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

Argumen

DATABASE

Menentukan pencadangan database lengkap. Selama pencadangan database, Azure SQL Managed Instance mencadangkan log transaksi yang cukup untuk menghasilkan database yang konsisten saat cadangan dipulihkan.

Penting

Cadangan database yang dibuat pada instans terkelola hanya dapat dipulihkan pada Azure SQL Managed Instance lain. Ini tidak dapat dipulihkan ke instans lokal SQL Server (mirip dengan cara cadangan database SQL Server 2016 tidak dapat dipulihkan ke instans SQL Server 2012).

Saat Anda memulihkan cadangan yang dibuat oleh BACKUP DATABASE ( cadangan data), seluruh cadangan dipulihkan. Untuk memulihkan dari pencadangan otomatis SQL Managed Instance, lihat Memulihkan database ke Azure SQL Managed Instance.

{ database_name | @database_name_var }

Apakah database tempat database lengkap dicadangkan. Jika disediakan sebagai variabel (@database_name_var), nama ini dapat ditentukan baik sebagai konstanta string (@database_name_var=nama database) atau sebagai variabel jenis data string karakter, kecuali untuk jenis data ntext atau teks .

Untuk informasi selengkapnya, lihat Pencadangan File Lengkap dan File Cadangan dan Grup File.

KE URL

Menentukan URL yang akan digunakan untuk operasi pencadangan. Format URL digunakan untuk membuat cadangan ke layanan penyimpanan Microsoft Azure.

Penting

Untuk mencadangkan ke beberapa perangkat saat mencadangkan ke URL, Anda harus menggunakan token Tanda Tangan Akses Bersama (SAS). Untuk contoh pembuatan Tanda Tangan Akses Bersama, lihat SQL Server Pencadangan ke URL dan Menyederhanakan pembuatan Kredensial SQL dengan token Tanda Tangan Akses Bersama (SAS) di Azure Storage dengan Powershell.

n
Adalah tempat penampung yang menunjukkan bahwa hingga 64 perangkat cadangan dapat ditentukan dalam daftar yang dipisahkan koma.

WITH OptionsSpecifies options yang akan digunakan dengan operasi pencadangan

INFORMASI MASUK

Digunakan hanya saat membuat cadangan ke microsoft Azure Blob Storage.

ENKRIPSI

Digunakan untuk menentukan enkripsi untuk cadangan. Anda dapat menentukan algoritma enkripsi untuk mengenkripsi cadangan dengan atau menentukan NO_ENCRYPTION agar cadangan tidak dienkripsi. Enkripsi disarankan untuk membantu mengamankan file cadangan. Daftar algoritma yang dapat Anda tentukan adalah:

  • AES_128
  • AES_192
  • AES_256
  • TRIPLE_DES_3KEY
  • NO_ENCRYPTION

Jika Anda memilih untuk mengenkripsi, Anda juga harus menentukan enkripsi menggunakan opsi enkripsi:

  • SERVER CERTIFICATE = <Encryptor_Name>
  • SERVER ASYMMETRIC KEY = <Encryptor_Name>

Opsi kumpulan cadangan

COPY_ONLY

Menentukan bahwa cadangan adalah cadangan khusus salinan, yang tidak memengaruhi urutan cadangan normal. Cadangan khusus salinan dibuat secara independen dari pencadangan otomatis Azure SQL Database. Untuk informasi selengkapnya, lihat Pencadangan Khusus Salin.

{ | PEMADATAN NO_COMPRESSION }

Menentukan apakah kompresi cadangan dilakukan pada cadangan ini, menggantikan default tingkat server.

Perilaku default bukan kompresi cadangan. Tetapi default ini dapat diubah dengan mengatur opsi konfigurasi server default kompresi cadangan . Untuk informasi tentang menampilkan nilai saat ini dari opsi ini, lihat Menampilkan atau Mengubah Properti Server.

PEMADATAN
Secara eksplisit memungkinkan kompresi cadangan.

NO_COMPRESSION
Secara eksplisit menonaktifkan kompresi cadangan.

DESKRIPSI = { 'text'text_variable | @ }

Menentukan teks bentuk bebas yang menjelaskan kumpulan cadangan. String dapat memiliki maksimal 255 karakter.

NAMA = { backup_set_name | @backup_set_var }

Menentukan nama kumpulan cadangan. Nama dapat memiliki maksimal 128 karakter. Jika NAME tidak ditentukan, nama tersebut kosong.

MEDIADESCRIPTION = { text | @text_variable }

Menentukan deskripsi teks bentuk bebas, maksimal 255 karakter, dari set media.

MEDIANAME = { media_name | @media_name_variable }

Menentukan nama media untuk seluruh set media cadangan. Nama media tidak boleh lebih dari 128 karakter, Jika MEDIANAME ditentukan, nama media harus cocok dengan nama media yang ditentukan sebelumnya yang sudah ada pada volume cadangan. Jika tidak ditentukan, atau jika opsi SKIP ditentukan, tidak ada pemeriksaan verifikasi nama media.

BLOCKSIZE = { blocksize | @blocksize_variable }

Menentukan ukuran blok fisik, dalam byte. Ukuran yang didukung adalah 512, 1024, 2048, 4096, 8192, 16384, 32768, dan 65536 (64 KB) byte. Defaultnya adalah 65536 untuk perangkat pita dan 512 sebaliknya. Biasanya, opsi ini tidak perlu karena BACKUP secara otomatis memilih ukuran blok yang sesuai dengan perangkat. Secara eksplisit menyatakan ukuran blok mengambil alih pemilihan otomatis ukuran blok.

Opsi transfer data

BUFFERCOUNT = { buffercount | @buffercount_variable }

Menentukan jumlah total buffer I/O yang akan digunakan untuk operasi pencadangan. Anda dapat menentukan bilangan bulat positif apa pun; namun, sejumlah besar buffer dapat menyebabkan kesalahan "kehabisan memori" karena ruang alamat virtual yang tidak memadai dalam proses Sqlservr.exe.

Total ruang yang digunakan oleh buffer ditentukan oleh: BUFFERCOUNT * MAXTRANSFERSIZE.

Catatan

Untuk informasi penting tentang menggunakan opsi , BUFFERCOUNT lihat opsi transfer data BufferCount yang salah dapat menyebabkan blog kondisi OOM .

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Menentukan unit transfer terbesar dalam byte yang akan digunakan antara SQL Server dan media cadangan. Nilai yang mungkin adalah kelipatan 65536 byte (64 KB) berkisar hingga 4194304 byte (4 MB).

Untuk database yang diaktifkan Transparent Data Encryption (TDE) dengan satu file data, defaultnya MAXTRANSFERSIZE adalah 65536 (64 KB). Untuk database terenkripsi non-TDE, defaultnya MAXTRANSFERSIZE adalah 1048576 (1 MB) saat menggunakan cadangan ke DISK, dan 65536 (64 KB) saat menggunakan VDI atau TAPE.

Catatan

MAXTRANSFERSIZE menentukan unit transfer terbesar, dan tidak menjamin bahwa setiap operasi tulis akan mentransfer ukuran terbesar yang ditentukan. MAXTRANSFERSIZE untuk operasi tulis cadangan log transaksi bergaris diatur ke 64 KB.

Opsi manajemen kesalahan

Opsi ini memungkinkan Anda menentukan apakah checksum cadangan diaktifkan untuk operasi pencadangan dan apakah operasi berhenti mengalami kesalahan.

{ NO_CHECKSUM | CHECKSUM }

Mengontrol apakah checksum cadangan diaktifkan.

NO_CHECKSUM
Secara eksplisit menonaktifkan pembuatan checksum cadangan (dan validasi checksum halaman). Ini adalah perilaku default.

CHECKSUM
Menentukan bahwa operasi pencadangan memverifikasi setiap halaman untuk checksum dan halaman yang robek, jika diaktifkan dan tersedia, dan menghasilkan checksum untuk seluruh cadangan.

Menggunakan checksum cadangan dapat memengaruhi beban kerja dan throughput cadangan.

Untuk informasi selengkapnya, lihat Kemungkinan Kesalahan Media Selama Pencadangan dan Pemulihan.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Mengontrol apakah operasi pencadangan berhenti atau berlanjut setelah mengalami kesalahan checksum halaman.

STOP_ON_ERROR
Menginstruksikan BACKUP untuk gagal jika checksum halaman tidak memverifikasi. Ini adalah perilaku default.

CONTINUE_AFTER_ERROR
Menginstruksikan BACKUP untuk melanjutkan meskipun mengalami kesalahan seperti checksum yang tidak valid atau halaman yang robek.

Jika Anda tidak dapat mencadangkan ekor log menggunakan opsi NO_TRUNCATE saat database rusak, Anda dapat mencoba pencadangan log log ekor dengan menentukan CONTINUE_AFTER_ERROR alih-alih NO_TRUNCATE.

Untuk informasi selengkapnya, lihat Kemungkinan Kesalahan Media Selama Pencadangan dan Pemulihan.

Opsi kompatibilitas

RESTART

Tidak berpengaruh. Opsi ini diterima oleh versi untuk kompatibilitas dengan versi SQL Server sebelumnya.

Opsi pemantauan

STATS [ =persentase ]

Menampilkan pesan setiap kali persentase lain selesai, dan digunakan untuk mengukur kemajuan. Jika persentase dihilangkan, SQL Server menampilkan pesan setelah setiap 10 persen selesai.

Opsi STATS melaporkan persentase selesai pada ambang batas untuk melaporkan interval berikutnya. Ini sekitar persentase yang ditentukan; misalnya, dengan STATS=10, jika jumlah yang diselesaikan adalah 40 persen, opsi mungkin menampilkan 43 persen. Untuk set cadangan besar, ini bukan masalah, karena persentase selesai bergerak sangat lambat antara panggilan I/O yang selesai.

Batasan untuk SQL Managed Instance

Ukuran stripe cadangan maksimum adalah 195 GB (ukuran blob maksimum). Tingkatkan jumlah garis dalam perintah cadangan untuk mengurangi ukuran garis individu dan tetap dalam batas ini.

Keamanan

Izin

BACKUP DATABASE izin default untuk anggota peran server tetap sysadmin dan peran database tetap db_owner dan db_backupoperator .

Masalah kepemilikan dan izin pada URL dapat mengganggu operasi pencadangan. SQL Server harus dapat membaca dan menulis ke perangkat; akun tempat layanan SQL Server berjalan harus memiliki izin tulis.

Contoh

Contoh melakukan pencadangan Sales COPY_ONLY ke microsoft Azure Blob Storage. Nama Akun penyimpanan adalah mystorageaccount. Kontainer disebut myfirstcontainer. Kebijakan akses tersimpan telah dibuat dengan hak baca, tulis, hapus, dan daftar. Kredensial SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, dibuat menggunakan Tanda Tangan Akses Bersama yang terkait dengan Kebijakan Akses Tersimpan. Untuk informasi tentang pencadangan SQL Server ke microsoft Azure Blob Storage, lihat SQL Server Pencadangan dan Pemulihan dengan Microsoft Azure Blob Storage dan pencadangan SQL Server ke URL.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;

Langkah berikutnya

Memulihkan database

*Analytics
Sistem Platform (PDW) *
 

 

Sistem Platform Analisis

Membuat cadangan database Analytics Platform System (PDW) dan menyimpan cadangan appliance di lokasi jaringan yang ditentukan pengguna. Gunakan pernyataan ini dengan RESTORE DATABASE - Analytics Platform System untuk pemulihan bencana, atau untuk menyalin database dari satu appliance ke appliance lainnya.

Sebelum memulai, lihat "Memperoleh dan Mengonfigurasi Server Cadangan" di dokumentasi produk Analytics Platform System (PDW).

Ada dua jenis cadangan di Analytics Platform System (PDW). Pencadangan database lengkap adalah cadangan dari seluruh database Analytics Platform System (PDW). Pencadangan database diferensial hanya menyertakan perubahan yang dilakukan sejak pencadangan penuh terakhir. Cadangan database pengguna mencakup pengguna database, dan peran database. Cadangan master database mencakup login.

Untuk informasi selengkapnya tentang pencadangan database Analytics Platform System (PDW), lihat "Pencadangan dan Pemulihan" dalam dokumentasi produk Analytics Platform System (PDW).

Sintaks

--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    [ WITH [ ( ]<with_options> [ ,...n ][ ) ] ]
[;]

--Create a differential backup of a user database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    WITH [ ( ] DIFFERENTIAL
    [ , <with_options> [ ,...n ] [ ) ]
[;]

<with_options> ::=
    DESCRIPTION = 'text'
    | NAME = 'backup_name'

Argumen

database_name

Nama database untuk membuat cadangan. Database dapat berupa master database atau database pengguna.

KE DISK = '\\UNC_path\backup_directory'

Jalur jaringan dan direktori tempat Sistem Platform Analitik (PDW) akan menulis file cadangan. Contohnya:\\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup

  • Jalur ke nama direktori cadangan harus sudah ada dan harus ditentukan sebagai jalur konvensi penamaan universal (UNC) yang sepenuhnya memenuhi syarat.
  • Direktori cadangan, backup_directory, tidak boleh ada sebelum menjalankan perintah pencadangan. Analytics Platform System (PDW) akan membuat direktori cadangan.
  • Jalur ke direktori cadangan tidak dapat menjadi jalur lokal dan tidak dapat menjadi lokasi di salah satu simpul appliance Analytics Platform System (PDW).
  • Panjang maksimum jalur UNC dan nama direktori cadangan adalah 200 karakter.
  • Server atau host harus ditentukan sebagai alamat IP. Anda tidak dapat menentukannya sebagai nama host atau server.

DESKRIPSI = 'teks'

Menentukan deskripsi tekstual cadangan. Panjang maksimum teks adalah 255 karakter.

Deskripsi disimpan dalam metadata, dan akan ditampilkan ketika header cadangan dipulihkan dengan RESTORE HEADERONLY.

NAME = 'backup _name'

Menentukan nama cadangan. Nama cadangan bisa berbeda dari nama database.

  • Nama dapat memiliki maksimal 128 karakter.
  • Tidak dapat menyertakan jalur.
  • Harus dimulai dengan karakter huruf atau angka atau garis bawah (_). Karakter khusus yang diizinkan adalah garis bawah (_), tanda hubung (-), atau spasi ( ). Nama cadangan tidak boleh diakhir dengan karakter spasi.
  • Pernyataan akan gagal jika backup_name sudah ada di lokasi yang ditentukan.

Nama ini disimpan dalam metadata, dan akan ditampilkan ketika header cadangan dipulihkan dengan RESTORE HEADERONLY.

DIFERENSIAL

Menentukan untuk melakukan pencadangan diferensial database pengguna. Jika dihilangkan, defaultnya adalah pencadangan database lengkap. Nama cadangan diferensial tidak perlu cocok dengan nama cadangan lengkap. Untuk melacak diferensial dan pencadangan penuh yang sesuai, pertimbangkan untuk menggunakan nama yang sama dengan 'penuh' atau 'diff' ditambahkan.

Contohnya:

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;

Izin

BACKUP DATABASE Memerlukan izin atau keanggotaan dalam peran database tetap db_backupoperator. Database master tidak dapat dicadangkan tetapi oleh pengguna biasa yang ditambahkan ke peran database tetap db_backupoperator . Database master hanya dapat dicadangkan oleh sa, administrator fabric, atau anggota peran server tetap sysadmin .

Memerlukan akun Windows yang memiliki izin untuk mengakses, membuat, dan menulis ke direktori cadangan. Anda juga harus menyimpan nama dan kata sandi akun Windows di Analytics Platform System (PDW). Untuk menambahkan kredensial jaringan ini ke Analytics Platform System (PDW), gunakan prosedur tersimpan sp_pdw_add_network_credentials - Azure Synapse Analytics.

Untuk informasi selengkapnya tentang mengelola kredensial di Analytics Platform System (PDW), lihat bagian Keamanan .

Penanganan Kesalahan

Kesalahan DATABASE BACKUP dalam kondisi berikut:

  • Izin pengguna tidak cukup untuk melakukan pencadangan.
  • Analytics Platform System (PDW) tidak memiliki izin yang benar ke lokasi jaringan tempat cadangan akan disimpan.
  • Database tidak ada.
  • Direktori target sudah ada pada berbagi jaringan.
  • Berbagi jaringan target tidak tersedia.
  • Berbagi jaringan target tidak memiliki cukup ruang untuk pencadangan. Perintah BACKUP DATABASE tidak mengonfirmasi bahwa ruang disk yang memadai ada sebelum memulai pencadangan, sehingga memungkinkan untuk menghasilkan kesalahan di luar ruang disk saat menjalankan DATABASE BACKUP. Ketika ruang disk tidak cukup terjadi, Analytics Platform System (PDW) mengembalikan perintah BACKUP DATABASE. Untuk mengurangi ukuran database Anda, jalankan DBCC SHRINKLOG (Azure Synapse Analytics)
  • Coba mulai pencadangan dalam transaksi.

Keterangan Umum

Sebelum Anda melakukan pencadangan database, gunakan DBCC SHRINKLOG (Azure Synapse Analytics) untuk mengurangi ukuran database Anda.

Cadangan Analytics Platform System (PDW) disimpan sebagai sekumpulan beberapa file dalam direktori yang sama.

Pencadangan diferensial biasanya membutuhkan lebih sedikit waktu daripada pencadangan penuh dan dapat dilakukan lebih sering. Ketika beberapa cadangan diferensial didasarkan pada pencadangan penuh yang sama, setiap diferensial mencakup semua perubahan dalam cadangan diferensial sebelumnya.

Jika Anda membatalkan perintah BACKUP, Analytics Platform System (PDW) akan menghapus direktori target dan file apa pun yang dibuat untuk cadangan. Jika Analytics Platform System (PDW) kehilangan konektivitas jaringan ke berbagi, pembatalan tidak dapat diselesaikan.

Pencadangan penuh dan cadangan diferensial disimpan dalam direktori terpisah. Konvensi penamaan tidak diberlakukan untuk menentukan bahwa pencadangan penuh dan cadangan diferensial berada bersama-sama. Anda dapat melacak ini melalui konvensi penamaan Anda sendiri. Atau, Anda dapat melacak ini dengan menggunakan opsi WITH DESCRIPTION untuk menambahkan deskripsi, lalu dengan menggunakan pernyataan RESTORE HEADERONLY untuk mengambil deskripsi.

Batasan dan Pembatasan

Anda tidak dapat melakukan pencadangan master diferensial database. Hanya pencadangan master penuh database yang didukung.

File cadangan disimpan dalam format yang hanya cocok untuk memulihkan cadangan ke appliance Analytics Platform System (PDW) dengan menggunakan pernyataan RESTORE DATABASE - Analytics Platform System .

Cadangan dengan pernyataan BACKUP DATABASE tidak dapat digunakan untuk mentransfer data atau informasi pengguna ke SMP SQL Server database. Untuk fungsionalitas tersebut, Anda dapat menggunakan fitur salinan tabel jarak jauh. Untuk informasi selengkapnya, lihat "Salinan Tabel Jarak Jauh" di dokumentasi produk Analytics Platform System (PDW).

Analytics Platform System (PDW) menggunakan teknologi pencadangan SQL Server untuk mencadangkan dan memulihkan database. SQL Server opsi pencadangan telah dikonfigurasi sebelumnya untuk menggunakan pemadatan cadangan. Anda tidak dapat mengatur opsi pencadangan seperti kompresi, checksum, ukuran blok, dan jumlah buffer.

Hanya satu pencadangan atau pemulihan database yang dapat berjalan pada appliance pada waktu tertentu. Analytics Platform System (PDW) akan mengantre perintah pencadangan atau pemulihan hingga perintah pencadangan atau pemulihan saat ini selesai.

Appliance target untuk memulihkan cadangan harus memiliki setidaknya node Komputasi sebanyak appliance sumber. Target dapat memiliki lebih banyak simpul Komputasi daripada appliance sumber, tetapi tidak dapat memiliki lebih sedikit simpul Komputasi.

Analytics Platform System (PDW) tidak melacak lokasi dan nama cadangan karena cadangan disimpan dari appliance.

Analytics Platform System (PDW) memang melacak keberhasilan atau kegagalan pencadangan database.

Pencadangan diferensial hanya diperbolehkan jika pencadangan penuh terakhir berhasil diselesaikan. Misalnya, pada hari Senin Anda membuat cadangan penuh database Penjualan dan pencadangan berhasil diselesaikan. Kemudian pada hari Selasa Anda membuat cadangan penuh database Penjualan dan gagal. Setelah kegagalan ini, Anda kemudian tidak dapat membuat cadangan diferensial berdasarkan pencadangan penuh Senin. Anda harus terlebih dahulu membuat cadangan penuh yang berhasil sebelum membuat cadangan diferensial.

Metadata

Tampilan manajemen dinamis ini berisi informasi tentang semua operasi pencadangan, pemulihan, dan pemuatan. Informasi tetap ada di seluruh sistem yang dimulai ulang.

Performa

Untuk melakukan pencadangan, Analytics Platform System (PDW) terlebih dahulu mencadangkan metadata, lalu melakukan pencadangan paralel data database yang disimpan pada simpul Komputasi. Data disalin langsung dari setiap simpul Komputasi ke direktori cadangan. Untuk mencapai performa terbaik untuk memindahkan data dari simpul Komputasi ke direktori cadangan, Analytics Platform System (PDW) mengontrol jumlah simpul Komputasi yang menyalin data secara bersamaan.

Penguncian

Mengambil kunci ExclusiveUpdate pada objek DATABASE.

Keamanan

Cadangan Analytics Platform System (PDW) tidak disimpan di appliance. Oleh karena itu, tim IT Anda bertanggung jawab untuk mengelola semua aspek keamanan cadangan. Misalnya, ini termasuk mengelola keamanan data cadangan, keamanan server yang digunakan untuk menyimpan cadangan, dan keamanan infrastruktur jaringan yang menghubungkan server cadangan ke appliance Analytics Platform System (PDW).

Mengelola Kredensial Jaringan

Akses jaringan ke direktori cadangan didasarkan pada keamanan berbagi file sistem operasi standar. Sebelum melakukan pencadangan, Anda perlu membuat atau menunjuk akun Windows yang akan digunakan untuk mengautentikasi Sistem Platform Analitik (PDW) ke direktori cadangan. Akun Windows ini harus memiliki izin untuk mengakses, membuat, dan menulis ke direktori cadangan.

Penting

Untuk mengurangi risiko keamanan dengan data Anda, kami menyarankan agar Anda menunjuk satu akun Windows hanya untuk tujuan melakukan operasi pencadangan dan pemulihan. Izinkan akun ini memiliki izin ke lokasi pencadangan dan di tempat lain.

Anda perlu menyimpan nama pengguna dan kata sandi di Analytics Platform System (PDW) dengan menjalankan prosedur tersimpan sp_pdw_add_network_credentials - Azure Synapse Analytics. Analytics Platform System (PDW) menggunakan Windows Credential Manager untuk menyimpan dan mengenkripsi nama pengguna dan kata sandi pada simpul Kontrol dan simpul Komputasi. Kredensial tidak dicadangkan dengan perintah BACKUP DATABASE.

Untuk menghapus kredensial jaringan dari Analytics Platform System (PDW), lihat sp_pdw_remove_network_credentials - Azure Synapse Analytics.

Untuk mencantumkan semua kredensial jaringan yang disimpan di Analytics Platform System (PDW), gunakan tampilan manajemen dinamis sys.dm_pdw_network_credentials .

Contoh

A. Menambahkan kredensial jaringan untuk lokasi pencadangan

Untuk membuat cadangan, Analytics Platform System (PDW) harus memiliki izin baca/tulis ke direktori cadangan. Contoh berikut menunjukkan cara menambahkan kredensial untuk pengguna. Analytics Platform System (PDW) akan menyimpan kredensial ini dan menggunakannya untuk operasi pencadangan dan pemulihan.

Penting

Untuk alasan keamanan, sebaiknya buat satu akun domain hanya untuk tujuan melakukan pencadangan.

EXEC sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

B. Menghapus kredensial jaringan untuk lokasi pencadangan

Contoh berikut menunjukkan cara menghapus kredensial untuk pengguna domain dari Analytics Platform System (PDW).

EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C. Membuat cadangan lengkap database pengguna

Contoh berikut membuat cadangan lengkap database pengguna Faktur. Analytics Platform System (PDW) akan membuat Invoices2013 direktori dan akan menyimpan file cadangan ke \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full direktori.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

D. Membuat cadangan diferensial database pengguna

Contoh berikut membuat cadangan diferensial, yang mencakup semua perubahan yang dilakukan sejak pencadangan Invoices penuh terakhir database. Analytics Platform System (PDW) akan membuat \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff direktori tempatnya akan menyimpan file. Deskripsi 'Faktur cadangan diferensial 2013' akan disimpan dengan informasi header untuk cadangan.

Pencadangan diferensial hanya akan berjalan dengan sukses jika pencadangan penuh faktur terakhir berhasil diselesaikan.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

E. Membuat cadangan lengkap database master

Contoh berikut membuat cadangan master lengkap database dan menyimpannya di direktori \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master, di mana IP adalah alamat IP jaringan.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';

F. Membuat cadangan informasi masuk appliance

Database master menyimpan informasi login appliance. Untuk mencadangkan informasi login appliance, Anda perlu mencadangkan master database.

Contoh berikut membuat cadangan master lengkap database.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
    DESCRIPTION = 'Master Backup 20130722',
    NAME = 'login-backup'
)
;

Langkah berikutnya

RESTORE DATABASE - Gudang Data Paralel