Bagikan melalui

Pencadangan dan pemulihan di Azure Database for PostgreSQL

Cadangan merupakan bagian penting dari strategi kelangsungan bisnis apa pun. Mereka membantu melindungi data dari kerusakan atau penghapusan yang tidak disengaja.

Azure Database for PostgreSQL secara otomatis melakukan cadangan secara berkala server Anda. Anda kemudian dapat melakukan pemulihan point-in-time (PITR) selama periode retensi yang Anda tentukan. Waktu keseluruhan untuk pemulihan dan pulih total biasanya tergantung ukuran file data dan jumlah pemulihan yang akan dijalankan.

Ringkasan pencadangan

Azure Database for PostgreSQL mengambil cadangan rekam jepret file data dan menyimpannya dengan aman di penyimpanan zona redundan atau penyimpanan redundan secara lokal, tergantung pada wilayah tersebut. Server ini juga mem-backup log transaksi ketika file write-ahead log (WAL) siap untuk diarsipkan. Anda dapat menggunakan cadangan ini untuk memulihkan server ke titik waktu tertentu dalam periode retensi cadangan yang dikonfigurasikan.

Periode retensi cadangan default adalah 7 hari, tetapi Anda dapat memperpanjang periode hingga maksimal 35 hari. Semua cadangan dienkripsi menggunakan enkripsi AES 256-bit untuk data yang tersimpan secara tenang.

File cadangan ini tidak dapat diekspor atau digunakan untuk membuat server di luar instans server fleksibel Azure Database for PostgreSQL Anda. Untuk tujuan itu, Anda dapat menggunakan alat PostgreSQL pg_dump dan pg_restore /psql.

Frekuensi pencadangan

Pencadangan pada instans server fleksibel Azure Database for PostgreSQL berbasis rekam jepret. Pencadangan rekam jepret pertama dijadwalkan segera setelah server dibuat. Cadangan rekam jepret saat ini diambil sehari sekali. Jika tidak ada modifikasi lebih lanjut yang dilakukan pada database apa pun di server setelah pencadangan rekam jepret terakhir, cadangan rekam jepret untuk sementara ditangguhkan. Segera setelah database di server dimodifikasi, rekam jepret baru segera diambil untuk menangkap perubahan terbaru. Rekam jepret pertama adalah cadangan penuh dan rekam jepret berturut-turut adalah cadangan diferensial.

Cadangan log transaksi terjadi pada frekuensi yang bervariasi, tergantung pada beban kerja dan kapan file WAL diisi dan siap untuk diarsipkan. Secara umum, RPO untuk penundaan (tujuan titik pemulihan) bisa maksimal 5 menit.

Opsi redundansi cadangan

Azure Database for PostgreSQL menyimpan beberapa salinan cadangan Anda untuk membantu melindungi data Anda dari peristiwa yang direncanakan dan tidak direncanakan. Peristiwa ini dapat meliputi kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, dan bencana alam. Redundansi pencadangan memastikan bahwa database Anda memenuhi target ketersediaan dan ketahanan, bahkan bila terjadi kegagalan.

Azure Database for PostgreSQL menawarkan tiga opsi:

  • Penyimpanan cadangan redundan zona: Opsi ini secara otomatis dipilih untuk wilayah yang mendukung zona ketersediaan. Ketika cadangan disimpan di penyimpanan cadangan zona-redundan, tiga salinan data disimpan dalam zona ketersediaan tempat server Anda dihosting. Selain itu, data direplikasi ke zona ketersediaan lain untuk perlindungan tambahan.

    Opsi ini menyediakan ketersediaan data cadangan di seluruh zona ketersediaan dan membatasi replikasi data ke dalam suatu negara/wilayah untuk memenuhi persyaratan residensi data. Opsi ini memberikan setidaknya durabilitas objek cadangan sebesar 99,9999999999% (12 angka sembilan) selama tahun tertentu.

  • Penyimpanan cadangan yang berlebihan secara lokal: Opsi ini secara otomatis dipilih untuk wilayah yang belum mendukung zona ketersediaan. Ketika cadangan disimpan di penyimpanan cadangan yang lokal redundan, beberapa salinan cadangan disimpan di pusat data yang sama.

    Opsi ini melindungi data Anda dari kegagalan rak server dan drive. Ini juga memberikan setidaknya durabilitas objek cadangan sebesar 99,999999999% (11 angka sembilan) selama satu tahun.

    Secara bawaan, penyimpanan cadangan untuk server dengan ketersediaan tinggi (HA) di zona yang sama atau tanpa konfigurasi ketersediaan tinggi diatur sebagai redundan lokal.

  • Penyimpanan cadangan geo-redundan: Anda dapat memilih opsi ini pada saat pembuatan server. Ketika cadangan disimpan dalam penyimpanan cadangan geo-redundan, selain tiga salinan data yang disimpan di wilayah tempat server Anda dihosting, data tersebut juga direplikasi ke wilayah yang dipasangkan secara geografis.

    Opsi ini memungkinkan Anda memulihkan server anda di wilayah yang berbeda jika terjadi bencana. Ini juga memberikan setidaknya durabilitas objek cadangan sebesar 99,99999999999999% (16 angka sembilan) selama satu tahun.

    Geo-redundansi didukung untuk server yang dihosting di salah satu wilayah berpasangan Azure.

