Ringkasan pencadangan Bigtable
Halaman ini menyediakan ringkasan pencadangan Bigtable. Konten yang disajikan di sini ditujukan untuk administrator dan developer Bigtable.
Cadangan memungkinkan Anda menyimpan salinan skema dan data tabel, lalu memulihkannya dari cadangan ke tabel baru di lain waktu. Bigtable menawarkan dua jenis pencadangan. Jenis pencadangan yang Anda buat bergantung pada persyaratan disaster recovery (DR) dan 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 meningkatkan performa tabel ke tingkat produksi. Untuk informasi selengkapnya, lihat Performa saat memulihkan
- Pencadangan panas memberikan pemulihan yang paling efisien untuk performa tingkat produksi dan penayangan latensi rendah. Untuk informasi selengkapnya, lihat Pencadangan panas
Anda dapat membuat cadangan dengan cara berikut:
- Mengaktifkan pencadangan otomatis agar Bigtable membuat pencadangan harian untuk Anda
- Membuat cadangan on demand, menggunakan konsol Google Cloud, gcloud CLI, atau library klien Bigtable
- Membuat salinan cadangan
Sebelum membaca halaman ini, Anda harus sudah memahami ringkasan Bigtable dan Mengelola tabel.
Fitur
- Terintegrasi sepenuhnya: Pencadangan ditangani sepenuhnya oleh layanan Bigtable, tanpa perlu mengimpor atau mengekspor.
- Inkremental: Cadangan memiliki penyimpanan fisik yang sama dengan tabel sumber dan cadangan tabel lainnya.
- Hemat biaya: Dengan menggunakan cadangan Bigtable, Anda dapat menghindari biaya yang terkait dengan mengekspor, menyimpan, dan mengimpor data menggunakan layanan lain.
- Masa berlaku otomatis: Setiap cadangan memiliki tanggal habis masa berlaku yang ditentukan pengguna yang dapat berlangsung hingga 90 hari setelah cadangan dibuat. Anda dapat menyimpan salinan cadangan hingga 30 hari.
- Opsi pemulihan yang fleksibel: Anda dapat memulihkan dari cadangan ke tabel di instance lain dari tempat cadangan dibuat.
- Pencadangan otomatis: Aktifkan pencadangan otomatis agar Bigtable dapat membuat pencadangan harian.
- Pencadangan data aktif: Rencanakan pemulihan dari bencana dengan pencadangan data aktif yang siap produksi.
Kasus penggunaan
Pencadangan berguna untuk kasus penggunaan berikut:
- Kelanjutan bisnis
- Kepatuhan terhadap peraturan
- Pengujian dan pengembangan
- Pemulihan dari bencana
Pertimbangkan skenario disaster recovery berikut:
| Sasaran | Strategi pencadangan | Strategi pemulihan |
|---|---|---|
| Lindungi dari kesalahan manusia: Anda harus selalu memiliki cadangan data terbaru jika terjadi penghapusan atau kerusakan data yang tidak disengaja. | Tentukan jadwal pembuatan cadangan yang sesuai dengan kebutuhan bisnis Anda, seperti 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 di project atau instance dengan izin akses terbatas. | Pulihkan ke tabel baru dari cadangan atau salinan, lalu arahkan ulang permintaan ke tabel baru. |
| Ketidaktersediaan zona: Anda harus memastikan bahwa jika zona Google Cloud tidak tersedia, data Anda masih tersedia. | Aktifkan pencadangan otomatis agar Bigtable dapat membuat cadangan 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 penayangan Anda tidak tersedia, pulihkan dari salinan cadangan jarak jauh ke tabel baru, lalu alihkan permintaan ke tabel baru. |
| Kerusakan data: Gunakan cadangan untuk memulihkan beberapa data tabel, seperti saat sebagian tabel sumber telah rusak. | Aktifkan replikasi dan pencadangan otomatis untuk membuat pencadangan harian di beberapa region, sehingga jika tabel rusak di satu cluster, Anda memiliki satu atau beberapa pencadangan yang tidak berbagi penyimpanan di cluster yang rusak. | Memulihkan 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. | Selalu pertahankan cadangan panas terbaru tabel Anda. | Pulihkan ke tabel baru dari hot backup, lalu arahkan ulang 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 mengonversi hot backup menjadi cadangan standar, tetapi tidak dapat mengonversi cadangan standar menjadi hot backup.
Anda tidak dapat membuat cadangan panas menggunakan pencadangan otomatis, dan Anda tidak dapat membuat cadangan panas di cluster HDD.
Menangani pencadangan 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 ke tabel baru |
|
|
| Menyalin cadangan1, 2 |
|
|
Lihat Mengelola pencadangan untuk mendapatkan petunjuk langkah demi langkah tentang tindakan ini serta operasi seperti memperbarui dan menghapus pencadangan.
Penyimpanan cadangan
Cadangan tabel yang Anda buat sesuai permintaan disimpan di satu cluster yang Anda tentukan. Jika pencadangan otomatis diaktifkan, pencadangan akan dibuat dan disimpan di setiap cluster dalam instance.
Cadangan tabel mencakup semua data yang ada dalam tabel pada saat cadangan dibuat, di cluster tempat cadangan dibuat. Cadangan tidak akan lebih besar dari ukuran tabel sumber pada saat cadangan dibuat.
Pencadangan standar bersifat inkremental. Jumlah penyimpanan yang digunakan cadangan standar bergantung pada ukuran tabel dan sejauh mana cadangan 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.
Di sisi lain, hot backup adalah salinan lengkap yang menggunakan jumlah penyimpanan yang sama pada saat pencadangan, berapa pun perubahan tabel sumber. Cadangan dianggap hot karena penyimpanannya yang dioptimalkan, yang memungkinkan Anda memulihkan ke tingkat performa produksi secara efisien.
Anda dapat membuat hingga 150 cadangan per tabel per cluster.
Anda dapat menghapus tabel yang memiliki cadangan. Untuk melindungi cadangan, Anda tidak dapat menghapus cluster yang berisi cadangan, dan Anda tidak dapat menghapus 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 masa berlakunya jika tidak lagi diperlukan. Penyimpanan cadangan tidak dihitung dalam batas penyimpanan node untuk project.
Data dalam cadangan dienkripsi.
Retensi
Anda dapat menentukan periode retensi hingga 90 hari untuk cadangan. Jika Anda membuat salinan cadangan, periode retensi maksimum untuk salinan tersebut adalah 30 hari sejak salinan dibuat.
Untuk tabel dengan pencadangan otomatis yang diaktifkan, periode retensi default-nya adalah tiga hari. Anda dapat mengubah periode retensi untuk cadangan agar disimpan hingga 90 hari setelah waktu pembuatan cadangan.
Penyimpanan pasca-pemulihan
Biaya penyimpanan untuk tabel baru yang dipulihkan dari cadangan sama dengan biaya untuk tabel apa pun.
Tabel yang dipulihkan dari cadangan mungkin tidak menggunakan jumlah penyimpanan yang sama dengan tabel asli, dan ukurannya mungkin berkurang setelah pemulihan. Perbedaan ukuran bergantung pada seberapa baru pengompresian terjadi di cluster sumber dan cluster tujuan.
Karena pemadatan terjadi secara rolling, 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 tabel sumber. Konfigurasikan kebijakan pembersihan sampah di tabel baru sebelum Anda mulai menulis data baru ke tabel. Untuk informasi selengkapnya, lihat Mengonfigurasi pembersihan sampah memori.
Biaya
Biaya jaringan standar berlaku saat menggunakan pencadangan. Anda tidak dikenai biaya untuk operasi pencadangan, termasuk membuat, menyalin, atau memulihkan dari cadangan.
Biaya penyimpanan
Biaya penyimpanan berbeda untuk cadangan standar dan cadangan panas.
Biaya penyimpanan cadangan standar
Untuk menyimpan cadangan standar atau salinan cadangan, Anda akan dikenai tarif penyimpanan cadangan standar untuk region tempat cluster yang berisi cadangan atau salinan cadangan berada.
Cadangan standar adalah salinan logika lengkap dari tabel. Di balik layar, Bigtable mengoptimalkan pemanfaatan penyimpanan cadangan standar. Pengoptimalan ini berarti bahwa pencadangan standar bersifat inkremental — pencadangan ini berbagi penyimpanan fisik dengan tabel asli atau dengan pencadangan tabel lainnya jika memungkinkan. Karena pengoptimalan penyimpanan bawaan Bigtable, biaya untuk menyimpan cadangan standar atau salinan cadangan terkadang lebih rendah daripada biaya salinan fisik lengkap cadangan tabel.
Pada instance yang direplikasi dengan pencadangan otomatis diaktifkan, biaya penyimpanan mungkin lebih tinggi karena cadangan dibuat di setiap cluster setiap hari.
Biaya penyimpanan hot backup
Untuk menyimpan cadangan panas, Anda akan dikenai tarif penyimpanan cadangan panas untuk region tempat cluster yang berisi cadangan panas berada.
Karena pencadangan data aktif disimpan dalam status siap, yang dioptimalkan untuk pemulihan cepat, Anda akan ditagih untuk penyimpanan seluruh salinan logis tabel, bukan untuk bagian inkremental, seperti yang Anda lakukan dengan pencadangan standar.
Biaya saat menyalin cadangan
Saat membuat salinan cadangan di region yang berbeda dengan cadangan sumber, Anda akan dikenai tarif jaringan standar untuk biaya menyalin data ke cluster tujuan. Anda tidak akan dikenai biaya untuk traffic jaringan saat membuat salinan di region yang sama dengan cadangan sumber.
Biaya saat memulihkan
Saat memulihkan tabel baru dari cadangan, Anda akan ditagih untuk biaya jaringan replikasi. Jika tabel baru berada dalam instance yang menggunakan replikasi, Anda akan dikenai biaya replikasi satu kali agar data dapat 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 diambil. Setelah cadangan dibuat, kunci dan versi kuncinya tidak dapat diubah, meskipun kunci KMS dirotasi.
Saat Anda memulihkan dari cadangan, versi kunci yang digunakan untuk menyematkan cadangan harus diaktifkan agar proses dekripsi cadangan berhasil. Tabel baru dilindungi dengan versi utama kunci CMEK terbaru untuk setiap cluster di instance tujuan. Jika Anda ingin memulihkan dari cadangan yang dilindungi CMEK ke instance lain, 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 di instance yang menggunakan replikasi.
Replikasi dan pencadangan
Saat mencadangkan tabel secara manual di instance yang direplikasi, Anda memilih cluster tempat Anda ingin membuat dan menyimpan cadangan. Untuk tabel dengan pencadangan otomatis yang diaktifkan, cadangan harian akan dibuat di setiap cluster dalam instance.
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 pencadangan.
Setiap pencadangan memiliki waktu mulai dan waktu berakhir. Operasi tulis yang dikirim ke cluster segera sebelum atau selama operasi pencadangan mungkin tidak disertakan dalam pencadangan. Ada dua faktor yang berkontribusi pada ketidakpastian ini:
- Operasi tulis mungkin dikirim ke bagian tabel yang telah disalin oleh cadangan.
- Operasi tulis ke cluster lain mungkin belum direplikasi ke cluster yang berisi cadangan.
Dengan kata lain, ada kemungkinan beberapa operasi tulis 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 operasi tulis yang direplikasi disertakan dalam pencadangan.
Pencadangan tabel yang direplikasi yang dibuat sebagai bagian dari pencadangan otomatis bukan salinan persis satu sama lain, karena waktu pencadangan dapat bervariasi dari cluster ke cluster.
Replikasi dan pemulihan
Saat Anda memulihkan cadangan ke tabel baru, replikasi ke dan dari cluster lain di 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 buat cadangan satu tabel lebih dari sekali setiap lima menit. Membuat cadangan lebih sering berpotensi menyebabkan peningkatan latensi penayangan yang dapat diamati.
Performa saat memulihkan
Memulihkan dari cadangan ke tabel dalam instance cluster tunggal memerlukan waktu beberapa menit. Pada instance yang direplikasi, pemulihan memerlukan waktu lebih lama karena data harus disalin ke semua cluster. Bigtable selalu memilih rute yang paling hemat energi 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 pencadangan dibuat.
Tabel yang lebih besar memerlukan waktu lebih lama untuk dipulihkan daripada tabel yang lebih kecil.
Jika memiliki instance SSD, Anda mungkin awalnya 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 tingkat 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 tempat Anda memulihkan.
| 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
Praktik terbaik berikut harus diperhatikan sebelum membuat strategi pencadangan.
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. Sebaiknya simpan cadangan sedekat mungkin dengan aplikasi penyaluran.
- Pemanfaatan penyimpanan. Anda memerlukan ruang penyimpanan yang cukup untuk menyimpan cadangan seiring bertambahnya ukuran. Bergantung pada workload, Anda dapat memiliki cluster dengan ukuran yang berbeda atau dengan penggunaan disk yang berbeda. Hal ini dapat memengaruhi klaster yang Anda pilih.
- Jika Anda perlu memastikan bahwa semua operasi tulis yang direplikasi disertakan dalam pencadangan saat mencadangkan tabel di instance yang menggunakan replikasi, gunakan token konsistensi dengan permintaan tulis Anda.
Memulihkan dari cadangan
- Rencanakan nama tabel baru yang akan Anda beri nama jika perlu memulihkan dari cadangan. Poin utamanya adalah bersiap-siap terlebih dahulu sehingga Anda tidak perlu memutuskan saat menghadapi masalah.
- Jika Anda memulihkan tabel karena alasan selain penghapusan tidak disengaja, pastikan semua operasi baca dan tulis masuk ke tabel baru sebelum Anda menghapus tabel asli.
- Jika Anda berencana memulihkan ke instance lain, buat instance tujuan sebelum memulai operasi pemulihan cadangan.
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. Pencadangan tidak mewakili status yang konsisten. Hal yang sama juga berlaku untuk pencadangan 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 pencadangan 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.
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 untuk selesai karena Bigtable menunggu pengoptimalan tabel selesai.
Menyalin
- Anda tidak dapat membuat salinan cadangan yang akan berakhir masa berlakunya 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.