Disaster Recovery Plan

Teknologi Informasi

1
 WTC 2001

2
 Jakarta 2007

3
 Japan Tsunami 2014

4
 Ilustrasi
 Ketika banjir besar di Jakarta Pebruari 2007, sentral telepon
Telkom di Semanggi sempat tenggelam dan tidak dapat
digunakan selama beberapa hari.
 Bagaimana jika seandainya perusahaan memiliki server yang
di-hosting di Telkom Semanggi? atau jaringan data antar
kantor hanya mengandalkan jaringan dari Telkom yang
kebetulan melewati sentral Semanggi?
 Berapa besar kerugian perusahaan karena tidak dapat
menjalankan bisnisnya? atau Berapa besar kerugian karena
perusahaan tidak dapat melakukan konsolidasi dengan
cabang?
5
  Untuk mengurangi kerugian yang diakibatkan oleh bencana
perlu disusun sebuah rencana pemulihan dari bencana atau
lebih dikenal dengan Disaster Recovery Plan(DRP).
 Dalam scope kecil, bagian TI dapat menyiapkan rencana DRP
untuk layanan TI saja. Misalnya, kesiapan server backup,
ketersediaan telepon cadangan jika jalur komunikasi utama
mati.
 Dalam skala yang lebih besar perusahaan dapat menyiapkan
DRP secara menyeluruh. Mulai dari ketersediaan personel,
ruang kerja pengganti, hingga prosedur manual yang akan
dikerjakan jika sistem otomatis tidak dapat berjalan.
6
 Latar Belakang
 Adanya ancaman dari lingkungan alam seperti bencana alam,
ataupun lingkungan sosial politik seperti kerusuhan, atau
musibah lainnya seperti kebakaran, kerusakan layanan listrik
dan lain-lain telah menempatkan informasi yang selama ini
dititipkan pada infrastruktur teknologi informasi dalam posisi
yang rawan.
 Paradigma baru seperti paperless office atau office automation
yang menempatkan informasi dalam bentuk digital sebagai
pengganti informasi fisik berupa kertas atau dokumen juga
turut menambah tingginya resiko kehilangan informasi akibat
kasus bencana.

7
  Ada baiknya perusahaan atau organisasi mulai memikirkan
antisipasi yang sungguh-sungguh untuk menyelamatkan
informasi yang sangat berguna bagi kelangsungan bisnis,
terutama setelah bencana terjadi.
 Business continuity atau keberlangsungan bisnis setelah satu
bencana juga turut dijadikan salah satu parameter penilaian
kematangan manajemen dalam mengelola sumber daya yang
dimiliki di satu organisasi.
 Salahsatu elemen penting pada business continuity yaitu disaster
recovery plan(DRP), atau penyusunan rencana pemulihan
setelah terjadinya bencana.
8
  Wujud DRP secara sederhana hanya berupa dokumen yang
berisi response plan (rencana tanggap) terhadap bencana.
Tetapi, proses penyusunan dokumen tersebut tidaklah mudah
dan memerlukan pengetahuan yang mendalam mengenai
berbagai resiko yang dihadapi perusahaan / organisasi.
 Ruang lingkup DRP dapat dibuat melebar meliputi
infrastruktur, personel dan prosedur

9
 Sasaran
 Memahami konsep Business Continuity Planning
(perencanaan kontinuitas layanan TI).
 Memahami strategi pemulihan layanan TI dalam Disaster
Recovery Plan (rencana penanggulangan bencana).
 Mampu menyusun dokumen DRP

10
 Pendahuluan
 Disaster recovery plan (DRP) adalah rencana yang disiapkan organisasi
untuk membantu organisasi pulih setelah terjadi musibah atau
bencana.
 Penyebab musibah bervariasi, mulai dari fenomena alam hingga
akibat perbuatan manusia, baik yang disengaja maupun tidak
disengaja.
 Pada bidang teknologi informasi, penyebab dapat lebih spesifik
