Praktik terbaik kebijakan rencana pencadangan

Dengan mengikuti praktik terbaik ini, Anda dapat menghindari beberapa kesalahan umum yang dilakukan pengguna saat membuat dan mengubah template kebijakan.

Anda perlu mengonfigurasi template kebijakan sesuai dengan toleransi jumlah data yang hilang (RPO) dan batas waktu pemulihan (RTO). Seiring waktu, Anda mungkin perlu melakukan perubahan pada template tersebut.

Pengambilan pencadangan data awal

Saat pertama kali kebijakan dalam template kebijakan membuat cadangan data aplikasi, kebijakan tersebut akan mencadangkan data secara keseluruhan. Pencadangan berikutnya akan bersifat inkremental.

Untuk melindungi beberapa aplikasi dengan satu template kebijakan, terapkan template kebijakan hanya ke beberapa aplikasi. Setelah pengambilan data lengkap awal selesai, terapkan template kebijakan ke lebih banyak aplikasi. Ulangi prosesnya hingga template kebijakan telah diterapkan ke semua aplikasi.

Mengubah ukuran volume

Jika Anda mengubah ukuran volume yang berisi data yang dilindungi, untuk beberapa jenis aplikasi, saat berikutnya kebijakan snapshot untuk volume tersebut berjalan, kebijakan tersebut dapat melakukan operasi pencadangan penuh; terlepas dari berapa kali data volume tersebut telah dicadangkan sebelumnya. Hal ini mencakup VMDK VMWare yang diubah ukurannya dan cadangan berbasis agen dari aplikasi Microsoft Windows dan aplikasi Linux yang tidak berada di LVM.

Jika Anda harus mengubah ukuran volume untuk jenis aplikasi yang terpengaruh, pertimbangkan dampak pengambilan semua data terhadap server aplikasi, jaringan, dan perangkat pencadangan/pemulihan.

Konkurensi tugas

Secara default, appliance pencadangan/pemulihan dapat menjalankan enam tugas snapshot secara serentak. Jika Anda memiliki lebih dari jumlah tugas yang diizinkan yang dijadwalkan untuk periode waktu yang sama, penjadwal kebijakan akan memulai sebanyak mungkin tugas yang diizinkan dan mengantrekan tugas lainnya.

Karena desain jaringan, tata letak data, dan class penyimpanan setiap pengguna berbeda, lakukan eksperimen dengan konkurensi hingga jumlah tugas serentak yang optimal tercapai.

Jadwal kebijakan

Konsol pengelolaan mendukung dua metode untuk menentukan jadwal kebijakan saat mengonfigurasi kebijakan:

  • Berjendela. Menentukan jadwal pencadangan snapshot terpisah yang mematuhi frekuensi dan periode waktu tertentu (misalnya, melakukan pencadangan setiap 30 menit, setiap hari dari pukul 09.00 hingga 17.00 UTC). Anda dapat menginstruksikan perangkat pencadangan/pemulihan untuk menjalankan beberapa tugas pencadangan pada interval frekuensi yang ditentukan atau sekali selama periode waktu yang ditentukan.
  • Berkelanjutan. Menentukan jadwal pencadangan snapshot berkelanjutan (misalnya, melakukan tugas pencadangan setiap delapan jam, memulai tugas pertama pada pukul 01.00 UTC). Dalam jadwal kebijakan ini, tugas berjalan terus-menerus (24/7) pada interval waktu yang ditentukan.

Perhitungan frekuensi

Periode adalah waktu antara operasi terjadwal dan frekuensi adalah jumlah tugas yang dijalankan per satuan waktu. Misalnya, jika jadwal memanggil tugas untuk dijalankan setiap 4 jam, periodenya adalah 4 jam dan frekuensi yang diharapkan adalah 6 kali per hari. Jika tugas memerlukan waktu satu jam untuk diselesaikan dan kebijakan memiliki frekuensi 12 jam, tugas kebijakan akan berjalan lagi 11 jam setelah tugas sebelumnya selesai.

