Skenario pemulihan dari bencana untuk data

Dokumen ini adalah bagian ketiga dari seri yang membahas pemulihan dari bencana (DR) dalam Google Cloud. Bagian ini membahas skenario untuk mencadangkan dan memulihkan data.

Seri ini terdiri dari bagian-bagian berikut:

Pengantar

Rencana pemulihan dari bencana Anda harus menentukan cara menghindari kehilangan data selama bencana. Istilah data di sini mencakup dua skenario. Mencadangkan lalu memulihkan database, data log, dan jenis data lainnya sesuai dengan salah satu skenario berikut:

  • Pencadangan data. Mencadangkan data saja melibatkan penyalinan sejumlah data berbeda dari satu tempat ke tempat lain. Cadangan dibuat sebagai bagian dari rencana pemulihan, baik untuk pemulihan dari kerusakan data sehingga Anda dapat memulihkannya ke keadaan baik yang telah diketahui langsung di lingkungan produksi, atau sehingga Anda dapat memulihkan data di lingkungan DR jika lingkungan produksi Anda sedang tidak beroperasi. Biasanya, cadangan data memiliki RTO kecil hingga sedang dan RPO yang kecil.
  • Pencadangan database. Pencadangan database sedikit lebih kompleks, karena biasanya melibatkan pemulihan ke titik waktu tertentu. Oleh karena itu, selain mempertimbangkan cara mencadangkan dan memulihkan cadangan database dan memastikan pemulihan sistem database mencerminkan konfigurasi produksi (versi yang sama, konfigurasi disk yang diduplikasi), Anda juga harus mempertimbangkan cara mencadangkan log transaksi. Selama pemulihan, setelah Anda memulihkan fungsionalitas database, Anda harus menerapkan cadangan database terbaru, kemudian log transaksi yang dipulihkan, yang dicadangkan setelah pencadangan terakhir. Karena faktor rumit yang melekat pada sistem database (misalnya, harus mencocokkan versi antara sistem produksi dan pemulihan), mengadopsi pendekatan yang mengutamakan ketersediaan tinggi untuk meminimalkan waktu pemulihan dari situasi yang dapat menyebabkan ketidaktersediaan server database memungkinkan Anda mencapai nilai RTO dan RPO yang lebih kecil.

Saat menjalankan beban kerja produksi di Google Cloud, Anda mungkin menggunakan sistem yang terdistribusi secara global sehingga jika terjadi masalah di satu region, aplikasi akan terus menyediakan layanan meskipun ketersediaannya kurang luas. Intinya, aplikasi tersebut memanggil rencana DR-nya.

Bagian lainnya dari dokumen ini membahas contoh cara mendesain beberapa skenario untuk data dan database yang dapat membantu Anda memenuhi sasaran RTO dan RPO.

Lingkungan produksi tersedia di infrastruktur lokal

Dalam skenario ini, lingkungan produksi Anda bersifat lokal, dan rencana pemulihan dari bencana Anda melibatkan penggunaan Google Cloud sebagai situs pemulihan.

Pencadangan dan pemulihan data

Anda dapat menggunakan sejumlah strategi untuk menerapkan proses guna mencadangkan data secara rutin dari infrastruktur lokal ke Google Cloud. Bagian ini membahas dua solusi yang paling umum.

Solusi 1: Cadangkan data ke Cloud Storage menggunakan tugas terjadwal

Pola ini menggunakan elemen penyusun DR berikut:

  • Cloud Storage

Salah satu opsi untuk mencadangkan data adalah membuat tugas terjadwal yang menjalankan skrip atau aplikasi untuk mentransfer data ke Cloud Storage. Anda dapat mengotomatiskan proses pencadangan ke Cloud Storage menggunakan perintah Google Cloud CLI gcloud storage atau dengan menggunakan salah satu library klien Cloud Storage. Misalnya, perintah gcloud storage berikut menyalin semua file dari direktori sumber ke bucket yang telah ditentukan.

gcloud storage cp -r SOURCE_DIRECTORY gs://BUCKET_NAME

Ganti SOURCE_DIRECTORY dengan jalur ke direktori sumber Anda dan BUCKET_NAME dengan nama pilihan Anda untuk bucket. Nama ini harus memenuhi persyaratan nama bucket.

