Foto oleh Jakub Zerdzicki via Pexels

Backup Full, Differential, dan Transaction Log SQL Server: Membangun Strategi Pemulihan Data Terbaik

Apa yang terjadi jika server database Anda tiba-tiba down, hardware gagal, atau data terkorupsi secara tidak sengaja? Seberapa cepat Anda bisa mengembalikan operasional bisnis dan berapa banyak data yang mungkin hilang? Tanpa strategi backup yang matang, kerugian finansial dan reputasi bisa sangat besar. Di SQL Server, mengandalkan satu jenis backup saja seringkali tidak cukup. Untuk mencapai Recovery Point Objective (RPO) dan Recovery Time Objective (RTO) yang optimal, kita perlu memahami dan mengimplementasikan kombinasi dari Full, Differential, dan Transaction Log backup.

Mengapa Satu Jenis Backup Saja Tidak Cukup?

Bayangkan Anda hanya melakukan backup full sekali seminggu. Jika terjadi bencana pada hari Kamis sore, Anda akan kehilangan data selama hampir empat hari. Hal ini jelas tidak dapat diterima untuk aplikasi dengan volume transaksi tinggi. Di sisi lain, melakukan backup full setiap jam akan sangat memakan waktu, sumber daya, dan ruang penyimpanan.

Di sinilah peran backup differential dan transaction log menjadi krusial. Kombinasi ketiganya memungkinkan kita untuk menyeimbangkan kebutuhan akan pemulihan data yang cepat dan minim, dengan efisiensi sumber daya.

Prasyarat: Recovery Model Full

Sebelum kita menyelami berbagai jenis backup, penting untuk mengingat kembali konsep Recovery Model. Seperti yang sudah dibahas pada artikel sebelumnya tentang Recovery Model Simple Full dan Bulk Logged, jenis recovery model yang Anda pilih sangat menentukan kemampuan backup dan restore. Untuk bisa memanfaatkan Differential Backup dan khususnya Transaction Log Backup, database harus dikonfigurasi dengan Recovery Model FULL (atau Bulk-Logged, meskipun Full lebih umum untuk skenario ini).

Tanpa Recovery Model Full, SQL Server tidak mencatat semua transaksi ke dalam transaction log dengan cara yang memungkinkan pemulihan ke titik waktu tertentu, sehingga Transaction Log Backup tidak dapat dilakukan.

1. Full Backup: Pondasi Strategi

Full Backup adalah salinan lengkap dari seluruh database pada saat backup dilakukan. Ini mencakup setiap objek database (tabel, indeks, stored procedure, dsb.) dan sebagian dari transaction log yang diperlukan untuk membuat database konsisten secara transaksional saat direstore.

Kapan Dilakukan?

• Sebagai backup awal setelah database dibuat atau setelah perubahan besar.
• Secara teratur, misalnya seminggu sekali (atau lebih sering, tergantung RPO/RTO).
• Sebagai dasar untuk serangkaian backup differential dan transaction log selanjutnya.

Contoh Query Full Backup:

Untuk membuat full backup, Anda bisa menggunakan perintah BACKUP DATABASE. Pastikan lokasi output sudah ada dan SQL Server memiliki izin menulis ke sana.

Pada contoh di atas, MyDatabase adalah nama database yang di-backup, dan 'D:\SQLBackup\MyDatabase_Full.bak' adalah lokasi dan nama file backup.

2. Differential Backup: Efisiensi untuk Perubahan

Differential Backup hanya mencadangkan data yang telah berubah sejak full backup terakhir. Ini bukan kumulatif dari differential backup sebelumnya, melainkan selalu mengacu pada full backup terakhir sebagai basisnya.

Manfaat:

• Lebih cepat dan lebih kecil: Karena hanya menyalin data yang berubah, ukurannya jauh lebih kecil dan prosesnya lebih cepat dibandingkan full backup.
• Mengurangi waktu restore: Saat restore, Anda hanya perlu full backup terakhir dan differential backup terakhir.

Kapan Dilakukan?

• Secara berkala di antara jadwal full backup, misalnya setiap hari.
• Ketika perubahan data signifikan terjadi, tetapi tidak cukup sering untuk membenarkan full backup.

Trade-off:

Pemulihan data membutuhkan full backup terakhir dan differential backup terakhir. Jika full backup dasar rusak, maka differential backup yang bergantung padanya juga tidak berguna.

Kesalahan Umum:

Banyak yang salah paham bahwa differential backup adalah kumulatif dari differential backup sebelumnya. Ingat, selalu dari full backup terakhir. Jika Anda melakukan full backup baru, semua differential backup sebelumnya akan menjadi usang dan differential backup berikutnya akan berbasis pada full backup yang baru itu.

