PEMULIHAN BENCANA DI CLOUD COMPUTING

APA ITU DISASTER RECOVERY?

Yaitu persiapan dan pemulihan kita terhadap kegagalan, kesalahan, atau bencana yang
terjadi terhadap proses bisnis kita. Setiap peristiwa yang berdampak negatif pada
kelangsungan atau keuangan bisnis perusahaan bisa disebut bencana. Ini termasuk
kegagalan perangkat keras atau perangkat lunak, pemadaman jaringan, pemadaman listrik,
kerusakan fisik pada bangunan seperti api atau banjir, kesalahan manusia, atau lainnya
peristiwa penting.
Menurut AWS, “Pemulihan bencana adalah proses analisis dan perbaikan terus-menerus,
sebagai bisnis dan sistem berevolusi. Untuk setiap layanan bisnis, pelanggan perlu
menetapkan titik pemulihan dan waktu yang dapat diterima, dan kemudian buat solusi
Disaster Recovery yang tepat. ” Disaster Recovery di Cloud dapat mengurangi biaya secara
signifikan (hingga setengah biaya) dibandingkan dengan perusahaan yang mempertahankan
datanya sendiri yang berada di server pusat. Biaya-biaya ini termasuk pembelian dan
memelihara server dan pusat data, menyediakan konektivitas yang aman dan stabil dan
menjaga mereka tetap aman. Itu

KLASIFIKASI KERUSAKAN :
Negligible : Tidak ada biaya atau kerusakan yang signifikan
Minor : Kejadian yang tidak dapat diabaikan tanpa materi atau keuangan berdampak
pada bisnis
Major : Dampak satu atau lebih departemen dan dapat berdampak klien luar
Crisis : Memiliki dampak material atau keuangan yang besar padabisnis

WAKTU PEMULIHAN :
Interruption Window : Organisasi durasi waktu dapat menunggu antara titik kegagalan dan
kembalinya layanan
Service Delivery Objective (SDO) : Tingkat layanan di Alternate Mode
Maximum Tolerable Outage : Waktu maksimum dalam Mode Alternatif
PENGERTIAN :
Business Continuity : Menawarkan layanan penting jika terjadi gangguan
Alternate Process Mode : Layanan yang ditawarkan oleh sistem cadangan
Disaster Recovery Plan (DRP) : Bagaimana melakukan transisi ke Alternate Mode Proses
Restoration Plan : Bagaimana untuk kembali ke mode sistem reguler

KLASIFIKASI LAYANAN
Critical ($$$$) : Tidak dapat dilakukan secara manual. Toleransi untuk interupsi sangat
rendah
Vital ($$) : Dapat dilakukan secara manual untuk waktu yang sangat singkat
Sensitive ($) : Dapat dilakukan secara manual untuk jangka waktu tertentu, namun mungkin
lebih mahal dalam staf
Non Sensitive (¢) : Dapat dilakukan secara manual untuk perpanjangan jangka waktu
dengan sedikit biaya tambahan dan upaya pemulihan yang minimal

MENENTUKAN TINGKAT KRISIS DARI BISINIS PROSES

Recovery Point Objective (RPO)

Jumlah kehilangan data yang dapat diterima diukur dalam waktu. Misalnya, jika terjadi bencana
pada jam 12:00 siang (siang) dan RPO adalah satu jam, sistem harus memulihkan semua data yang
ada di sistem sebelum jam 11 pagi. Kehilangan data hanya akan berlangsung satu jam, antara jam
11:00 dan 12:00 siang (siang).

Orphan Data : Sebuah data yang telah hilang dan tidak dapat dikembalikan lagi.

Recovery Time Objective (RTO)

Waktu yang dibutuhkan setelah gangguan untuk memulihkan proses bisnis ke tingkat
layanannya, sebagaimana didefinisikan oleh perjanjian tingkat operasional (OLA). Misalnya,
jika terjadi bencana pada jam 12:00 PM (siang) dan RTO adalah delapan jam, proses DR
harus mengembalikan proses bisnis ke tingkat layanan yang dapat diterima sebelum jam
8:00 malam.
Perusahaan biasanya memutuskan RTO dan RPO yang dapat diterima berdasarkan pada
dampak keuangan terhadap bisnis ketika sistem tidak tersedia. Perusahaan menentukan
dampak keuangan dengan mempertimbangkan banyak faktor, seperti kehilangan bisnis dan
kerusakan reputasinya karena downtime dan kurangnya ketersediaan sistem.

Organisasi TI kemudian merencanakan solusi untuk menyediakan sistem yang hemat biaya
pemulihan berdasarkan RPO dalam timeline dan level layanan didirikan oleh RTO

TRADITIONAL DISASTER RECOVERY PRACTICES

