Jika topik ini terdengar membingungkan, kami mengerti. Dengan saran para ahli kami, kami berharap dapat meredakan kekhawatiran Anda – sambil juga menyampaikan beberapa pertimbangan penting untuk organisasi Anda sebelum atau sesudah pergi multi-awan . Perencanaan untuk pemulihan bencana adalah titik kebingungan umum bagi perusahaan yang menggunakan komputasi awan, terutama ketika melibatkan banyak penyedia awan.

Cukup melelahkan untuk memastikan perlindungan data dan pemulihan bencana (DR) saat semua data berada di lokasi. Namun saat ini banyak perusahaan memiliki data di tempat serta dengan beberapa penyedia cloud, strategi hibrida yang mungkin masuk akal secara bisnis tetapi dapat menciptakan tantangan bagi mereka yang bertugas dengan perlindungan data. Sebelum kita mempelajari detailnya, mari kita definisikan istilah kuncinya.

Apa itu multi-cloud?

Multi-cloud adalah pemanfaatan dua atau lebih penyedia cloud untuk melayani layanan dan infrastruktur TI organisasi. Pendekatan multi-cloud biasanya terdiri dari kombinasi penyedia cloud publik utama, yaitu Amazon Web Services (AWS), Google Cloud Platform (GCP), dan Microsoft Azure.

Organisasi memilih layanan terbaik dari setiap penyedia cloud berdasarkan biaya, persyaratan teknis, ketersediaan geografis, dan faktor lainnya. Ini mungkin berarti bahwa perusahaan menggunakan Google Cloud untuk pengembangan/pengujian, saat menggunakan AWS untuk pemulihan bencana, dan Microsoft Azure untuk memproses data analitik bisnis.

Multi-cloud berbeda dari hybrid cloud yang mengacu pada lingkungan komputasi yang menggabungkan infrastruktur lokal, layanan cloud pribadi, dan cloud publik.

Siapa yang menggunakan banyak awan?

• Industri yang diatur – Banyak organisasi menjalankan operasi bisnis yang berbeda di lingkungan cloud yang berbeda. Ini mungkin merupakan strategi yang disengaja untuk mengoptimalkan lingkungan TI mereka berdasarkan kekuatan masing-masing penyedia cloud atau hanya produk dari organisasi TI yang terdesentralisasi.

• Media dan Hiburan – Lanskap media dan hiburan saat ini semakin terdiri dari studio yang relatif kecil dan khusus yang memenuhi kebutuhan produksi konten yang membengkak dari para pemain terbesar, seperti Netflix dan Hulu. Solusi multi-cloud memungkinkan tim-tim ini untuk bekerja sama dalam proyek yang sama, mengakses alat produksi pilihan mereka dari berbagai cloud publik, dan menyederhanakan persetujuan tanpa penundaan terkait dengan pemindahan file media besar dari satu situs ke situs lainnya.

• Transportasi dan Mengemudi Otonom – Proyek mobil yang terhubung dan mengemudi otonom menghasilkan sejumlah besar data dari berbagai sensor. Produsen mobil, agen transportasi umum, dan perusahaan rideshare termasuk di antara mereka yang termotivasi untuk memanfaatkan inovasi multi-cloud, memadukan aksesibilitas data di beberapa cloud tanpa risiko biaya keluar yang signifikan dan transfer yang lambat, sambil mempertahankan kebebasan untuk memanfaatkan optimal layanan cloud publik untuk setiap proyek.

• Sektor Energi – Adopsi multi-cloud dapat membantu menurunkan biaya signifikan yang terkait dengan pencarian dan pengeboran sumber daya.Insinyur dan ilmuwan data dapat menggunakan analitik pembelajaran mesin (ML) untuk mengidentifikasi tempat-tempat yang membutuhkan lebih banyak sumber daya untuk prospek minyak, untuk mengukur risiko lingkungan dari proyek-proyek baru, dan untuk meningkatkan keselamatan.

Poin nyeri pemulihan bencana multi-cloud:

• Tidak membaca sebelum Anda menandatangani.Pelanggan mungkin menghadapi masalah jika mereka gagal membaca cetakan kecil dalam perjanjian cloud mereka. Penyedia cloud bertanggung jawab atas infrastruktur komputernya, tetapi pelanggan bertanggung jawab untuk melindungi aplikasi dan data mereka. Ada banyak alasan untuk waktu henti aplikasi yang tidak tercakup dalam SLA cloud. Beban kerja penting bisnis memerlukan ketersediaan tinggi dan perangkat lunak perlindungan pemulihan bencana juga.

• Mengembangkan kebijakan proteksi terpusat.Kebijakan perlindungan terpusat harus dibuat untuk mencakup semua data, di mana pun ia tinggal. Setiap penyedia cloud memiliki cara unik untuk mengakses, membuat, memindahkan, dan menyimpan data, dengan tingkat penyimpanan yang berbeda. Mungkin rumit untuk membuat rencana pemulihan bencana yang mencakup data di berbagai awan.