misalnya kegagalan infrastruktur , kekeliruan operator, hingga
serangan virus.
 Tingginya kebergantungan organisasi pada infrastruktur teknologi
informasi menyebabkan perlunya dipertimbangkan DRP di bidang
infrastruktur jaringan komputer.
11
 Disaster
 Disaster (bencana) didefiniskan sebagai kejadian yang waktu
terjadinya tidak dapat diprediksi dan bersifat sangat merusak.
Pengertian ini mengidentifikasikan sebuah kejadian yang
memiliki empat faktor utama, yaitu :
 tiba-tiba
 tidak diharapkan
 bersifat sangat merusak
 kurang perencanaan

12
  Dalam dunia IT beberapa penyebab bencana dapat kita
rumuskan sebagai berikut :
 Kebakaran
 Banjir
 Gempa bumi dan tanah longsor
 Perubahan suhu dan kelembaban yang ekstrim
 Virus Komputer
 Kecelakaan pesawat, kendaraan dll

13
  Hal-hal yang perlu dibuat dalam perencanaan penanggulangan
bencana ini adalah :
 Prosedur penyimpanan dan alternative lain
 Pihak pengelola apabila terjadi bencana
 Langkah-langkah yang sistematis dalam beckup data
 Ukuran tercapainya kesusksesan dalam penanggulangan bencana
 Prosedur pemulihan

14
  Sebuah dokumen DRP idealnya memuat elemen-elemen
berikut :
1. Prosedur deklarasi keadaan dalam bencana
2. Nama dan alamat yang dapat dihubungi dalam keadaan
darurat
3. Tim tanggap darurat
4. Prosedur penilaian tingkat kerusakan
5. Prosedur recovery dan restart sistem
6. Transisi ke kondisi normal
7. Tim recovery

15
  Saat ini sudah diterbitkan pedoman standar khusus sebagai
pedoman penyusunan dan evaluasi DRP, khusus untuk
operasional dan manajemen teknologi informasi, yaitu
ISO/IEC 24762:2008 yang menyediakan pedoman
penyusunan DRP untuk teknologi informasi dan komunikasi.
 Pedoman ini merupakan bagian dari dari manajemen business
continuity, dan diterapkan baik bagi penyedia layanan
teknologi informasi dan komunikasi internal (information
communication technology-ICT) maupun eksternal (outsourced),
dan meliputi fasilitas fisik dan layanan

16
  Spesifikasi ISO/IEC 24762:2008 meliputi :
1. Kebutuhan untuk menerapkan, mengoperasikan, memonitor
dan memelihara fasilitas dan layanan disaster recovery untuk
ICT.
2. Kemampuan yang harus dimiliki oleh layanan disaster
recovery ICT eksternal dan pedoman praktis yang harus
dijalankan untuk menyediakan lingkungan operasional
minimal yang aman dan memfasilitasi usaha organisasi untuk
melakukan recovery.
3. Pedoman memilih situs recovery dan pedoman untuk
peningkatan layanan disaster recovery ICT

17
 Business Continuity Plan (BCP)
 Kontinuitas layanan TI perusahaan harus dijaga dari gangguan:
 Bencana alam
 Ulah manusia (disengaja atau tidak)
 Kerusakan.

 Dibutuhkan perencanaan untuk mencegah, menangani, dan

menanggulangi gangguan
 Policy dan prosedur penanganan bencana.
 Strategi pemulihan layanan.
 Strategi minimasi dampak bencana.

18
 Fase Penanganan Bencana
Pemulihan
Layanan Vital

Evaluasi Restorasi
insiden Notifikasi Kerusakan Layanan

Perbaikan
Kerusakan

 Tidak semua insiden berstatus bencana

 Ditentukan oleh hasil evaluasi.
 Pemulihan layanan menggunakan fasilitas alternatif/cadangan atau
secara manual.
 Perbaikan dapat berupa pemindahan lokasi layanan.

19
 Tahap Penyusunan DRP
 Penyusunan DRP untuk teknologi informasi di suatu
