Melindungi data Anda menggunakan pencadangan

Pilih versi dokumentasi:

Halaman ini menjelaskan arsitektur referensi Ketersediaan Standar AlloyDB Omni, yang memberikan perlindungan data menggunakan cadangan.

Kasus penggunaan

Arsitektur referensi ini mendukung skenario berikut:

  • Anda memiliki database yang dapat menoleransi beberapa periode nonaktif dan kehilangan data sejak pencadangan terakhir.
  • Anda ingin melindungi database AlloyDB Omni dari error pengguna, kerusakan, atau kegagalan fisik di tingkat database, bukan snapshot image server atau VM.
  • Anda ingin memulihkan database di tempat atau dari jarak jauh, mungkin hingga titik waktu tertentu.

Cara kerja arsitektur referensi

Arsitektur referensi Ketersediaan Standar mencakup pencadangan dan pemulihan database AlloyDB Omni Anda.

Meskipun Ketersediaan Standar adalah implementasi dasar dan meminimalkan hardware atau layanan tambahan yang diperlukan, Batas Waktu Pemulihan (RTO) meningkat seiring bertambahnya ukuran database. Makin banyak data yang perlu dicadangkan, makin lama waktu yang diperlukan untuk memulihkan dan memulihkan database. Kehilangan data bergantung pada jenis cadangan. Jika hanya file data yang dicadangkan secara berkala, saat Anda memulihkan, Anda akan mengalami kehilangan data sejak pencadangan terakhir.

Mengurangi RPO

Fitur pengarsipan berkelanjutan PostgreSQL memungkinkan Anda mencapai Toleransi Jumlah Data yang Hilang (RPO) yang rendah dan mengaktifkan pemulihan point-in-time melalui pencadangan. Proses ini melibatkan pengarsipan file Write-Ahead Logging (WAL) dan streaming data WAL, yang berpotensi ke lokasi penyimpanan jarak jauh.

Jika file WAL hanya diarsipkan saat penuh atau pada interval tertentu, kehilangan database secara menyeluruh (termasuk file WAL saat ini) akan membatasi pemulihan ke file WAL terakhir yang diarsipkan, yang berarti RPO Anda harus memperhitungkan potensi kehilangan data. Sebaliknya, transfer data WAL berkelanjutan meminimalkan potensi kehilangan data.

Saat mengonfigurasi pencadangan berkelanjutan, Anda dapat melakukan pemulihan ke titik waktu tertentu. Pemulihan point-in-time memungkinkan Anda memulihkan database ke status sebelum terjadi error, seperti penghapusan tabel yang tidak disengaja atau update batch yang salah. Namun, metode pemulihan ini memengaruhi RPO dan RTO, kecuali jika Anda menggunakan database tambahan sementara. Memulihkan seluruh database secara langsung akan me-roll back transaksi berikutnya pada tabel yang tidak terpengaruh dan membuat database offline, sedangkan memulihkan ke database tambahan sementara memungkinkan Anda hanya menyalin data yang dipulihkan.

Strategi pencadangan

AlloyDB Omni mendukung strategi perlindungan data seperti pencadangan fisik berkala, pemulihan point-in-time, pengarsipan dan streaming WAL, serta penyimpanan cadangan di lokasi yang berbeda. Atau, untuk database kecil, Anda dapat melakukan pencadangan logis menggunakan pg_dump untuk satu database atau pg_dumpall untuk seluruh cluster, dan memulihkan menggunakan pg_restore.

Alat pencadangan

Untuk deployment Kubernetes, Anda dapat mengonfigurasi pencadangan berkelanjutan menggunakan paket pencadangan (BackupPlan) yang dikelola oleh operator AlloyDB Omni untuk setiap cluster database. Untuk mengetahui informasi selengkapnya, lihat Mencadangkan dan memulihkan di Kubernetes.

Bergantung pada opsi deployment, Anda dapat mengonfigurasi AlloyDB Omni untuk menyimpan cadangan di penyimpanan lokal atau jarak jauh, seperti Cloud Storage atau opsi penyimpanan yang disediakan oleh vendor cloud mana pun. Meskipun penyimpanan lokal mungkin lebih cepat untuk pencadangan dan pemulihan, penyimpanan jarak jauh biasanya lebih andal untuk menangani kegagalan saat seluruh host atau VM gagal. Untuk mengetahui informasi selengkapnya, lihat Gambar 1, yang menunjukkan potensi tujuan cadangan.

AlloyDB Omni dengan opsi pencadangan

Gambar 1. AlloyDB Omni dengan opsi pencadangan.

Anda dapat melakukan pencadangan ke opsi penyimpanan lokal atau jarak jauh. Pencadangan lokal cenderung lebih cepat karena hanya mengandalkan throughput I/O, sedangkan pencadangan jarak jauh biasanya memiliki latensi yang lebih tinggi dan bandwidth jaringan yang lebih rendah. Namun, pencadangan jarak jauh memberikan perlindungan yang lebih baik terhadap kegagalan host dan zona daripada pencadangan lokal.

