Saat ini, terdapat banyak teknologi pemulihan bencana (DR) di industri, termasuk mirror database, clustering, dan solusi replikasi. Namun, log shipping merupakan metode yang lebih sederhana serta mudah dikonfigurasi dan dipelihara. Artikel ini akan membahas langkah-langkah pemulihan bencana SQL Server dengan menggunakan log shipping.
Solusi Pemulihan Bencana dengan Log Shipping
Log shipping terutama menjaga cadangan di server sekunder dan mengambil alih server utama bila diperlukan untuk meningkatkan ketersediaan basis data secara keseluruhan. Dengan kata lain, ketika basis data utama tidak tersedia akibat bencana, Anda dapat secara manual mengaktifkan basis data sekunder untuk terus memberikan layanan.
Untuk mengkonfigurasi log shipping untuk sebuah database, SQL Server membuat tiga job agen berikut untuk mengotomatisasi operasi backup, salin, dan restore:
Pekerjaan pertama dijalankan pada instance utama. Ini membuat cadangan log transaksi di database utama.
Pekerjaan kedua berjalan di server sekunder. Ini menyalin cadangan log dari server primer ke server sekunder.
Pekerjaan ketiga juga dijalankan pada server sekunder. Ini memulihkan cadangan log dan memperbarui entri log pada basis data sekunder.
Pertimbangan Sebelum Mengonfigurasi Log Shipping di SQL Server
Meskipun mengonfigurasi log shipping tidak sulit, beberapa pertimbangan harus diperhatikan sebelum implementasi:
Perlindungan tingkat database: Jika Anda hanya perlu melindungi sejumlah kecil database dalam kejadian bencana, tingkat ini sudah mencukupi. Namun, jika Anda ingin mempertahankan beberapa database pada tingkat instans SQL Server, solusi log shipping mandiri tidak memadai.
Failover manual pada server sekunder: Log shipping sendirian tidak dapat melakukan failover otomatis dari server primer ke server sekunder. Anda harus secara manual mengaktifkan database sekunder.
Konfigurasi login SQL manual: Login SQL tidak secara otomatis ditransfer dari server utama ke server sekunder. Anda perlu memindahkan kredensial login dari instansi server utama ke instansi server sekunder untuk sinkronisasi login. Selain itu, Anda juga sering perlu secara manual membuat berbagai rencana pemeliharaan, server terhubung, dan paket SSIS (SQL Server Integration Services) di server sekunder.
Risiko kehilangan data: Secara umum, ketika basis data utama tidak tersedia, hanya cadangan log transaksi terakhir yang dapat dipulihkan. Ini berarti semua transaksi yang terjadi setelah cadangan log terakhir dikirim ke server sekunder akan hilang. Sebagai contoh, jika server utama gagal pada pukul 9:00 pagi dan cadangan terakhir yang disalin ke instansi server sekunder B adalah pada pukul 8:45 pagi, maka seluruh data dari pukul 8:45 pagi hingga pukul 9:00 pagi akan hilang.
Reverse log shipping: Ini berguna ketika beralih peran server tanpa melakukan cadangan database penuh. Contohnya, jika Anda memiliki cadangan besar dan perlu memindahkan data dari server sekunder ke server primer jarak jauh, menyalin seluruh cadangan mungkin memakan waktu lama.
Cara Mengonfigurasi dan Menggunakan Pengiriman Log?
Umumnya, proses pengaturan pengiriman log dapat dibagi menjadi dua langkah berbeda:
Langkah 1 – Inisialisasi Basis Data pada Server Sekunder
Anggap kita memiliki dua database pada instance server utama, dan kita perlu mengirimkan log untuk TestDB1 ke server sekunder yang awalnya tidak memiliki database. Perlu dicatat bahwa untuk mengatur pengiriman log, database harus berada dalam mode pemulihan FULL atau BULK-LOGGED. Jika database berada dalam mode pemulihan SIMPLE, pengiriman log akan gagal karena cadangan log transaksi tidak dapat digunakan.
1. Pertama, kami perlu melakukan cadangan basis data penuh dan cadangan log transaksi. Anda dapat menjalankan kueri T-SQL berikut untuk membuat cadangan "penuh" dan "log transaksi":
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. Selanjutnya, pulihkan cadangan pada server sekunder tersebut.
3. Pada antarmuka Pulihkan Basis Data, pilih Perangkat sebagai sumber data dan klik ikonnya.
4. Dalam kotak dialog Pilih perangkat cadangan, klik Tambah.
5. Pilih file cadangan yang akan dipulihkan dan klik OK.
6. Jalankan pemulihan untuk cadangan TestDB1.
7. Klik Pilih halaman dan pergi ke File untuk mengubah lokasi file database fisik jika diperlukan.
8. Kemudian, klik Options di sebelah kiri. Pada halaman Options, pilih RESTORE WITH STANDBY dari daftar dropdown Recovery state. Perhatikan bahwa memilih RESTORE WITH STANDBY memastikan basis data tetap berada dalam keadaan hanya bisa dibaca. Jika Anda memilih RESTORE WITH NORECOVERY, basis data akan menjadi tidak dapat diakses.
9. Setelah memilih keadaan pemulihan yang sesuai, klik OK untuk memastikan proses pemulihan berhasil. Ini akan memulihkan TestDB1 dalam mode Siaga (hanya baca) pada instansi server sekunder.
Pada tahap ini, basis data telah berhasil diinisialisasi pada server sekunder.
Langkah 2 – Aktifkan Basis Data Utama
1. Klik kanan TestDB1 pada instance server primer dan klik Properties.
2. Pilih Aktifkan ini sebagai basis data utama dalam konfigurasi log shipping.
Secara bawaan, log transaksi dicadangkan setiap 15 menit. Namun, terkadang log transaksi bisa menjadi terlalu besar hingga tidak dapat disalin dan dipulihkan dalam batas waktu yang telah ditentukan. Untuk mengatasi ini, Anda perlu menjadwalkan pencadangan log tambahan. Klik Pengaturan Cadangan, tentukan lokasi file cadangan di antarmuka Pengaturan Pencadangan Log Transaksi, lalu klik Jadwal, dan ubah frekuensi pencadangan menjadi setiap 1-2 menit.
3. Klik Tambah untuk mengatur database sekunder. Sistem akan meminta Anda untuk terhubung ke instance server sekunder.
4. Seperti yang telah dikonfigurasi pada Langkah 1, pada antarmuka Pengaturan Basis Data Sekunder, pilih Tidak, basis data sekunder telah diinisialisasi.
5. Lanjutkan menyalin file dengan menentukan lokasi folder cadangan server sekunder, mengatur frekuensi pencadangan, dan mengklik OK.
6. Pada antarmuka Restore Transaction Log, atur status database ke mode Standby dan centang opsi Putuskan koneksi pengguna di database saat memulihkan cadangan. Setelah mengatur interval cadangan, klik OK.
7. Untuk menambahkan instans server sekunder dan basis data, klik OK untuk membuat pekerjaan agen SQL Server.
Di bawah SQL Server Agent pada server utama, Anda akan menemukan tugas cadangan log transaksi.
Di bawah SQL Server Agent pada server sekunder, Anda akan menemukan dua pekerjaan yang baru saja dibuat: satu pekerjaan yang menyalin cadangan log transaksi dari basis data primer dan satu pekerjaan lain yang memulihkan cadangan log transaksi pada basis data sekunder.
8. Pada tahap ini, solusi pemulihan bencana dengan log shipping telah sepenuhnya dikonfigurasi. Jika database utama gagal, Anda dapat segera mengaktifkan database sekunder. Anda juga dapat menjalankan kueri berikut untuk memastikan bahwa database sekunder telah keluar dari mode siaga:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. Dengan menyegarkan basis data, Anda akan melihat bahwa TestDB1 pada server sekunder kini sudah online.
Strategi Perlindungan Data yang Lebih Komprehensif untuk SQL Server
Saat menerapkan solusi pemulihan bencana seperti log shipping, bisnis sering membutuhkan strategi perlindungan data yang lebih menyeluruh dan efisien. Vinchin Backup & Recovery menawarkan solusi cadangan dan pemulihan otomatis yang dirancang khusus untuk VM dan basis data seperti SQL Server, mendukung cadangan penuh, bertahap, dan diferensial. Dengan teknologi deduplikasi dan kompresi data bawaan, solusi ini secara signifikan mengurangi penggunaan penyimpanan dan waktu pencadangan.
Selain itu, solusi cadangan Vinchin menghilangkan kebutuhan akan intervensi manual yang kompleks, memungkinkan perlindungan database secara otomatis sekaligus mendukung migrasi lintas platform dan penyimpanan awan. Dalam kejadian kegagalan SQL Server, Vinchin membantu administrator memulihkan database secara cepat, mencegah kehilangan data dan waktu henti yang lama, sehingga memberikan jaminan pemulihan bencana yang lebih komprehensif bagi perusahaan.
Untuk membuat pekerjaan cadangan database SQL Server, silakan masuk ke halaman Physical Backup > Database Backup > Backup:
1. Pilih database yang perlu dicadangkan.
2. Pilih node cadangan tempat Anda ingin data cadangan diproses dan disimpan.
3. Konfigurasikan strategi cadangan sesuai kebutuhan Anda.
4. Tinjau dan konfirmasi pengaturan.
Klik tombol di bawah untuk mencoba uji coba gratis Vinchin selama 60 hari dan rasakan sendiri solusi pencadangan dan pemulihan data yang efisien serta andal!
Pertanyaan yang Sering Diajukan tentang Pemulihan Bencana SQL Server
1. Apa perbedaan antara High Availability (HA) dan Disaster Recovery (DR)?
HA memastikan waktu henti minimal dengan menggunakan failover clustering, Always On Availability Groups, atau database mirroring, sedangkan DR berfokus pada pemulihan layanan setelah kegagalan yang bersifat bencana, sering kali melibatkan cadangan di lokasi lain atau pusat data sekunder.
2. Apa itu SQL Server Failover Cluster Instance (FCI), dan bagaimana hal tersebut membantu dalam pemulihan bencana (DR)?
FCI adalah solusi high-availability yang menggunakan Windows Server Failover Clustering (WSFC) untuk memberikan failover otomatis pada tingkat instans SQL Server. Memerlukan penyimpanan bersama (SAN, Storage Spaces Direct, atau solusi berbasis cloud). Sangat ideal untuk high availability di lingkungan lokal tetapi bukan solusi DR tunggal, karena tidak melindungi dari kegagalan seluruh situs.
Kesimpulan
Log shipping merupakan solusi pemulihan bencana yang ekonomis, efisien, dan sederhana untuk SQL Server. Ini adalah pilihan ideal untuk pemulihan bencana pada tingkat basis data. Namun demikian, untuk pemulihan bencana pada tingkat instans, teknik pemulihan bencana lain seperti database mirroring atau failover clustering perlu dipertimbangkan. Selain itu, log shipping dapat menyebabkan hilangnya data. Jika Anda perlu memulihkan data yang terhapus atau tidak dapat diakses dari sebuah basis data SQL yang rusak, pertimbangkan untuk menggunakan tools pemulihan SQL profesional.