organisasi, secara umum mengacu pada langkah-langkah
pengelolaan proyek pada umumnya, yaitu : inisialisasi,
eksekusi dan evaluasi.
 Pada tahap inisialisasi, diperlukan dukungan manajemen dan
kontrak proyek yang jelas antara manajemen yang berwenang
dengan pihak yang akan menyusun DRP. Kontrak proyek ini
diperlukan untuk menjaga konsistensi komitmen semua pihak
yang terlibat.
 Pada tahap eksekusi, dilakukan sekumpulan aktivitas yang
keluaran akhirnya diharapkan dapat menghasilkan dokumen
DRP yang sesuai dengan kondisi dan kebutuhan organisasi
20
 Aktivitas Penyusunan DRP
 Melakukan business impact analysis, yang meliputi penentuan
maximum tolerable downtime (MTD), penentuan recovery objective yang
meliputi recovery time objective (RTO), dan recovery point objective
(RPO), membuat analisis resiko, menyajikan semua hasil analisis
dalam satu laporan terintegrasi.
 Mendefinisikan prosedur recovery, yaitu membuat DRP untuk setiap
proses dengan cara memetakan proses dengan infrastruktur,
membuat DRP dalam bentuk tertulis, dan menguji DRP tersebut.
 Evaluasi dan monitoring meliputi proses pengujian dan kaji ulang
secara periodik misalnya setiap bulan setiap 4 bulan atau tahunan.
Tahap lainnya yaitu memberikan pelatihan yang memadai bagi
semua tim DRP yang terlibat, khususnya tim recovery.
21
 Tahapan BC Planning
 Tahapan perencanaan:
1. Penyusunan policy rencana darurat.
2. Analisa dampak bisnis (dari gangguan).
3. Identifikasi mekanisme pencegahan.
4. Pengembangan strategi pemulihan layanan.
5. Penyusunan prosedur penanganan situasi darurat.
6. Uji coba, pelatihan, dan latihan prosedur darurat.
7. Re-evaluasi rencana penanganan situasi darurat.

22
 Proses Pengembangan BCP
1. Penyusunan Policy
 Identifikasi peraturan perundangan yang mempersyaratkan
perencanaan situasi darurat.
 Penyusunan kebijakan penanganan situasi darurat.
 Mendapatkan persetujuan.
 Mensosialisasikan policy.

23
 Proses Pengembangan BCP
2. Analisa Dampak terhadap bisnis
 Identifikasi sumber daya TI vital.
 Identifikasi dampak gangguan dan batas lamanya gangguan.
 Menyusun prioritas pemulihan sumber daya TI.
3. Identifikasi mekanisme pencegahan
 Implementasi mekanisme pencegahan.
 Pemeliharaan mekanisme pencegahan.

24
 Proses Pengembangan BCP
4. Pengembangan strategi pemulihan layanan
 Identifikasi metoda pemulihan.
 Integrasi metoda dalam rancangan arsitektur TI.
5. Pengembangan rencana penanganan situasi darurat
 Dokumentasi strategi pemulihan layanan.

25
 Proses Pengembangan BCP
6. Uji-coba, pelatihan, dan latihan prosedur darurat
 Pengembangan target uji-coba dan kriteria keberhasilan.
 Perbaikan berdasarkan pengalaman/ permasalahan.
 Pelatihan personil.
7. Reevaluasi rencana penanggulangan situasi darurat
 Review dan update.

26
 BCP Policy
 Terutama berisi:
 Peran dan tanggung-jawab dalam organisasi penanggulangan
bencana
 Kepala: koordinator penanggulangan bencana.
 Ruang lingkup: bagian dalam organisasi dan kategori
komponen infrastruktur.
 Kebutuhan sumber daya.
 Kebutuhan pelatihan personil.
 Jadwal uji-coba dan latihan.
 Jadwal reevaluasi rencana penanggulang-an bencana.

27
 Klasifikasi Insiden
 Policy juga mengatur insiden apa yang masuk kategori bencana
(mengaktifkan BCP).
 Menerapkan klasifikasi insiden:
