10 Kesalahan Yang Harus Dihindari Dalam Proses Perencanaan Disaster Recovery

disaster recovery

Di awal tahun baru, banyak team IT mengambil langkah untuk mencegah terjadinya gangguan. Singkatnya, mereka memutuskan untuk mulai serius dalam melindungi data dan perencanaan Disaster Recovery (DR) untuk operasional bisnis mereka.

Mengapa proses perencanaan Disaster Recovery bisa sangat sulit ?

Jika dilakukan secara tepat, perencanaan Disaster Recovery adalah tugas yang kompleks dan memakan waktu lama, inilah yang menyebabkan mengapa berdasarkan survey beberapa tahun belakangan ini terjadi penurunan jumlah perusahaan yang mempunyai perencanaan Disaster Recovery. Dalam laporan tahunan Pricewaterhhouse Cooper, perusahaan dengan perencanaan Disaster Recovery turun sekitar 50% sedangkan tahun sebelumnya hanya turun 39%. Dari perusahaan yang memiliki Disaster Recovery, yang benar-benar melakukan test rencana Disaster Recovery mereka hanya sebagian kecil saja.

Biaya juga menjadi salah satu rintangan. Para manager selalu berpikir cara untuk menginvestasikan uang sehingga mereka dapat menghasilkan uang lebih banyak untuk perusahaan. Dengan kondisi ekonomi yang tidak menentu saat ini, pilihan normal untuk lebih fokus membelanjakan uang pada hal yang berpotensi menghasilkan keuntungan.

Disaster Recovery adalah investasi

Sangat umum dalam suatu perusahaan untuk mengalokasikan budget dengan efisien, dengan adanya beberapa kemampuan teknologi seperti virtualisasi server, data deduplication, cloud dan lain-lain, kebutuhan resource untuk proses perencanaan Disaster Recovery mungkin dapat berkurang.

Dalam beberapa tahun terakhir, vendor-vendor sudah berusaha untuk meyakinkan pelanggannya bahwa kelebihan dari teknologi-teknologi tersebut sudah berkembang atau meningkatkan perlindungan terhadap data dan operasional. Vendor virtualisasi server bisa saja berkata “High availability mengalahkan Disaster Recovery”. Vendor peralatan  deduplikasi data berkata “Tape sudah kuno, beralihlah ke yang lebih baik”. Atau “Cloud bisa memberikan Tier 1 perlindungan data,” pengakuan dari salah satu cloud provider. Pernyataan-pernyataan ini menyarankan bahwa perencanaan Disaster Recovery sudah kuno, digantikan dengan kemampuan yang lebih handal dan kemampuan high availability yang sudah built in di dalam produk baru.

Tetapi, betulkah pernyataan diatas ? Mungkin perlu penjelasan lebih mengenai hal ini sebagai berikut,