Langkah-langkah berikut menguraikan cara menerapkan proses pencadangan dan pemulihan menggunakan perintah gcloud storage.

  1. Instal gcloud CLI di komputer lokal tempat Anda ingin mengupload file data.
  2. Buat bucket sebagai target untuk pencadangan data.
  3. Membuat akun layanan
  4. Buat kebijakan IAM untuk membatasi siapa yang dapat mengakses bucket dan objeknya. Menyertakan akun layanan yang dibuat khusus untuk tujuan ini. Untuk mengetahui detail tentang izin akses ke Cloud Storage, lihat Izin IAM untuk gcloud storage.
  5. Gunakan Peniruan identitas akun layanan untuk memberikan akses bagi pengguna (atau akun layanan) Google Cloud lokal Anda untuk meniru identitas akun layanan yang baru saja Anda buat sebelumnya. Atau, Anda dapat membuat pengguna baru khusus untuk tujuan ini.
  6. Uji apakah Anda dapat mengupload dan mendownload file di bucket target.
  7. Siapkan jadwal untuk skrip yang Anda gunakan untuk mengupload cadangan menggunakan alat seperti Linux crontab dan Windows Task Scheduler.
  8. Konfigurasi proses pemulihan yang menggunakan perintah gcloud storage untuk memulihkan data ke lingkungan DR pemulihan Anda pada Google Cloud.

Anda juga dapat menggunakan perintah gcloud storage rsync untuk melakukan sinkronisasi inkremental secara real-time antara data Anda dan bucket Cloud Storage.

Misalnya, perintah gcloud storage rsync berikut menjadikan konten dalam bucket Cloud Storage sama dengan konten di direktori sumber dengan menyalin semua file atau objek yang hilang, atau yang datanya telah berubah. Jika volume data yang telah berubah di antara sesi pencadangan berturut-turut relatif kecil terhadap seluruh volume data sumber, penggunaan gcloud storage rsync bisa lebih efisien daripada menggunakan perintah gcloud storage cp. Dengan menggunakan gcloud storage rsync, Anda dapat menerapkan jadwal pencadangan yang lebih sering dan mencapai RPO yang lebih rendah.

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

Untuk mengetahui informasi selengkapnya, lihat perintah gcloud storage untuk transfer data lokal yang lebih kecil.

Solusi 2: Cadangkan ke Cloud Storage menggunakan Transfer Service untuk data lokal

Pola ini menggunakan elemen penyusun DR berikut:

  • Cloud Storage
  • Transfer Service untuk data lokal

Mentransfer data dalam jumlah besar melalui jaringan sering kali memerlukan perencanaan yang cermat dan strategi eksekusi yang andal. Mengembangkan skrip khusus yang skalabel, andal, dan mudah dipelihara bukanlah tugas yang mudah. Skrip khusus sering kali dapat mengakibatkan penurunan nilai RPO dan bahkan peningkatan risiko kehilangan data.

Untuk panduan memindahkan data dalam volume besar dari lokasi lokal ke Cloud Storage, lihat Memindahkan atau mencadangkan data dari penyimpanan lokal.

Solusi 3: Cadangkan ke Cloud Storage menggunakan solusi gateway partner

Pola ini menggunakan elemen penyusun DR berikut:

  • Cloud Interconnect
  • Penyimpanan bertingkat Cloud Storage

Aplikasi lokal sering kali terintegrasi dengan solusi pihak ketiga yang dapat digunakan sebagai bagian dari strategi pencadangan dan pemulihan data Anda. Solusinya sering menggunakan pola penyimpanan bertingkat di mana Anda menyimpan cadangan terbaru di penyimpanan yang lebih cepat, dan perlahan memindahkan cadangan lama ke penyimpanan yang lebih murah (lebih lambat). Saat menggunakan Google Cloud sebagai target, Anda memiliki beberapa opsi kelas penyimpanan yang dapat digunakan sebagai opsi yang setara dengan paket yang lebih lambat.

Salah satu cara menerapkan pola ini adalah dengan menggunakan gateway partner di antara penyimpanan lokal Anda dan Google Cloud untuk memfasilitasi transfer data ini ke Cloud Storage. Diagram berikut menunjukkan pengaturan tersebut, dengan solusi partner yang mengelola transfer dari perangkat NAS lokal atau SAN.

Diagram arsitektur yang menunjukkan pusat data lokal yang terhubung ke Google Cloud menggunakan interkoneksi khusus.