Anda juga dapat membagi cadangan lokal menjadi penyimpanan lokal atau penyimpanan bersama. Meskipun penyimpanan lokal tidak memiliki opsi pemulihan dari bencana (disaster recovery) saat host database gagal, penyimpanan bersama memungkinkan Anda merelokasi penyimpanan tersebut ke server lain dan menggunakannya untuk pemulihan. Artinya, penyimpanan bersama berpotensi menawarkan RTO yang lebih cepat.

Untuk deployment penyimpanan lokal, bersama, dan jarak jauh, Anda dapat menjadwalkan jenis pencadangan berikut atau melakukannya secara manual sesuai permintaan:

  • Pencadangan penuh: pencadangan lengkap semua file database yang diperlukan untuk pemulihan data.
  • Pencadangan diferensial: pencadangan hanya perubahan file sejak pencadangan penuh terakhir.
  • Pencadangan inkremental: pencadangan hanya untuk perubahan file sejak pencadangan terakhir dari jenis apa pun.

Pemulihan point-in-time

Pencadangan berkelanjutan file WAL PostgreSQL mendukung pemulihan point-in-time. Jika, setelah peristiwa kegagalan, file WAL masih utuh dan dapat digunakan, Anda dapat menggunakan file ini untuk memulihkan ke titik waktu tertentu dan membantu meminimalkan kehilangan data.

Jadwal pencadangan

Di sebagian besar lingkungan, pencadangan biasanya dijadwalkan setiap minggu. Berikut adalah jadwal pencadangan mingguan yang umum:

  • Minggu: pencadangan penuh
  • Senin, Selasa: pencadangan inkremental
  • Rabu: pencadangan diferensial
  • Kamis, Jumat: pencadangan inkremental
  • Sabtu: pencadangan diferensial

Dengan menggunakan jadwal umum ini, periode pemulihan berkelanjutan selama satu minggu memerlukan ruang penyimpanan hingga tiga pencadangan penuh ditambah pencadangan inkremental atau pencadangan diferensial yang diperlukan. Pendekatan ini mendukung pemulihan untuk kegagalan yang terjadi selama pencadangan penuh pada hari Minggu, saat pemulihan database harus diperpanjang hingga hari Minggu sebelumnya sebelum pencadangan dimulai.

Untuk meminimalkan RTO dengan potensi RPO yang lebih tinggi, database tambahan dapat beroperasi dalam mode pemulihan berkelanjutan. Mode ini melibatkan pemutaran ulang cadangan dan terus memperbarui lingkungan sekunder dengan mengarsipkan dan memutar ulang file WAL baru. RPO sebenarnya, yang mencerminkan potensi kehilangan data, bergantung pada frekuensi transaksi, ukuran file WAL, dan penggunaan streaming WAL.

Pemulihan cadangan

Anda dapat memulihkan database AlloyDB Omni dari cadangan yang disimpan atau memulihkan ke titik waktu tertentu dalam periode retensi Anda. Bergantung pada lingkungan deployment dan kebutuhan pemulihan, Anda dapat memulihkan data di tempat atau memulihkan cadangan ke instance atau cluster database baru.

Untuk deployment Kubernetes, operator AlloyDB Omni mendukung pemulihan database ke cluster dan namespace Kubernetes yang sama dari cadangan bernama atau cloning dari titik waktu tertentu. Untuk mengetahui informasi selengkapnya, lihat Mencadangkan dan memulihkan di Kubernetes dan Ringkasan meng-clone cluster database secara manual dari cadangan Kubernetes.

Penerapan

Saat Anda memilih arsitektur referensi ketersediaan, perhatikan manfaat, batasan, dan alternatif berikut.

Manfaat

  • Mudah digunakan dan dikelola, serta cocok untuk database non-kritis dengan RTO dan RPO yang longgar.
  • Memerlukan hardware tambahan minimal.
  • Menyediakan cadangan dasar yang diperlukan untuk rencana pemulihan dari bencana.
  • Mendukung pemulihan ke titik waktu mana pun dalam periode pemulihan.

Batasan

  • Dapat memerlukan lebih banyak ruang penyimpanan daripada database itu sendiri, bergantung pada persyaratan retensi Anda.
  • Pemulihan bisa lambat dan dapat menghasilkan RTO yang lebih tinggi.
  • Dapat mengakibatkan beberapa kehilangan data, bergantung pada ketersediaan data WAL saat ini setelah kegagalan database, yang mungkin berdampak negatif pada RPO.

Alternatif

Pertimbangkan arsitektur referensi Ketersediaan yang Ditingkatkan atau Ketersediaan Premium untuk meningkatkan ketersediaan dan opsi pemulihan dari bencana (disaster recovery).

Langkah berikutnya