Ringkasan pencadangan Bigtable
Halaman ini menyajikan ringkasan cadangan Bigtable. Konten yang disajikan di sini ditujukan untuk administrator dan developer Bigtable.
Cadangan Bigtable memungkinkan Anda menyimpan salinan skema dan data tabel, lalu memulihkannya dari cadangan ke tabel baru nanti. Anda dapat membuat cadangan secara manual atau mengaktifkan pencadangan otomatis untuk mengizinkan Bigtable membuat pencadangan harian. Anda juga dapat membuat salinan cadangan.
Sebelum membaca halaman ini, Anda harus sudah memahami Ringkasan Bigtable dan Mengelola tabel.
Features
- Terintegrasi sepenuhnya: Pencadangan ditangani sepenuhnya oleh layanan Bigtable, tanpa perlu mengimpor atau mengekspor.
- Inkremental: Cadangan berbagi penyimpanan fisik dengan tabel sumber dan cadangan tabel lainnya.
- Hemat biaya: Dengan menggunakan cadangan Bigtable, Anda dapat menghindari biaya yang terkait dengan ekspor, penyimpanan, dan impor data menggunakan layanan lain.
- Masa berlaku otomatis: Setiap cadangan memiliki tanggal habis masa berlaku yang ditentukan pengguna, maksimal 90 hari setelah cadangan dibuat. Anda dapat menyimpan salinan cadangan hingga 30 hari.
- Opsi pemulihan yang fleksibel: Anda dapat memulihkan dari cadangan ke tabel dalam instance yang berbeda dari tempat cadangan dibuat.
- Pencadangan otomatis: Aktifkan pencadangan otomatis untuk memungkinkan Bigtable membuat pencadangan harian.
Kasus penggunaan
Cadangan berguna untuk kasus penggunaan berikut:
- Kelanjutan bisnis
- Kepatuhan terhadap peraturan
- Pengujian dan pengembangan
- Pemulihan dari bencana
Pertimbangkan skenario pemulihan dari bencana berikut:
| Sasaran | Strategi pencadangan | Strategi pemulihan |
|---|---|---|
| Lindungi dari error manusia: Anda sebaiknya selalu menyiapkan cadangan data terbaru jika terjadi penghapusan atau kerusakan yang tidak disengaja. | Tentukan jadwal pembuatan cadangan yang tepat untuk kebutuhan bisnis Anda, seperti harian. Jika ingin, 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 yang dibatasi. | Pulihkan ke tabel baru dari cadangan atau salinan, lalu rutekan ulang permintaan ke tabel baru. |
| Ketidaktersediaan zona: Anda perlu memastikan bahwa jika zona Google Cloud menjadi tidak tersedia, sekalipun terjadi, data Anda masih tersedia. | Buat pencadangan secara teratur, misalnya setiap hari. Kemudian, buat salinan cadangan terbaru secara berkala dan simpan di satu atau beberapa cluster di zona berbeda (secara opsional dalam instance atau project berbeda). | Jika zona tempat cluster penayangan Anda tidak tersedia, pulihkan salinan cadangan jarak jauh ke tabel baru, lalu rutekan ulang permintaan ke tabel baru. |
| Kerusakan data: Menggunakan cadangan untuk memulihkan beberapa data tabel, seperti saat bagian dari tabel sumber mengalami kerusakan. | Buat cadangan data Anda secara berkala. | Memulihkan dari cadangan ke tabel baru pada instance baru. Kemudian, tulis aplikasi menggunakan library klien Bigtable atau Dataflow yang membaca dari tabel baru, lalu menulis kembali data tersebut ke tabel sumber. Setelah data disalin ke tabel asal, hapus tabel baru. |
Bekerja dengan cadangan Bigtable
Tindakan berikut tersedia untuk cadangan Bigtable. Dalam semua kasus, project tujuan, instance, dan cluster tujuan harus sudah ada. Anda tidak dapat membuat resource ini sebagai bagian dari operasi pencadangan. Anda tidak dapat membuat salinan salinan cadangan.
| Tindakan | Opsi tujuan iklan |
|---|---|
| Buat cadangan |
|
| Memulihkan dari cadangan ke tabel baru |
|
| Menyalin cadangan |
|
Lihat Mengelola cadangan untuk mengetahui petunjuk langkah demi langkah tentang tindakan ini serta operasi seperti memperbarui dan menghapus cadangan.
Gunakan perintah berikut untuk bekerja dengan cadangan Bigtable:
- Konsol Google Cloud
- Google Cloud CLI
- Library klien Cloud Bigtable
Anda juga dapat mengakses Cloud Bigtable Admin API secara langsung, tetapi kami sangat menyarankan Anda melakukannya hanya jika Anda tidak dapat menggunakan library klien Cloud Bigtable yang melakukan panggilan cadangan ke API.
Cara kerja cadangan Bigtable
Membuat cadangan melibatkan pemahaman tentang penyimpanan cadangan dan retensi di Bigtable.
Penyimpanan cadangan
Pencadangan tabel dapat dibuat secara manual, atau Anda dapat mengaktifkan pencadangan otomatis agar Bigtable dapat mengambil pencadangan harian. Cadangan tabel disimpan di cluster pada sebuah instance. Dalam kasus pencadangan manual, cadangan tabel Anda disimpan di satu cluster pada instance yang Anda pilih. Jika pencadangan otomatis diaktifkan, pencadangan tabel akan disimpan di setiap cluster dalam instance.
Cadangan tabel mencakup semua data yang ada di 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 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 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 membiarkan masa berlakunya habis saat Anda tidak lagi memerlukannya. Penyimpanan cadangan tidak mengurangi batas penyimpanan node untuk project.
Data dalam cadangan dienkripsi.
Retensi
Anda dapat menentukan periode retensi data hingga 90 hari untuk pencadangan. Jika Anda membuat salinan cadangan, periode retensi data maksimum untuk salinan tersebut adalah 30 hari sejak salinan dibuat.
Untuk tabel dengan pencadangan otomatis yang diaktifkan, periode retensi data default adalah 3 hari. Anda dapat mengubah periode retensi data untuk cadangan hingga 90 hari dari waktu pembuatan cadangan.
Penyimpanan setelah 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 seperti tabel asli, dan mungkin ukurannya akan berkurang setelah pemulihan. Perbedaan ukuran bergantung pada seberapa baru pemadatan terjadi pada cluster sumber dan cluster tujuan.
Karena pemadatan terjadi secara bertahap, mungkin pemadatan akan terjadi segera setelah tabel dibuat. Namun, pemadatan dapat memerlukan waktu hingga satu minggu.
Biaya
Biaya jaringan standar berlaku saat bekerja dengan cadangan. Anda tidak dikenai biaya untuk operasi pencadangan, termasuk pembuatan, penyalinan, atau pemulihan dari cadangan.
Biaya penyimpanan
Untuk menyimpan cadangan atau salinan cadangan, Anda akan dikenai biaya tarif penyimpanan cadangan standar untuk region tempat cluster yang berisi salinan cadangan atau cadangan berada.
Cadangan adalah salinan logis dari suatu tabel. Di balik layar, {i>Bigtable<i} mengoptimalkan penggunaan penyimpanan cadangan. Dengan pengoptimalan ini, cadangan bersifat inkremental — berbagi penyimpanan fisik dengan tabel asli atau dengan cadangan lain dari tabel jika memungkinkan. Karena pengoptimalan penyimpanan bawaan Bigtable, biaya untuk menyimpan cadangan atau salinan cadangan terkadang lebih rendah daripada biaya salinan fisik penuh cadangan tabel.
Dalam instance replika dengan pencadangan otomatis diaktifkan, biaya penyimpanan mungkin lebih tinggi karena pencadangan dibuat di setiap cluster setiap hari.
Biaya saat menyalin cadangan
Jika 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 memulihkan tabel baru dari cadangan, Anda akan dikenai biaya jaringan 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 tersebut.
Jika Anda memulihkan ke instance yang berbeda dengan tempat cadangan dibuat, dan instance pencadangan 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
Jika 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 kunci tersebut diambil. Setelah cadangan dibuat, kunci dan versi kuncinya tidak dapat diubah, meskipun kunci KMS dirotasi.
Saat Anda memulihkan dari cadangan, versi kunci tempat cadangan disematkan harus diaktifkan agar proses dekripsi cadangan berhasil. Tabel baru dilindungi dengan versi utama kunci CMEK terbaru 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 harus memiliki konfigurasi CMEK yang sama dengan instance sumber.
Pertimbangan replikasi
Bagian ini menjelaskan konsep tambahan yang harus dipahami saat mencadangkan dan memulihkan tabel dalam instance yang menggunakan replikasi.
Replikasi dan pencadangan
Saat mencadangkan tabel secara manual dalam instance yang direplikasi, Anda memilih cluster tempat Anda ingin membuat dan menyimpan cadangan. Untuk tabel yang mengaktifkan pencadangan otomatis, pencadangan harian akan diambil pada setiap cluster di instance.
Anda tidak perlu berhenti menulis ke cluster yang berisi cadangan, tetapi Anda harus memahami cara penanganan 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 cadangan memiliki waktu mulai dan berakhir. Operasi tulis yang dikirim ke cluster sesaat 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.
- Penulisan ke cluster lain mungkin belum direplikasi ke cluster yang berisi cadangan.
Dengan kata lain, ada kemungkinan beberapa penulisan dengan stempel waktu sebelum waktu pencadangan mungkin tidak disertakan dalam cadangan. Hal ini juga berlaku untuk cadangan yang dibuat ketika pencadangan otomatis diaktifkan. Cadangan instance bukanlah salinan persis satu sama lain karena waktu pencadangan dapat bervariasi antara cluster yang satu dengan cluster yang lain.
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.
Replikasi dan pemulihan
Saat Anda memulihkan cadangan ke tabel baru, replikasi ke dan dari cluster lain dalam instance akan dimulai segera setelah operasi pemulihan selesai di cluster tujuan.
Performa
Saat membuat cadangan, gunakan praktik terbaik berikut untuk memastikan performa Anda tetap optimal.
Performa saat mencadangkan
Pembuatan cadangan biasanya memerlukan waktu kurang dari satu menit, tetapi juga 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 dapat berpotensi menyebabkan peningkatan latensi penayangan yang dapat diamati.
Performa saat memulihkan
Pemulihan 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 memakan waktu lebih lama dibandingkan 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 membutuhkan waktu pemulihan yang lebih lama daripada tabel yang lebih kecil.
Jika memiliki instance SSD, Anda mungkin awalnya mengalami latensi pembacaan 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. Aplikasi tidak perlu menggunakan jenis penyimpanan yang sama dengan instance sumber.
Kontrol akses
Izin IAM mengontrol akses ke operasi pencadangan dan pemulihan. Izin pencadangan berada pada 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 jika tabel berada (instance sumber).
Akun yang Anda gunakan untuk menyalin cadangan harus memiliki izin untuk membaca cadangan sumber dan membuat cadangan di project dan instance tujuan.
Akun yang Anda gunakan untuk memulihkan tabel baru dari cadangan harus memiliki izin untuk membuat tabel pada instance tempat Anda memulihkan.
| Tindakan | Izin IAM yang diperlukan |
|---|---|
| Buat cadangan | bigtable.tables.readRows, bigtable.backups.create |
| Dapatkan cadangan | bigtable.backups.get |
| Mencantumkan pencadangan | 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 cadangan.
Membuat cadangan
- Jangan mencadangkan tabel lebih 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 berbiaya lebih rendah daripada yang lain.
- Kedekatan dengan server aplikasi Anda. Sebaiknya simpan cadangan sedekat mungkin dengan aplikasi penyaluran.
- Pemanfaatan penyimpanan. Anda memerlukan ruang penyimpanan yang cukup untuk menyimpan cadangan Anda saat terakumulasi. Bergantung pada workload, Anda dapat memiliki cluster dengan ukuran berbeda atau dengan penggunaan disk yang berbeda. Hal ini dapat memengaruhi cluster mana yang Anda pilih.
- 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 sebelumnya nama yang akan Anda berikan untuk tabel baru jika Anda perlu memulihkannya dari cadangan. Hal yang penting adalah Anda harus mempersiapkan diri sebelumnya sehingga Anda tidak perlu memutuskan ketika Anda sedang menghadapi masalah.
- Jika Anda memulihkan tabel untuk alasan selain penghapusan yang tidak disengaja, pastikan semua operasi baca dan tulis dipindahkan ke tabel baru sebelum menghapus tabel asli.
- Jika Anda berencana untuk melakukan pemulihan 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 yang dapat diskalakan.
Batasan
Batasan berikut berlaku pada cadangan Bigtable:
Umum
- Anda tidak dapat membaca langsung dari cadangan.
- Cadangan adalah versi tabel dalam satu cluster pada waktu tertentu. Cadangan tidak merepresentasikan status yang konsisten. Hal yang sama juga berlaku untuk cadangan tabel yang sama di cluster 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.
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 tabel 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 masa berlakunya akan habis dalam waktu 24 jam.
- Anda tidak dapat membuat salinan salinan cadangan.
CMEK
- Cadangan yang dilindungi oleh CMEK harus dipulihkan ke tabel baru pada instance yang dilindungi CMEK.
- Saat Anda membuat salinan cadangan yang dilindungi CMEK, cluster tujuan juga harus dilindungi CMEK.