131
Pembuatan Disaster Recovery Planning SQL Server
dengan Metode Log Shipping
Ratna Wahyuningsih1, Rusdianto Roestam2, Nenden Siti Fatonah3
Jurusan Teknik Informatika, Fakultas Ilmu Komputer, Universitas Mercu Buana Jl. Raya Meruya Selatan, Kembangan, Jakarta, 11650
E-mail : veira_15@yahoo.com1 , nendenfatonah@gmail3
Abstrak -- Disaster Recovery Planning adalah
pernyataan lengkap berkaitan dengan semua tindakan konsisten yang dibutuhkan untuk menangani gangguan yang terjadi terhadap sumber daya sistem informasi, yang dilakukan sebelum, tepat ketika atau sesudah waktu terjadinya gangguan tersebut. Penelitian ini berusaha membuat disaster recovery planning terhadap data yang tersimpan dalam SQL Server, dengan menggunakan metode log
shipping. Berdasarkan hasil pengujian, dapat
disimpulkan bahwa metode log shipping cukup efektif dalam mengembalikan data yang hilang akibat gangguan yang terjadi terhadap basis data.
Kata Kunci: Disaster Recovery Planning, SQL Server, log shipping
I. PENDAHULUAN
Bencana adalah sesuatu yang tidak dapat terpisahkan dari kehidupan manusia. Bencana terjadi dengan frekuensi yang tidak menentu dan akibat yang ditimbulkannya meningkat bagi mereka yang tidak mempersiapkan diri terhadap kemungkinan-kemungkinan timbulnya bencana. Rencana pencegahan dan perbaikan terhadap bencana dapat membantu melindungi semua bagian organisasi/perusahaan, termasuk sumber daya manusia, pekerjaan, data-data penting, dan fasilitas organisasi.
Cakupan bencana tidak hanya terbatas pada hilangnya data dan sumber informasi, tetapi juga kematian dari pekerja yang sangat diandalkan, keracunan produk, meledaknya sistem peralatan, kebakaran yang terjadi pada pusat distribusi utama, atau tumpahnya cairan kimia, dan lain sebagainya, sangat mempengaruhi suatu organisasi perusahaan. Kebutuhan akan perencanaan untuk menghadapi bencana dalam hal ini untuk melindungi aset yang sangat berharga dari perusahaan yaitu data, data elektronik yang tersimpan dalam sebuah server basis data.
Berdasarkan latar belakang diatas dapat dirumuskan masalahnya adalah bagaimana membangun sebuah aplikasi untuk persiapan jika terjadi sesuatu yang tidak diinginkan terhadap basis
data SQL Server dengan menggunakan metode log
shipping.
II LANDASAN TEORI 2.1 Log Shipping
2.1.1 Pengertian Log Shipping
a. Log shipping adalah proses mengirim transaksi
log secara otomatis dari satu server ke server
lain. Transaksi log memback up secara berkala diserver primer dan di copy ke server standby dimana transaksi log diperbaiki secara berurutan. Jika arus server primer berhenti bekerja, dapat di
upgrade dari server yang hidup ke server yang
primer.
b. Log shipping adalah metode replikasi basis data yang ada dalam Microsoft SQL 2000.
c. Log Shipping adalah arsitektur yang digunakan untuk otomisasi backup dan restore basis data
SQL server untuk memelihara server basis data
pada server cadangan.
Untuk menjalankan log shipping ini dengan membuat sebuah program atau script untuk men-copy transaction log dari server utama ke server cadangan dan melakukan restore ke basis data server cadangan.
Istilah yang biasa ditemukan dalam log shipping adalah :
1. Primary atau server sumber: server ini terdiri dari database sumber (asli ) yang dibuat untuk log shipping. Backup database pertama dan transaksi backup log berikutnya mengambil dari server ini. Biasanya, server primary disebut juga server penghasil atau server perkembangan. 2. Secondary atau server tujuan : database pertama
dan transaksi backup log selanjutnya diperbaiki di server ini. Biasanya, biasanya server ini adalah warm stanby server.
3. Monitor server : server ini digunakan untk monitor log shipping. Monitor server terdiri dari semua informasi yang berkaitan dengan status log shipping.
4. Transfer logins task : dapat menggunakan Data
Transformation Services (DTS) task untuk transfer logins dari server sumber ke server
tujuan.
Microsoft menganjurkan tidak menggunakan
server yang sama yaitu antara server monitor dan server sumber sebab server monitor memelihara
132 informasi kritis mengenai sistem log shipping. Informasi akan hilang jika server primary berhenti bekerja. Juga karena monitor menyimpan aktivitas beberapa server overhead. Seperti semua server-server SQL lainnya, server-server monitor harus di backup secara rutin. Contohnya walaupun tidak ada anjuran, dapat membuat server sumber dan server tujuan menjadi beberapa komputer fisik dengan multiple
instance.
2.2 Back Up dan Restore Data Base
Proses back up dan restore tidak dapat dilepaskan dari keberadaan suatu data yang disimpan pada komputer. Proses tersebut bertujuan untuk mengantisipasi bila terjadi kerusakan atau kehilangan data sebagai akibat kegiatanyang disengaja atau tidak disengaja.
Membackup data meliputi proses duplikat (copy) database ke lokasi yang aman. Salinan data sedapat mungkin ditempatkan kekomputer lain di dalam media network, tape atau media magnetic lainnya. Salinan data yang dimaksud adalah semua yang terdapat di dalam database, termasuk catatan transaksinya. Catatan transaksi yang disimpan di file
log, merupakan sebuah record serial yang berisikan
semua perubahan yang dilakukan terhadap database.
Log ini digunakan pada proses restore untuk
mengulangi semua perubahan yang terjadi di dalam database setelah proses back up dilakukan.
Restore database adalah suatu proses yang
bertujuan untuk mengembalikan database ke status terdahulu seperti saat back up terakhir dilakukan. Konsistensi data sangat diperhatikan selama proses
back up dan restore, sehingga jika terjadi transaksi
tidak lengkap maka proses back up di batalkan. Secara otomatis proses restore juga tidak dapat dilakukan.
2.2.1 Jenis-jenis Back Up 1. Full database backup
Full database backup merupakan proses backup seluruh database termasuk tabel, index, tabel sistem termasuk juga membackup record-record
log transaksi.
2. Differential database backup
Differential database backup merupakan proses
backup semua page yang pernah diubah sejak proses backup database terakhir. Proses backup ini lebih mudah digunakan karena proses
restore-nya lebih cepat daripada restore backup log transaksi.
3. Transaction log backup
Transaction log back up merupakan proses back up record-record dari setiap perubahan yang
dibuat pada database. Jenis backup ini berisi perintah- perintah yang dijalankan user, aktivitas sistem background. Keuntungan dari pemakaian
transaction log backup antara lain:
a. Log dapat dijalankan berulang-ulang untuk melakukan restore terhadap semua aktivitas yang telah disimpan ke log transaksi.
b. Seluruh transaksi dapat dijalankan ulang dari suatu kondisi ke kondisi yang lain.
Pada Gambar 1 disajikan langkah-langkah back up pada metode transaction log back up.
Gambar 1 Transaction Log Back Up 4. File (s) dan filesgroup (s) backup
File (s) dan filesgroup (s) backup merupakan proses backup yang digunakan untuk membackup file-file dan filegroup yang dipilih saja. Keuntungan dari pemakaian file (s) dan
filegroup backup antara lain :
a. File-file yang di backup dari disk tertentu yang gagal masih dapat di restore sehingga tidak perlu membackup seluruh database. b. Prosesnya lebih cepat dibandingkan dengan
proses backup seluruh database karena file-file yang di backup dapat dipilih sesuai kebutuhan.
2.2.2 Konsep Restore Database
Restore database adalah proses pengambilan
kembali database yang telah di backup. Proses restore ini dijalankan jika database yang sedang digunakan diserver mengalami kerusakan sehingga tidak dapat digunakan.
SQL Server mempunyai dua cara untuk
memperbaiki kerusakan pada database (recovery), yaitu secara otomatis dan manual.
1. Recovery Otomatis
Merupakan proses yang dilakukan servis
MSSQLServer pada saat SQL Server diaktifkan.
Karena proses ini dikerjakan secara otomatis maka pihak luar (user) tidak dapa interfensi di dalamnya.
Proses yang dilakukan setiap kali SQL Server diaktifkan ulang yaitu:
a. Dilakukan transaksi roll forward yaitu transaksi yang telah di commit akan dijalankan ulang pada database yang
START DATA LOG RANSAKSI COPY DATA LOG
TRANSAKSI BACK UP LOG
TRANSAKSI EXIT
133 ditemukan pada log transaksi dan terjadi sejak checkpoint terakhir.
b. Dilakukan rollback transaksi di dalam log transaksi yang belum di commit. Maksudnya transakasi yang belum komplit tetapi belum di commit akan dibuang dari database. Artinya jika ada salah satu ransaksi yang tidak dijalankan maka akan langsung dihapus dari database, sebaliknya jika transaki semua dilakukan maka akan langsung di commit.
c. Hasil dari proses diatas, setiap database berada dalam keadaan konsisten dan dibuat sebuah checkpoint. Dengan recovery otomatis menjamin SQL Server akan diaktifkan lagi dalam keadaan konsisten, seperti apapun SQL Server berhenti.
Pada konfigurasi recovery otomatis terdapat option yang menyatakan banyaknya proses
recovery otomatis maksimum yang akan
dikerjakan pada setiap database. Option tersebut adalah Recovery Interval. Untuk mengeset option recovery interval digunakan
stored procedure sistem sp_configure.
2. Recovery Manual
Recovery manual merupakan proses recovery
yang dilakukan dengan cara recovery dari backup seluruh database, recovery differential atau recovery dari beberapa log transaksi. Ternyata proses recovery manual tidak selamanya mulus. Ada beberapa batasan yang tidak bisa dihindari saat proses recovery ini dijalankan, yaitu :
a. Saat proses recovery berlangsung, database tidak dapat digunakan.
b. Untuk melaksanakan proses ini, user harus mempunyai hak khusus sebagai anggota SysAdmin atau db_owner.
c. Setiap log transaksi yang dibuat mempunyai nomor urut. Oleh karenanya saat user
me-restore log transaksi harus sesuai dengan
urutan pembuatannya.
III. HASIL DAN PEMBAHASAN 3.1 Analisa, Perancangan dan Implementasi Sistem 3.1.1 Tujuan dan Sasaran DRP
Tujuan DRP yang utama adalah untuk menyediakan suatu cara yang terorganisir untuk membuat keputusan jika suatu peristiwa yang mengganggu terjadi. Selain disaster recovery plan bertujuan untuk mengurangi kebingungan organisasi dan meningkatkan kemampuan organisasi untuk berhubungan dengan krisis tersebut.
Sesungguhnya, ketika suatu peristiwa yang mengganggu terjadi, organisasi tidak akan mempunyai kemampuan untuk menciptakan dan melaksanakan suatu rencana pemulihan dengan segera. Oleh karena itu, jumlah perencanaan dan pengujian yang telah dilakukan sebelumnya akan
menentukan kemampuan organisasi tersebut dalam mengangani suatu bencana.
DRP mempunyai banyak sasaran, dan masing-masing sasaran tersebut penting. Sasaran-sasaran tersebut meliputi:
1. Melindungi suatu organisasi dari kegagalan penyediaan jasa komputer.
2. Memperkecil risiko keterlambatan suatu organisasi dalam menyediakan jasa
3. Menjamin keandalan sistem melalui pengujian dan simulasi
4. Memperkecil pengambilan keputusan oleh personil selama suatu bencana
3.1.2 Analisa Resiko Database
Proses ini adalah mendaftar semua faktor yang mengancam keberadaan database atau yang menyebabkan database tidak berjalan sebagaimana mestinya.
Berikut ini resiko atau ancaman bagi database: 1. Faktor lingkungan luar dari komputer bisa berupa bencana alam, kebakaran atau pencurian komputer.
2. Kerusakan perangkat keras, komputer yang menyimpan database mengalami kerusakan . 3. Kerusakan software, kerusakan database yang
berasal dari perangkat lunak yang disebabkan oleh virus, serangan hacker atau lainnya. 3.1.3 Analisa Penjadwalan pada Log Shipping.
Untuk mengatur penjadwalan pada log
shipping harus melihat berdasarkan beberapa faktor
yang mempengaruhi proses log shipping.
1. Besarnya transaksi, dengan cara memonitor besarnya transaksi yang ada. Semakin sering transaksi yang terjadi pada database kita akan berakibat semakin besar file backup log yang ada. Dengan begitu untuk memperkecil file
backup log dilakukan dengan memperkecil
interval waktu backup log. Transaksi = interval waktu backup.
2. Fasilitas Jaringan, dengan semakin lambat jaringan diperlukan interval waktu semakin lama untuk mencopy file backup log ke server cadangan. Fasilitas Jaringan >< interval waktu mengcopy file log.
3. Kemampuan proses server cadangan, dengan semakin lama kemampuan proses server cadangan untuk melakukan proses restore maka diperlukan waktu yang lama untuk melakukan
restore. Server Cadangan >< interval waktu Restore.
4. Proses backup, copy dan restore merupakan proses yang berdiri sendiri sehingga proses satu dengan yang lain tidak saling mempengaruhi
134 Monitoring Server Primary Server Secondary Server 1 2 3 4 Status & History
Backup Log
Share File Log Copy File Log
Restore Log
Gambar 2 Topologi untuk Log Shipping 3.1.4 Perancangan Replikasi Data Menggunakan
Log Shipping
Log shipping adalah metode replikasi basis
data yang ada dalam Microsoft SQL 2000.
Log Shipping adalah arsitektur yang digunakan
untuk otomisasi backup dan restore basis data SQL
server untuk memelihara server basis data pada server cadangan.
Untuk menjalankan log shipping ini dengan membuat sebuah program atau script untuk men-copy transaction log dari server utama ke server cadangan dan melakukan restore ke basis data
server cadangan.
Pada Gambar 2 dicantumkan topologi jaringan yang dibutuhkan untuk melakukan disaster recovery menggunakan log shipping.
Primary Server merupakan komputer yang
terdapat database SQL Server utama. Secondary
Server merupakan komputer yang terdapat SQL Server database cadangan.
4. Pengujian
Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan program log shipping ini diiringi dengan aktivitas jaminan kualitas dengan melakukan serangkaian pengujian.
Black box testing adalah pengujian yang
fokusnya adalah domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam. Dalam pengujian black box testing sebagai acuan untuk menguji bahwa sebuah sistem berjalan sebagaimana mestinya.
4.1 Pengujian Perubahan Database
Pengujian Log Shipping dilakukan pada hal-hal yang menyebabkan perubahan database baik itu struktur atau data. Jika dilakukan perubahan database pada server utama, perubahan itu harus otomatis dilakukan pada server kedua. Pengujian ini dilakukan pada 2 bahasa manipulasi database yaitu : Data Definition Language (DDL) dan Data
Manipulation Language (DML). Untuk melihat
hasil pengujian pada database server kedua terdapat selisih waktu sesuai dengan interval waktu yang ada pada log shipping.
4.1.1 Pengujian Perubahan Data Definition Language (DDL)
Berfokus pada pengujian perubahan yang dilakukan oleh perintah perintah Data Definition
Language.
a. Membuat Obyek Basisdata (Create)
Untuk menguji aplikasi digunakan sebuah data base, dalam hal ini membuat tabel baru pada server primer kemudian akan di restore ke server
135 b. Merubah Obyek Basisdata (Modify)
Dalam merubah tabel, sebagai contoh merubah
field table region pada primery server, proses dapat
kita lihat pada propertise setelah proses berjalan dan berhasil maka dapat dilihat pada database kedua c. Menghapus Obyek Basisdata (Drop)
Untuk menghapus obyek basisdata digunakan
table region, dimana jika pada primary server table region dihapus maka akan secara otomatis table region juga akan terhapus pada secondary server.
4.1.2 Pengujian Perubahan Data Manipulation
Language (DML)
Pengujian ini memusatkan perhatian pada pengujian perubahan yang dilakukan oleh perintah perintah Data Manipulation Language (DML). a. Memasukan Data Baru (Insert)
b. Merubah Data (Update) c. Menghapus Data (Delete) 4.2.2 Pengujian Sistem
Pengujian system memusatkan perhatian pada keseluruhan sistem pada DRC yang ada. Testing akan mencoba menguji DRC yang ada apakah berjalan dengan sebagaimana mestinya jika terjadi sesuatu kerusakan pada database utama yang disebabkan oleh apapun. Setelah terjadi kerusakan terhadap database utama sistem harus bisa mengembalikan/ menyelamatkan database yang ada dalam keadaan sebelum database mengalami kerusakan. Ada 2 proses yang harus dilakukan bila terjadi kerusakan pada database utama.
4.2.2.1 Memastikan Server Database Cadangan (Secondary) Sudah Terbaru
Bila terjadi kerusakan database utama (primary) maka kita harus menggantikannya dengan database standby. Periksa Status Log Shipping pada
Server Monitoring seperti yang ditunjukkan pada
Gambar 3.
Gambar 3 Log Shipping Pair Properties
Ada 3 keadaan yang bisa terjadi pada sistem DRC menggunakan log shipping
Last Backup file, Last file Copied dan Last File
Loaded adalah file yang sama yang berarti
database cadangan sudah terbaru.
Last Backup file lebih baru dari Last file Copied dan Last File Loaded yang berarti ada file
backup log yang belum dicopy dan direstore ke
server cadangan. Copy file log yang belum tercopy jika file tersebut ada ke server cadangan dan lakukan proses restore log
Last Backup file dan Last file Copied sama tetapi masih lebih baru dibandingkan Last File
Loaded yang berarti ada file backup log yang
belum direstore ke server cadangan. lakukan proses restore log seperti yang ditunjukkan dalam Gambar 4.
Gambar 4 Log Shipping Restore for data Proses restore bisa dilakukan secara otomatis dari sistem atau secara manual, Jika ingin secara otomatis tunggu sampai system me-restore file
transaction log yang terakhir di copy. Untuk
mempercepat proses kita bisa mengubah schedule
SQL jobs yang me-restore transaction log. Log Shipping Restore for DATA01.Sipamlu_logshipping
Setelah itu restore melalui enterprise manager log yang terakhir dikopi, sebagaimana yang ditunjukkan pada Gambar 5.
136 Gambar 5 Restore melalui enterprise manager log
yang terakhir dikopi
Pilih from device dan select devices untuk memilih file transaction log terakhir yang akan di
restore (lihat Gambar 6). Pilih option transaction log. Pilih tab options – di move to physical file
name tentukan letak dari file log dan data database yang akan kita restore di simpan. Klik OK
Gambar 6 Restore Database
4.2.2.2 Merubah Server Cadangan Menjadi Server Utama
Bila terjadi kerusakan database utama (primary) maka kita harus mengantikannya dengan database cadangan. Lakukan full backup dan
Restore pada Database Baru.
Gambar 7 Merubah Server Cadangan Menjadi Server Utama
Setelah mempunyai database utama baru ulangi proses konfigurasi log shipping untuk membuat log shipping baru.
IV. KESIMPULAN
Kesimpulan dalam membuat disaster recovery
planning untuk database Microsoft SQL Server
menggunakan log shipping ini adalah sebagai berikut :
1. Log Shipping yang dibangun dapat digunakan untuk melakukan backup database sebagai salah satu solusi disaster recovery center.
2. Log shipping dapat dibangun dengan menggunakan SQL server 2000 pada semua edisi. Sehingga cocok untuk perusahaan yang mempunyai anggaran terbatas.
3. Log shipping hanya digunakan untuk membackup data dengan server database
backup standby (warm backup) jadi membutuhkan proses recovery sedikit lebih lama.
4. Log Shipping hanya meng-copy log database yang mengalami perubahan setiap satuan waktu sehingga membutuhkan akses jaringan yang kecil, cocok untuk perusahaan dengan jaringan terbatas.
V. DAFTAR PUSTAKA
[1] Thomas Moore, SQL Server 2000 Database Design and Implementation, Que, 2003.
[2] Bambang Robi’in, Manajemen dan Administrasi Database Menggunakan SQL Server 2000, Penerbit Andi, 2005.
[3] M. Rudyanto Arief, Pemrograman Basis Data Menggunakan Transact-SQL dengan Microsoft SQL Server 2000, Penerbit Andi, 2006.