Pastikan untuk memilih frekuensi yang mencapai Recovery Point Objectives (RPO) yang diperlukan dan memberikan waktu yang memadai untuk menyelesaikan tugas.

  • Frekuensi minimum yang direkomendasikan untuk kebijakan Snapshot adalah 1 jam (RPO lokal).
  • Kebijakan StreamSnap dapat mengarah ke kebijakan Snapshot apa pun dengan frekuensi 1 jam atau lebih lama (RPO jarak jauh).

Perlindungan log database dalam kebijakan rencana pencadangan

Saat membuat kebijakan snapshot untuk database, Anda juga memiliki opsi untuk mengambil file lognya dengan frekuensi yang ditentukan. Frekuensi pencatatan log database ditentukan secara terpisah dari database. Misalnya, database dapat diambil setiap hari dan lognya diambil setiap jam.

Frekuensi pencadangan log database ditetapkan dalam hitungan menit, dan frekuensi pencatatan log tidak boleh melebihi frekuensi saat database terkait dicatat. Misalnya, jika frekuensi pengambilan database adalah setiap 24 jam, frekuensi pengambilan file log harus kurang dari setiap 24 jam.

Frekuensi dan retensi ditentukan di setelan lanjutan kebijakan snapshot database. Perekaman log dilakukan tanpa mempertimbangkan batas hari, periode, atau frekuensi saat database terkait direkam.

Anda mengaktifkan fitur Perlindungan Log melalui setelan lanjutan Aktifkan Pencadangan Log Database dalam kebijakan snapshot rencana pencadangan. Frekuensi dan retensi juga ditentukan di setelan lanjutan untuk kebijakan rencana pencadangan.

Ruang fisik yang diperlukan untuk mengakomodasi log database dikelola secara otomatis oleh konsol pengelolaan. Setidaknya, konsol pengelolaan akan mengevaluasi ukuran log standar dan periode retensinya, serta menambahkan ruang sesuai kebutuhan.

Untuk mengaktifkan pencadangan log dan mengelola persyaratan penyimpanan log database dengan lebih efisien dan efektif, lihat tabel ini.

Setelan Input
Memotong atau menghapus log setelah pencadangan Wajib disetel ke Yes untuk menghapus log produksi. Untuk mengelola penghapusan log, pilih opsi ini. Tindakan ini akan menjalankan penghapusan log di akhir setiap pencadangan log. Setelan defaultnya adalah Jangan Pangkas.

Jika kebijakan dengan Enable database log backup disetel ke No, dan jika Truncate or purge log after backup disetel ke Yes, penghapusan log akan berjalan di akhir setiap pencadangan database, yang akan menghapus semua log.
Periode retensi pencadangan log Cadangan log di disk staging Pencadangan dan DR akan dipertahankan sesuai nilai yang ditetapkan di sini. Retensi log cadangan dapat berbeda dengan retensi snapshot.
Ukuran pertumbuhan disk staging log Tetapkan persentase untuk menambah disk staging cadangan log jika diperlukan.
Estimasi rasio perubahan Estimasi persentase perubahan data database setiap hari.
Mengompresi cadangan log database Gunakan ini untuk mengaktifkan pencadangan log database agar berjalan dalam mode kompresi menggunakan API database tingkat aplikasi.
Mengaktifkan pencadangan log database Opsi Enable Database Log Backup memungkinkan kebijakan rencana pencadangan mencadangkan database dan semua file log terkait. Log dicadangkan saat tugas pencadangan log berjalan. Opsi yang tersedia adalah Ya atau Tidak. Jika ditetapkan ke Ya, opsi terkait akan diaktifkan.
RPO Jika Aktifkan Pencadangan Log Database disetel ke Ya, RPO akan menentukan frekuensi untuk pencadangan log database. Frekuensi ditetapkan dalam menit dan tidak boleh melebihi interval pencadangan database.
Mereplikasi log (Menggunakan teknologi StreamSnap) Jika Enable Database Log Backup ditetapkan ke Enable, setelan lanjutan Replicate Logs memungkinkan pencadangan log database direplikasi ke perangkat pencadangan/pemulihan jarak jauh. Agar tugas replikasi pencadangan log dapat berjalan, harus ada kebijakan replikasi StreamSnap yang disertakan dalam template beserta profil resource yang menentukan appliance pencadangan/pemulihan jarak jauh, dan setidaknya satu replikasi database yang berhasil harus diselesaikan terlebih dahulu. Kemudian, Anda dapat menggunakan cadangan log di situs jarak jauh untuk image database apa pun dalam rentang retensi cadangan log yang direplikasi. Fungsi ini diaktifkan secara default.