Berpindah dari opsi penyimpanan cadangan lainnya ke penyimpanan cadangan geo-redundan

Anda dapat mengonfigurasi penyimpanan geo-redundansi untuk cadangan hanya pada saat pembuatan server. Setelah server disediakan, Anda tidak dapat mengubah opsi redundansi penyimpanan cadangan.

Retensi Pencadangan

Cadangan disimpan berdasarkan pengaturan periode penyimpanan cadangan yang Anda atur untuk server tersebut. Anda dapat memilih periode retensi antara 7 (default) hingga 35 hari. Anda dapat mengatur periode retensi selama pembuatan server atau memperbaruinya di lain waktu. Cadangan disimpan bahkan untuk server yang dihentikan.

Periode retensi cadangan data mengatur jangka waktu di mana PITR dapat diambil menggunakan cadangan yang tersedia. Anda juga dapat memperlakukan periode retensi cadangan sebagai jendela pemulihan dari perspektif pemulihan.

Semua cadangan yang diperlukan untuk melakukan PITR (Point In Time Recovery) dalam periode penyimpanan cadangan disimpan dalam penyimpanan cadangan. Misalnya, jika periode retensi cadangan diatur ke 7 hari, jendela pemulihan totalnya adalah 7 hari terakhir. Dalam skenario ini, semua data dan log yang diperlukan untuk mengembalikan dan memulihkan server dalam 7 hari terakhir disimpan.

Biaya penyimpanan cadangan

Azure Database for PostgreSQL menyediakan hingga 100 persen penyimpanan server yang disediakan sebagai penyimpanan cadangan tanpa biaya tambahan. Setiap penyimpanan cadangan tambahan yang Anda gunakan dikenakan biaya dalam gigabyte per bulan.

Misalnya, jika Anda telah menyediakan server dengan penyimpanan 250 gibibyte (GiB), maka Anda memiliki kapasitas penyimpanan cadangan 250 GiB tanpa biaya lagi. Jika penggunaan cadangan harian adalah 25 GiB, Anda dapat memiliki penyimpanan cadangan gratis hingga 10 hari. Konsumsi penyimpanan cadangan yang melebihi 250 GiB dibebankan seperti yang didefinisikan dalam model harga.

Jika Anda mengonfigurasi server Anda dengan cadangan geo-redundan, data cadangan juga disalin ke wilayah yang dipasangkan Azure. Jadi, ukuran cadangan Anda akan menjadi dua kali ukuran salinan cadangan lokal. Penagihan dihitung sebagai ( (2 x ukuran cadangan lokal) - ukuran penyimpanan yang disediakan ) x harga @ gigabyte per bulan.

Anda dapat menggunakan metrik Penyimpanan Cadangan yang Digunakan di portal Microsoft Azure untuk memantau penyimpanan cadangan yang digunakan server. Metrik Penyimpanan Cadangan Yang Digunakan menunjukkan jumlah penyimpanan yang digunakan oleh semua cadangan database dan cadangan log yang dipertahankan, berdasarkan periode retensi cadangan yang ditetapkan untuk server tersebut.

Catatan

Terlepas dari ukuran database, aktivitas transaksional yang berat di server menghasilkan lebih banyak file WAL. Peningkatan file pada gilirannya meningkatkan penyimpanan cadangan.

Pemulihan ke titik waktu tertentu