Contoh Query Differential Backup:

Klausa WITH DIFFERENTIAL memberi tahu SQL Server untuk membuat differential backup.

3. Transaction Log Backup: Pemulihan ke Titik Waktu

Transaction Log Backup adalah jenis backup yang paling sering dilakukan dalam strategi backup yang komprehensif. Ini mencadangkan semua transaksi yang telah dicatat dalam transaction log sejak transaction log backup terakhir. Ini adalah kunci untuk mencapai pemulihan data ke titik waktu tertentu (Point-in-Time Recovery), yang akan kita bahas lebih lanjut di artikel berikutnya.

Manfaat:

• Pemulihan granular: Memungkinkan pemulihan database hingga ke detik terakhir sebelum kegagalan (jika backup log dilakukan sangat sering).
• Mengosongkan transaction log: Setelah transaction log backup berhasil, bagian dari log yang sudah di-backup dapat ditandai untuk digunakan kembali, sehingga mencegah transaction log membengkak (asumsi Recovery Model FULL).

Kapan Dilakukan?

• Sangat sering, tergantung RPO yang diinginkan. Misalnya, setiap 15-30 menit, atau bahkan setiap 5 menit untuk sistem kritis.

Trade-off:

Hanya bisa dilakukan pada database dengan Recovery Model FULL atau Bulk-Logged. Proses restore log sangat berurutan; Anda harus memiliki semua transaction log backup dalam rangkaian yang tidak terputus sejak full backup (atau differential backup terakhir).

Kesalahan Umum:

Tidak melakukan transaction log backup sama sekali ketika database menggunakan Recovery Model FULL. Ini adalah kesalahan fatal yang akan menyebabkan transaction log terus membengkak dan Anda tidak dapat melakukan pemulihan ke titik waktu tertentu, bahkan setelah full backup. Log backup secara efektif memotong log.

Contoh Query Transaction Log Backup:

Strategi Backup Kombinasi: Full, Differential, dan Transaction Log

Kombinasi ketiga jenis backup ini memungkinkan kita untuk merancang strategi yang robust:

1. Jadwal Full Backup Mingguan: Misalnya setiap hari Minggu malam. Ini menjadi titik dasar baru setiap minggunya.
2. Jadwal Differential Backup Harian: Setiap malam (Senin-Sabtu) setelah jam kerja. Ini menghemat waktu dan ruang dibandingkan full backup harian.
3. Jadwal Transaction Log Backup Per Jam/Setengah Jam: Sepanjang hari, setiap hari. Ini memastikan kita bisa memulihkan database dengan kehilangan data minimal.

Dengan strategi ini, jika bencana terjadi pada hari Rabu sore:

1. Anda akan restore full backup dari hari Minggu malam.
2. Kemudian, restore differential backup dari Selasa malam.
3. Terakhir, restore semua transaction log backup secara berurutan mulai dari setelah differential backup terakhir hingga log backup terakhir sebelum kegagalan.

Ini memungkinkan pemulihan ke waktu yang sangat spesifik, sesuai dengan RPO Anda.

Pentingnya Validasi Backup: Jangan Sampai Backup Rusak!

Memiliki file backup saja tidak cukup. Anda harus memastikan backup tersebut valid dan dapat direstore. SQL Server menyediakan opsi WITH CHECKSUM saat melakukan backup. Opsi ini akan memverifikasi integritas backup file dengan melakukan checksum pada data saat dibaca dari database dan menulis checksum ke file backup.

Meskipun ada sedikit overhead performa, penggunaan WITH CHECKSUM sangat direkomendasikan untuk mendeteksi korupsi data pada sumber atau saat proses backup.

Selain CHECKSUM, secara berkala Anda juga harus melakukan restore test ke server terpisah. Ini adalah satu-satunya cara pasti untuk memverifikasi bahwa backup Anda benar-benar berfungsi.

Kesimpulan

Mengimplementasikan strategi backup yang komprehensif menggunakan kombinasi Full, Differential, dan Transaction Log Backup adalah pilar utama dari setiap rencana pemulihan bencana (DRP) yang efektif di SQL Server. Pilihlah recovery model yang tepat (umumnya FULL), pahami kapan setiap jenis backup harus digunakan, dan selalu validasi backup Anda.

Setelah memahami cara kerja ketiga jenis backup ini, langkah selanjutnya adalah mempelajari bagaimana kita bisa menggunakan backup-backup ini untuk mengembalikan database ke kondisi operasional, bahkan hingga ke titik waktu yang sangat spesifik. Ini akan menjadi pembahasan kita di artikel selanjutnya: Restore Database Point-in-Time di SQL Server.