Cara Mengesahkan Backup Laman Web Benar-Benar Boleh Dipulihkan

Fail backup yang tersimpan dalam storan hampir tidak membuktikan apa-apa dengan sendirinya. Ia membuktikan satu proses telah berjalan dan menghasilkan satu fail. Ia tidak membuktikan fail itu lengkap, bahawa ia boleh diubah semula menjadi laman web yang berfungsi, atau berapa lama masa itu akan diambil jika anda memerlukannya dengan segera. Satu-satunya perkara yang membuktikan backup berfungsi ialah memulihkannya (restore) dan menyemak hasilnya — dan kebanyakan perniagaan tidak pernah melihat itu berlaku, kerana ia biasanya tidak kelihatan melainkan sesuatu sudah pun tersasar.

Artikel ini ditulis untuk pemilik bukan teknikal yang ingin bertanya soalan yang tepat, bukan sekadar menerima "kami ada backup" sebagai jawapan yang lengkap.

Backup yang tidak diuji hanyalah satu hipotesis

Anggap backup sebagai satu dakwaan dan bukan fakta sehinggalah seseorang mengujinya. Fail boleh ditulis separuh sahaja. Eksport pangkalan data boleh selesai tetapi merujuk kepada jadual atau plugin yang tidak pernah disertakan. Backup boleh disimpan dengan betul tetapi alat restore atau kelayakan (credentials) yang diperlukan untuk menggunakannya boleh hilang, tamat tempoh, atau langsung tidak pernah dicuba. Tiada satu pun daripada masalah ini kelihatan hanya dengan melihat senarai fail atau e-mel "backup berjaya" — ia hanya kelihatan apabila seseorang benar-benar memulihkan backup itu di suatu tempat dan menyemak sama ada laman web itu berfungsi.

Ujian praktikal ini mudah diterangkan tetapi jarang dilakukan: ambil satu backup, pulihkan ia ke dalam salinan laman web yang berasingan dan peribadi, dan sahkan halaman-halaman dimuatkan, pangkalan data utuh, dan tiada apa-apa yang kritikal hilang. Jika tiada siapa telah melakukan itu untuk laman web anda, anda pada masa ini tidak tahu sama ada backup anda berfungsi.

RPO dan RTO, dalam bahasa yang mudah

Dua istilah sering muncul dalam perbualan tentang backup dan pemulihan bencana (disaster recovery), dan ia berbaloi difahami kerana ia mengubah kebimbangan yang kabur menjadi soalan khusus yang boleh dijawab.

Recovery Point Objective (RPO) ialah berapa banyak data yang mampu anda kehilangan, diukur dalam masa. National Institute of Standards and Technology Amerika Syarikat mentakrifkan RPO sebagai "titik masa yang mana data mesti dipulihkan selepas sesuatu outage" (NIST, SP 800-34). Pada praktiknya: jika backup anda berjalan sekali sehari dan sesuatu tersasar lima minit sebelum backup seterusnya, RPO anda lebih kurang 24 jam — bermakna pesanan, penyerahan borang, atau perubahan kandungan sepanjang sehari boleh hilang.

Recovery Time Objective (RTO) pula ialah berapa lama masa yang diambil untuk kembali berfungsi. NIST menerangkan RTO sebagai tempoh masa sesuatu sistem boleh berada dalam fasa pemulihan "sebelum menjejaskan misi organisasi atau proses misi/perniagaannya secara negatif" (NIST, SP 800-34). Pada praktiknya: jika restore tidak pernah dicuba, RTO sebenar anda adalah tidak diketahui, bukan sifar — dan "tidak diketahui" adalah nombor yang teruk untuk ditemui semasa outage sebenar berlaku.

Tanya mana-mana penyedia untuk kedua-dua nombor ini khusus untuk laman web anda, bukan sekadar dakwaan umum. Jika mereka tidak dapat menjawab, itu adalah titik permulaan yang jujur untuk sesuatu perbualan, bukan sebab untuk berundur — banyak laman web perniagaan kecil yang memang belum mengukur ini lagi.

Prinsip 3-2-1

Satu asas yang digunakan secara meluas, dan disyorkan oleh Cybersecurity and Infrastructure Security Agency Amerika Syarikat untuk perniagaan kecil, ialah peraturan 3-2-1: simpan tiga salinan data anda, pada dua jenis storan yang berbeza, dengan sekurang-kurangnya satu salinan disimpan di suatu tempat yang secara fizikal berasingan daripada yang asal (CISA, Back Up Business Data). Sebabnya mudah — satu backup tunggal yang disimpan di tempat yang sama dengan laman live terdedah kepada kegagalan yang sama (pelayan yang digodam, masalah akaun hosting, satu kesilapan) yang boleh meruntuhkan yang asal. Dua jenis media berbeza dan satu salinan luar tapak (offsite) mengurangkan kemungkinan satu kejadian buruk memusnahkan semuanya sekali gus.

