Ringkasan pencadangan Bigtable
Halaman ini memberikan ringkasan tentang pencadangan Bigtable. Konten yang ditampilkan 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 dua jenis pencadangan. Jenis cadangan yang Anda buat bergantung pada persyaratan pemulihan dari bencana (DR) dan jenis penyimpanan (HDD atau SSD) yang digunakan oleh 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 membuat tabel mencapai performa tingkat produksi. Untuk mengetahui informasi selengkapnya, lihat Performa saat memulihkan.
- Pencadangan aktif memberikan pemulihan yang paling efisien ke performa tingkat produksi dan penayangan latensi rendah. Untuk mengetahui informasi selengkapnya, lihat Backup aktif.
Anda dapat membuat cadangan dengan cara berikut:
- Aktifkan pencadangan otomatis agar Bigtable membuat cadangan harian untuk Anda.
- Buat cadangan sesuai permintaan, menggunakan Google Cloud konsol, gcloud CLI, atau library klien Bigtable.
- Buat 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 dan dapat mencapai 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 yang berbeda dari tempat cadangan dibuat.
- Pencadangan otomatis: Aktifkan pencadangan otomatis agar Bigtable dapat membuat cadangan harian.
- Pencadangan data aktif: Rencanakan pemulihan dari bencana dengan pencadangan data aktif yang siap produksi.
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 |
---|---|---|
Melindungi dari kesalahan manusia: Anda harus selalu memiliki cadangan data terbaru yang siap digunakan jika terjadi penghapusan atau kerusakan yang tidak disengaja. | Tentukan jadwal pembuatan cadangan yang tepat untuk kebutuhan bisnis Anda, seperti harian. Secara opsional, buat salinan berkala dari cadangan 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 alihkan kembali permintaan ke tabel baru. |
Ketidaktersediaan zona: Anda harus memastikan bahwa jika terjadi peristiwa yang tidak mungkin terjadi, yaitu Google Cloud zona menjadi tidak tersedia, data Anda tetap tersedia. | Aktifkan pencadangan otomatis agar Bigtable 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 menjadi tidak tersedia, pulihkan dari salinan cadangan jarak jauh ke tabel baru, lalu alihkan permintaan ke tabel baru. |
Kerusakan data: Gunakan cadangan untuk memulihkan sebagian data tabel, seperti 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 kembali data ke tabel sumber. Setelah data disalin ke tabel asli, hapus tabel baru. |
Pemulihan cepat: Pulihkan ke tingkat performa produksi penuh dengan cepat, sehingga meminimalkan waktu henti. | Selalu pertahankan cadangan aktif terbaru dari tabel Anda. | Pulihkan ke tabel baru dari cadangan aktif, lalu alihkan permintaan ke tabel baru. |
Pencadangan aktif
Cadangan aktif 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 cadangan aktif lebih cepat daripada memulihkan dari cadangan standar.
Anda dapat mengonversi cadangan aktif menjadi cadangan standar, tetapi Anda tidak dapat mengonversi cadangan standar menjadi cadangan aktif.
Anda tidak dapat membuat cadangan aktif menggunakan pencadangan otomatis, dan Anda tidak dapat membuat cadangan aktif di cluster HDD.
Bekerja dengan cadangan Bigtable
Tindakan berikut tersedia untuk cadangan 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 cadangan aktif |
|
|
Memulihkan dari cadangan standar atau aktif ke tabel baru |
|
|
Menyalin cadangan1, 2 |
|
Lihat Mengelola cadangan untuk petunjuk langkah demi langkah tentang tindakan ini serta operasi seperti memperbarui dan menghapus cadangan.
Gunakan hal berikut untuk mengelola 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, cadangan akan disimpan di setiap cluster dalam instance.
Jika cluster Anda melampaui batas yang direkomendasikan untuk penggunaan CPU atau penyimpanan saat Anda membuat cadangan, pembuatan cadangan Anda mungkin 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. Ukuran 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 seberapa besar 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 membiarkannya berakhir jika tidak lagi diperlukan. Penyimpanan cadangan tidak dihitung dalam batas penyimpanan node untuk suatu 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 adalah 30 hari sejak salinan dibuat.
Anda dapat mengubah periode retensi cadangan untuk menyimpannya hingga 90 hari setelah waktu pembuatan cadangan. Untuk mengetahui informasi selengkapnya, lihat Mengubah cadangan atau salinan cadangan.
Untuk tabel yang mengaktifkan pencadangan otomatis, periode retensi data adalah tujuh hari jika Anda menetapkan kebijakan menggunakan flag --enable-automated-backup
. Anda dapat menetapkan periode retensi kustom dengan
meneruskan tanda --automated-backup-retention-period
, yang menerima nilai
dari 3 hari hingga 90 hari. Untuk mengetahui informasi selengkapnya, lihat Memperbarui kebijakan pencadangan otomatis.
Penyimpanan setelah pemulihan
Biaya penyimpanan untuk tabel baru yang dipulihkan dari cadangan sama dengan biaya untuk tabel lainnya.
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 pemadatan terjadi di cluster sumber dan cluster tujuan.
Karena pemadatan terjadi secara berkelanjutan, pemadatan dapat terjadi segera setelah tabel dibuat. Namun, pemadatan dapat memerlukan waktu hingga satu minggu untuk terjadi.
Tabel baru yang dipulihkan dari cadangan tidak mewarisi kebijakan pengumpulan sampah tabel sumber. Konfigurasi kebijakan pengumpulan sampah 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 bekerja dengan cadangan. Anda tidak dikenai biaya untuk operasi pencadangan, termasuk membuat, menyalin, atau memulihkan dari cadangan.
Biaya penyimpanan
Biaya penyimpanan berbeda untuk cadangan standar dan cadangan aktif.
Biaya penyimpanan cadangan standar
Untuk menyimpan cadangan standar atau salinan cadangan, Anda akan ditagih tarif penyimpanan cadangan standar untuk region tempat cluster yang berisi cadangan atau salinan cadangan berada.
Cadangan standar adalah salinan logis lengkap dari suatu 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 kecil daripada biaya salinan fisik lengkap cadangan tabel.
Di instance yang direplikasi dengan pencadangan otomatis diaktifkan, biaya penyimpanan mungkin lebih tinggi karena cadangan dibuat di setiap cluster setiap hari.
Biaya penyimpanan cadangan aktif
Untuk menyimpan cadangan aktif, Anda akan ditagih tarif penyimpanan cadangan aktif untuk region tempat cluster yang berisi cadangan aktif berada.
Karena cadangan 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 terjadi pada cadangan standar.
Biaya saat menyalin cadangan
Saat Anda membuat salinan cadangan di region yang berbeda dengan cadangan sumber, Anda akan dikenai biaya tarif jaringan standar untuk biaya penyalinan data ke cluster tujuan. Anda tidak dikenai biaya 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 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 penyalinan 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 diambil. 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 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 harus 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 mencadangkan tabel secara manual di instance yang direplikasi, Anda memilih cluster tempat Anda ingin membuat dan menyimpan cadangan. Untuk tabel dengan pencadangan otomatis diaktifkan, pencadangan harian 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 cadangan.
Setiap pencadangan 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 menyebabkan 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 tidak disertakan dalam pencadangan.
Jika inkonsistensi ini tidak dapat diterima untuk persyaratan bisnis Anda, Anda dapat menggunakan token konsistensi dengan permintaan penulisan untuk memastikan bahwa semua penulisan yang direplikasi disertakan dalam cadangan.
Cadangan tabel yang direplikasi yang dibuat sebagai bagian dari pencadangan otomatis bukanlah salinan yang sama 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 memakan 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 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 paling efisien untuk menyalin data.
Jika Anda memulihkan ke instance yang berbeda dari tempat cadangan dibuat, operasi pemulihan akan memakan 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 membutuhkan waktu pemulihan yang lebih lama 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 lain dari tempat cadangan dibuat, instance tujuan dapat menggunakan penyimpanan HDD atau SSD. 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 pencadangan 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 project dan instance 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 membuat strategi pencadangan, pertimbangkan praktik terbaik berikut. Untuk mengetahui informasi selengkapnya tentang perencanaan pemulihan dari bencana, lihat bagian Bigtable di Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.
Membuat cadangan
- Jangan mencadangkan tabel lebih sering daripada sekali setiap lima menit.
- Saat 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 penulisan Anda.
Memulihkan dari cadangan
- Rencanakan nama tabel baru yang akan Anda gunakan jika Anda perlu memulihkan dari cadangan. Poin utamanya adalah bersiaplah sebelumnya agar Anda tidak perlu memutuskan saat sedang menghadapi masalah.
- Jika Anda memulihkan tabel karena alasan selain penghapusan yang tidak disengaja, pastikan semua operasi baca dan tulis dilakukan ke tabel baru sebelum Anda menghapus tabel asli.
- Jika Anda berencana memulihkan ke instance lain, buat instance tujuan sebelum Anda 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 dengan lebih cepat, gunakan pencadangan aktif.
Kuota dan batas
Permintaan pencadangan dan pemulihan serta penyimpanan cadangan tunduk pada kuota dan batas Bigtable.
Batasan
Batasan berikut berlaku untuk cadangan 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 sudah 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 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.