DATABASE ADMINISTRATION Pertemuan ke-10

Disaster Planning source : Database Administration the complete guide to practices and procedures chapter 16 by. Craig S. Mullins

pengantar Disaster planning mirip dengan asuransi Implementasi disasater planning akan membutuhkan biaya rutin, tapi kita akan mendapatkan pengganti ketika ada musibah (bisa disebut investasi)

Kebutuhan akan planning Disaster recovery planning disebut juga dengan contingency planning : sebuah proses mempersiapan aset dan operasi organisasi untuk menghadapi bencana Disaster (bencana) dalam IT : any unplanned, extended loss of critical business applications due to lack of computer processing capabilities for more than a 48-hour period (Sungard Recovery Services -1995)

"any event that has a small chance of transpiring, a high level of uncertainty, and a potentially devastating outcome.“ The DB2 Developer's Guide (Mullins 2000)

Disasters bisa merupakan buatan manusia, seperti kerusakan listrik, ledakan pipa atau perang Efek yang besar disaster dalam bisnis adalah alasan utama mengapa ada disaster recovery planning tempat mempengaruhi jenis bencana yang terjadi Meski disaster tidak dapat diprediksi dan tidak diharapkan, setiap organisasi harus memiliki rencana yang komperhensif dan telah dites untuk menghadapi situasi bencana Segera setelah bencana terjadi, perusahaan yang memiliki disaster plan dapat memberikan service pada customer lebih cepat daripada perusahaan yang tidak memiliki disaster plan. Perusahaan yang menghadapi disaster tanpa disaster plan kecil kemungkinannya dalam melanjutkan bisnis

Pasca bencana perusahan harus merestore IT infrastructure Pasca bencana perusahaan harus menghandle beberapa isu bisnis seperti –Lokasi alternatif untuk melaksanakan bisnis –Metode komunikasi untuk menginformasikan lokasi dan prosudur baru bisnis pada karyawan –Menginformasikan pada custumer bagaimana transaksi bisnis dengan perusahaan pasca bencana Salah satu komponen penting yang harus direcovery adalah database dan DBMS

Risk and Recovery Tujuan utama dari disaster recovery plan adalah meminimalkan biaya yang hilang pada fasilitas IT Dalam database recovery local, DBA harus melakukan evaluasi menyeluruh pada seluruh objek database untuk disaster recovery Berdasarkan kebutuhan data ada 3 tipe resiko (dengan derajat masing-masing di tiap kategori) –financial loss, –business service interruption, and –legal responsibilities Saat membangun disaster recovery plan, bisnis harus diletakkan pada prioritas pertama, bukan teknis atau isu yang lain

Kita dapat mengkatagorikan aplikasi pada beberapa grup berdasarkan besarnya efek jika aplikasi tersebut tidak ada: –Very critical applications. Penting dan mendesak untuk kelangsungan perusahaan, support kebutuhan –Business-critical applications penting untuk kelanjutan bisnis contoh : aplikasi untuk telepon provider service, sistem untuk deliver phone service, customer billing –Critical applications. Penting tapi tidak mendesak –Required Applications. Penting tapi dapat dilakukan dilakukan backup di remote location, biasanya untuk support –Noncritical applications. Tidak terlalu dibutuhkan, bahkan pasca bencana terkadang tidak perlu di recovery

General Disaster Recovery Guidelines Tujuan utama disaster recovery adalah meminimalkan downtime dan kehilangan data. Planning untuk disaster recovery adalah pekerjaan level enterprisewide DBMS dan database recovery hanyalah satu komponen dari seluruh disaster recovery plan Sebuah disaster recovery plan, harus melihat seluruh fungsi bisnis, interface customer, phone center, jaringan, dan aplikasi

The Remote Site –Dibutuhkan ketika bencana terjadi, sebuah lokasi off-site dimana perusahaan dapat melanjutkan binnis –Jika perusahaan besar dan memiliki beberapa data center, perusahaan dapat menggunakan salah satu data center untuk backup –Beberapa perusahaan memembuat sebuah remote location dimana setiap data dikirimkan secara rutin –Backup materials harus disimpan dengan aman –Jika bencana terjadi, perusahaan harus memiliki mekanisme untuk memindahkan material dari storage location ke recovery location