High availability tidak sama dengan Disaster Recovery. Mungkin kesalahan pertama dan paling penting untuk dihindari ketika membangun Disaster Recovery adalah terlalu mempercayai vendor yang mengatakan hal tersebut tidak ada hubungannya dengan perencanaan Disaster Recovery. Pada kenyataanya High Availability selalu menjadi salah satu alternative untuk mencapai pemulihan dari bencana.

  • Jangan mengimplementasikan semua aplikasi dengan hanya satu pendekatan Disaster Recovery. Kesalahan umum yang kedua dalam perencanaan Disaster Recovery adalah mencoba untuk mengimplementasikan strategi one-size-fits-all dalam melindungi data. Tidak semua data butuh replikasi disk-to-disk jarak jauh, disk-to-disk mirroring, replikasi data secara terus menerus atau metode lainnya. Terkadang banyak data yang cukup efektif dengan hanya backup dan restore dari media backup.
  • Jangan backup semuanya. Berharap semua data perlu dimasukkan ke dalam proses backup adalah kesalahan lain. Pada kenyataannya banyak data, mungkin 40% sampai 70% hanya terdiri dari data yang tidak pernah berubah dan tidak pernah diakses yang bisa dipindahkan ke dalam media arsip.
  • Jangan abaikan data yang tidak disimpan secara terpusat. Data kritikal mungkin tersimpan di kantor cabang, di PC, di laptop dan mungkin di smartphone. Dalam sebuah survey, 46% dan 211 perusahaan di Eropa mengakui tidak pernah melakukan backup data pada perangkat user. Sangat memungkinkan untuk menggunakan layanan backup di cloud untuk melakukan backup data perangkat-perangkat user.
  • Jangan sampai salah mengatur data dan infrastruktur. Kesalahan lain dalam perencanaan Disaster Recovery adalah dengan mengabaikan sumber masalah dari bencana, yang mana adalah kurangnya kemampuan mengatur data dan infrastruktur. Kurangnya kemampuan mengatur data, atau gagal untuk mengklasifikasikan data yang menjadi prioritas untuk dipulihkan, menyebabkan tingginya biaya dalah proses perencanaan Disaster Recovery. Sedangkan dalam infrastruktur, kita tidak bisa melindungi infrastruktur yang tidak bisa kita lihat. Kegagalan untuk membangun pemantauan infrastruktur dan kemampuan reporting berarti kita tidak dapat merespon secara aktif terhadap kegagalan perangkat. Hal ini bisa diperbaiki dengan mengimplementasikan alat pengklasifikasian data untuk bisa mengatur data dengan benar dan menggunakan software pengaturan infrastruktur.
  • Jangan menduplikasi konfigurasi perangkat di lokasi Disaster Recovery. Kesalahan ini terjadi ketika perusahaan melakukan rencana Disaster Recovery dengan mengganti semua perangkat di lokasi Disaster Recovery. Mengingat hanya sebagian aplikasi dan data yang dilindungi, kita tidak perlu membuat desain di lokasi Disaster Recovery yang sama persis dengan di lokasi data center utama. Dengan konfigurasi perangkat yang minimum dapat mengurangi biaya Disaster Recovery dan menyederhanakan pengetesan.
  • Jangan lupa untuk membentengi koneksi WAN. Terlalu yakin pada koneksi WAN dan meremehkan dampak negative yang dapat terjadi dalam rentang waktu pemulihan juga menjadi kesalahan dalam merencanakan Disaster Recovery. WAN adalah layanan yang harus dikonfigur dan diukur secara tepat, dan harus dapat bekerja secara maksimal dalam memfasilitasi pemulihan data atau untuk akses secara remote.
  • Jangan terlalu percaya pada cloud provider. Jika kita berencana untuk menjalankan aplikasi di infrastruktur cloud provider, atau menjadikannya sebagai “hot site”, pastikan kita mengunjungi fasilitas data center dari cloud provider tersebut. Pastikan bahwa apa yang ditawarkan sesuai dan memiliki fasilitas paling tidak Rated-3 data center.
  • Jangan biarkan aplikasi menggagalkan Disaster Recovery. Supaya kemampuan bisnis yang berkelanjutan bisa terwujud sepenuhnya, ketahanan dan kemampuan pemulihan harus dibangun ke dalam aplikasi dan infrastruktur dari awal.
  • Jangan lupa untuk “follow the money”. Managemen memegang biaya, jadi bisa menjadi kesalahan besar jika tidak membuat rencana Disaster Recovery berdasarkan nilai bisnis dan hanya fokus pada teknikal semata. Kita harus bisa menunjukkan ke management bahwa kita melakukan semua kemungkinan pengeluaran biaya yang relevan untuk menjaga kelangsungan bisnis tanpa mengorbankan efektifitas dari rencana Disaster Recovery.

Perlu dicatat, pengeluaran terbesar dari rencana Disaster Recovery bukanlah biaya perlindungan data, reinstalasi aplikasi atau re-routing jaringan, tetapi adalah biaya pengetesan yang berkepanjangan. Jadi, buatlah Disaster Recovery yang dapat ditest sebagai bagian dari operasional sehari-hari, meringankan beban pada jadwal test resmi, dimana bisa menjadi uji coba apakah data dapat dipulihkan atau tidak.

Untuk Layanan Disaster Recovery dari Datacomm Cloud Business bisa klik di tautan berikut : klik disini atau hubungi cloudciti@datacomm.co.id

Source : Disaster Recovery in the age of Cloud, ComputerWeekly.com 

  • 17
    Shares

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*