• Pelaporan.Hal ini penting untuk memastikan perlindungan data sesuai dengan perjanjian tingkat layanan yang mengaturnya. Mengingat seberapa cepat pengguna dapat meningkatkan sumber daya cloud, mungkin sulit untuk memastikan Anda melindungi setiap sumber daya dengan tepat dan mengidentifikasi semua data yang perlu dimasukkan ke dalam rencana DR Anda.

• Uji rencana DR Anda.Pelanggan harus sepenuhnya menyaring dan menguji strategi DR mereka. Strategi multi cloud menambah kebutuhan akan pengujian. Beberapa penyedia mungkin membebankan biaya kepada pelanggan untuk pengujian, yang memperkuat kebutuhan untuk membaca cetakan kecil kontrak.

• Perangkat keterampilan sumber daya . Menemukan seorang ahli dalam satu cloud bisa jadi menantang; dengan multi-cloud, Anda perlu menemukan keahlian di setiap cloud, atau individu langka yang memiliki signifikansi di banyak cloud.

Mengatasi tantangan DR multi-cloud

Memenuhi tantangan ini mengharuskan perusahaan untuk mengembangkan perlindungan data dan strategi pemulihan yang mencakup banyak masalah. Coba tanyakan pada diri Anda pertanyaan strategis berikut:

• Sudahkah Anda menentukan tingkat kekritisan untuk semua aplikasi dan data? Berapa banyak uang yang akan dikeluarkan beberapa menit untuk aplikasi penting yang membebani organisasi Anda dalam produktivitas pengguna akhir, kepuasan pelanggan, dan tenaga kerja TI?
• Apakah perlindungan dan pemulihan data akan ditangani oleh IT atau pemilik dan pembuat aplikasi dalam model layanan mandiri?
• Apakah Anda merencanakan pengoptimalan data, menggunakan berbagai opsi berbasis cloud dan lokal?
• Bagaimana Anda berencana untuk memulihkan data? Memulihkan data ke mesin virtual berbasis cloud atau menggunakan gambar cadangan sebagai sumber pemulihan?

Dapatkan solusi DR multi-cloud yang tepat

Kunci terbesar untuk sukses dalam perlindungan dan pemulihan data dalam skenario multi-cloud adalah memastikan Anda memiliki visibilitas ke semua data Anda, tidak peduli bagaimana data itu disimpan. Alat dari perusahaan memungkinkan Anda untuk menentukan data dan aplikasi mana yang harus dipulihkan dalam skenario bencana dan bagaimana melakukannya – baik dari gambar cadangan atau dengan memindahkan data ke VM yang baru dibuat di cloud, misalnya.

Alat ini akan membantu Anda mengatur skenario pemulihan dan, yang penting, mengujinya. Jika alat ini terintegrasi dengan baik dengan alat pencadangan data Anda, alat ini juga memungkinkan Anda untuk menggunakan cadangan sebagai sumber data pemulihan, bahkan jika data disimpan di lokasi yang berbeda – seperti beberapa awan. Webinar SIOS terbaru kami membahas hal yang sama; jam tangan itu disini jika Anda tertarik.Penjaga Data SIOS memungkinkan Anda menjalankan aplikasi penting bisnis Anda dalam lingkungan cloud yang fleksibel dan skalabel, seperti Layanan Web Amazon (AWS) , Biru langit , dan Google Cloud Platform tanpa mengorbankan kinerja, ketersediaan tinggi atau perlindungan bencana. SIOS DataKeeper tersedia di Pasar AWS dan satu-satunya perangkat lunak ketersediaan tinggi bersertifikat Azure untuk WSFC yang ditawarkan di Pasar Azure.

Selain 99,99% waktu ketersediaan, ketersediaan tinggi lingkungan juga harus memenuhi waktu pemulihan yang ketat dan tujuan titik pemulihan, RTO dan RPO, masing-masing. RTO dan RPO adalah dua parameter utama yang harus ditentukan oleh bisnis sebelum membuat rencana kelangsungan bisnis dan pemulihan bencana mereka. Kedua metrik membantu merancang proses pemulihan, dan untuk menentukan batas waktu pemulihan, frekuensi pencadangan, dan prosedur pemulihan. Meskipun RTO dan RPO mungkin tampak sama, ada perbedaan inti yang harus Anda pertimbangkan. Baca terus untuk memahami perbedaan antara RTO vs RPO.

Agar jelas, RTO adalah ukuran waktu yang berlalu dari kegagalan aplikasi hingga pemulihan operasi aplikasi. Ini adalah ukuran yang menentukan berapa banyak waktu yang Anda miliki untuk pulih setelah bencana melanda. Di samping itu, RPO adalah ukuran seberapa mutakhir data saat ketersediaan aplikasi telah dipulihkan setelah masalah waktu henti. Hal ini sering digambarkan sebagai jumlah maksimum kehilangan data yang dapat ditoleransi ketika terjadi kegagalan.

