Website WordPress kecil yang jarang berubah biasanya memerlukan backup sekurang-kurangnya setiap minggu. Website yang menerima artikel, borang, tempahan atau pesanan setiap hari patut dibackup setiap hari, manakala website e-commerce dan sistem yang merekod transaksi penting mungkin memerlukan backup lebih kerap atau hampir masa nyata.
Jadual terbaik bergantung pada satu soalan mudah: berapa banyak data yang anda sanggup kehilangan jika website perlu dipulihkan sekarang? Jika kehilangan transaksi sejam pun memberi kesan besar, backup harian tidak mencukupi. Selain jadual automatik, buat backup sebelum mengemas kini WordPress, theme, plugin atau kod.
Cadangan jadual backup mengikut jenis website
| Jenis website | Kadar perubahan | Cadangan backup | Catatan |
|---|---|---|---|
| Company profile yang jarang dikemas kini | Rendah | Mingguan | Buat backup tambahan sebelum update atau perubahan besar |
| Blog yang menerbitkan beberapa artikel seminggu | Sederhana | Harian atau selepas penerbitan penting | Pastikan database dan media baharu disimpan |
| Website dengan borang pertanyaan aktif | Sederhana | Harian | Semak juga sama ada data borang disimpan dalam WordPress atau dihantar ke sistem lain |
| Website keahlian, kursus atau portal pelanggan | Tinggi | Beberapa kali sehari | Aktiviti pengguna, kemajuan dan rekod akaun boleh berubah sepanjang hari |
| WooCommerce atau website tempahan | Tinggi | Setiap jam atau hampir masa nyata | Jadual perlu sepadan dengan jumlah pesanan dan transaksi |
| Sebelum update, migrasi atau perubahan kod | Risiko perubahan tinggi | Backup manual semasa | Simpan titik pemulihan sebelum kerja bermula |
Jadual ini ialah titik permulaan, bukan peraturan mutlak. Dokumentasi rasmi WordPress juga mengaitkan kekerapan dengan tahap aktiviti: mingguan untuk website kecil dan harian untuk website yang aktif. Keperluan sebenar boleh menjadi lebih ketat jika website menyimpan transaksi atau data pengguna yang kerap berubah.
Apa yang perlu ada dalam backup WordPress?
Backup WordPress yang lengkap mempunyai dua bahagian utama: database dan fail. Menyimpan salah satu sahaja boleh menyebabkan proses pemulihan tidak lengkap.
1. Backup database
Database biasanya menyimpan artikel, halaman, tetapan, akaun pengguna, komen, pesanan WooCommerce dan data yang digunakan oleh plugin. Untuk website yang aktif, database berubah lebih kerap daripada fail dan mungkin memerlukan jadual backup yang lebih kerap.
2. Backup fail website
Fail merangkumi theme, plugin, gambar, dokumen yang dimuat naik, fail konfigurasi dan kod tambahan. Jika hanya database disimpan, media atau fungsi custom mungkin tidak dapat dipulihkan. Fail boleh dibackup setiap hari atau mengikut kadar perubahan, tetapi satu salinan baharu perlu dibuat selepas memasang plugin, memuat naik banyak media atau mengubah kod.
Tentukan jadual berdasarkan jumlah data yang boleh hilang
Bayangkan website rosak pada jam 4 petang dan backup terakhir dibuat pada tengah malam. Semua perubahan selama 16 jam mungkin hilang. Untuk company profile, risikonya mungkin hanya satu pembetulan teks. Untuk kedai online, ia boleh melibatkan pesanan, pendaftaran pelanggan dan perubahan stok.
Gunakan tiga soalan berikut:
- Berapa banyak rekod atau perubahan berlaku dalam satu jam dan satu hari?
- Berapa lama operasi boleh terganggu sebelum menjejaskan pelanggan?
- Bolehkah data yang hilang dibina semula daripada e-mel, payment gateway atau sistem lain?
Jawapan ini lebih berguna daripada memilih “harian” hanya kerana ia pilihan lalai dalam plugin backup.
Backup automatik perlu disimpan di lokasi berasingan
Backup yang disimpan hanya dalam hosting yang sama masih terdedah kepada kegagalan server, akaun hosting digodam, ruang storan penuh atau fail dipadam bersama website. Sekurang-kurangnya satu salinan perlu dihantar ke lokasi lain seperti cloud storage atau storan luar yang dikawal.
Pendekatan yang praktikal ialah mempunyai:
- satu salinan semasa untuk pemulihan cepat;
- beberapa versi terdahulu supaya masalah yang lewat dikesan tidak menimpa semua backup; dan
- sekurang-kurangnya satu salinan di luar server website.
Panduan backup rasmi WordPress mencadangkan sekurang-kurangnya tiga hingga lima backup terkini dalam lokasi berbeza. Bilangan yang lebih banyak mungkin diperlukan jika masalah hanya diketahui selepas beberapa hari atau minggu.
Berapa lama backup perlu disimpan?
Tempoh simpanan perlu cukup panjang untuk kembali ke versi sebelum masalah bermula. Menyimpan tujuh backup harian sahaja mungkin tidak membantu jika malware atau kerosakan data hanya disedari dua minggu kemudian.
| Lapisan simpanan | Contoh kekerapan | Tujuan |
|---|---|---|
| Backup terkini | Setiap jam atau setiap hari | Memulihkan perubahan dan transaksi terbaru |
| Backup mingguan | Satu salinan setiap minggu | Kembali ke keadaan sebelum masalah yang lewat dikesan |
| Backup bulanan | Satu salinan setiap bulan | Rujukan lebih panjang atau sebelum perubahan besar |
| Backup sebelum perubahan | Setiap kali sebelum update, migrasi atau pembangunan | Menyediakan titik rollback yang jelas |
Polisi sebenar perlu mempertimbangkan ruang storan, sensitiviti data, keperluan organisasi dan tempoh rekod perlu disimpan. Jangan menyimpan backup tanpa had jika ia mengandungi data peribadi yang sudah tidak diperlukan.
Bila backup manual perlu dibuat walaupun sistem automatik aktif?
- Sebelum mengemas kini WordPress, theme atau plugin utama.
- Sebelum memasang plugin baharu atau mengubah kod.
- Sebelum migrasi hosting, domain atau struktur URL.
- Sebelum mengimport, memadam atau mengubah data secara pukal.
- Sebelum menjalankan kerja pembaikan selepas website digodam.
- Selepas perubahan besar selesai dan telah diuji.
Backup sebelum perubahan memberikan titik pemulihan yang diketahui. Catat masa backup, perubahan yang akan dibuat dan orang yang menjalankan kerja supaya pasukan tidak memilih fail yang salah ketika berlaku masalah.
Backup belum dianggap berjaya sehingga restore diuji
Notifikasi “backup completed” hanya menunjukkan proses telah berjalan. Ia tidak membuktikan fail lengkap, database boleh diimport atau website boleh berfungsi selepas dipulihkan.
Ujian restore sebaiknya dibuat pada staging atau persekitaran yang berasingan. Periksa perkara berikut:
- website boleh dibuka dan halaman utama dipaparkan;
- gambar, theme dan plugin tersedia;
- akaun pengguna dan data terbaru wujud;
- borang, login, checkout atau fungsi penting boleh digunakan;
- URL dan sambungan HTTPS berfungsi; dan
- masa yang diperlukan untuk memulihkan website telah direkodkan.
Untuk website kritikal, lakukan ujian berkala dan selepas menukar kaedah backup, hosting atau struktur website.
Kesilapan backup WordPress yang biasa berlaku
Menganggap backup hosting sentiasa mencukupi
Sesetengah hosting menyediakan backup, tetapi kekerapan, tempoh simpanan dan skopnya berbeza. Sahkan sama ada ia merangkumi fail dan database, berapa lama salinan disimpan serta siapa yang boleh menjalankan restore.
Menyimpan semua backup pada server yang sama
Jika server atau akaun hosting terjejas, backup mungkin hilang bersama website. Ia juga boleh memenuhi ruang storan dan menyebabkan proses baharu gagal.
Tidak memantau kegagalan automasi
Backup automatik boleh gagal akibat storan penuh, sambungan cloud terputus, cron tidak berjalan atau perubahan kebenaran fail. Semak log dan notifikasi, bukan sekadar memasang plugin.
Memulihkan terus pada website live tanpa persediaan
Restore boleh menggantikan data semasa dengan versi lama. Sebelum memulihkan, kenal pasti data yang akan hilang, buat salinan keadaan semasa dan tentukan sama ada database penuh atau bahagian tertentu sahaja perlu dikembalikan.
Checklist ringkas untuk pemilik website
- Tentukan berapa banyak data yang sanggup hilang.
- Pastikan database dan fail termasuk dalam backup.
- Gunakan backup automatik mengikut kadar perubahan website.
- Simpan beberapa versi dan sekurang-kurangnya satu salinan off-site.
- Buat backup manual sebelum update atau perubahan besar.
- Semak log kegagalan dan ruang storan.
- Uji proses restore secara berkala.
- Hadkan akses kepada fail backup kerana ia mungkin mengandungi data sensitif.
Jika website telah digodam atau rosak, jangan terus memulihkan backup tanpa mengenal pasti puncanya. Baca panduan tindakan segera apabila website kena hack dan perbandingan kos membaiki atau membina semula website.
Pastikan backup benar-benar boleh digunakan
Jadual backup yang baik perlu disertai pemantauan, salinan off-site dan ujian restore. Jika anda tidak pasti sama ada backup WordPress sedang berjalan atau boleh dipulihkan, Alfatih Studio boleh menyemak setup, kemas kini, keselamatan asas dan keadaan semasa melalui servis Maintenance, Care & Grow.
Soalan lazim
Website kecil yang jarang berubah biasanya boleh bermula dengan backup mingguan. Buat backup tambahan sebelum update WordPress, theme, plugin, migrasi atau perubahan besar.
Ia bergantung pada jumlah transaksi. Jika pesanan berlaku sepanjang hari, backup harian boleh menyebabkan kehilangan banyak pesanan apabila restore dibuat. Pertimbangkan backup database setiap jam atau hampir masa nyata.
Jangan membuat andaian. Semak kekerapan, tempoh simpanan, kandungan backup dan proses restore yang disediakan oleh hosting. Simpan sekurang-kurangnya satu salinan di lokasi berasingan.
Ya. Database menyimpan kandungan, pengguna dan banyak data operasi, manakala fail merangkumi gambar, theme, plugin, konfigurasi dan kod. Kedua-duanya diperlukan untuk pemulihan website yang lengkap.
WordPress mencadangkan sekurang-kurangnya tiga hingga lima backup terkini dalam lokasi berbeza. Website aktif mungkin memerlukan gabungan backup setiap jam, harian, mingguan dan bulanan.
Lakukan ujian restore pada staging atau persekitaran berasingan. Pastikan halaman, gambar, pengguna, data terbaru serta fungsi penting seperti borang, login dan checkout boleh digunakan.
Backup membantu proses pemulihan tetapi tidak menghalang serangan. Website masih memerlukan kemas kini, kawalan akses, pemantauan dan langkah keselamatan. Pastikan backup yang dipulihkan dibuat sebelum jangkitan bermula.