Replikasi log menggunakan teknologi StreamSnap untuk melakukan replikasi antara perangkat pencadangan/pemulihan lokal dan jarak jauh; replikasi log langsung dilakukan dari kumpulan snapshot lokal ke kumpulan snapshot di perangkat jarak jauh.

Catatan: Replikasi log tidak terjadi hingga database telah dilindungi dan image cadangan database telah direplikasi ke perangkat pencadangan/pemulihan jarak jauh.
Mengirim log ke Tampungan OnVault Jika ditetapkan ke Ya, log akan direplikasi ke satu atau beberapa kumpulan penyimpanan OnVault yang memungkinkan pemulihan point-in-time dari kumpulan OnVault di situs lain.

Prioritas dan penjadwalan tugas

Semua aktivitas berjalan sebagai tugas. Tugas dijalankan sesuai dengan jadwal yang dikonfigurasi saat kebijakan dibuat.

Beberapa tugas memerlukan waktu yang jauh lebih lama daripada tugas lainnya. Tugas masa berlaku berjalan dengan cepat. Tugas snapshot bergantung pada variabel seperti ukuran aplikasi atau VM dan jumlah data yang telah berubah sejak snapshot terakhirnya; snapshot awal dari aplikasi atau VM apa pun adalah data baru, sehingga dapat memerlukan waktu lama.

Penjadwal kebijakan mengidentifikasi kapan satu atau beberapa kebijakan yang diterapkan ke aplikasi akan dijalankan, lalu memulai tugas yang menempatkan kebijakan ke dalam antrean saat waktu mulai terjadwal terjadi. Untuk setiap jenis kebijakan, ada mekanisme kecepatan untuk memastikan bahwa sistem tidak kewalahan dengan tugas yang berjalan. Mekanisme kecepatan ini menggunakan slot tugas untuk mencapai status stabil ini, yang berarti meskipun tugas seharusnya dimulai pada waktu tertentu, tugas tersebut hanya akan dijalankan saat slot tugas tersedia.

Jika beberapa aplikasi dijadwalkan untuk berjalan secara bersamaan dengan prioritas tugas yang sama, pemilihan aplikasi yang akan dijalankan akan diacak untuk memastikan keadilan di semua aplikasi yang memiliki prioritas yang sama.

Percobaan ulang tugas

Jika tugas gagal, penjadwal akan otomatis mencoba lagi menjalankan tugas. Saat pertama kali tugas gagal, penjadwal akan menunggu 4 menit sebelum menyediakan tugas untuk dicoba lagi. Setelah 3 percobaan tugas gagal, tugas tersebut akan ditandai sebagai Gagal dan tidak akan dicoba ulang lagi. Tugas berikutnya akan dicoba sesuai dengan jadwal kebijakan.

Penjadwal akan memperlakukan percobaan ulang tugas seperti tugas lain yang tersedia. Jika ada lebih banyak tugas yang tersedia daripada slot untuk mengakomodasinya, tugas akan diantrekan. Hal ini dapat menyebabkan percobaan ulang gagal dimulai dalam periode waktu tersebut dan tugas ditandai sebagai gagal.

Percobaan ulang tugas dilaporkan di Monitor. Untuk mengidentifikasi percobaan ulang tugas, Monitor menambahkan a terlebih dahulu, lalu b, dan terakhir c ke setiap nama tugas percobaan ulang.

Langkah selanjutnya