Jika terjadi kegagalan, data yang sedang dicadangkan harus dipulihkan ke lingkungan DR Anda. Lingkungan DR digunakan untuk menyajikan traffic produksi hingga Anda dapat kembali ke lingkungan produksi. Cara mencapainya bergantung pada aplikasi Anda, serta solusi partner dan arsitekturnya. (Beberapa skenario yang menyeluruh dibahas dalam dokumen aplikasi DR.)

Anda juga dapat menggunakan database Google Cloud terkelola sebagai tujuan DR. Misalnya, Cloud SQL untuk SQL Server mendukung impor log transaksi. Anda dapat mengekspor log transaksi dari instance SQL Server lokal, menguploadnya ke Cloud Storage, lalu mengimpornya ke Cloud SQL untuk SQL Server.

Untuk panduan lebih lanjut tentang cara mentransfer data dari infrastruktur lokal ke Google Cloud, lihat Mentransfer set big data ke Google Cloud.

Untuk informasi selengkapnya tentang solusi partner, lihat halaman Partner di Google Cloud situs.

Pencadangan dan pemulihan database

Anda dapat menggunakan sejumlah strategi untuk menerapkan proses pemulihan sistem database dari lokal ke Google Cloud. Bagian ini membahas dua solusi yang paling umum.

Dalam dokumen ini, kita tidak membahas secara mendetail berbagai mekanisme pencadangan dan pemulihan bawaan yang disertakan dengan database pihak ketiga. Bagian ini memberikan panduan umum, yang diimplementasikan dalam solusi yang dibahas di sini.

Solusi 1: Pencadangan dan pemulihan menggunakan server pemulihan di Google Cloud

  1. Buat cadangan database menggunakan mekanisme pencadangan bawaan dari sistem pengelolaan database Anda.
  2. Hubungkan jaringan lokal dan Google Cloud jaringan.
  3. Buat bucket Cloud Storage sebagai target untuk pencadangan data Anda.
  4. Salin file cadangan ke Cloud Storage menggunakan gcloud storage gcloud CLI atau solusi gateway partner (lihat langkah-langkah yang dibahas sebelumnya di bagian pencadangan dan pemulihan data). Untuk mengetahui detailnya, lihat Bermigrasi ke Google Cloud: Mentransfer set data besar.
  5. Salin log transaksi ke situs pemulihan Anda di Google Cloud. Memiliki cadangan log transaksi membantu menjaga nilai RPO Anda tetap kecil.

Setelah mengonfigurasi topologi pencadangan ini, Anda harus memastikan bahwa Anda dapat melakukan pemulihan ke sistem yang berada di Google Cloud. Langkah ini biasanya tidak hanya melibatkan pemulihan file cadangan ke database target, tetapi juga memutar ulang log transaksi untuk mencapai nilai RTO terkecil. Urutan pemulihan umumnya terlihat seperti ini:

  1. Buat image kustom server database Anda di Google Cloud. Server database harus memiliki konfigurasi pada image yang sama dengan server database lokal Anda.
  2. Terapkan proses untuk menyalin file cadangan lokal dan log transaksi Anda ke Cloud Storage. Lihat solusi 1 untuk contoh implementasi.
  3. Mulai instance berukuran minimal dari image kustom dan pasang persistent disk yang diperlukan.
  4. Tetapkan tanda hapus otomatis ke salah untuk persistent disk.
  5. Terapkan file cadangan terbaru yang telah disalin sebelumnya ke Cloud Storage mengikuti petunjuk dari sistem database Anda untuk memulihkan file cadangan.
  6. Terapkan kumpulan file log transaksi terbaru yang telah disalin ke Cloud Storage.
  7. Ganti instance minimal dengan instance lebih besar yang mampu menerima traffic produksi.
  8. Alihkan klien agar mengarah ke database yang dipulihkan di Google Cloud.

Setelah lingkungan produksi Anda berjalan dan dapat mendukung beban kerja produksi, Anda harus membatalkan langkah-langkah yang diikuti untuk beralih ke Google Cloud lingkungan pemulihan. Urutan umum untuk kembali ke lingkungan produksi akan terlihat seperti ini:

  1. Cadangkan database yang berjalan di Google Cloud.
  2. Salin file cadangan ke lingkungan produksi Anda.
  3. Terapkan file cadangan ke sistem database produksi Anda.
  4. Cegah klien terhubung ke sistem database di Google Cloud; misalnya, dengan menghentikan layanan sistem database. Di titik ini, aplikasi Anda tidak akan tersedia sampai Anda selesai memulihkan lingkungan produksi.
  5. Salin file log transaksi apa pun ke lingkungan produksi dan terapkan.
  6. Alihkan koneksi klien ke lingkungan produksi.

