Backup Data Pesantren Belum Selesai sampai Bisa Dipulihkan

Berkas backup yang berhasil diunduh belum membuktikan bahwa layanan bisa kembali berjalan.

Arsip mungkin bisa dibuka, tetapi kunci enkripsinya tertinggal. Database mungkin berhasil diimpor, tetapi dokumen santri belum ikut. Masalah seperti ini lebih baik ditemukan saat latihan, bukan ketika bendahara membutuhkan riwayat pembayaran dan server utama sedang tidak dapat dipakai.

Rencana backup perlu menjawab tiga hal: data apa yang disalin, berapa banyak perubahan yang sanggup diulang bila terjadi gangguan, dan siapa yang benar-benar dapat memulihkannya. Jawaban tersebut menentukan jadwal, tempat penyimpanan, serta bentuk pengujiannya.

Tentukan batas kehilangan data yang masih dapat diterima #Tautan ke bagian Tentukan batas kehilangan data yang masih dapat diterima

Bicarakan dengan pengurus: kalau sistem berhenti, berapa lama pencatatan bisa menunggu? Berapa banyak transaksi yang masih bisa dimasukkan ulang dari bukti? Pondok yang menerima pembayaran setiap hari perlu menilai risiko berbeda dari website yang hanya sesekali mengganti pengumuman.

Frekuensi backup tidak menjamin waktu pulih. Salinan harian masih membutuhkan server pengganti, akses konfigurasi, dan petugas yang mengerti prosesnya. Tulis kebutuhannya dengan jelas, misalnya: “bukti penerimaan tetap disimpan agar pencatatan sejak backup terakhir bisa direkonsiliasi”. Hindari janji pulih beberapa menit jika belum pernah diukur.

Ketahui isi backup Pondok CMS #Tautan ke bagian Ketahui isi backup Pondok CMS

Dokumentasi backup menjelaskan arsip yang berisi data tabel, manifest, berkas private, dan berkas public. Data SQL di dalamnya tidak membawa struktur tabel. Kode aplikasi versi yang sesuai tetap diperlukan untuk membentuk tabel sebelum data dipulihkan.

Berkas .env tidak ikut arsip. Simpan salinannya melalui tempat penyimpanan rahasia yang dibatasi akses. APP_KEY yang sama diperlukan untuk membaca kembali kolom terenkripsi. Jangan menempelkan isi konfigurasi tersebut pada grup pengurus atau catatan serah terima yang dibagikan luas.

Backup bawaan mendukung MySQL, MariaDB, dan SQLite. Untuk PostgreSQL, dokumentasi mengarahkan penggunaan alat atau backup panel yang sesuai. Jangan menganggap satu prosedur dapat digunakan tanpa penyesuaian pada semua jenis database.

Jangan biarkan seluruh salinan berada pada server yang sama #Tautan ke bagian Jangan biarkan seluruh salinan berada pada server yang sama

Arsip lokal membantu pemulihan cepat, tetapi ikut berisiko jika akun hosting diambil alih atau server rusak. Simpan salinan tambahan di luar hosting pada media yang dikelola lembaga, dengan akses terbatas dan perlindungan yang sesuai tingkat sensitivitasnya.

Backup memuat data pribadi. Jangan menaruh arsip di folder website publik, termasuk public_html. Menyembunyikan nama berkas bukan pembatasan akses. Catat siapa boleh mengambil arsip, bagaimana pemindahannya, dan kapan salinan yang tidak lagi dibutuhkan dihapus.

Dokumentasi menyebut penyimpanan tiga arsip terbaru; backup manual ikut dalam hitungan tersebut. Karena itu, jangan memperlakukan rotasi lokal sebagai arsip jangka panjang. Pengurus perlu menentukan retensi salinan luar hosting berdasarkan kebutuhan dan kapasitas, bukan hanya mengikuti jumlah berkas yang tersisa di server.

Latihan pemulihan dilakukan di tempat terpisah #Tautan ke bagian Latihan pemulihan dilakukan di tempat terpisah

Siapkan lingkungan uji yang tidak memakai database, folder unggahan, atau domain produksi. Batasi aksesnya karena salinan uji tetap berisi data sensitif. Nonaktifkan pengiriman email nyata, integrasi keluar, serta pekerjaan terjadwal yang dapat menghubungi pengguna atau menjalankan transaksi.

Minta petugas teknis mengikuti urutan pemulihan pada dokumentasi: gunakan versi aplikasi yang cocok, siapkan database kosong, bentuk tabel tanpa seeder, lalu pulihkan data dan unggahan. Jangan mengimpor SQL backup ke database produksi untuk sekadar mencoba. Perintah pemulihan dapat mengganti data yang sudah ada.

Sebelum mulai, minta pemeriksa kedua memastikan nama database dan direktori tujuan. Catat waktu mulai dan hambatan. Berhentilah jika tujuan belum bisa dibedakan dengan jelas dari layanan yang sedang dipakai.

Periksa hasilnya melalui pekerjaan nyata #Tautan ke bagian Periksa hasilnya melalui pekerjaan nyata

Uji beberapa sampel yang disepakati: pencarian santri, tagihan lama, pembayaran, unduhan dokumen, dan foto. Cocokkan jumlah baris dengan manifest serta beberapa nilai dengan laporan pembanding. Berhasil masuk ke halaman login saja belum cukup.

Jalankan pemeriksaan aplikasi sesuai dokumentasi dan baca hasilnya. HTTPS dan pemeriksaan menjelaskan fungsi pondok:doctor; sesudahnya, petugas yang berhak tetap perlu memeriksa data dan berkas yang biasa dipakai.

Tulis hasil latihan: arsip yang dipakai, versi aplikasi, petugas, durasi, sampel, serta kegagalan yang ditemukan. Setelah selesai, hapus salinan uji dan rahasia yang tidak lagi diperlukan sesuai prosedur lembaga. Bila latihan gagal, perbaiki rencananya dan ulangi pengujian sebelum menyatakan backup dapat dipulihkan.

Masukkan lokasi petunjuk pemulihan ke serah terima operator. Pengganti operator perlu tahu cara menemukan panduan dan meminta akses, tanpa harus menerima seluruh rahasia melalui satu dokumen terbuka.