Pendekatan tradisional terhadap DR melibatkan berbagai level di luar lokasi duplikasi data
dan infrastruktur. Layanan bisnis penting ditetapkan dan dipelihara pada infrastruktur ini
dan diuji berkala. Lokasi lingkungan pemulihan bencana dan sumber infrastruktur fisik harus
terpisah jarak yang signifikan untuk memastikan bahwa lingkungan pemulihan bencana
diisolasi dari kesalahan yang dapat berdampak pada situs sumber.
1. Fasilitas untuk membangun infrastruktur, termasuk daya dan pendinginan.
2. Keamanan untuk memastikan fisik perlindungan aset.
3. Kapasitas yang sesuai untuk skala lingkungan.
4. Dukungan untuk memperbaiki, mengganti, dan menyegarkan infrastruktur
5. Perjanjian kontrak dengan Internet penyedia layanan (ISP) untuk menyediakan
konektivitas internet yang dapat dipertahankanpemanfaatan bandwidth untuk
lingkungan di bawah beban penuh.
6. Infrastruktur jaringan seperti firewalls, router, switch, dan load balancers.
7. Kapasitas server cukup untuk menjalankan semua layanan misi-kritis, termasuk
peralatan penyimpanan untuk pendukungnya data, dan server untuk menjalankan
aplikasi dan layanan backend seperti pengguna otentikasi, Sistem Nama Domain
(DNS), Konfigurasi Host Dinamis Protokol (DHCP), pemantauan, dan mengingatkan.
 RAID – DATA MIRRORING

NETWORK RECOVERY
STRATEGI PEMULIHAN ALTERNATIF :
Hot Site : Terkonfigurasi secara penuh dan siap di jalankan dalam hitungan jam.
Warm Site : Siap untuk dijalankan dalam hitungan hari. Berupa komputer utama dengan
sedikit atau tanpa listrik, hanya berupa penyimpanan, jaringan, dan perlengkapan lainnya.
Cold Site : Siap untuk dijalankan dalam hitungan minggu. Berupa kabel listrik, AC
(pendingin), dan Lantai.
Duplicate or Redudant Info. Processing Facility : Menyiapkan Hot Site dengan
pengorganisasian
Reciprocal Agreement with another organization or division
Mobile Site : Terkonfigurasi secara penuh atau sebagian, siap dihubungkan dengan
gelombang mikro atau komunikasi satelit.

CONTOH SKENARIO DISASTER RECOVERY DENGAN AWS

Gambar berikut menunjukkan spektrum untuk empat skenario, diatur
oleh seberapa cepat sistem dapat tersedia bagi pengguna setelah acara DR.

• Untuk memulihkan data Anda jika terjadi bencana apa pun, Anda harus terlebih dahulu
memiliki data yang dicadangkan secara berkala dari sistem Anda ke AWS. Mencadangkan
data dapat dilakukan melalui berbagai mekanisme dan pilihan Anda yang didasarkan pada
RPO (Recovery Point Objective).
• Misalnya, jika Anda memiliki basis data yang sering berubah seperti misalnya pasar saham,
maka Anda akan membutuhkan RPO yang sangat tinggi. Namun jika Anda data kebanyakan
statis dengan frekuensi perubahan yang rendah, Anda dapat memilih
cadangan inkremental berkala.
REPLIKASI DATA
Ketika data direplikasi ke lokasi terpencil, faktor-faktor ini perlu dipertimbangkan:
 Jarak antar lokasi - Jarak yang lebih besar biasanya tunduk pada lebih banyak latensi
atau jitter.
 Bandwidth yang tersedia
 Kecepatan data yang dibutuhkan oleh aplikasi Anda - Tingkat data seharusnya lebih
rendah dari bandwidth yang tersedia.
 Ada dua pendekatan utama untuk mereplikasi data: synchronous dan asynchronous.

SYNCHRONOUS REPLICATION
Data diperbarui secara atomis di beberapa lokasi. Ini menempatkan
ketergantungan pada kinerja jaringan dan ketersediaan. Di AWS,
Zona Ketersediaan di suatu wilayah terhubung dengan baik, tetapi secara fisik
dipisahkan. Misalnya, ketika digunakan dalam mode Multi-AZ, Amazon
RDS menggunakan replikasi sinkron untuk menggandakan data dalam hitungan detik
Zona Ketersediaan. Ini memastikan bahwa data tidak hilang jika yang utama
Zona Ketersediaan menjadi tidak tersedia.

ASYNCHRONOUS REPLICATION
Data tidak diperbarui secara atomis di beberapa lokasi. ini
ditransfer sebagai kinerja jaringan dan ketersediaan memungkinkan, dan
aplikasi terus menulis data yang mungkin tidak sepenuhnya
direplikasi.
Banyak sistem basis data mendukung replikasi data asynchronous. Data replika dapat
ditemukan dari jarak jauh, dan replikanya tidak harus sepenuhnya disinkronkan dengan
server basis data primer. Ini dapat diterima di banyak skenario, misalnya, sebagai sumber
cadangan atau kasus penggunaan pelaporan / baca-saja. Di Selain sistem basis data, ini juga
dapat diperluas ke sistem file jaringan dan volume data.
DISRUPTION Vs. RECOVERY COST