Anda di halaman 1dari 27

DATABASE ADMINISTRATION

Pertemuan ke-12
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 salah satu 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
– Dengan disaster recovery test perusahaan dapat melihant
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 16-1. 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 tepat
• Salah satu cara yang lain adalah membuat sebuah
remote 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 tepat
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:
• http://www.survive.com
• http://www.thebci.org
• http://www.globalcontinuity.com
• http://www.sungard.com
• http://www.gedisasterrecovery.com
Summary

• Kunci utama dari tugas DBA adalah develop plan untuk


meminimalkan kerusakan jika ada bencana
• Tujuan disaster plan adalah membuat aplikasi kembali
online dengan sesedikit mungkin loss dan interupsi
• Ada banyak komponen yang dibutuhkan 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 sangat
dibutuhkan untuk kelanjutan proses bisnis
• Membuat video backup data di sqlserver atau
oracle atau mysql.
• Format File :
Materi POKOK SUB POKOK BAHASAN DAFTAR PUSTAKA
BAHASAN
7 Application 1. Designing application for relational access Buku 1 Bab 12
Performance 2. Relational optimization
3. Additional optimization consideration
4. SQL coding and tuning for efficiency
8 Database 1. Database Security Basicx Buku 1 Bab 14
Security 2. Granting and Revoking Authority
3. Authenticatiion Roles and Groups
4. Others Database Security Mechanism
5. Auditing
6. External Security
9 Backup & 1. Preaparing for Problems Buku 1 Bab 15
Recovery 2. Image Copy Backups
3. Recovery
4. Alternatives to Backup and Recovery
10 Disaster Planning 1. The Need for Planning Buku 1 Bab 16
2. General Disaster Recovery Guidelines
3. Backing Up the Database for Database
Recovery
4. Disaster Prevention
11 Data and Storage 1. Storage Management Basics Buku 1 Bab 17
Management 2. Files and Data Sets
3. Space Management
4. Storage ptions
5. Planning for the Future
12 Data Movement Loading and Unloading Data Buku 1 Bab 18
and EXPORT and IMPORT
Distribution Bulk Data Movement
Distributed Database
13 Database Client/Server Computing Buku 1 Bab 20
Connectivity Databases, the Internet and the Web
14 DBA Tools 1. Types and Benefits of DBA Tools Buku 1 Bab 22 dan 23
DBA Rulues 2. Evaluating DBA Tools Vendors
3. The Rule
Terima kasih

Anda mungkin juga menyukai