Backup vault adalah resource regional yang dikelola Google yang menyediakan penyimpanan yang terisolasi, tidak dapat diubah, dan tidak dapat dihapus untuk cadangan. Layanan ini mengatur data ke dalam hierarki vault, sumber data, dan cadangan, sehingga melindungi data dari penghapusan yang tidak disengaja atau berbahaya melalui periode retensi yang diterapkan dan isolasi identitas level project.
Dokumen ini menjelaskan cara kerja vault cadangan, termasuk model resource hierarkis, workload yang didukung, model cadangan, kompatibilitas lokasi, ketersediaan, dan persyaratan penamaan.
Hierarki resource
Data dalam Backup and DR diatur ke dalam hierarki tiga tingkat dalam vault cadangan:
Vault cadangan: container tingkat teratas yang menerapkan kebijakan retensi minimum global.
Sumber data: resource turunan yang mewakili entity tertentu yang dilindungi (misalnya, instance Compute Engine). Sistem akan membuat bucket ini secara otomatis saat pencadangan pertama.
Cadangan: resource turunan dari sumber data yang mewakili cadangan terpisah dengan titik pemulihan point-in-time tertentu.
Diagram berikut menunjukkan model resource vault cadangan:
Batasan
Halaman ini menjelaskan vault cadangan untuk resource yang dikelola melalui konsolGoogle Cloud (seperti Compute Engine atau Cloud SQL). Jika Anda menggunakan konsol pengelolaan peralatan untuk workload seperti Oracle atau Google Cloud VMware Engine, lihat Ringkasan vault cadangan yang dikelola dari konsol pengelolaan peralatan.
Cluster AlloyDB dan instance Filestore di vault cadangan tidak didukung untuk multi-region.
Backup and DR tidak memberlakukan batasan apa pun pada lokasi tujuan yang kompatibel saat memulihkan workload dari cadangan vault cadangan.
Anda dapat dikenai biaya transfer jaringan, bergantung pada lokasi vault cadangan dan workload sumber. Untuk mengetahui informasi selengkapnya, lihat Harga Backup and DR.
Resource yang didukung
| Jenis workload | Pengelolaan |
|---|---|
| Instance Compute Engine | KonsolGoogle Cloud |
| Disk Compute Engine | KonsolGoogle Cloud |
| Instance Filestore | KonsolGoogle Cloud |
| Instance Cloud SQL | KonsolGoogle Cloud |
| Cluster AlloyDB | KonsolGoogle Cloud |
| Google Cloud VMware Engine, database Oracle, dan database SQL Server | Konsol pengelolaan peralatan |
Model cadangan untuk resource
| Model terpusat | Model terdesentralisasi | |
|---|---|---|
| Google Cloud console | Menggabungkan pengelolaan cadangan dengan membuat vault cadangan dan rencana cadangan di project administrator pusat. Administrator dapat menggunakan rencana yang dikelola secara terpusat ini untuk melindungi resource di beberapa project layanan, atau menggunakan izin IAM untuk mendelegasikan akses rencana pencadangan kepada pemilik aplikasi. |
Mengisolasi pengelolaan cadangan dengan membuat vault cadangan dan rencana cadangan terpisah dalam setiap project. Pendekatan ini ideal untuk organisasi terdesentralisasi, di mana setiap tim aplikasi bertanggung jawab untuk mencadangkan resource mereka sendiri. |
| Konsol pengelolaan peralatan | Menggabungkan pengelolaan cadangan dengan men-deploy konsol pengelolaan peralatan dan membuat vault cadangan di project administrator pusat. Administrator mengonfigurasi kebijakan pencadangan dalam konsol pengelolaan pusat untuk melindungi resource, seperti VM Google Cloud VMware Engine, di beberapa project layanan. |
Mengisolasi pengelolaan cadangan dengan men-deploy konsol pengelolaan peralatan dan vault cadangan terpisah untuk setiap project atau lini bisnis. Pendekatan ini ideal untuk organisasi terdesentralisasi yang tanggung jawab pengelolaan cadangannya dibagi ke beberapa tim. |
Lokasi yang didukung vault cadangan
Anda dapat membuat vault cadangan di region yang sama dengan workload sumber (regional), di region yang berbeda dari workload sumber (lintas-regional), atau di beberapa region (multi-regional).
Wilayah dan lintas wilayah yang didukung
Anda dapat membuat vault cadangan di region dan lintas region berikut:
| Area Geografis | Nama Region | Deskripsi Region | |
|---|---|---|---|
| Amerika Utara | |||
northamerica-northeast1 * |
Montréal |
 CO Rendah2