Dalam instans server fleksibel Azure Database for PostgreSQL, melakukan PITR membuat server baru di wilayah yang sama dengan server sumber Anda, tetapi Anda dapat memilih zona ketersediaan. Ini dibuat dengan konfigurasi server sumber untuk tingkat harga, generasi komputasi, jumlah core virtual, ukuran penyimpanan, periode retensi cadangan, dan opsi redundansi cadangan.

File database fisik pertama kali dipulihkan dari cadangan snapshot ke lokasi data server. Cadangan yang sesuai yang dilakukan lebih awal dari titik waktu yang diinginkan secara otomatis dipilih dan dipulihkan. Proses pemulihan selanjutnya dimulai menggunakan file WAL untuk membawa database ke status yang konsisten.

Misalnya, mari kita asumsikan cadangan data dilakukan pada pukul 23.00 setiap malam. Jika titik pemulihan adalah untuk 15 Agustus pukul 10:00, maka cadangan harian 14 Agustus dipulihkan. Database akan dipulihkan hingga pukul 10:00 pagi 15 Agustus dengan menggunakan cadangan log transaksi dari 14 Agustus, 23.00, hingga 15 Agustus, 10:00.

Untuk memulihkan server database Anda, lihat salah satu hal berikut ini:

Penting

Operasi pemulihan di instans server fleksibel Azure Database for PostgreSQL Selalu membuat server database baru dengan nama yang Anda berikan. Operasi tersebut tidak mengganti server database yang ada.

PITR berguna dalam skenario seperti ini:

  • Pengguna secara tidak sengaja menghapus data, tabel, atau database.
  • Aplikasi secara tidak sengaja menimpa data baik dengan data buruk karena kerusakan aplikasi.
  • Anda ingin mengkloning server Anda untuk pengujian, pengembangan, atau untuk verifikasi data.

Dengan pencadangan log transaksi secara berkelanjutan, Anda dapat memulihkan hingga ke titik transaksi terakhir. Anda dapat memilih opsi pemulihan berikut:

  • Titik pemulihan terbaru (sekarang): Ini adalah opsi default, yang memungkinkan Anda memulihkan server ke titik waktu terbaru.

  • Titik pemulihan kustom: Opsi ini memungkinkan Anda memilih titik waktu apa pun dalam periode retensi yang ditentukan untuk instans server fleksibel Azure Database for PostgreSQL ini. Secara default, waktu terbaru dalam UTC dipilih secara otomatis. Pilihan otomatis berguna bila Anda ingin memulihkan transaksi yang terakhir dilakukan untuk tujuan pengujian. Anda dapat memilih hari dan waktu lain secara opsional.

  • Titik pemulihan cepat: Opsi ini memungkinkan pengguna memulihkan server dalam waktu secepat mungkin dalam periode retensi yang ditentukan untuk instans server fleksibel Azure Database for PostgreSQL mereka. Pemulihan tercepat dimungkinkan dengan langsung memilih stempel waktu dari daftar cadangan. Operasi pemulihan ini menyediakan server dan hanya memulihkan cadangan rekam jepret lengkap dan tidak memerlukan pemulihan log apa pun, yang membuatnya cepat. Kami sarankan Anda memilih stempel waktu cadangan yang lebih baru dari titik pemulihan paling awal untuk memastikan operasi pemulihan yang berhasil.

Waktu yang diperlukan untuk memulihkan menggunakan opsi titik pemulihan terbaru dan kustom bervariasi berdasarkan faktor-faktor seperti volume log transaksi untuk diproses sejak pencadangan terakhir dan jumlah total database yang dipulihkan secara bersamaan di wilayah yang sama Waktu pemulihan keseluruhan biasanya memakan waktu dari beberapa menit hingga beberapa jam.

Jika Anda mengonfigurasi server dalam jaringan virtual, Anda dapat memulihkan ke jaringan virtual yang sama atau ke jaringan virtual yang berbeda. Namun, Anda tidak dapat memulihkan akses publik. Demikian pula, jika Anda mengonfigurasi server Anda dengan akses publik, Anda tidak dapat memulihkan ke akses jaringan virtual privat.

Penting

Server yang dihapus dapat dipulihkan. Jika Anda menghapus server, Anda dapat mengikuti panduan kami Memulihkan server fleksibel Azure Database for Azure Database for PostgreSQL yang dihentikan untuk dipulihkan. Gunakan kunci sumber daya Azure untuk membantu mencegah penghapusan server secara tidak disengaja.

Pencadangan dan pemulihan dengan redundansi geografis