Solusi 2: Replikasi ke server standby di Google Cloud

Salah satu cara untuk mencapai nilai RTO dan RPO yang sangat kecil adalah dengan mereplikasi (tidak hanya mencadangkan) data dan, dalam beberapa kasus, menampilkan status database secara real time ke replika server database Anda.

  1. Hubungkan jaringan lokal dan Google Cloud jaringan Anda.
  2. Buat image kustom server database Anda di Google Cloud. Server database harus memiliki konfigurasi pada image yang sama dengan konfigurasi server database lokal Anda.
  3. Mulai instance dari image kustom dan pasang persistent disk yang diperlukan.
  4. Tetapkan tanda hapus otomatis ke salah untuk persistent disk.
  5. Konfigurasikan replikasi antara server database lokal dan server database target dalam Google Cloud dengan mengikuti petunjuk khusus untuk software database.
  6. Klien dikonfigurasi dalam operasi normal untuk mengarah ke server database di infrastruktur lokal.

Setelah mengonfigurasi topologi replikasi ini, alihkan klien agar mengarah ke server standby yang berjalan di Google Cloud jaringan Anda.

Setelah lingkungan produksi Anda mencadangkan dan dapat mendukung beban kerja produksi, Anda harus menyinkronkan ulang server database produksi denganGoogle Cloud server database, lalu mengalihkan klien agar mengarah kembali ke lingkungan produksi

Lingkungan produksi adalah Google Cloud

Dalam skenario ini, lingkungan produksi dan lingkungan pemulihan dari bencana Anda berjalan di Google Cloud.

Pencadangan dan pemulihan data

Pola umum untuk pencadangan data adalah menggunakan pola penyimpanan bertingkat. Jika beban kerja produksi Anda aktif Google Cloud, sistem penyimpanan bertingkat akan terlihat seperti diagram berikut. Anda memigrasikan data ke tingkat yang memiliki biaya penyimpanan lebih rendah, karena kemungkinkan persyaratan untuk mengakses data yang dicadangkan lebih kecil.

Pola ini menggunakan elemen penyusun DR berikut:

Diagram konseptual yang menunjukkan gambar yang menunjukkan penurunan biaya saat data dimigrasikan dari persistent disk ke Nearline ke Coldline.

Karena kelas penyimpanan Nearline, Coldline, dan Archive dimaksudkan untuk menyimpan data yang jarang diakses, ada biaya tambahan yang terkait dengan pengambilan data atau metadata yang tersimpan di kedua kelas ini, serta durasi penyimpanan minimum yang dikenai biaya.

Pencadangan dan pemulihan database

Saat Anda menggunakan database yang dikelola sendiri (misalnya, Anda telah menginstal MySQL, PostgreSQL, atau SQL Server pada instance Compute Engine), masalah operasional yang sama berlaku seperti pengelolaan database produksi secara lokal, tetapi Anda tidak perlu lagi mengelola infrastruktur yang mendasarinya.

Layanan Pencadangan dan DR adalah solusi berbasis cloud terpusat untuk mencadangkan dan memulihkan workload cloud dan hybrid. Layanan ini menawarkan pemulihan data yang cepat dan memfasilitasi dimulainya kembali operasi bisnis yang penting dengan cepat.

Untuk mengetahui informasi selengkapnya tentang cara menggunakan Pencadangan dan DR untuk skenario database yang dikelola sendiri di Google Cloud, lihat referensi berikut:

Atau, Anda dapat menyiapkan konfigurasi HA menggunakan fitur elemen penyusun DR yang sesuai agar RTO tetap kecil. Anda dapat mendesain konfigurasi database agar dapat memulihkan ke status sedekat mungkin dengan status pra-bencana; hal ini membantu menjaga nilai RPO Anda tetap kecil. Google Cloud menyediakan berbagai opsi untuk skenario ini.

Dua pendekatan umum dalam mendesain arsitektur pemulihan database Anda untuk database yang dikelola sendiri di Google Cloud dibahas di bagian ini.