|
|
northamerica-northeast2 |
Toronto |
CO Rendah2
|
|
us-central1 |
Iowa |
CO2 rendah
|
|
us-east1 |
South Carolina | ||
us-east4 |
Northern Virginia | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
CO2 Rendah
|
|
us-west1 |
Oregon |
CO2 rendah
|
|
us-west2 |
Los Angeles | ||
us-west3 |
Salt Lake City | ||
us-west4 |
Las Vegas | ||
northamerica-south1 * |
Querétaro | ||
| Amerika Selatan | |||
southamerica-east1 |
Sao Paulo |
CO Rendah2
|
|
southamerica-west1 |
Santiago |
CO Rendah2
|
|
| Eropa | |||
europe-central2 |
Warsawa |
CO2 Rendah
|
|
europe-north1 |
Finlandia |
CO2 rendah
|
|
europe-north2 |
Stockholm |
CO Rendah2
|
|
europe-southwest1 |
Madrid |
CO2 rendah
|
|
europe-west1 |
Belgia |
CO2 rendah
|
|
europe-west2 |
London |
CO Rendah2
|
|
europe-west3 |
Frankfurt | ||
europe-west4 |
Belanda |
CO2 rendah
|
|
europe-west6 |
Zürich |
CO Rendah2
|
|
europe-west8 |
Milan |
CO2 rendah
|
|
europe-west9 |
Paris |
CO Rendah2
|
|
europe-west10 |
Berlin | ||
europe-west12 |
Turin |
CO2 rendah
|
|
| Timur Tengah | |||
me-central1 |
Doha | ||
me-central2 |
Dammam | ||
me-west1 |
Israel | ||
| Afrika | |||
africa-south1 |
Johannesburg | ||
| Asia Pasifik | |||
asia-east1 |
Taiwan | ||
asia-east2 |
Hong Kong | ||
asia-northeast1 |
Tokyo | ||
asia-northeast2 * |
Osaka | ||
asia-northeast3 |
Seoul | ||
asia-southeast1 |
Singapura | ||
asia-southeast2 |
Jakarta | ||
australia-southeast1 |
Sydney | ||
australia-southeast2 |
Melbourne | ||
| India | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Delhi |
* Querétaro (northamerica-south1), Montréal (northamerica-northeast1), dan Osaka (asia-northeast2) tidak mendukung pemisahan zona. Artinya, beberapa zona dalam setiap region ini mungkin tidak berada di kampus pusat data yang terpisah secara fisik. Akibatnya, satu peristiwa bencana fisik yang terlokalisasi berpotensi memengaruhi beberapa zona dalam region yang sama, sehingga meningkatkan risiko kehilangan data dibandingkan dengan region yang mendukung pemisahan zona.
Multi-region yang didukung
Anda dapat membuat vault cadangan di multi-region berikut:
| Nama multi-region | Deskripsi |
|---|---|
ASIA |
Pusat data di Asia |
EU |
Pusat data di Uni Eropa |
US |
Pusat data di Amerika Serikat |
Kompatibilitas lokasi workload
Tabel berikut menjelaskan lokasi vault cadangan yang kompatibel untuk setiap workload yang didukung, saat menggunakan vault cadangan regional dan lintas-regional. Perhatikan bahwa paket pencadangan di konsol Google Cloud harus dibuat di region yang sama dengan workload sumber.
| Workload | Vault cadangan harus berada di region yang sama dengan workload sumber | Dukungan regional | Dukungan multi-regional | Dukungan lintas-region |
|---|---|---|---|---|
| Instance Compute Engine | Tidak | |||
| Disk Compute Engine | Tidak | |||
| Instance Cloud SQL | Ya | |||
| Cluster AlloyDB | Ya | |||
| Instance Filestore | Tidak | |||
| Google Cloud VMware Engine, database Oracle, dan database SQL Server | Tidak |
Kompatibilitas multi-region
Persyaratan berikut harus dipenuhi untuk menggunakan multi-region:
Jika workload mendukung vault cadangan multi-region, lokasi workload sumber harus kompatibel dengan lokasi vault cadangan multi-region.
Anda hanya dapat mencadangkan resource di region yang memiliki awalan yang sama. Misalnya, resource di region dengan awalan
asiahanya diizinkan untuk dicadangkan ke multi-regionasia.
Tabel berikut menjelaskan lokasi vault cadangan yang kompatibel untuk setiap workload yang didukung saat menggunakan vault cadangan multi-region:
| Jenis workload | Mendukung penggunaan vault cadangan multi-region? | Multi-region vault cadangan yang didukung |
|---|---|---|
| Instance Compute Engine | asia, eu, us |
|
| Disk Compute Engine | asia, eu, us |
|
| Instance Filestore | T/A | |
| Instance Cloud SQL | asia, eu, us |
|
| Cluster AlloyDB | T/A | |
| Google Cloud VMware Engine, database Oracle, dan database SQL Server | T/A |
Ketersediaan
Vault cadangan yang dibuat di lokasi regional dan lintas-regional memberikan ketahanan terhadap pemadaman layanan di satu zona. Data cadangan disimpan secara redundan di setidaknya dua zona terpisah.
Vault cadangan yang dibuat di lokasi multi-region memberikan ketahanan terhadap pemadaman layanan di satu region. Data cadangan disimpan secara redundan di setidaknya dua region terpisah.
Membandingkan vault cadangan multi-region dan lintas-region
| Kriteria | Pencadangan multi-region | Pencadangan lintas region |
|---|---|---|
| Pembuatan cadangan | Diotomatiskan oleh Google di dua region dalam satu benua. | Otonomi untuk menentukan region secara eksplisit guna membuat cadangan. |
| Kasus penggunaan | Ketersediaan tinggi & kemudahan operasional | Kepatuhan yang ketat, hukum residensi data, atau situs pemulihan dari bencana yang ditargetkan, di dalam dan di luar batas regional sumber. |
| Pengelolaan | Overhead rendah. Satu vault, penyeimbangan otomatis | Overhead sedang. Memerlukan penyiapan penyambungan target tertentu. |
| Kunci enkripsi yang dikelola pelanggan (Customer-Managed Encryption Key/CMEK) | Vault cadangan multi-region harus menggunakan CMEK dari region yang sama dengan vault cadangan. | Cross-region vault cadangan harus menggunakan CMEK dari region yang sama dengan vault cadangan. |
| Implikasi biaya | Biaya upload dan download multi-regional, jika berlaku. Biaya penyimpanan cadangan untuk vault multi-region. Biaya pengelolaan. | Biaya transfer data antar-region. Biaya penyimpanan cadangan. Biaya pengelolaan. |
| Workload yang didukung |
|
|
Nama vault cadangan
Nama vault cadangan Anda harus memenuhi persyaratan berikut:
Nama vault cadangan hanya boleh berisi huruf kecil, karakter numerik, dan tanda hubung (
-). Spasi tidak diizinkan.Nama vault cadangan harus diawali dan diakhiri dengan angka atau huruf.
Nama vault cadangan harus berisi 3-63 karakter. Nama yang mengandung titik dapat berisi hingga 222 karakter, tetapi setiap komponen yang dipisahkan titik dapat berisi tidak lebih dari 63 karakter.
Nama vault cadangan tidak dapat direpresentasikan sebagai alamat IP dalam notasi desimal bertitik. Misalnya,
192.0.2.255.
Mencegah penghapusan cadangan
Untuk melindungi data Anda dari penghapusan yang tidak disengaja atau berbahaya, Anda (administrator) mengonfigurasi periode retensi yang diterapkan untuk vault cadangan Anda. Setelah dikonfigurasi, cadangan sepenuhnya tidak dapat diubah—cadangan tidak dapat dihapus secara manual oleh Anda, pengguna lain, atau Google hingga durasi yang Anda tentukan berlalu.
Anda mengontrol retensi yang diterapkan menggunakan tiga setelan utama Vault:
- Retensi minimum yang diterapkan: Saat membuat vault, Anda harus menetapkan periode retensi dasar (antara 1 hari dan 99 tahun). Tindakan ini akan membuat nilai minimum wajib di seluruh vault:
Tidak ada cadangan yang dapat dihapus sebelum waktu ini berlalu. Setiap paket cadangan yang menyimpan data di vault ini harus memiliki periode retensi cadangan yang sama dengan atau lebih lama dari batas minimum ini.
Mewarisi retensi dari aturan pencadangan: Alih-alih hanya mengandalkan batas minimum dasar vault, Anda dapat mengonfigurasi vault untuk mengadopsi periode retensi yang tepat yang ditentukan dalam rencana pencadangan spesifik Anda. Anda harus mengaktifkan setelan ini selama pembuatan vault.
Jika minimum vault Anda adalah 3 hari, tetapi retensi paket cadangan Anda adalah 7 hari, cadangan akan dikunci selama 7 hari penuh. Hasil: Penghapusan manual sepenuhnya dicegah. Cadangan hanya akan dihapus secara otomatis setelah durasi tertentu dari rencana cadangan berakhir.
Mengunci periode retensi yang diterapkan: Untuk persyaratan kepatuhan yang ketat, Anda dapat mengunci konfigurasi retensi minimum yang diterapkan secara permanen.
Saat menetapkan penguncian, Anda memilih tanggal mulai berlaku. Sebelum tanggal mulai berlaku, Anda masih dapat menyesuaikan periode retensi minimum ke atas atau ke bawah untuk memperbaiki kesalahan. Setelah tanggal mulai berlaku, tidak ada seorang pun (bahkan Project Owner) yang dapat mengurangi periode retensi. Anda hanya diizinkan untuk meningkatkannya.
Pembatasan akses vault cadangan
Setelan batasan akses vault cadangan memungkinkan Anda mengontrol sumber tempat data dapat dicadangkan atau dipulihkan dari vault cadangan. Setelan ini menentukan jenis resource yang dapat Anda simpan di vault cadangan.
Anda dapat memilih salah satu setelan pembatasan akses berikut untuk vault cadangan. Perhatikan bahwa setelan ini bersifat permanen dan tidak dapat diubah.
Membatasi akses ke organisasi saat ini: operasi pencadangan dan pemulihan hanya didukung dalam organisasi Anda saat ini. Pilihan ini membuat vault cadangan kompatibel dengan resource yang dikelola melalui konsolGoogle Cloud , seperti instance Compute Engine, tetapi tidak dengan resource yang dikelola melalui konsol pengelolaan peralatan.
Membatasi akses ke project saat ini: operasi pencadangan dan pemulihan hanya didukung dalam project Anda saat ini. Pilihan ini membuat tresor cadangan kompatibel dengan resource yang dikelola melalui konsolGoogle Cloud (misalnya, instance Compute Engine), tetapi tidak dengan resource yang dikelola melalui konsol pengelolaan peralatan.
Membatasi akses ke organisasi saat ini & akses tidak terbatas untuk peralatan pencadangan: untuk resource yang dikelola melalui konsol Google Cloud , operasi pencadangan dan pemulihan hanya didukung dalam organisasi Anda saat ini. Resource yang dikelola melalui konsol pengelolaan peralatan (misalnya, VM Google Cloud VMware Engine) juga didukung, tetapi operasi pencadangan dan pemulihan untuk resource tersebut tidak dibatasi untuk organisasi Anda saat ini. Pilihan ini membuat vault cadangan kompatibel dengan resource yang dikelola melalui konsolGoogle Cloud dan dengan resource yang dikelola melalui konsol pengelolaan peralatan.
Izinkan akses tidak terbatas: mengizinkan operasi pencadangan dan pemulihan ke atau dari project atau organisasi mana pun. Pilihan ini membuat vault cadangan kompatibel dengan resource yang dikelola melalui konsol Google Cloud dan dengan resource yang dikelola melalui konsol pengelolaan peralatan.
Enkripsi
Secara default, Google Cloud otomatis mengenkripsi data saat dalam penyimpanan menggunakan Google-owned and Google-managed encryption keys. Jika Anda memiliki persyaratan kepatuhan atau peraturan khusus yang terkait dengan kunci yang melindungi data, Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK) untuk cadangan Anda. Lihat Kunci enkripsi yang dikelola pelanggan (CMEK).
Langkah berikutnya
- Mengotomatiskan perlindungan instance Compute Engine
- Membuat dan mengelola vault cadangan di konsol Google Cloud
- Mencadangkan disk ke vault cadangan