Untuk mengaktifkan cadangan geo-redundan dari panel Komputasi + penyimpanan di portal Microsoft Azure, lihat Membuat Azure Database for PostgreSQL.

Penting

Cadangan georedundan hanya dapat dikonfigurasi saat pembuatan server.

Setelah mengonfigurasi server dengan cadangan geo-redundan, Anda dapat memulihkannya ke wilayah yang dipasangkan secara geografis. Untuk informasi selengkapnya, lihat wilayah yang didukung untuk cadangan geo-redundan.

Ketika server dikonfigurasi dengan cadangan geo-redundan, data cadangan dan log transaksi disalin ke wilayah yang dipasangkan secara asinkron melalui replikasi penyimpanan. Setelah Anda membuat server, tunggu satu jam sebelum memulai pemulihan geo. Hal ini memungkinkan kumpulan data cadangan pertama direplikasi ke wilayah yang dipasangkan.

Kemudian, log transaksi dan cadangan harian disalin secara asinkron ke wilayah yang dipasangkan. Mungkin ada penundaan hingga satu jam dalam transmisi data. Jadi, Anda dapat memperkirakan hingga satu jam titik pemulihan (RPO) saat Anda melakukan pemulihan. Anda hanya dapat memulihkan ke data cadangan terakhir yang tersedia di wilayah yang dipasangkan. Saat ini, PITR cadangan geo-redundan tidak tersedia.

Perkiraan waktu untuk memulihkan RTO server (tujuan waktu pemulihan) tergantung pada faktor-faktor seperti ukuran database, waktu pencadangan database terakhir, dan jumlah WAL untuk diproses hingga data cadangan terakhir yang diterima. Waktu pemulihan keseluruhan biasanya memakan waktu beberapa menit hingga beberapa jam.

Dalam pemulihan geografis, konfigurasi server yang dapat diubah mencakup pengaturan jaringan virtual dan opsi menghapus cadangan geo-redundan dari server yang dipulihkan. Mengubah konfigurasi server lain, seperti komputasi, penyimpanan, atau tingkat harga (Burstable, General Purpose, atau Memory Optimized), ketika melakukan pemulihan geografis, tidak dapat dilakukan.

Untuk informasi selengkapnya, lihat Pulihkan ke wilayah yang dipasangkan (pemulihan geografis).

Penting

Saat wilayah utama tidak berfungsi, pengguna tidak dapat membuat server geo-redundan di masing-masing wilayah yang dipasangkan secara geografis karena penyimpanan tidak dapat disediakan di wilayah utama. Sebelum Anda memprovisikan server geo-redundan di wilayah yang dipasangkan secara geografis, Anda harus menunggu hingga wilayah utama siap.

Dengan wilayah utama gagal beroperasi, Anda masih dapat melakukan pemulihan ulang server sumber ke wilayah pasangan geografis. Untuk informasi selengkapnya, lihat Pulihkan ke wilayah yang dipasangkan (pemulihan geografis). Anda harus menggunakan Geo-replika sebagai strategi pemulihan bencana (DR) Jika Anda perlu mengonfigurasi DR ke wilayah mana pun, atau jika wilayah utama tidak mendukung pencadangan Geo-redundan.

Sebaiknya gunakan Titik Akhir Virtual untuk beban kerja penting misi Anda, karena menyediakan titik koneksi yang stabil untuk aplikasi, memastikan gangguan minimal. Jika Anda memiliki Titik Akhir Virtual yang dipetakan ke server utama Anda, hapus titik akhir virtual dari server utama, setelah dihapus, tambahkan titik akhir virtual yang sama ke server yang baru dibuat. Ini memastikan konektivitas aplikasi tetap konsisten dan meminimalkan waktu henti. Untuk informasi selengkapnya, lihat menggunakan titik akhir virtual untuk nama host yang konsisten selama PITR

Pemulihan sistem dan jaringan

Pemulihan ke titik waktu tertentu

Jika server sumber Anda dikonfigurasi dengan jaringan akses publik , Anda hanya dapat memulihkan ke akses publik.

Jika server sumber Anda dikonfigurasi dengan jaringan virtual akses privat , Anda dapat memulihkan ke jaringan virtual yang sama atau ke jaringan virtual yang berbeda. Anda tidak dapat melakukan PITR antar akses publik dan privat.

Pemulihan Geografis