Memulihkan server database tanpa menyinkronkan status

Pola yang umum adalah mengaktifkan pemulihan server database yang tidak memerlukan status sistem agar disinkronkan dengan replika standby terbaru.

Pola ini menggunakan elemen penyusun DR berikut:

  • Compute Engine
  • Grup instance terkelola
  • Cloud Load Balancing (load balancing internal)

Diagram berikut mengilustrasikan contoh arsitektur yang membahas skenario tersebut. Dengan menerapkan arsitektur ini, Anda memiliki rencana DR yang akan otomatis bereaksi terhadap kegagalan tanpa memerlukan pemulihan secara manual.

Diagram arsitektur yang menunjukkan image persistent disk yang diambil dari persistent disk dalam satu zona

Langkah-langkah berikut menjelaskan cara mengonfigurasi skenario ini:

  1. Buat Jaringan VPC

  2. Buat image kustom yang dikonfigurasi dengan server database dengan melakukan langkah berikut:

    1. Konfigurasikan server agar file database dan file log ditulis ke persistent disk standar yang terpasang.
    2. Buat snapshot dari persistent disk yang terpasang.
    3. Konfigurasikan skrip startup untuk membuat persistent disk dari snapshot dan untuk memasang disk.
    4. Buat image kustom dari boot disk.

  3. Buat template instance yang menggunakan gambar tersebut.

  4. Dengan menggunakan template instance, konfigurasi grup instance terkelola dengan ukuran target 1.

  5. Mengonfigurasi health check menggunakan metrik Cloud Monitoring.

  6. Konfigurasikan load balancing internal menggunakan grup instance terkelola.

  7. Konfigurasikan tugas terjadwal untuk membuat snapshot reguler dari persistent disk.

Jika instance database pengganti diperlukan, konfigurasi ini akan melakukan hal berikut secara otomatis:

  • Memunculkan versi server database lain yang benar di zona yang sama.
  • Memasang persistent disk yang memiliki file log transaksi dan cadangan terbaru ke instance server database yang baru dibuat.
  • Meminimalkan kebutuhan untuk mengonfigurasi ulang klien yang berkomunikasi dengan server database Anda sebagai respons terhadap suatu peristiwa.
  • Memastikan bahwa Google Cloud kontrol keamanan (kebijakan IAM, setelan firewall) yang berlaku untuk server database produksi berlaku untuk server database yang dipulihkan.

Karena instance pengganti dibuat dari template instance, kontrol pada instance asli akan diterapkan pada instance pengganti.

Skenario ini memanfaatkan beberapa fitur HA yang tersedia di Google Cloud; Anda tidak perlu memulai langkah failover apa pun, karena langkah tersebut otomatis terjadi jika terjadi bencana. Load balancer internal memastikan bahwa meskipun instance pengganti diperlukan, alamat IP yang sama akan digunakan untuk server database. Template instance dan image kustom memastikan bahwa instance pengganti dikonfigurasi secara identik dengan instance yang diganti. Dengan mengambil snapshot persistent disk secara rutin, Anda memastikan bahwa saat disk dibuat ulang dari snapshot dan dipasang ke instance pengganti, instance pengganti akan menggunakan data yang dipulihkan sesuai dengan nilai RPO yang ditentukan sesuai frekuensi pengambilan snapshot. Dalam arsitektur ini, file log transaksi terbaru yang ditulis di persistent disk juga akan dipulihkan secara otomatis.

Grup instance terkelola menyediakan HA secara mendalam. Solusi ini menyediakan mekanisme untuk merespons kegagalan di tingkat aplikasi atau instance, dan Anda tidak perlu melakukan intervensi secara manual saat salah satu skenario tersebut terjadi. Menetapkan ukuran target sebesar satu akan memastikan Anda hanya memiliki satu instance aktif yang berjalan di grup instance terkelola dan menyajikan traffic.

Persistent disk standar bersifat sesuai zona, jadi jika terjadi kegagalan zona, snapshot diperlukan untuk membuat ulang disk. Snapshot juga tersedia di seluruh region, sehingga Anda dapat memulihkan disk tidak hanya dalam region yang sama, tetapi juga ke region yang berbeda.

Variasi pada konfigurasi ini adalah menggunakan persistent disk regional sebagai pengganti persistent disk standar. Dalam kasus ini, Anda tidak perlu memulihkan snapshot sebagai bagian dari langkah pemulihan.

