Ringkasan pencadangan Bigtable
Halaman ini menyediakan ringkasan pencadangan Bigtable. Konten yang disajikan di sini ditujukan untuk administrator dan developer Bigtable.
Dengan cadangan, Anda dapat menyimpan salinan skema dan data tabel, lalu memulihkannya dari cadangan ke tabel baru di lain waktu. Bigtable menawarkan jenis pencadangan berikut yang bergantung pada persyaratan disaster recovery (DR) Anda, jenis penyimpanan (HDD atau SSD) yang digunakan cluster Bigtable Anda.
- Cadangan standar dioptimalkan untuk retensi jangka panjang. Saat Anda memulihkan dari cadangan standar ke cluster SSD, operasi pemulihan memerlukan pengoptimalan tambahan oleh Bigtable untuk membawa tabel ke performa tingkat produksi. Untuk mengetahui informasi selengkapnya, lihat Performa saat memulihkan.
- Hot backup memberikan pemulihan paling efisien ke performa tingkat produksi dan penyaluran latensi rendah. Untuk mengetahui informasi selengkapnya, lihat Hot backup.
Anda dapat membuat cadangan dengan cara berikut:
- Aktifkan pencadangan otomatis agar Bigtable membuat pencadangan harian untuk Anda.
- Buat cadangan sesuai permintaan menggunakan konsol Google Cloud , gcloud CLI, atau library klien Bigtable.
- Buat salinan cadangan.
Sebelum membaca halaman ini, tinjau Ringkasan Bigtable dan Mengelola tabel.
Fitur
Cadangan Bigtable memberikan fitur dan manfaat berikut:
- Terintegrasi sepenuhnya: Bigtable menangani pencadangan tanpa perlu mengimpor atau mengekspor data.
- Inkremental: cadangan berbagi penyimpanan fisik dengan tabel sumber dan cadangan lain dari tabel tersebut.
- Hemat biaya: menggunakan cadangan Bigtable memungkinkan Anda menghindari biaya yang terkait dengan ekspor, penyimpanan, dan impor data menggunakan layanan lain.
- Masa berlaku otomatis: setiap cadangan memiliki periode retensi yang ditentukan pengguna. Untuk mengetahui informasi selengkapnya, lihat bagian Retensi dalam dokumen ini.
- Opsi pemulihan yang fleksibel: memulihkan dari cadangan ke tabel di instance yang berbeda dari tempat cadangan dibuat.
- Pencadangan otomatis: aktifkan pencadangan otomatis agar Bigtable dapat membuat pencadangan harian.
- Hot backup: hot backup yang siap produksi memungkinkan Anda merencanakan disaster recovery.
Kasus penggunaan
Cadangan berguna untuk kasus penggunaan berikut:
- Kelanjutan bisnis
- Kepatuhan terhadap peraturan
- Pengujian dan pengembangan
- Disaster recovery
Pertimbangkan skenario disaster recovery berikut:
| Sasaran | Strategi pencadangan | Strategi pemulihan |
|---|---|---|
| Melindungi dari kesalahan manusia: Anda ingin selalu memiliki cadangan data terbaru yang siap jika terjadi penghapusan atau kerusakan yang tidak disengaja. | Tentukan jadwal pembuatan cadangan yang tepat untuk kebutuhan bisnis Anda, misalnya harian. Secara opsional, buat salinan cadangan secara berkala dan simpan di project atau region yang berbeda untuk meningkatkan isolasi dan perlindungan. Untuk perlindungan yang lebih baik, simpan salinan cadangan dalam project atau instance dengan izin akses terbatas. | Pulihkan ke tabel baru dari cadangan atau salinan, lalu rutekan ulang permintaan ke tabel baru. |
| Zona tidak tersedia: Anda harus memastikan bahwa jika zona Google Cloud tidak tersedia, data Anda masih tersedia. | Aktifkan pencadangan otomatis agar Bigtable membuat pencadangan harian di setiap cluster dalam instance. Atau, buat cadangan secara rutin, lalu buat salinan cadangan terbaru secara berkala dan simpan di satu atau beberapa cluster di zona yang berbeda (opsional di instance atau project yang berbeda). | Jika zona tempat cluster penyaluran Anda tidak tersedia, pulihkan dari salinan cadangan jarak jauh ke tabel baru, lalu rute ulang permintaan ke tabel baru. |
| Kerusakan data: Gunakan cadangan untuk memulihkan sebagian data tabel, misalnya saat sebagian tabel sumber telah rusak. | Aktifkan replikasi dan pencadangan otomatis untuk membuat cadangan harian di beberapa region, sehingga jika tabel rusak di satu cluster, Anda memiliki satu atau beberapa cadangan yang tidak berbagi penyimpanan di cluster yang rusak. | Pulihkan dari cadangan ke tabel baru di cluster atau instance baru. Kemudian, tulis aplikasi menggunakan library klien Bigtable atau Dataflow yang membaca dari tabel baru, lalu menulis data kembali ke tabel sumber. Setelah data disalin ke tabel asli, hapus tabel baru. |
| Pemulihan cepat: Pulihkan ke tingkat performa produksi penuh dengan cepat, sehingga meminimalkan periode nonaktif. | Konfigurasikan pencadangan otomatis untuk membuat hot backup harian, atau buat hot backup sesuai permintaan, untuk memastikan Anda selalu memiliki hot backup terbaru dari tabel Anda. | Pulihkan ke tabel baru dari hot backup, lalu alihkan rute permintaan ke tabel baru. |
Hot backup
Hot backup adalah cadangan siap produksi yang dioptimalkan untuk pemulihan cepat, dengan latensi yang lebih rendah saat membaca dari tabel baru segera setelah pemulihan. Memulihkan ke performa produksi dari hot backup lebih cepat daripada memulihkan dari cadangan standar.
Anda dapat membuat hot backup on demand kapan pun Anda membutuhkannya, atau mengonfigurasi kebijakan pencadangan otomatis untuk membuat hot backup harian:
- Hot backup on-demand: menetapkan waktu transisi hot-to-standard bersifat opsional. Jika Anda tidak menetapkan waktu transisi, cadangan akan tetap hot hingga masa berlakunya habis. Untuk mentransisikan cadangan ke cadangan standar secara otomatis, Anda dapat menetapkan waktu transisi setidaknya 24 jam setelah waktu mulai pembuatan cadangan. Anda juga dapat menetapkan atau mengubah waktu ini nanti. Untuk mengetahui informasi selengkapnya, lihat Membuat hot backup dan Mengubah cadangan atau salinan cadangan.
- Pencadangan otomatis hot: menetapkan durasi keep-hot diperlukan. Untuk mengaktifkan pencadangan otomatis hot pada instance SSD, Anda harus menentukan durasi dari 24 jam hingga 10 hari, tidak melebihi periode retensi kebijakan. Setelan ini menentukan berapa lama setiap cadangan harian tetap hot sebelum otomatis beralih ke cadangan standar selama sisa periode retensinya. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi pencadangan otomatis hot.
Menjaga cadangan terbaru Anda tetap aktif
Untuk menyeimbangkan disaster recovery yang cepat dengan biaya penyimpanan, Anda dapat menyimpan hanya cadangan terbaru sebagai hot backup, sementara cadangan yang lebih lama disimpan sebagai cadangan standar:
- Pencadangan otomatis harian: konfigurasikan kebijakan pencadangan otomatis dengan durasi keep-hot 24 jam, atau 1 hari di konsol Google Cloud . Karena Bigtable membuat cadangan otomatis setiap 24 jam, setiap cadangan harian tetap hot hingga cadangan harian berikutnya dibuat, lalu otomatis beralih ke cadangan standar selama sisa periode retensinya. Untuk mengetahui petunjuknya, lihat Mengonfigurasi pencadangan otomatis hot.
- Pencadangan on-demand: saat Anda membuat hot backup dengan jadwal berulang, tetapkan waktu transisi hot-to-standard setiap cadangan ke waktu hot backup berikutnya dijadwalkan (setidaknya 24 jam setelah waktu mulai pembuatan cadangan). Saat waktu tersebut tercapai, cadangan yang lebih lama akan otomatis beralih ke cadangan standar, sementara cadangan terbaru Anda tetap hot. Untuk mengetahui petunjuknya, lihat Membuat hot backup.
Batasan untuk hot backup
Hot backup memiliki batasan berikut:
- Anda dapat mengonversi hot backup menjadi cadangan standar, tetapi Anda tidak dapat mengonversi cadangan standar menjadi hot backup.
- Anda dapat membuat hot backup on-demand dan mengonfigurasi hot backup otomatis hanya untuk tabel di instance SSD. Anda tidak dapat membuat hot backup di instance HDD.
- Bigtable tidak mendukung hot backup untuk tabel dengan penyimpanan bertingkat yang diaktifkan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penyimpanan bertingkat.
- Salinan hot backup selalu berupa cadangan standar. Salinan cadangan tidak memiliki pemulihan cepat yang sama ke performa tingkat produksi dan penyajian latensi rendah seperti hot backup asli.
Menggunakan cadangan Bigtable
Tindakan berikut tersedia untuk pencadangan Bigtable. Dalam semua kasus, project, instance, dan cluster tujuan harus sudah ada. Anda tidak dapat membuat resource ini sebagai bagian dari operasi pencadangan.
|
||
| Tindakan | Opsi tujuan | |
|---|---|---|
| Membuat cadangan standar |
|
|
| Membuat hot backup |
|
|
| Memulihkan dari cadangan standar atau hot backup ke tabel baru |
|
|
| Menyalin cadangan1, 2 |
|
|
Lihat Mengelola pencadangan untuk mengetahui petunjuk langkah demi langkah tentang tindakan ini serta operasi seperti mengupdate dan menghapus pencadangan.
Gunakan hal berikut untuk menggunakan cadangan Bigtable:
- Konsol Google Cloud
- Google Cloud CLI
- Library klien Cloud Bigtable
Penyimpanan cadangan
Cadangan tabel yang Anda buat secara manual atau terprogram disimpan di satu cluster yang Anda tentukan. Jika pencadangan otomatis diaktifkan, Bigtable akan menyimpan cadangan di setiap cluster dalam instance. Di edisi Enterprise Plus, Anda dapat memilih lokasi cluster tempat pencadangan otomatis diaktifkan.
Jika cluster Anda melebihi batas yang direkomendasikan untuk pemakaian CPU atau penyimpanan saat Anda membuat cadangan, pembuatan cadangan mungkin akan tertunda. Untuk mengetahui informasi selengkapnya, lihat Memahami penggunaan CPU dan disk.
Cadangan tabel mencakup semua data yang ada dalam tabel pada saat cadangan dibuat, di cluster tempat cadangan dibuat. Cadangan tidak pernah lebih besar dari ukuran tabel sumber pada saat cadangan dibuat.
Cadangan Bigtable bersifat inkremental. Jumlah penyimpanan yang digunakan cadangan bergantung pada ukuran tabel dan sejauh mana cadangan tersebut dapat berbagi penyimpanan data yang tidak berubah dengan tabel asli atau cadangan lain dari tabel yang sama. Oleh karena itu, ukuran cadangan bergantung pada jumlah perbedaan data sejak pencadangan sebelumnya.
Anda dapat membuat hingga 150 cadangan per tabel per cluster.
Anda dapat menghapus tabel yang memiliki cadangan. Untuk melindungi cadangan, Anda tidak dapat menghapus hal berikut:
- Cluster yang berisi satu atau beberapa cadangan. Untuk menghapus cluster, Anda harus menghapus cadangan tersebut atau menunggu hingga masa berlakunya habis.
- Cluster yang dikonfigurasi sebagai lokasi dalam kebijakan pencadangan otomatis tabel. Untuk menghapus cluster, Anda harus memperbarui kebijakan pencadangan otomatis terlebih dahulu untuk menghapus lokasi cluster atau menonaktifkan pencadangan otomatis untuk tabel.
- Instance yang memiliki satu atau beberapa cadangan di cluster mana pun.
Cadangan masih ada setelah Anda memulihkannya ke tabel baru. Anda dapat menghapusnya atau membiarkannya berakhir saat tidak lagi diperlukan. Penyimpanan cadangan tidak mengurangi batas penyimpanan node untuk sebuah project.
Data dalam cadangan dienkripsi.
Retensi
Dengan cadangan Bigtable, Anda dapat menyimpan data untuk jangka waktu tertentu. Anda dapat mengonfigurasi periode retensi untuk setiap cadangan atau sebagai bagian dari kebijakan pencadangan otomatis:
- Periode retensi dimulai sejak pencadangan dibuat.
- Periode retensi default untuk tabel dengan pencadangan otomatis yang diaktifkan adalah tujuh hari.
- Anda dapat mengonfigurasi periode retensi kustom untuk kebijakan pencadangan otomatis hingga 90 hari di edisi Enterprise dan Enterprise Plus. Untuk pencadangan on-demand individual atau saat Anda memperbarui periode retensi pencadangan yang ada, Anda dapat menentukan hingga 90 hari di edisi Enterprise atau hingga 365 hari di edisi Enterprise Plus.
- Jika Anda membuat salinan cadangan, periode retensi maksimum untuk salinan tersebut adalah 30 hari sejak salinan dibuat.
- Saat membuat cadangan, Anda dapat menentukan tanggal habis masa berlaku, bukan periode retensi. Tanggal habis masa berlaku adalah tanggal dan waktu mutlak, sedangkan periode retensi data menentukan durasi. Kedua metode tersebut menghasilkan waktu habis masa berlaku yang mengikuti aturan dan batasan yang sama.
- Mentransisikan hot backup ke pencadangan standar tidak mengubah periode retensi atau waktu habis masa berlakunya. Untuk hot backup on-demand, menetapkan waktu transisi hot-to-standard bersifat opsional, sedangkan hot backup otomatis memerlukan durasi keep-hot.
Anda dapat mengubah periode retensi untuk cadangan atau untuk kebijakan pencadangan otomatis. Untuk mengetahui informasi selengkapnya, lihat Mengubah cadangan atau salinan cadangan dan Memperbarui kebijakan pencadangan otomatis.
Penyimpanan pasca-pemulihan
Biaya penyimpanan untuk tabel baru yang dipulihkan dari cadangan sama dengan biaya penyimpanan untuk tabel mana pun.
Tabel yang dipulihkan dari cadangan mungkin tidak menggunakan jumlah penyimpanan yang sama dengan tabel aslinya, dan ukurannya mungkin berkurang setelah pemulihan. Perbedaan ukuran bergantung pada seberapa baru pemadatan terjadi pada cluster sumber dan cluster tujuan.
Karena pemadatan terjadi secara berkelanjutan, pemadatan mungkin terjadi segera setelah tabel dibuat. Namun, pemadatan dapat memerlukan waktu hingga satu minggu untuk terjadi.
Tabel baru yang dipulihkan dari cadangan tidak mewarisi kebijakan pembersihan sampah memori dari tabel sumber. Konfigurasikan kebijakan pembersihan sampah memori di tabel baru sebelum Anda mulai menulis data baru ke tabel. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi pembersihan sampah memori.
Biaya
Biaya jaringan standar berlaku saat menggunakan cadangan. Anda tidak dikenai biaya untuk operasi pencadangan, termasuk membuat, menyalin, atau memulihkan dari cadangan.
Biaya penyimpanan
Biaya penyimpanan berbeda untuk pencadangan standar dan hot backup.
Biaya penyimpanan cadangan standar
Untuk menyimpan cadangan standar atau salinan cadangan, Anda akan dikenai biaya tarif penyimpanan cadangan standar untuk region tempat cluster yang berisi cadangan atau salinan cadangan berada.
Cadangan standar adalah salinan logis lengkap dari tabel. Di balik layar, Bigtable mengoptimalkan penggunaan penyimpanan cadangan standar. Pengoptimalan ini berarti bahwa pencadangan standar bersifat inkremental — pencadangan ini berbagi penyimpanan fisik dengan tabel asli atau dengan cadangan tabel lainnya jika memungkinkan. Karena pengoptimalan penyimpanan bawaan Bigtable, biaya untuk menyimpan cadangan standar atau salinan cadangan terkadang lebih kecil daripada biaya salinan fisik lengkap cadangan tabel.
Pada instance yang direplikasi dengan pencadangan otomatis diaktifkan, biaya penyimpanan mungkin lebih tinggi karena pencadangan harian dibuat di setiap cluster. Di edisi Enterprise Plus, Anda dapat mengurangi biaya ini dengan mengaktifkan pencadangan otomatis hanya untuk cluster di lokasi tertentu.
Biaya penyimpanan hot backup
Untuk menyimpan hot backup, Anda akan dikenai biaya tarif penyimpanan hot backup untuk region tempat cluster yang berisi hot backup berada.
Karena hot backup disimpan dalam status siap, yang dioptimalkan untuk pemulihan cepat, Anda akan dikenai biaya untuk penyimpanan seluruh salinan logis tabel, bukan untuk bagian inkremental, seperti halnya dengan pencadangan standar.
Saat hot backup beralih ke pencadangan standar—termasuk saat durasi keep-hot dari hot backup otomatis berakhir—Anda akan dikenai tarif penyimpanan hot backup selama pencadangan masih hot, dan tarif penyimpanan pencadangan standar setelah transisi. Anda tidak dikenai biaya tambahan untuk transisi itu sendiri. Untuk memeriksa durasi keep-hot yang dikonfigurasi untuk tabel, lihat Melihat kebijakan pencadangan otomatis. Untuk mengetahui informasi selengkapnya tentang tarif penyimpanan cadangan, lihat Harga.
Biaya saat menyalin cadangan
Saat membuat salinan cadangan di region yang berbeda dengan cadangan sumber, Anda akan dikenai tarif jaringan standar untuk biaya penyalinan data ke cluster tujuan. Anda tidak dikenai biaya untuk traffic jaringan saat membuat salinan di region yang sama dengan cadangan sumber.
Biaya saat memulihkan
Saat Anda memulihkan tabel baru dari cadangan, Anda akan ditagih biaya jaringan untuk replikasi. Jika tabel baru berada dalam instance yang menggunakan replikasi, Anda akan dikenai biaya replikasi satu kali untuk data yang akan disalin ke semua cluster dalam instance.
Jika Anda memulihkan ke instance yang berbeda dengan tempat cadangan dibuat, dan instance cadangan serta instance tujuan tidak memiliki setidaknya satu cluster di region yang sama, Anda akan dikenai biaya satu kali untuk salinan data awal ke cluster tujuan dengan tarif jaringan standar.
CMEK
Saat Anda membuat cadangan di cluster yang dilindungi oleh kunci enkripsi yang dikelola pelanggan (CMEK), cadangan akan disematkan ke versi utama kunci CMEK cluster pada saat cadangan dibuat. Setelah cadangan dibuat, kunci dan versi kuncinya tidak dapat diubah, meskipun kunci KMS dirotasi.
Saat Anda memulihkan dari cadangan, versi kunci yang disematkan ke cadangan harus diaktifkan agar proses dekripsi cadangan berhasil. Tabel baru dilindungi dengan versi utama terbaru dari kunci CMEK untuk setiap cluster dalam instance tujuan. Jika Anda ingin memulihkan dari cadangan yang dilindungi CMEK ke instance yang berbeda, instance tujuan juga harus dilindungi CMEK, tetapi tidak perlu memiliki konfigurasi CMEK yang sama dengan instance sumber.
Pertimbangan replikasi
Bagian ini menjelaskan konsep tambahan yang perlu dipahami saat mencadangkan dan memulihkan tabel dalam instance yang menggunakan replikasi.
Replikasi dan pencadangan
Saat membuat cadangan tabel secara manual di instance yang direplikasi, Anda memilih cluster tempat Anda ingin membuat dan menyimpan cadangan. Untuk tabel dengan pencadangan otomatis yang diaktifkan, pencadangan harian dibuat di setiap cluster dalam instance. Di edisi Enterprise Plus, Anda dapat membatasi pencadangan otomatis ke cluster hanya di lokasi tertentu.
Anda tidak perlu berhenti menulis ke cluster yang berisi cadangan, tetapi Anda harus memahami cara Bigtable menangani penulisan yang direplikasi ke cluster.
Cadangan adalah salinan tabel dalam statusnya di cluster tempat cadangan disimpan, pada saat cadangan dibuat. Data tabel yang belum direplikasi dari cluster lain dalam instance tidak disertakan dalam cadangan.
Setiap pencadangan memiliki waktu mulai dan waktu berakhir. Operasi tulis yang dikirim ke cluster sesaat sebelum atau selama operasi pencadangan mungkin tidak disertakan dalam cadangan. Dua faktor yang berkontribusi pada ketidakpastian ini:
- Operasi tulis mungkin dikirim ke bagian tabel yang telah disalin oleh cadangan.
- Penulisan ke cluster lain mungkin belum direplikasi ke cluster yang berisi cadangan.
Dengan kata lain, ada kemungkinan bahwa beberapa penulisan dengan stempel waktu sebelum waktu pencadangan mungkin tidak disertakan dalam pencadangan.
Jika inkonsistensi ini tidak dapat diterima untuk persyaratan bisnis Anda, Anda dapat menggunakan token konsistensi dengan permintaan tulis untuk memastikan bahwa semua penulisan yang direplikasi disertakan dalam cadangan.
Cadangan tabel yang direplikasi yang dibuat sebagai bagian dari pencadangan otomatis bukanlah salinan persis satu sama lain, karena waktu pencadangan dapat bervariasi dari satu cluster ke cluster lainnya.
Replikasi dan pemulihan
Saat Anda memulihkan cadangan ke tabel baru, replikasi ke dan dari cluster lain dalam instance akan segera dimulai setelah operasi pemulihan selesai di cluster tujuan.
Performa
Saat membuat cadangan, gunakan praktik terbaik berikut untuk memastikan performa Anda tetap optimal.
Performa saat mencadangkan
Membuat cadangan biasanya memerlukan waktu kurang dari satu menit, meskipun dapat memerlukan waktu hingga satu jam. Dalam keadaan normal, pembuatan cadangan tidak memengaruhi performa penayangan.
Untuk performa yang optimal, jangan membuat cadangan satu tabel lebih dari sekali setiap lima menit. Membuat cadangan lebih sering berpotensi menyebabkan peningkatan latensi penyaluran yang dapat diamati.
Performa saat memulihkan
Memulihkan dari cadangan ke tabel dalam instance cluster tunggal memerlukan waktu beberapa menit. Dalam instance yang direplikasi, pemulihan memerlukan waktu lebih lama karena data harus disalin ke semua cluster. Bigtable selalu memilih rute yang paling efisien untuk menyalin data.
Jika Anda memulihkan ke instance yang berbeda dari tempat cadangan dibuat, operasi pemulihan akan memerlukan waktu lebih lama daripada jika Anda memulihkan ke instance yang sama. Hal ini terutama berlaku jika instance tujuan tidak memiliki cluster di zona yang sama dengan cluster tempat cadangan dibuat.
Tabel yang lebih besar memerlukan waktu lebih lama untuk dipulihkan daripada tabel yang lebih kecil.
Jika memiliki instance SSD, Anda mungkin awalnya akan mengalami latensi baca yang lebih tinggi, bahkan setelah pemulihan selesai, saat tabel dioptimalkan. Anda dapat memeriksa status kapan saja selama operasi pemulihan untuk melihat apakah pengoptimalan masih dalam proses.
Jika Anda memulihkan ke instance yang berbeda dari tempat cadangan dibuat, instance tujuan dapat menggunakan penyimpanan HDD atau SSD. Instance ini tidak perlu menggunakan jenis penyimpanan yang sama dengan instance sumber.
Kontrol akses
Izin IAM mengontrol akses ke operasi pencadangan dan pemulihan. Izin pencadangan berada di level instance dan berlaku untuk semua cadangan dalam instance.
Akun yang Anda gunakan untuk membuat cadangan tabel harus memiliki izin untuk membaca tabel dan membuat cadangan di instance tempat tabel berada (instance sumber).
Akun yang Anda gunakan untuk menyalin cadangan harus memiliki izin untuk membaca cadangan sumber dan membuat cadangan di instance dan project tujuan.
Akun yang Anda gunakan untuk memulihkan tabel baru dari cadangan harus memiliki izin untuk membuat tabel di instance yang Anda pulihkan.
| Tindakan | Izin IAM yang diperlukan |
|---|---|
| Membuat cadangan | bigtable.tables.readRows, bigtable.backups.create |
| Mendapatkan cadangan | bigtable.backups.get |
| Mencantumkan cadangan | bigtable.backups.list |
| Menghapus cadangan | bigtable.backups.delete |
| Memperbarui cadangan | bigtable.backups.update |
| Menyalin cadangan | bigtable.backups.read, bigtable.backups.create |
| Memulihkan dari cadangan ke tabel baru | bigtable.tables.create, bigtable.backups.restore |
| Mendapatkan operasi | bigtable.instances.get |
| Mencantumkan operasi | bigtable.instances.get |
Praktik terbaik
Sebelum Anda membuat strategi pencadangan, pertimbangkan praktik terbaik berikut. Untuk mengetahui informasi selengkapnya tentang perencanaan disaster recovery, lihat bagian Bigtable di Merancang disaster recovery untuk pemadaman infrastruktur cloud.
Membuat cadangan
- Jangan mencadangkan tabel lebih sering dari sekali setiap lima menit.
- Saat Anda mencadangkan tabel yang menggunakan replikasi, pilih cluster untuk menyimpan
cadangan setelah mempertimbangkan faktor-faktor berikut:
- Biaya. Satu cluster di instance Anda mungkin berada di region dengan biaya yang lebih rendah daripada cluster lainnya.
- Kedekatan dengan server aplikasi Anda. Anda sebaiknya menyimpan cadangan sedekat mungkin dengan aplikasi penyaluran.
- Jika Anda perlu memastikan bahwa semua penulisan yang direplikasi disertakan dalam cadangan saat Anda mencadangkan tabel dalam instance yang menggunakan replikasi, gunakan token konsistensi dengan permintaan tulis Anda.
Memulihkan dari cadangan
- Rencanakan terlebih dahulu nama tabel baru jika Anda perlu memulihkan dari cadangan. Poin utamanya adalah bersiaplah terlebih dahulu sehingga Anda tidak perlu memutuskan saat menghadapi masalah.
- Jika Anda memulihkan tabel karena alasan selain penghapusan yang tidak disengaja, pastikan semua pembacaan dan penulisan mengarah ke tabel baru sebelum Anda menghapus tabel asli.
- Jika Anda berencana memulihkan ke instance lain, buat instance tujuan sebelum memulai operasi pemulihan cadangan.
- Untuk menghindari pemulihan tabel yang lambat, tunggu hingga operasi pemulihan selesai sebelum Anda memulai pemulihan lain untuk tabel sumber yang sama di zona yang sama.
- Tunggu setidaknya satu jam setelah pembuatan sebelum Anda memulihkan dari cadangan standar. Jika Anda perlu memulihkan lebih cepat, gunakan hot backup.
Kuota dan batas
Permintaan pencadangan dan pemulihan serta penyimpanan cadangan tunduk pada kuota dan batas Bigtable.
Batasan
Batasan berikut berlaku untuk pencadangan Bigtable:
Umum
- Anda tidak dapat membaca langsung dari cadangan.
- Cadangan adalah versi tabel dalam satu cluster pada waktu tertentu. Cadangan tidak mewakili status yang konsisten. Hal yang sama juga berlaku untuk cadangan tabel yang sama di cluster yang berbeda.
- Anda tidak dapat mencadangkan lebih dari satu tabel dalam satu operasi.
- Anda tidak dapat mengekspor, menyalin, atau memindahkan cadangan Bigtable ke layanan lain, seperti Cloud Storage.
- Cadangan Bigtable hanya berisi data Bigtable dan tidak terintegrasi dengan atau terkait dengan cadangan untuk layanan Google lainnya.
- Anda tidak dapat membuat cadangan tampilan.
Memulihkan
- Anda tidak dapat memulihkan dari cadangan ke tabel yang ada.
- Anda hanya dapat memulihkan ke instance yang sudah ada. Bigtable tidak membuat instance baru saat memulihkan dari cadangan. Jika instance tujuan yang ditentukan dalam permintaan pemulihan tidak ada, operasi pemulihan akan gagal.
- Jika Anda memulihkan dari cadangan ke tabel di cluster SSD, lalu menghapus tabel yang baru dipulihkan, penghapusan tabel mungkin memerlukan waktu beberapa saat karena Bigtable menunggu pengoptimalan tabel selesai.
Menyalin
- Anda tidak dapat membuat salinan cadangan yang akan berakhir dalam waktu 24 jam.
- Anda tidak dapat membuat salinan dari salinan cadangan.
CMEK
- Cadangan yang dilindungi oleh CMEK harus dipulihkan ke tabel baru dalam instance yang dilindungi CMEK.
- Saat Anda membuat salinan cadangan yang dilindungi CMEK, cluster tujuan juga harus dilindungi CMEK.