Anda tidak perlu menyiasat pelaksanaan teknikal yang tepat, tetapi adalah wajar untuk bertanya sama ada backup disimpan di suatu tempat yang berasingan daripada pelayan live, dan sama ada lebih daripada satu salinan wujud pada bila-bila masa.

Nota tentang skrip dan kelayakan (credentials)

Jika sesuatu penyedia menunjukkan kepada anda skrip atau konfigurasi yang digunakan untuk menjalankan atau menguji restore, satu perkara yang wajar disemak tanpa mengira butiran teknikalnya: ia tidak sepatutnya mengandungi kata laluan, API key, atau passphrase yang ditulis terus ke dalam fail itu. Kelayakan (credentials) sepatutnya berada dalam environment variables — nilai yang ditetapkan di luar skrip, pada mesin atau sistem yang menjalankannya — supaya skrip itu sendiri boleh dikongsi, disemak, atau disimpan dalam version control tanpa membocorkan akses kepada apa-apa. Skrip dengan kata laluan sebenar yang ditaip terus di dalamnya ialah skrip yang membocorkan kata laluan itu kepada sesiapa sahaja yang pernah melihat fail tersebut, termasuk dalam backup skrip itu sendiri. Corak yang selamat kelihatan seperti ini, menggambarkan idea tersebut dan bukan mana-mana alat tertentu:

#!/usr/bin/env bash
# Restore test — reads the passphrase from the environment,
# never from a value written into this file.
set -euo pipefail

: "${BACKUP_ARCHIVE_PATH:?set BACKUP_ARCHIVE_PATH}"
: "${RESTORE_PASSPHRASE:?set RESTORE_PASSPHRASE in the environment, not here}"

backup-restore-tool --archive "$BACKUP_ARCHIVE_PATH" \
  --passphrase-env RESTORE_PASSPHRASE \
  restore latest --target /tmp/restore-check

echo "Restore complete. Now check the site actually works."

Intinya bukan alat tertentu itu — tetapi coraknya: kelayakan datang daripada environment, skrip itu gagal secara jelas (fails loudly) jika ia hilang, dan tiada apa-apa yang sensitif disimpan dalam teks biasa (plain text) bersebelahan dengan kod.

Apa yang perlu diminta daripada penyedia sebagai bukti

Satu set soalan yang khusus dan adil: Bila kali terakhir restore daripada backup kami benar-benar diuji, dan apa hasilnya? Apakah RPO kami sekarang — berapa banyak data yang boleh kami hilang jika sesuatu berlaku sekarang juga? Apakah RTO kami sekarang — lebih kurang berapa lama restore sebenar akan mengambil masa? Adakah backup disimpan di suatu tempat yang berasingan daripada pelayan live? Berapa banyak salinan backup terkini disimpan, dan untuk berapa lama?

Jika sesuatu penyedia dapat menjawab soalan-soalan ini dengan tarikh dan butiran khusus, itu adalah tanda yang baik. Jika jawapan jujurnya ialah "kami belum menguji restore baru-baru ini," itu masih berguna — ia memberitahu anda dengan tepat apa yang perlu dibaiki dahulu, dan ia jawapan yang lebih berguna berbanding keyakinan palsu.

Apa yang ini tidak janjikan

Mengesahkan satu restore sekali sahaja tidak bermakna setiap backup pada masa hadapan juga akan pulih dengan bersih selama-lamanya — konfigurasi berubah, data berkembang, dan pengujian perlu berlaku secara berterusan, bukan sebagai satu latihan sekali sahaja. Proses backup yang telah diuji meningkatkan peluang anda dengan ketara dalam situasi buruk; ia tidak menjadikan kehilangan data mustahil.

---

JagaWeb Care (RM450 sebulan, tidak termasuk SST) merangkumi backup yang disahkan sebagai sebahagian daripada retainer — bermakna restore benar-benar diuji, bukan sekadar diandaikan berfungsi — bersama monitoring, patching, dan dua kemas kini kandungan sebulan, dengan checkout kad tanpa panggilan jualan. Ini adalah satu pilihan antara beberapa cara untuk menangani perkara ini, bukan jaminan bahawa tiada apa-apa akan pernah rosak. Maklumat lanjut di jagaweb.my, sales@jagaweb.my, atau WhatsApp jagaweb.my.