Variasi yang Anda pilih ditentukan oleh anggaran serta nilai RTO dan RPO Anda.

Memulihkan dari kerusakan parsial dalam database yang sangat besar

Replikasi Asinkron Persistent Disk menawarkan replikasi block storage dengan RPO rendah dan RTO rendah untuk DR pasif aktif-lintas region. Opsi penyimpanan ini dapat Anda gunakan untuk mengelola replikasi beban kerja Compute Engine di tingkat infrastruktur, bukan di tingkat workload.

Jika Anda menggunakan database yang mampu menyimpan data berukuran petabyte, Anda mungkin mengalami pemadaman layanan yang akan memengaruhi beberapa data, tetapi tidak semuanya. Dalam kasus ini, Anda ingin meminimalkan jumlah data yang perlu dipulihkan; Anda tidak perlu (atau ingin) memulihkan seluruh database hanya untuk memulihkan sebagian datanya.

Ada sejumlah strategi mitigasi yang dapat Anda gunakan:

  • Simpan data Anda dalam tabel yang berbeda untuk jangka waktu tertentu. Metode ini memastikan bahwa Anda hanya perlu memulihkan sebagian data ke tabel baru, bukan seluruh set data.

  • Simpan data asli di Cloud Storage. Pendekatan ini memungkinkan Anda membuat tabel baru dan memuat ulang data yang tidak rusak. Dari sana, Anda dapat menyesuaikan aplikasi untuk mengarah ke tabel baru.

Selain itu, jika RTO Anda memungkinkan, Anda dapat mencegah akses ke tabel yang memiliki data yang rusak dengan membiarkan aplikasi Anda offline hingga data yang tidak rusak telah dipulihkan ke tabel baru.

Layanan database terkelola di Google Cloud

Bagian ini membahas beberapa metode yang dapat Anda gunakan untuk mengimplementasikan mekanisme pencadangan dan pemulihan yang tepat bagi layanan database terkelola di Google Cloud.

Database terkelola dirancang untuk skala, sehingga mekanisme pencadangan dan pemulihan tradisional yang Anda dapati pada RDMBS tradisional biasanya tidak tersedia. Dalam kasus database yang dikelola sendiri, jika menggunakan database yang mampu menyimpan data berukuran petabyte, Anda ingin meminimalkan jumlah data yang perlu dipulihkan dalam skenario DR. Ada sejumlah strategi untuk setiap database terkelola untuk membantu Anda mencapai tujuan ini.

Bigtable menyediakan Replikasi Bigtable. Database Bigtable yang direplikasi dapat memberikan ketersediaan yang lebih tinggi daripada satu cluster, read throughput tambahan, serta durabilitas dan ketahanan yang lebih tinggi dalam menghadapi kegagalan zona atau regional.

Pencadangan Bigtable adalah layanan terkelola sepenuhnya yang memungkinkan Anda menyimpan salinan skema dan data tabel, serta memulihkan data dari cadangan ke tabel baru di lain waktu.

Anda juga dapat mengekspor tabel dari Bigtable sebagai serangkaian file berurutan Hadoop. Selanjutnya, Anda dapat menyimpan file ini di Cloud Storage atau menggunakannya untuk mengimpor kembali data ke instance Bigtable lain. Anda dapat mereplikasi set data Bigtable secara asinkron di seluruh zona dalam satu Google Cloud region.

BigQuery. Jika ingin mengarsipkan data, Anda dapat memanfaatkan penyimpanan jangka panjang BigQuery. Jika tabel tidak diedit selama 90 hari berturut-turut, harga penyimpanan untuk tabel tersebut akan otomatis turun sebanyak 50 persen. Tidak ada penurunan performa, durabilitas, ketersediaan, atau fungsi lainnya jika tabel dianggap sebagai penyimpanan jangka panjang. Namun, jika diedit, tabel akan kembali ke harga penyimpanan reguler dan hitung mundur 90 hari akan dimulai kembali.

