Sandaran dan Pemulihan Aplikasi CFML

Sandaran dan Pemulihan Aplikasi CFML

Penulis: Thalhah · Tarikh: 16 Oktober 2026

Sandaran aplikasi CFML bermaksud menyimpan salinan empat perkara: kod, pangkalan data, fail muat naik pengguna, dan konfigurasi Lucee. Sandaran tidak bermakna jika ia tidak diuji untuk dipulihkan. Artikel ini menerangkan apa yang mesti disandarkan, kenapa konfigurasi Lucee sering dilupakan, dan senarai semak sebelum kemas kini berisiko.

Apa yang Mesti Disandarkan

Empat aset membentuk aplikasi CFML yang lengkap. Pertama, kod sumber, iaitu fail .cfm dan .cfc, yang paling mudah kerana biasanya sudah dalam kawalan versi. Kedua, pangkalan data, yang memegang data pelanggan dan perniagaan. Ketiga, fail muat naik pengguna, yang hidup pada sistem fail dan tidak pernah dalam kawalan versi. Keempat, konfigurasi Lucee, yang menentukan datasource, pemetaan dan tetapan lain.

Kod dan pangkalan data sering disandarkan, tetapi fail muat naik dan konfigurasi Lucee ialah dua lubang yang paling kerap dilupakan. Sandaran pangkalan data boleh dilakukan dengan alat seperti mysqldump, dan kod serta fail muat naik dengan arkib fail:

mysqldump -u app_user -p myapp > myapp-$(date +%F).sql
tar -czf myapp-$(date +%F).tar.gz /var/www /opt/lucee/web

Arahan pertama mengeksport pangkalan data ke fail SQL bertarikh, manakala arahan kedua mengarkibkan webroot dan konfigurasi web Lucee ke satu fail termampat. Pastikan arahan sandaran pangkalan data menggunakan akaun dengan keistimewaan baca sahaja untuk mengurangkan risiko.

Kenapa Konfigurasi Lucee Sering Dilupakan

Konfigurasi Lucee ialah fail .CFConfig.json yang sejak Lucee 6 menggantikan konfigurasi XML lama. Ia menyimpan datasource, pemetaan, tetapan caching dan banyak lagi, dan tanpanya aplikasi anda tidak boleh menyambung ke pangkalan data selepas pemulihan. Fail konfigurasi pelayan biasanya terletak di /lucee-server/context/.CFConfig.json, manakala konfigurasi web dalam mod berbilang berada di /WEB-INF/lucee/.CFConfig.json.

Konfigurasi ini sering dilupakan kerana ia diubah melalui Lucee Administrator dan bukannya fail yang disentuh pembangun setiap hari. Amalan terbaik ialah mengeksport konfigurasi selepas setiap perubahan dan menyimpannya bersama kod. Konfigurasi menyokong pemegang tempat untuk data sensitif, jadi kata laluan boleh disimpan sebagai pemboleh ubah persekitaran dan bukannya teks kosong dalam fail:

{
  "dataSources": {
    "myds": {
      "host": "localhost",
      "username": "{env:MYDS_USERNAME}",
      "password": "${MYDS_PASSWORD}"
    }
  }
}

Untuk memahami datasource dengan lebih mendalam, baca panduan konfigurasi datasource.

Menjadualkan Sandaran Automatik

Sandaran manual mudah dilupakan, jadi jadualkan ia. Penjadual Lucee boleh menjalankan tugas pada selang tetap, dan anda boleh memautkannya kepada skrip sandaran pada pelayan. Untuk pangkalan data, gunakan cron sistem pengendalian atau alat pengurusan sandaran yang menjalankan mysqldump pada waktu trafik rendah. Kunci kejayaan ialah memastikan sandaran benar-benar selesai dan tidak gagal secara senyap, jadi hantar pemberitahuan kegagalan dan semak log sandaran secara berkala. Uji pemulihan daripada sandaran automatik dan bukannya sandaran manual, kerana skrip yang dijadualkan boleh menghasilkan fail yang berbeza daripada yang anda jangkakan.

Sandaran Pangkalan Data: Dump Penuh dan Tambahan

Dump penuh mengeksport keseluruhan pangkalan data pada satu masa, manakala sandaran tambahan hanya merekod perubahan sejak sandaran terakhir. Dump penuh lebih mudah dipulihkan kerana ia lengkap sendiri, tetapi mengambil ruang dan masa yang lebih banyak. Banyak pangkalan data menyokong log binari yang membolehkan pemulihan ke titik masa tertentu, berguna apabila ralat disedari lewat. Pilih gabungan yang sepadan dengan toleransi kehilangan data anda dan uji pemulihan kedua-dua jenis.

Kekerapan dan Retensi

Kekerapan sandaran ditentukan oleh berapa banyak data yang anda sanggup hilang. Pangkalan data pengeluaran biasanya disandarkan setiap hari, atau lebih kerap dengan sandaran tambahan. Kod disandarkan pada setiap commit melalui kawalan versi. Retensi pula ialah berapa lama anda menyimpan sandaran: simpan beberapa salinan harian, mingguan dan bulanan supaya ralat yang tidak disedari selama berminggu masih boleh dipulihkan. Uji jadual ini secara berkala supaya anda tahu ia benar-benar berjalan dan bukannya gagal secara senyap. Sesuaikan jadual dengan kadar perubahan data: aplikasi dengan transaksi tinggi memerlukan sandaran lebih kerap berbanding laman yang jarang berubah.

Sandaran Luar Pelayan

