Pembuatan Disaster Recovery Planning SQL Server dengan Metode Log Shipping

Seminar Nasional Pengaplikasian Telematika SINAPTIKA 2010 – ISSN 2086-8251

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 : [email protected] , 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 131

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


informasi kritis mengenai sistem log shipping. Informasi akan hilang jika server primary berhenti bekerja. Juga karena monitor menyimpan aktivitas beberapa server overhead. Seperti semua serverserver SQL lainnya, 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. START DATA LOG RANSAKSI COPY DATA LOG TRANSAKSI BACK UP LOG TRANSAKSI EXIT 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 filefile 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

132


2.

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

133


Monitoring Server

Status & History

Secondary Server Primary Server

1

4

Backup Log Copy File Log

Share File Log 2

Restore Log

3

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 mencopy 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 halhal 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 secondary.

134


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)

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.

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

Gambar 3 Log Shipping Pair Properties

135


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 7 Merubah Server Cadangan Menjadi Server Utama Setelah mempunyai database utama baru ulangi proses konfigurasi log shipping untuk membuat log shipping baru. IV. KESIMPULAN

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.

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] [2] [3]

136

Thomas Moore, SQL Server 2000 Database Design and Implementation, Que, 2003. Bambang Robi’in, Manajemen dan Administrasi Database Menggunakan SQL Server 2000, Penerbit Andi, 2005. M. Rudyanto Arief, Pemrograman Basis Data Menggunakan Transact-SQL dengan Microsoft SQL Server 2000, Penerbit Andi, 2006.

Pembuatan Disaster Recovery Planning SQL Server dengan Metode Log Shipping

Recommend Documents