1. Negligible (biasa): tidak menyebabkan kerusakan (listrik mati,
aplikasi crash, dsb.)
2. Minor (kecil): kerusakan yang tidak berdampak kerugian.
3. Major (besar): kerusakan yang berdampak kerugian pada bisnis.
4. Crisis (krisis): kerusakan yang berdampak kerugian besar,
mengancam kelangsungan bisnis, dan dapat mengganggu sistem
lain (pihak ketiga).

28
 Klasifikasi Insiden
 Kategori insiden biasanya dikaitkan dengan lamanya gangguan
(mulai dari kejadian sampai resolusi):

Kategori Level Lama gangguan Tindakan

Krisis 7 24 jam Aktifkan BCP
6 12 jam Aktifkan BCP
Mayor 5 6 jam Antisipasi BCP
4 4 jam Perbaiki/restorasi
3 2 jam Perbaiki
Minor 2 1 jam Perbaiki
1 0.5 jam Perbaiki
Biasa 0 Catat (log) & monitor

29
 Analisa Dampak Bencana
 Langkah I: Identifikasi sumber daya TI vital:
 Melibatkan berbagai pihak (user, pengelola proses bisnis,
pengelola aplikasi, dsb.), tahapan:
 Ranking proses bisnis berdasarkan nilai strategisnya.
 Identifikasi komponen infrastruktur yang mendukung proses-
proses bisnis strategis (server, akses ke WAN, dsb.)

30
 Analisa Dampak Bencana
 Langkah II: Klasifikasi layanan TI berdasarkan toleransi
terhadap lamanya gangguan
1) Critical: Layanan tidak dapat dijalankan tanpa fasilitas yang
identik, apalagi manual. Biaya interupsi sangat mahal.
2) Vital: Layanan dapat diganti dengan proses manual tapi
tidak bisa lama (max. 5 hari).
3) Sensitive: Layanan dapat diganti dengan proses manual
dengan biaya yang tidak terlalu tinggi (tambahan staf, dsb.)
4) Non-sensitive: Layanan dapat dihentikan dengan kerugian
kecil.

31
 Analisa Dampak Bencana
 Gangguan pada layanan tidak vital dapat berdampak pada
layanan vital.
 Toleransi terhadap lamanya gangguan layanan TI dipetakan ke
toleransi komponen infrastruktur pendukungnya
 Langkah III: Menyusun prioritas (urutan) dalam
pemulihan/perbaikan komponen infrastruktur berdasarkan
toleransi komponen-komponen infrastruktur vital.

32
 Mekanisme Pencegahan
 Mekanisme untuk mencegah atau meminimasi gangguan, misal
penggunaan:
 UPS (uninterrupted power supply).
 Generator set.
 AC dengan kapasitas berlebih.
 Fire hydrant atau suppressor.
 Detektor asap/api.
 Sensor kelembapan/air.
 Penyimpanan media tahan api dan kedap air.
 Tombol emergency shut down.
 Tempat penyimpanan media off-site.
 Backup rutin dan sering.

33
 Biaya Pencegahan
 Tingkat pencegahan yang ideal: minimasi (biaya pencegahan &
penanggulangan) + (kerugian akibat gangguan).
Biaya

minimum

Biaya pemulihan
/pencegahan

Waktu
34
 Contoh Biaya vs. Waktu
 RPO (recovery point objective): target titik waktu dimana
transaksi-transaksi terbaru dapat diselamatkan.
 RTO (recovery time objective): target waktu pemulihan layanan
dari gangguan.

gangguan
RPO RTO

waktu
tape mirroring 1 jam 24 jam
backup
disk 2 jam
backup

35
 Strategi Pemulihan Layanan
 Penjadwalan backup data dan file penting:
 Misal metoda child-parent-grand parent (harian: 7 versi,
mingguan: 4 versi, bulanan: 12 versi, tahunan: 1 versi).
 Penyimpanan backup di lokasi terpisah, kriteria
 Terpisah secara geografis (bebas bencana)
 Memiliki fasilitas keamanan (access control)
 Memiliki fasilitas penyimpanan bebas gangguan
 Biaya dan waktu untuk mengakses dapat diterima.