Hal-hal yang perlu dipertimbangkan untuk mengevaluasi rencana pemulihan bencana Anda

Pertama, penting untuk menentukan kekritisan aplikasi dan data yang terkait dengan operasi bisnis inti. Berapa menit downtime atau kehilangan data untuk aplikasi ini merugikan perusahaan? Selanjutnya, pertimbangkan rangkaian potensi bencana yang ingin Anda lindungi organisasi Anda. Beberapa bencana yang memerlukan pemulihan dan pencadangan data meliputi:

• Kehilangan data: Ini mungkin sesederhana seseorang menghapus folder, atau serumit kasus ransomware atau database yang terinfeksi.
• Kehilangan aplikasi: Ini mengacu pada saat perubahan keamanan, pembaruan, atau konfigurasi sistem berdampak negatif pada layanan.
• Kehilangan sistem: Ini termasuk ketika perangkat keras gagal, atau server virtual mogok.
• Kehilangan pusat data: Ini termasuk pusat data yang ada di lokasi dan di cloud publik
• Kehilangan lokasi bisnis: Dalam hal ini, bencana mungkin termasuk pemadaman listrik, kebakaran, banjir, atau bahkan tumpahan bahan kimia di luar gedung. Fasilitas bisnis memerlukan pemulihan ke lokasi alternatif.

Mengurangi RPO dan RTO organisasi

Penting untuk mempertimbangkan RTO dan RPO karena berlaku untuk berbagai jenis data. Organisasi yang melakukan pencadangan tingkat file database, daripada berinvestasi di lingkungan virtual di luar lokasi, akan melihat waktu pemulihan yang lebih lama dan membatasi seberapa baru data tersebut akan diperbarui setelah dipulihkan.

Pertimbangkan kemungkinan bencana, cocokkan dengan kumpulan data yang perlu dilindungi, lalu identifikasi tujuan pemulihan. Langkah-langkah ini kemudian akan memberi Anda informasi yang diperlukan untuk membangun solusi pencadangan taktis yang memenuhi tujuan waktu pemulihan dan tujuan titik pemulihan Anda.

Apa itu RTO dan RPO di SQL Server?

SQL Server memungkinkan pengguna untuk mengatur pencadangan log otomatis untuk dipulihkan dari server siaga. Dengan pengiriman log ini, pengguna dapat memulihkan salinan database yang cukup baru—bergantung pada RTO dan RPO dari proses tersebut. Persyaratan RTO dan RPO tersebut ditetapkan oleh pengguna, tergantung pada kebutuhan, anggaran, dan batasan jaringan teknologi apa pun.

Namun, SQL Server RTO dan RPO tidak selalu langsung. Dalam banyak kasus, prosesnya tidak secepat yang dibayangkan klien. Mereka mungkin memiliki RPO yang ideal, tetapi kecepatan jaringan yang lambat atau pencadangan yang tidak dikonfigurasi dengan benar dapat menghambat proses ini. Selain itu, memulihkan cadangan log dengan cara ini dapat melibatkan transfer data dalam jumlah besar, dan proses ini dapat dengan mudah melebihi RTO yang dapat diterima yang ditentukan.

Karena SQL Server biasanya merupakan aplikasi bisnis-kritis, pelanggan dapat dengan mudah membenarkan perlindungan HA/DR untuk itu – biasanya dalam bentuk kluster failover yang dapat failover di seluruh zona dan wilayah ketersediaan cloud untuk pemulihan bencana . Ini dapat dilakukan dengan mudah dengan menambahkan SIOS DataKeeper ke lingkungan Windows Server Failover Clustering atau dengan menggunakan SIOS Protection Suite di lingkungan Linux. Kedua solusi ini akan memberikan tidak hanya ketersediaan 99,99% tetapi juga RPO nol dan RTO hanya dalam hitungan detik.

Sekarang setelah Anda tahu…

Pada akhirnya, pencegahan kehilangan data untuk kelangsungan bisnis adalah persyaratan penting untuk bisnis apa pun. Luangkan waktu untuk mempertimbangkan bagaimana Anda akan memenuhi tujuan RTO dan RPO Anda, tidak peduli seberapa besar atau kecil bisnis Anda, atau operasi TI internal apa yang Anda dukung.Cluster ketersediaan tinggi SIOS memberikan RPO nol dan RTO hanya dalam beberapa menit.

Belajar lebih tentang SIOS DataKeeper untuk Windows atau Suite Perlindungan SIOS untuk Linux Untuk meminta uji coba gratis, beri tahu kami di sini .

Direproduksi dari SIOS