BigQuery direplikasi ke dua zona dalam satu region, tetapi hal ini tidak akan membantu kerusakan pada tabel Anda. Oleh karena itu, Anda harus memiliki rencana agar dapat memulihkan data dari skenario tersebut.   Misalnya, Anda dapat melakukan hal berikut:

  • Jika kerusakan terdeteksi dalam 7 hari, buat kueri tabel ke titik waktu di masa lalu untuk memulihkan tabel sebelum kerusakan terjadi menggunakan dekorator snapshot.
  • Ekspor data dari BigQuery, dan buat tabel baru yang berisi data yang diekspor tanpa menyertakan data yang rusak.
  • Simpan data Anda dalam tabel yang berbeda untuk jangka waktu tertentu. Metode ini memastikan bahwa Anda hanya perlu memulihkan sebagian data ke tabel baru, bukan seluruh set data.
  • Buat salinan set data pada jangka waktu tertentu. Anda dapat menggunakan salinan ini jika peristiwa kerusakan data terjadi melebihi waktu yang dapat dicatat oleh kueri point-in-time (misalnya, lebih dari 7 hari yang lalu). Anda juga dapat menyalin set data dari satu region ke region lain untuk memastikan ketersediaan data jika terjadi kegagalan region.
  • Simpan data asli di Cloud Storage, yang memungkinkan Anda membuat tabel baru dan memuat ulang data yang tidak rusak. Dari sana, Anda dapat menyesuaikan aplikasi untuk mengarah ke tabel baru.

Firestore. Layanan ekspor dan impor terkelola memungkinkan Anda mengimpor dan mengekspor entity Firestore menggunakan bucket Cloud Storage. Selanjutnya, Anda dapat menerapkan proses yang dapat digunakan untuk memulihkan data dari penghapusan yang tidak disengaja.

Cloud SQL. Jika menggunakan Cloud SQL, database Google Cloud MySQL yang terkelola sepenuhnya, Anda harus mengaktifkan pencadangan otomatis dan logging biner untuk instance Cloud SQL Anda. Pendekatan ini memungkinkan Anda melakukan pemulihan point-in-time, yang akan memulihkan database dari cadangan dan memulihkannya ke instance Cloud SQL baru. Untuk mengetahui informasi selengkapnya, lihat Tentang pencadangan Cloud SQL dan Tentang pemulihan dari bencana (DR) di Cloud SQL

Anda juga dapat mengonfigurasi Cloud SQL di konfigurasi HA dan replika lintas region untuk memaksimalkan waktu jika terjadi kegagalan di tingkat zona atau regional.

Jika Anda mengaktifkan pemeliharaan terencana periode nonaktif yang hampir nol untuk Cloud SQL, Anda dapat mengevaluasi peristiwa pemeliharaan dampak pada instance dengan menyimulasikan peristiwa pemeliharaan terencana periode nonaktif yang nyaris nol di Cloud SQL untuk MySQL, dan di Cloud SQL untuk PostgreSQL.

Untuk edisi Cloud SQL Enterprise Plus, Anda dapat menggunakan pemulihan dari bencana (DR) lanjutan untuk menyederhanakan proses pemulihan dan penggantian tanpa kehilangan data setelah Anda melakukan failover lintas-regional.

Spanner. Anda dapat menggunakan template Dataflow untuk melakukan ekspor penuh database ke kumpulan file Avro di bucket Cloud Storage, dan menggunakan template lain untuk mengimpor ulang file yang diekspor ke database Spanner baru.

Untuk pencadangan yang lebih terkontrol, konektor Dataflow memungkinkan Anda menulis kode untuk membaca dan menulis data ke Spanner di pipeline Dataflow. Misalnya, Anda dapat menggunakan konektor untuk menyalin data dari Spanner dan ke Cloud Storage sebagai target pencadangan. Seberapa cepat data yang dapat dibaca dari (atau ditulis kembali di) Spanner bergantung pada jumlah node yang dikonfigurasi. Hal ini berdampak langsung pada nilai RTO Anda.

Fitur stempel waktu commit Spanner dapat berguna untuk pencadangan inkremental, dengan memungkinkan Anda hanya memilih baris yang telah ditambahkan atau diubah sejak pencadangan penuh terakhir.

Untuk pencadangan terkelola, Pencadangan dan Pemulihan Spanner memungkinkan Anda membuat cadangan yang konsisten yang dapat dipertahankan hingga maksimal 1 tahun. Nilai RTO lebih rendah dibandingkan dengan ekspor karena operasi pemulihan akan langsung memasang cadangan tanpa menyalin data.

Untuk nilai RTO kecil, Anda dapat menyiapkan instance Spanner mode warm standby yang dikonfigurasi dengan jumlah minimum node yang diperlukan untuk memenuhi persyaratan throughput baca dan tulis penyimpanan Anda.