36
 Strategi Pemulihan Layanan
 Pemulihan layanan di lokasi alternatif/ cadangan
 Mirror (dual) site:
 Fasilitas identik dengan replikasi data real-time. Siap mengambil alih setiap
saat. Biasanya dimiliki dan dioperasikan oleh perusahaan.
 Hot site:
 Fasilitas cadangan yang dilengkapi dengan hardware, infrastruktur, dan
staf. Proses migrasi sistem dimulai begitu BCP diaktifkan.

37
 Strategi Pemulihan Layanan
 Warm site:
 Beberapa sarana sudah tersedia (biasanya merupakan lokasi
layanan lain). Perlu penyiapan untuk mengambil alih layanan.
 Cold site:
 Hanya fasilitas bangunan dengan infrastruktur dasar (listrik, AC,
dsb.) Perlu instalasi peralatan untuk mengambil alih layanan.
 Mobile site:
 Fasilitas portable yang dapat di-setup dimana saja. Biasanya
dimiliki pihak ketiga.

38
 Situs Alternatif
 Karakteristik:

Site Cost Hardware Communi- Setup time Location

cations
Cold site Low None None Long Fixed
Warm Medium Partial Partial/Full Medium Fixed
site
Hot site Medium/ Full Full Short Fixed
High
Mobile High Dependent Dependent Dependent Not Fixed
site
Mirror High Full Full None Fixed
site

39
 Strategi Pemulihan Layanan
 Strategi pengadaan perlengkapan pengganti
 Kontrak perjanjian (SLA) dengan vendor.
 Termasuk layanan prioritas dalam keadaan darurat.
 Beli dan simpan cadangan di gudang.
 Investasi besar dan ada resiko teknologi kadaluwarsa.
 Kontrak perjanjian dengan pihak ketiga untuk
meminjam fasilitas.
 Fasilitas perusahaan lain dengan teknologi serupa atau compatible.

40
 Tabulasi Biaya

Biaya (juta Rp)

Strategi Vendor Hardware Software Travel/ Labor/ Testing Supply
Shipping Contractor
Lokasi Cold site
Cadangan Warm site
Hot site
Mobile site
Mirror site
Penyimpan- Komersial
an Offsite Internal
Peralatan SLA
Cadangan Cadangan
Pinjam

41
 Peran dan Tanggung-jawab
 Daftar kontak resmi:

42
 Dokumen BCP

43
 Contoh

44
 Topologi Jaringan

45
 Responden
 Pada penelitian ini juga dilakukan semacam survey awal
untuk melihat perilaku pengguna jaringan komputer di
Universitas Widyatama, untuk menilai tingkat
kebergantungan pengguna dan pelaksanaan proses bisnis
terhadap infrastruktur jaringan komputer.
 Survey disebarkan kepada sekitar 60 responden, meliputi 30
mahasiswa, 15 dosen dan 15 pegawai. Jumlah sample
responden yang kecil dipilih karena penelitian ini baru
bersifat studi awal yang akan digunakan untuk pengembangan
penelitian yang lebih spesifik lagi

46
47
48
49
 Kesimpulan
 Perlu dilakukan inisiatif penyusunan DRP untuk infrastruktur
jaringan komputer mengingat banyaknya aktivitas yang
bergantung pada layanan jaringan komputer dan rendahnya
tingkat kesadaran pengguna terhadap pentingnya proses
pengamanan data milik sendiri ataupun data-data terkait
pekerjaan masing-masing.
 Kelayakan diperlukannya DRP didukung oleh fakta bahwa
secara teknis, saat ini implementasi jaringan komputer
universitas juga belum mengadopsi kebutuhan ke arah
tersebut. Hal ini dapat dilihat dari fakta bahwa semua server
penting disimpan pada satu ruangan dan tidak ada mekanisme
backup dan recovery pada setiap server tersebut.
50