Sandaran laman web: apa yang patut disandarkan dan berapa kerap

Hampir setiap pemilik laman web pernah mendengar ayat ini, jangan risau, hosting saya buat sandaran setiap hari. Ayat itu biasanya betul, tetapi ia tidak menjawab soalan yang sebenarnya penting. Soalan itu ialah, kalau laman ini hilang malam ini, berapa lama untuk pulih, dan berapa banyak data yang hilang.

Saya menjaga laman ini di atas pelayan sendiri. Setiap malam pukul 3.30 pagi satu skrip sandaran berjalan, dan ia selesai dalam masa kira-kira dua belas saat. Angka itu datang daripada log sebenar, bukan anggaran. Log itu menulis 03:30:01 mula, dan 03:30:13 selesai. Artikel ini menerangkan apa yang skrip itu sandarkan, mengapa dipilih begitu, dan kepincangan yang masih ada padanya.

Apa yang perlu disandarkan sebenarnya

Ramai orang fikir sandaran bermakna menyalin folder laman web. Itu baru satu bahagian daripada kerja. Ada empat benda berasingan, dan setiap satu hilang dengan cara yang berbeza.

• ▸ Fail tapak. Kandungan webroot, termasuk templat, skrip dan gambar. Saiz webroot di sini 128 MB, tetapi selepas cache dan kelas yang boleh dijana semula dikecualikan, fail yang benar-benar perlu disimpan hanya 92 MB. Menyalin cache hanya membesarkan sandaran tanpa menambah apa-apa yang berguna.
• ▸ Pangkalan data. Pangkalan data utama laman ini 29.9 MB dengan 64 jadual. Apabila didump dan dimampatkan, saiznya menjadi 1.2 MB. Nisbah mampatan yang tinggi ini biasa bagi kandungan teks dan HTML.
• ▸ Konfigurasi pelayan. Fail dalam /etc/nginx, sijil Let's Encrypt, fail fail2ban dan fail perkhidmatan systemd tidak berada dalam folder laman. Tanpa fail ini, laman tidak akan hidup semula walaupun semua fail tapak ada.
• ▸ Peti e-mel dan fail kelayakan. Mel dalam /var/mail/vhosts jarang berubah saiznya dengan banyak, tetapi membina semula semuanya daripada kosong mengambil masa berjam-jam, bukan minit.

Satu keputusan yang mungkin membingungkan ialah fail kelayakan juga dimasukkan ke dalam sandaran. Bunyinya melawan naluri keselamatan, tetapi sandaran itu sendiri disimpan dalam folder yang hanya boleh dibaca oleh root, dengan kebenaran 700. Sandaran yang tidak boleh dipulihkan kerana kata laluan asalnya sudah hilang bukan sandaran. Ia sekadar timbunan fail.

Berapa kerap, dan jawapan yang jujur

Dua ukuran menentukan kekerapan sandaran. Berapa banyak data yang anda sanggup hilang, dan berapa lama anda sanggup laman dibiarkan turun. Bagi laman maklumat seperti laman ini, sekali sehari pada 3.30 pagi sudah memadai. Kalau berlaku masalah pada pukul 2 petang, kita kehilangan pesanan, ulasan dan pos yang masuk sejak awal pagi itu.

Bagi kedai dalam talian yang menerima tempahan sepanjang hari, sekali sehari terlalu longgar. Sandaran penuh setiap jam pula membazir ruang dan masa cakera apabila pangkalan data sudah besar. Susunan yang lebih munasabah ialah sandaran penuh sekali sehari, ditambah binlog MySQL yang membolehkan pemulihan ke saat tertentu tanpa menulis semula seluruh pangkalan data.

Yang penting ialah masa. Satu dump pangkalan data laman ini mengambil masa kira-kira satu saat. Kalau pangkalan data anda 20 GB, jangkaan itu tidak lagi sah. Ukur dahulu, baru tetapkan jadual, supaya satu sandaran tidak bertindih dengan sandaran berikutnya.

Sandaran pada cakera yang sama bukan sandaran

Ini kelemahan terbesar pada banyak pelayan kecil. Sandaran harian disimpan dalam /root/backup, dan folder itu berada pada cakera yang sama dengan laman. Cakera itu /dev/sda1, berkapasiti 145 GB, dengan 33 GB digunakan. Sandaran harian mengambil 656 MB dalam 54 fail, jadi menyimpannya memang murah dan pantas.