The Written Plan –Sebuah rencana yang tertulis adalah pondasi sebuah disaster plan yang bagus –Disaster recovery plan harus dikirim ke seluruh personil yang memiliki peran dalam skenario recovery. –Setiap orang harus memiliki copy recovery plan di rumah dan di kantor,termasuk di lokasi recovery –disaster recovery plan adalah sebuah living document. –disaster recovery plan harus mengandung instruksi lengkap off-site disaster recovery.

disaster recovery plan harus memiliki beberapa informasi –Off-site location. –Personnel. –Authorizations. –Recovery procedures and scripts for all system software, applications, and data. –Reports

Testing Disaster Plans –Setiap membuat sebuah disaster recovery plan perusahaan harus selalu melakukan sebuah regular test –Perusahaan harus melakukan tes disaster recovery plan pada remote recovery site minimal setahun sekali –Denang disaster recovery test perusahaan dapat melihan kelemahan dan error pada sebuah plan –regular disaster recovery tes juga untuk memastikan setiap personil siap dalam menghadapi bencana –disaster recovery tes harus memenuhi seluruh aspek yang tertulis pada plan

Personnel Dalam perspektif DBMS tim harus memiliki kemampuan untuk menginstall dan mengkonfigurasi DBMS, memastikan DBMS dapat terintegrasi dengan software, merecovery database, dll Artinya tim recovery harus multiskill dan dapat berdadaptasi Seluruh tim harus bertemu dan cross tess secara rutin. Setiap tim harus dipastikan berada pada tempat dan kondisi yang direncanakan Tidak ada nya personil pada saat crucial task (karena rencana yan g kurang matang atau indisiplin) akan mengakibatkan seluruh disaster plan gagal

Backing Up the Database for Disaster Recovery Beberapa strategi backup untuk disaster recovery Tape Backups Startegi backup yang tepat untuk disaster recovery adalah dengan cara yang sama untuk membuat local backup file Perusahaan harus membuat copy dari report pada local site dan mengirim ke remote location segera Report harus menginfokan detail informasi yang dibutuhkan untuk recovery sperti: – file name, –type of backup (full or incremental), –how the image copy was created (database utility or file system command), –date and time of the backup, –date and time it was shipped off-site, –and the date and time it was received off-site (if possible).

Figure The database log and disasters

Storage Management Backups 1.Backup dengan storage management software dengan beberapa step: 2.Stop the DBMS to create a systemwide point of stability for recovery. 3.Copy all of the database objects, using storage management software to dump complete disk volumes to tape. 4.When all of the disk volumes containing database objects have been successfully copied, restart the DBMS. 5.Copy the backup tapes and send them to the remote site.

Cara yang lain Membuat sebuah wide-area network (WAN) untuk menunjang pengiriman backup ke remote lokasi adalah salah satu taktik yang bagus Salah satu cara yang lain adalah membuat sebuah remot mirroring dari data pada alternate site pada jaringan Agar strategi efektif, semua perubahan pada primary site harus di mirror pada remote site termasuk database change (INSERTs, UPDATEs, and DELETEs), database utility operations (LOAD and REORG), and local database recovery operations.

Disaster Prevention DBAs dan IT professionals umumnya harus membuat prosedur dan memastikan peraturan di dalamnya berjalan Memastikan prosedur dan peraturan berjalan adalah langkah awak yang tepa dalam disaster plan Ide lain yang tepat adalah membuat sebuah dokumentasi dan menyebarkan prosedur tersebut pada end user untuk mengajarkan mereka jika terjadi error

Ada beberapa referensi yang bagus untuk mengcover disaster dan contigency planning yang detail:

Summary Kunci utama dari tugas DBA adalah develop plan untuk meminimalkan kerusakan jika ada bencana Dengan tujuan adalah membuat aplikasi kembali online dengan sesedikit mungkin loss dan interupsi Ada banyak komponen yang dibutkan untuk membuat sebuah recovery plan, tapi yang utama adalah bagaimana rencana yang komperehensif dapat dibuat dan di maintenance. Meski tanggungjawab DBA adalah untuk merecovery database, tapi DBA harus jadi bagian dari multidisipline tim untuk disaster recovery. Regular planning, testing, and revising adalah sangat penting untuk dibuat

Terima kasih