Jika server sumber Anda dikonfigurasi dengan jaringan akses publik , Anda hanya dapat memulihkan ke akses publik. Selain itu, Anda harus menerapkan aturan firewall setelah operasi pemulihan selesai.

Jika server sumber Anda dikonfigurasi dengan jaringan virtual akses privat , Anda hanya dapat memulihkan ke jaringan virtual yang berbeda, karena jaringan virtual tidak dapat menjangkau wilayah. Anda tidak dapat melakukan pemulihan geografis antara akses publik dan privat.

Langkah-langkah pasca pemulihan

Setelah memulihkan server, Anda dapat melakukan tugas berikut untuk mencadangkan dan menjalankan pengguna dan aplikasi Anda:

  • Jika server baru dimaksudkan untuk mengganti server asli, alihkan klien dan aplikasi klien ke server baru. Ubah nama server string koneksi Anda untuk menunjuk ke server baru.

  • Nilai semua parameter server di server asli tidak diterapkan secara otomatis ke server baru. Pastikan bahwa semua parameter server di server baru dikonfigurasi ulang sesuai persyaratan server baru tersebut.

  • Pastikan bahwa aturan firewall tingkat server yang sesuai, titik akhir privat, dan aturan jaringan virtual tersedia untuk koneksi pengguna. Aturan ini tidak disalin dari server asli.

  • Tingkatkan atau perkecil komputasi server yang dipulihkan sesuai kebutuhan.

  • Pastikan akses masuk dan izin pada tingkat database yang sesuai telah diterapkan.

  • Konfigurasikan pemberitahuan sebagaimana mestinya.

  • Jika server sumber tempat Anda memulihkan dikonfigurasi dengan ketersediaan tinggi, dan Anda ingin mengonfigurasi server yang dipulihkan dengan ketersediaan tinggi, Anda kemudian dapat mengikuti langkah-langkah ini.

  • Jika server sumber tempat Anda memulihkan dikonfigurasi dengan replika baca, dan Anda ingin mengonfigurasi replika baca di server yang dipulihkan, Anda kemudian dapat mengikuti instruksi dalam Membuat replika baca.

Pencadangan Sesuai Permintaan

Instans server fleksibel Azure Database for PostgreSQL Anda secara otomatis menghasilkan rekam jepret volume penyimpanan dari seluruh instans database Anda, yang mencakup semua database, sebagai bagian dari cadangan terjadwalnya. Selain itu, Anda dapat membuat cadangan sesuai permintaan kapan pun diperlukan yang ideal untuk skenario seperti mempersiapkan operasi yang berpotensi berisiko atau melakukan refresh berkala di luar jadwal pencadangan biasa.

Pencadangan sesuai permintaan dapat diambil selain pencadangan otomatis terjadwal. Cadangan ini dipertahankan sesuai dengan jendela retensi cadangan Anda. Anda dapat menghapus cadangan sesuai permintaan ini kapan saja jika tidak lagi diperlukan. Untuk memulai pencadangan sesuai permintaan, cukup pilih instans database yang ingin Anda cadangkan dan tentukan nama cadangan. Cadangan ini disimpan bersama cadangan otomatis, tetapi hanya cadangan sesuai permintaan yang dapat dihapus oleh pengguna, karena pencadangan otomatis dikelola dan dipertahankan oleh layanan untuk memenuhi persyaratan retensi cadangan.

Untuk informasi selengkapnya, lihat Melakukan pencadangan sesuai permintaan.

Batasan

  • Fitur pencadangan sesuai permintaan saat ini tidak didukung dengan tingkat komputasi server Burstable.
  • Fitur pencadangan sesuai permintaan saat ini tidak didukung dengan tingkat penyimpanan SSDv2.
  • Anda dapat mengambil maksimum 7 cadangan sesuai permintaan per instans server fleksibel, yang dipertahankan berdasarkan jendela retensi cadangan.

Retensi jangka panjang