Tetapi ia melindungi daripada satu perkara sahaja, iaitu silap padam atau fail yang rosak dan boleh diganti daripada salinan semalam. Ia tidak melindungi daripada cakera yang mati, pelayan yang dicuri, atau ransomware yang menyulitkan setiap fail yang boleh ditulis, termasuk folder sandaran itu sendiri. Kerana itu kita masih perlu satu salinan yang keluar dari pelayan, dan itulah bahagian yang paling kerap tertinggal.

Cara menyandarkan pangkalan data MySQL dengan betul

Menyalin fail pangkalan data ketika MySQL sedang berjalan menghasilkan fail yang nampak lengkap tetapi tidak boleh dipulihkan. Cara yang selamat ialah mysqldump. Dokumentasi MySQL menerangkan mysqldump sebagai sandaran logik yang menghasilkan satu set kenyataan SQL, dan set itu boleh dijalankan semula untuk membina semula struktur jadual dan datanya.

Satu pilihan yang tidak boleh dilangkau ialah --single-transaction. Dokumentasi MySQL menyatakan bahawa tanpa pilihan itu, mysqldump memerlukan kebenaran LOCK TABLES, iaitu jadual perlu dikunci semasa dump berjalan. Dengan pilihan itu, jadual InnoDB didump dalam satu transaksi yang konsisten sambil pelawat masih boleh membaca laman. Pilihan --routines, --triggers dan --events pula memastikan prosedur tersimpan dan pencetus tidak tercicir secara senyap.

mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 --databases thalhah_my \
  | gzip -9 > db-2026-10-06_0330-thalhah_my.sql.gz

Ada dua sebab saya gunakan --databases walaupun hanya satu pangkalan data disandarkan. Pertama, fail dump itu mengandungi kenyataan CREATE DATABASE, jadi pemulihan ke pelayan baharu tidak memerlukan langkah tambahan yang mudah terlupa. Kedua, gzip -9 memampatkan 29.9 MB data hidup kepada 1.2 MB. Sandaran yang kecil lebih mudah dihantar keluar dari pelayan, dan itulah yang menjadikan salinan luar tapak realistik untuk laman kecil.

Sandaran yang tidak diuji bukan sandaran

Pagi ini saya jalankan ujian pemulihan ke atas dump yang dihasilkan pada 3.30 pagi. Dump itu dibuka ke pangkalan data sementara. Bilangan jadual dalam salinan itu 64, sama dengan 64 jadual di pangkalan data hidup. Bilangan baris bagi jadual utama juga sama, produk 172, tarikan 83, resepi_staging 67, makanan 58, seni 40, bisnes 7, admin_pengguna 2. Selepas ujian selesai, pangkalan data sementara itu dibuang dan data hidup tidak disentuh.

gunzip -c /root/backup/db-2026-10-06_0330-thalhah_my.sql.gz | mysql
tar xzf /root/backup/tapak-2026-10-06_0330.tar.gz -C / \
    opt/lucee/tomcat/webapps/ROOT/index.cfm

Fail tapak diuji dengan cara yang sama. Saya keluarkan index.cfm dan Blog.cfc daripada arkib sandaran ke folder sementara, kemudian bandingkan cap jari MD5 kedua-duanya dengan fail yang sedang berjalan. Hasilnya sama. Ujian itu mengambil masa kurang daripada satu minit, dan ia menjawab soalan yang tidak boleh dijawab oleh mana-mana laporan sandaran.

Skrip sandaran itu sendiri membuat satu semakan yang tidak memerlukan manusia. Ia mengira bilangan jadual di dalam dump dan membandingkannya dengan bilangan jadual di pangkalan data hidup. Kalau dump itu kurang walaupun satu jadual, fail itu dibuang dan e-mel amaran dihantar. Dump yang rosak separuh lebih berbahaya daripada tiada dump langsung, kerana kita mempercayainya.

Peraturan 3-2-1 dan kos salinan luar tapak

Peraturan lama yang masih diulang dalam banyak panduan keselamatan ialah 3-2-1. Tiga salinan data, pada dua jenis media berbeza, dengan satu salinan di luar tapak. Tujuannya mudah. Kalau satu salinan hilang bersama pelayan, masih ada salinan lain yang tidak berkongsi nasib yang sama.

Salinan luar tapak pada 2026 tidak semestinya mahal. Storan objek Cloudflare R2 dikenakan AS$0.015 setiap GB sebulan untuk storan standard, dengan 10 GB pertama percuma setiap bulan, dan pemindahan data keluar tidak dikenakan bayaran. Pada kadar semasa kira-kira RM4.08 bagi satu dolar, 10 GB ruang sandaran berharga kira-kira RM0.61 sebulan. Kalau anda mahu lebih ruang dan kawalan, Storage VPS 300 GB daripada Contabo bermula pada AS$6.60 sebulan, lebih kurang RM27, dan ruang itu cukup untuk menyimpan salinan 90 hari.