Pemulihan point-in-time (PITR) Spanner memungkinkan Anda memulihkan data dari titik waktu tertentu di masa lalu. Misalnya, jika operator tidak sengaja menulis data atau peluncuran sebuah aplikasi merusak database, Anda dapat memulihkan data dari satu titik waktu sebelumnya dengan PITR hingga maksimum 7 hari.

Cloud Composer Anda dapat menggunakan Cloud Composer (Apache Airflow versi terkelola) untuk menjadwalkan pencadangan rutin beberapaGoogle Cloud database. Anda dapat membuat directed acyclic graph (DAG) untuk dijalankan sesuai jadwal (misalnya, setiap hari) baik untuk menyalin data ke project, set data, atau tabel lain (bergantung pada solusi yang digunakan), atau untuk mengekspor data ke Cloud Storage.

Mengekspor atau menyalin data dapat dilakukan menggunakan berbagai macam operator Cloud Platform.

Misalnya, Anda dapat membuat DAG untuk melakukan hal berikut:

Lingkungan produksi adalah cloud lainnya

Dalam skenario ini, lingkungan produksi Anda menggunakan penyedia cloud lain, dan disaster recovery plan Anda melibatkan penggunaan Google Cloud sebagai situs pemulihan.

Pencadangan dan pemulihan data

Mentransfer data antar penyimpanan objek adalah kasus penggunaan umum untuk skenario DR. Storage Transfer Service kompatibel dengan Amazon S3 dan merupakan cara yang direkomendasikan untuk mentransfer objek dari Amazon S3 ke Cloud Storage.

Anda dapat mengonfigurasi tugas transfer untuk menjadwalkan sinkronisasi berkala dari sumber data ke sink data, dengan filter lanjutan berdasarkan tanggal pembuatan file, filter nama file, dan waktu yang Anda pilih untuk mentransfer data. Untuk mencapai RPO yang diinginkan, Anda harus mempertimbangkan faktor-faktor berikut:

  • Laju perubahan. Jumlah data yang dihasilkan atau diperbarui untuk jangka waktu tertentu. Semakin tinggi laju perubahan, semakin banyak resource yang diperlukan untuk mentransfer perubahan ke tujuan pada setiap periode transfer inkremental.

  • Performa transfer. Waktu yang diperlukan untuk mentransfer file. Untuk transfer file berukuran besar, hal ini biasanya ditentukan oleh bandwidth yang tersedia antara sumber dan tujuan. Namun, jika tugas transfer terdiri dari banyak file berukuran kecil, QPS dapat menjadi faktor pembatas. Jika demikian, Anda dapat menjadwalkan beberapa tugas serentak untuk menskalakan performa selama bandwidth yang memadai tersedia. Sebaiknya Anda mengukur performa transfer menggunakan subset representatif dari data nyata Anda.

  • Frekuensi. Interval di antara tugas pencadangan. Keaktualan data di tujuan adalah yang terbaru sejak terakhir kali tugas transfer dijadwalkan. Oleh karena itu,sangat penting untuk memastikan interval antara tugas transfer berurutan tidak lebih lama dari tujuan RPO Anda. Misalnya, jika tujuan RPO adalah 1 hari, tugas transfer harus dijadwalkan setidaknya sekali sehari.

  • Pemantauan dan peringatan. Storage Transfer Service menyediakan notifikasi Pub/Sub untuk berbagai peristiwa. Sebaiknya Anda berlangganan notifikasi ini untuk menangani kegagalan tak terduga atau perubahan dalam waktu penyelesaian tugas.

Pencadangan dan pemulihan database

Dalam dokumen ini, kita tidak membahas secara mendetail berbagai mekanisme pencadangan dan pemulihan bawaan yang disertakan dengan database pihak ketiga atau teknik pencadangan dan pemulihan yang digunakan di penyedia cloud lain. Jika mengoperasikan database tidak terkelola pada layanan komputasi, Anda dapat memanfaatkan fasilitas dengan ketersediaan tinggi (HA) yang disediakan oleh penyedia produksi cloud Anda. Anda dapat memperluasnya untuk menggabungkan deployment HA ke Google Cloud, atau menggunakan Cloud Storage sebagai tujuan utama untuk cold storage file cadangan database.

Apa langkah selanjutnya?