Layanan Azure Backup dan Azure Database for PostgreSQL telah membangun solusi pencadangan jangka panjang kelas perusahaan untuk instans server fleksibel Azure Database for PostgreSQL yang mempertahankan cadangan hingga 10 tahun. Anda dapat menggunakan retensi jangka panjang (LTR) secara independen atau selain solusi pencadangan otomatis yang ditawarkan oleh Azure Database for PostgreSQL, yang menawarkan retensi hingga 35 hari. Pencadangan otomatis adalah cadangan fisik yang cocok untuk pemulihan operasional, terutama ketika Anda ingin memulihkan dari cadangan terbaru. Pencadangan jangka panjang membantu Anda memenuhi kebutuhan kepatuhan, memiliki tingkat detail yang lebih tinggi, dan dilakukan sebagai pencadangan logis menggunakan pg_dump bawaan. Selain retensi jangka panjang, solusi ini menawarkan kemampuan berikut:

  • Pencadangan terjadwal dan sesuai permintaan yang dikontrol pelanggan di tingkat database individual.
  • Pemantauan pusat dari semua operasi dan pekerjaan.
  • Cadangan disimpan dalam domain keamanan dan kesalahan terpisah. Jika server sumber atau langganan disusupi, cadangan tetap aman di brankas Cadangan (di akun penyimpanan terkelola Azure Backup).
  • Menggunakan pg_dump memungkinkan fleksibilitas yang lebih besar dalam memulihkan data di berbagai versi database.
  • Brankas cadangan Azure mendukung fitur immutabilitas dan penghapusan lunak (pratinjau), melindungi data Anda.
  • Dukungan pencadangan LTR untuk server yang mendukung CMK.

Batasan dan pertimbangan

  • Sangat disarankan untuk menguji perangkat lunak pencadangan dan pemulihan LTR Anda segera setelah konfigurasi untuk memastikan itu memenuhi persyaratan bisnis Anda.
  • Pemulihan LTR saat ini hanya tersedia sebagai 'Pulihkan sebagai File' ke akun penyimpanan, dengan fitur 'Pulihkan sebagai Server' yang direncanakan untuk masa mendatang.
  • LTR mencadangkan semua database dalam instans server yang fleksibel, dan database individual tidak dapat dikustomisasi untuk konfigurasi LTR.
  • Pencadangan LTR tidak didukung pada replika, dapat dilakukan pada server utama.
  • Ukuran database maksimum yang didukung untuk cadangan Retensi Jangka Panjang (LTR) adalah 1 TiB.
  • Pencadangan LTR dapat dijadwalkan setiap minggu, bulanan, atau tahunan. Jadwal pencadangan harian saat ini belum didukung.
  • Cadangan LTR tidak mendukung tabel yang berisi baris dengan panjang BYTEA melebihi 500 MB.
  • Saat memulihkan peran untuk pengguna Microsoft Entra, pastikan bahwa autentikasi Microsoft Entra diaktifkan dan Anda masuk sebagai Admin Microsoft Entra untuk membuat pengguna tambahan. Mencoba membuat peran Entra sebagai pengguna biasa akan mengakibatkan kesalahan.

Untuk informasi selengkapnya tentang melakukan pencadangan jangka panjang, kunjungi panduan cara.