Kalau menyewa storan kedua tidak berbaloi, cakera luaran juga mencukupi. Yang penting bukan jenama storan, tetapi sama ada salinan itu benar-benar keluar dari mesin yang sama. Fail yang disalin ke folder lain dalam pelayan yang sama tidak dikira sebagai salinan luar tapak. Untuk mengekalkan salinan jauh, rsync yang sedia ada dalam Ubuntu hanya memindahkan bahagian fail yang berubah, jadi hantarannya kecil selepas salinan pertama.

Untuk data peribadi pelanggan, ada satu lagi pertimbangan di Malaysia. Akta Perlindungan Data Peribadi 2010 meletakkan tujuh prinsip di bawah seksyen 5(1), dan salah satunya ialah Prinsip Keselamatan, iaitu langkah perlu diambil supaya data peribadi tidak diubah, disalahguna atau dizahirkan kepada pihak yang tidak berkenaan. Prinsip Penyimpanan pula menyatakan data peribadi tidak boleh disimpan lebih lama daripada yang diperlukan. Dua prinsip itu bersama-sama bermakna sandaran yang disimpan selamanya tanpa sebab juga satu masalah, bukan hanya sandaran yang tiada.

Soalan yang selalu ditanya pemilik laman

Bukankah hosting saya sudah buat sandaran. Biasanya ya, tetapi tanyakan tiga perkara sebelum mempercayainya. Berapa lama salinan disimpan, adakah ia berada pada pelayan yang sama, dan bolehkah anda memulihkannya sendiri tanpa menulis e-mel kepada sokongan. Pada kebanyakan pakej murah, tempoh simpanan tujuh hari dan salinan itu disimpan dalam akaun yang sama. Kalau akaun itu digantung kerana bil tertunggak, sandaran itu hilang bersama laman.

Kalau kata laluan pangkalan data hilang, bolehkah sandaran menolong. Dump yang dibuat dengan --databases membina semula pangkalan data itu, tetapi akaun pengguna MySQL berada dalam skema sistem yang berasingan. Sebab itu fail kelayakan perlu disimpan bersama sandaran, dan ia perlu dikemas kini setiap kali kata laluan bertukar. Laman yang pulih tanpa kata laluan yang betul hanya bertukar daripada laman mati kepada laman yang tidak boleh masuk ke pangkalan datanya.

Berapa lama sandaran patut disimpan. Di pelayan ini tempohnya tujuh hari kerana ruang cakera. Untuk salinan luar tapak, 30 hingga 90 hari lebih munasabah, terutama bagi laman yang menerima tempahan atau bayaran. Masalah yang paling menyakitkan bukan cakera rosak, tetapi data yang rosak perlahan dan hanya disedari tiga minggu kemudian, apabila semua salinan harian sudah ditulis ganti.

Apa yang saya belum pasti, dan had panduan ini

Angka dalam artikel ini datang daripada satu laman kecil, dengan pangkalan data 30 MB dan webroot 128 MB. Dokumentasi MySQL sendiri menyatakan mysqldump bukan penyelesaian yang pantas atau berskala besar, dan pemulihan data besar boleh menjadi perlahan kerana setiap baris perlu dimasukkan semula dan indeks perlu dibina semula. Kalau pangkalan data anda berukuran puluhan GB, cara yang lebih sesuai ialah sandaran fizikal atau klon, bukan dump SQL.

Saya juga belum menguji pemulihan penuh daripada pelayan kosong. Apa yang sudah diuji ialah memulihkan pangkalan data ke pangkalan data sementara, dan memulihkan fail daripada arkib sandaran. Membina semula sebuah pelayan baharu daripada sifar, termasuk pemasangan Lucee, nginx dan sijil, adalah kerja yang berbeza dan belum pernah dijalankan dari awal hingga akhir di sini. Harga storan yang saya sebut dalam dolar pula boleh berubah bila-bila masa, dan ia dikenakan oleh syarikat luar.

Peraturan 3-2-1 juga panduan, bukan undang-undang. Yang wajib di Malaysia ialah langkah keselamatan untuk data peribadi. Kalau laman anda menyimpan maklumat pelanggan, ukurannya bukan berapa banyak salinan yang anda ada, tetapi sama ada salinan itu boleh dipulihkan pada masa yang anda janjikan kepada pelanggan sendiri. Satu sandaran yang pernah diuji lebih bernilai daripada sepuluh sandaran yang tidak pernah dibuka.