Sandaran yang berada pada cakera yang sama dengan pelayan bukan sandaran: ia hilang bersama pelayan. Salin sandaran ke lokasi luar pelayan, seperti storan objek atau pelayan kedua di pusat data berbeza. Peraturan tiga-dua-satu ialah panduan berguna: tiga salinan, dua media berbeza, satu di luar tapak. Bagi aplikasi yang berjalan dalam bekas, pastikan volum berterusan disandarkan, seperti yang dibincangkan dalam panduan deploy Docker. Automasikan pemindahan supaya ia berlaku sejurus selepas sandaran selesai, dan sahkan salinan luar pelayan wujud dengan memeriksa saiz dan tarikhnya secara berkala, kerana pemindahan yang gagal secara senyap meninggalkan anda tanpa salinan luar.

Menyulitkan dan Melindungi Sandaran

Sandaran mengandungi data sensitif, jadi layan ia seperti aset sensitif. Sulitkan arkib sebelum menghantarnya ke storan luar pelayan, dan simpan kunci penyulitan berasingan daripada sandaran itu sendiri. Hadkan akses kepada fail sandaran kepada akaun yang benar-benar memerlukannya, kerana satu salinan yang bocor mendedahkan keseluruhan pangkalan data anda. Uji proses penyahsulitan semasa ujian pemulihan supaya anda tidak terkejut semasa bencana. Sandaran yang disulitkan tetapi kunci disimpan dalam fail yang sama tidak menambah perlindungan; pastikan kunci benar-benar berasingan dan hanya boleh diakses oleh proses pemulihan.

Ujian Pemulihan, Bukan Hanya Membuat Sandaran

Sandaran yang tidak pernah dipulihkan ialah andaian, bukan jaminan. Uji pemulihan secara berkala dengan memulihkan ke persekitaran ujian dan sahkan aplikasi berjalan. Proses ini mendedahkan masalah yang tidak kelihatan semasa membuat sandaran, seperti fail yang hilang, kebenaran yang salah, atau konfigurasi yang tidak lengkap. Catat masa yang diambil untuk memulihkan, kerana masa pemulihan ialah metrik sebenar yang penting semasa bencana, bukan sekadar wujudnya fail sandaran. Jadikan ujian pemulihan sebahagian daripada rutin tetap, bukan acara tahunan, kerana persekitaran berubah dan apa yang berfungsi bulan lepas mungkin gagal bulan ini.

Memulihkan Aplikasi Selepas Bencana

Pemulihan mengikut urutan terbalik sandaran. Pulihkan pangkalan data dahulu, kemudian fail kod dan muat naik, kemudian konfigurasi Lucee, dan akhir sekali uji aplikasi. Susunan penting kerana kod dan konfigurasi tidak berguna tanpa data, dan datasource yang ditakrifkan dalam konfigurasi mesti sepadan dengan pangkalan data yang dipulihkan. Jalankan ujian asap selepas pemulihan: buka halaman utama, log masuk, dan lakukan satu transaksi pangkalan data untuk memastikan keseluruhan laluan berfungsi. Catat setiap langkah pemulihan dalam dokumen yang boleh diikuti oleh sesiapa sahaja, bukan hanya orang yang menyediakan sandaran.

Senarai Semak Sebelum Kemas Kini Berisiko

Sebelum naik taraf Lucee atau kemas kini besar, jalankan senarai semak ini:

Naik taraf antara versi utama Lucee boleh membawa perubahan yang mematahkan kod, jadi rujuk panduan migrasi dan sambungkan proses ini dengan panduan deploy tanpa henti.

Dokumen Pelan Pemulihan

Pelanggan tidak peduli bahawa sandaran anda wujud; mereka peduli seberapa pantas anda kembali dalam talian. Tulis dokumen pelan pemulihan yang menyenaraikan setiap langkah mengikut urutan, bersama arahan sebenar yang perlu dijalankan dan lokasi setiap sandaran. Simpan dokumen ini di luar pelayan supaya ia boleh diakses walaupun pelayan mati. Uji pelan ini sekurang-kurangnya sekali setiap suku tahun, dan kemas kini ia setiap kali seni bina aplikasi berubah. Pelan pemulihan yang lapuk hampir sama buruknya dengan tiada pelan langsung.

Soalan Lazim (FAQ)

Apa yang mesti disandarkan untuk aplikasi CFML?

Kod, pangkalan data, fail muat naik pengguna, dan konfigurasi Lucee (.CFConfig.json).

Di manakah fail konfigurasi Lucee disimpan?

Konfigurasi pelayan biasanya di /lucee-server/context/.CFConfig.json, dan konfigurasi web di WEB-INF/lucee/.CFConfig.json dalam mod berbilang.

Kenapa konfigurasi Lucee sering dilupakan dalam sandaran?

Kerana ia diubah melalui Lucee Administrator dan bukannya fail yang disentuh pembangun setiap hari, jadi ia mudah terlepas pandang.

Berapa kerap saya patut membuat sandaran?

Pangkalan data biasanya setiap hari atau lebih kerap, kod pada setiap commit, dengan retensi gabungan harian, mingguan dan bulanan.

Kenapa ujian pemulihan penting?

Kerana sandaran yang tidak pernah dipulihkan ialah andaian, bukan jaminan. Ujian mendedahkan masalah seperti fail hilang atau konfigurasi tidak lengkap.

Sumber

• Configuration - CFConfig.json, docs.lucee.org
• Deploying Lucee, docs.lucee.org
• Docker, docs.lucee.org
• Creating Heap Dumps in Lucee, docs.lucee.org