Tanya jawab umum

  • Bagaimana Azure menangani backup server saya?

    Secara default, Azure Database for PostgreSQL memungkinkan pencadangan otomatis seluruh server Anda (mencakup semua database yang dibuat) dengan periode retensi default 7 hari. Penyimpanan cadangan otomatis menyertakan snapshot harian yang ditingkatkan dari basis data. File log (WAL) diarsipkan ke Azure Blob Storage secara terus menerus.

  • Dapatkah saya mengonfigurasi cadangan otomatis untuk menyimpan data untuk jangka panjang?

    Tidak. Saat ini, Azure Database for PostgreSQL mendukung retensi maksimum 35 hari. Anda dapat menggunakan pencadangan manual untuk persyaratan retensi jangka panjang menggunakan Azure Backup.

  • Bagaimana cara mencadangkan instans server fleksibel Azure Database for PostgreSQL saya secara manual?

    Anda dapat mengambil rekam jepret fisik secara manual menggunakan fitur pencadangan sesuai permintaan, Anda juga dapat mengambil cadangan logis menggunakan alat PostgreSQL pg_dump. Misalnya, lihat Memigrasikan database Azure Database for PostgreSQL Anda dengan menggunakan cadangan dan pemulihan.

  • Apa jendela cadangan untuk server saya? Bisakah saya menyesuaikannya?

    Azure mengelola jendela cadangan, dan Anda tidak dapat menyesuaikannya. Pencadangan snapshot lengkap pertama dijadwalkan segera setelah server dibuat. Pencadangan snapshot berikutnya adalah pencadangan inkremental yang terjadi sekali sehari.

  • Apakah cadangan saya dienkripsi?

    Ya. Semua data instans server fleksibel Azure Database for PostgreSQL, cadangan, dan file sementara yang dibuat selama eksekusi kueri dienkripsi melalui enkripsi AES (Standar Enkripsi Lanjutan) 256-bit. Enkripsi penyimpanan selalu aktif dan tidak dapat dinonaktifkan.

  • Bisakah saya memulihkan database tunggal atau beberapa database di server?

    Memulihkan satu/beberapa database atau tabel tidak didukung secara langsung. Namun, Anda dapat memulihkan seluruh server ke server baru, lalu menghilangkan tabel atau database yang tidak Anda butuhkan di server baru.

  • Apakah server saya tersedia saat pencadangan sedang berlangsung?

    Ya. Pencadangan adalah operasi online menggunakan rekam jepret. Operasi rekam jepret hanya membutuhkan waktu beberapa detik dan tidak mengganggu beban kerja produksi yang memastikan ketersediaan server yang tinggi.

  • Saat saya menyiapkan jendela pemeliharaan untuk server, apakah saya perlu memperhitungkan jendela cadangan?

    Tidak. Pencadangan dipicu secara internal sebagai bagian dari layanan terkelola dan tidak terkait dengan jendela pemeliharaan.

  • Di mana cadangan otomatis saya disimpan, dan bagaimana cara mengelola retensinya?

    Instans server fleksibel Azure Database for PostgreSQL Anda secara otomatis membuat cadangan server dan menyimpannya di:

    • Penyimpanan dengan redundansi zona, di wilayah tempat zona-zona didukung.
    • Penyimpanan redundansi lokal, di wilayah yang belum mendukung banyak zona.
    • Wilayah yang dipasangkan, jika Anda mengonfigurasi cadangan geo-redundan.

    File cadangan ini tidak dapat diekspor karena disimpan di akun penyimpanan yang dikelola Microsoft. Pelanggan memiliki akses baca-saja untuk memulihkan file-file ini tetapi tidak dapat mengubah atau menghapusnya. File cadangan dihapus secara otomatis setelah periode retensi

    Anda dapat menggunakan cadangan untuk memulihkan server Anda ke titik waktu tertentu saja. Periode penyimpanan cadangan default adalah 7 hari. Anda dapat mengonfigurasi penyimpanan cadangan secara opsional hingga 35 hari.

  • Dengan cadangan geo-redundan, seberapa sering cadangan disalin ke wilayah yang dipasangkan?

    Ketika server dikonfigurasi dengan cadangan geo-redundan, data cadangan disimpan dalam akun penyimpanan geo-redundan. Akun penyimpanan menyalin file data ke wilayah yang dipasangkan pada saat pencadangan harian dilakukan di server utama. File WAL dicadangkan saat siap diarsipkan.

    Data cadangan disalin dengan cara asinkron secara terus menerus ke region yang dipasangkan. Anda perlu menunggu hingga satu jam keterlambatan sebelum menerima data cadangan.

  • Dapatkah saya melakukan PITR di wilayah terpencil?

    Tidak. Data dipulihkan ke data cadangan terakhir yang tersedia di wilayah terpencil.

  • Bagaimana pencadangan dilakukan di server yang mendukung HA?

    Volume data dalam instans server fleksibel Azure Database for PostgreSQL dicadangkan melalui rekam jepret tambahan disk terkelola dari server utama. Cadangan WAL dilakukan baik dari server utama atau server siaga.

  • Bagaimana cara memvalidasi bahwa pencadangan dilakukan di server saya?

    Cara terbaik untuk memeriksa cadangan adalah dengan melakukan PITR berkala dan memastikan bahwa cadangan valid dan dapat dipulihkan. Operasi pencadangan atau file tidak ditampilkan kepada pengguna akhir.

  • Di mana saya dapat melihat penggunaan cadangan?

    Di portal Microsoft Azure, di bawah Pemantauan, pilih Metrik. Di Penyimpanan Cadangan yang Digunakan, Anda dapat memantau total penggunaan cadangan.

  • Apa yang terjadi pada cadangan saya jika saya menghapus server saya?

    Jika Anda menghapus server, semua cadangan milik server juga akan dihapus dan tidak dapat dipulihkan. Untuk membantu melindungi sumber daya server, dari penghapusan tidak disengaja atau perubahan tidak terduga pasca penyebaran, administrator dapat memanfaatkan kunci manajemen.

  • Bagaimana cadangan dipertahankan untuk server yang dihentikan?

    Tidak ada cadangan baru yang dilakukan untuk server yang dihentikan. Semua cadangan lama (dalam jendela retensi) pada waktu penghentian server akan terismpan hingga server dihidupkan ulang. Setelah itu, retensi cadangan untuk server aktif diatur oleh jendela retensinya.

  • Bagaimana saya akan ditagih dan dikenakan biaya untuk backup saya?

    Azure Database for PostgreSQL menyediakan hingga 100 persen penyimpanan server yang disediakan sebagai penyimpanan cadangan tanpa biaya tambahan. Penyimpanan cadangan lainnya yang Anda gunakan dikenakan biaya dalam gigabyte per bulan, seperti yang didefinisikan dalam model harga.

    Periode retensi cadangan dan opsi redundansi cadangan yang Anda pilih, bersama dengan aktivitas transaksional di server, secara langsung memengaruhi total penyimpanan dan penagihan cadangan.

  • Bagaimana saya akan dikenakan biaya untuk server yang telah dimatikan?

    Sementara instans server Anda dihentikan, tidak ada cadangan baru yang dilakukan. Anda dikenakan biaya untuk penyimpanan yang disediakan dan penyimpanan cadangan (cadangan yang disimpan dalam jendela retensi yang Anda tentukan).

    Penyimpanan cadangan gratis terbatas pada ukuran database yang Anda sediakan. Setiap data cadangan berlebih akan dikenakan biaya sesuai dengan harga cadangan.

  • Saya mengonfigurasi server saya dengan ketersediaan tinggi yang zona-redundan. Apakah Anda mengambil dua cadangan, dan apakah saya akan dikenakan biaya dua kali?

    Tidak. Terlepas dari server HA atau non-HA, hanya satu set salinan cadangan yang dipertahankan. Anda hanya dikenakan biaya sekali.

  • Bagaimana cara memulihkan server saya?

    Azure mendukung PITR untuk semua server. Pengguna dapat memulihkan ke titik pemulihan terbaru atau titik pemulihan kustom dengan menggunakan portal Azure, Azure CLI, dan API.

    Untuk memulihkan server Anda dari cadangan manual dengan menggunakan alat seperti pg_dump, Anda dapat terlebih dahulu membuat instans server fleksibel Azure Database for PostgreSQL lalu memulihkan database Anda ke server dengan menggunakan pg_restore.

  • Dapatkah saya memulihkan ke zona ketersediaan lain dalam wilayah yang sama?

    Ya. Jika wilayah mendukung beberapa zona ketersediaan, cadangan disimpan di akun penyimpanan zona-redundan sehingga Anda dapat memulihkan ke zona lain.

  • Berapa lama waktu yang dibutuhkan PITR? Mengapa pemulihan saya membutuhkan waktu yang lama?

    Operasi pemulihan data dari snapshot tidak bergantung pada ukuran data. Tetapi waktu proses pemulihan menerapkan log (aktivitas transaksi untuk diproses ulang) bisa beragam, tergantung pada cadangan tanggal/waktu yang diminta sebelumnya dan jumlah log yang harus diproses. Ini berlaku untuk pemulihan di dalam zona yang sama atau pemulihan data ke zona yang berbeda.

  • Jika saya memulihkan server saya yang mendukung ketersediaan tinggi, apakah server hasil pemulihan dikonfigurasi secara otomatis dengan ketersediaan tinggi?

    Tidak. Server dipulihkan sebagai instans server fleksibel Azure Database for PostgreSQL instans tunggal. Setelah pemulihan selesai, Anda dapat mengonfigurasi server secara opsional dengan ketersediaan tinggi.

  • Saya mengonfigurasi server saya dalam jaringan virtual. Bisakah saya memulihkan ke jaringan virtual yang berbeda?

    Ya. Pada waktu pemulihan, pilih jaringan virtual yang berbeda untuk dipulihkan.

  • Dapatkah saya memulihkan server akses publik saya ke jaringan virtual atau sebaliknya?

    Tidak. Azure Database for PostgreSQL saat ini tidak mendukung pemulihan server di seluruh akses publik dan privat.

  • Bagaimana cara melacak operasi pemulihan saya?

    Saat ini tidak ada cara untuk melacak operasi pemulihan. Anda dapat memantau log aktivitas untuk melihat apakah operasi masih berlangsung atau sudah selesai.

Konten terkait

  • Last updated on