Skip to content

Domain, hosting, code and data — in your name, in writing

jagaweb.

Pengehosan & Infrastruktur

Pelan Pemulihan Bencana (Disaster Recovery) Laman Web Perniagaan Malaysia

Bacaan 8 minitOleh Pasukan Teknikal JagaWeb

Bina pelan pemulihan bencana (DRP) laman web perniagaan Malaysia. Ketahui formula RTO, RPO, sandaran luar tapak automatik S3, dan simulasi pemulihan data.

Dalam dunia digital hari ini, bencana pelayan bukan lagi persoalan jika, tetapi bila. Kebakaran pusat data (seperti insiden kebakaran besar di hab AIMS/Cyberjaya sebelum ini), serangan perisian tebusan (ransomware), kegagalan migrasi pangkalan data, atau kesilapan manusia yang memadam fail produksi berlaku secara kerap di Malaysia.

Namun, lebih 80% PKS di Malaysia hanya bergantung kepada sandaran automatik cPanel yang disimpan pada pelayan yang sama dengan laman web mereka. Sekiranya pelayan fizikal tersebut terbakar atau akaun digodam, semua fail sandaran akan musnah bersama-sama laman web.

Berikut adalah panduan kejuruteraan lengkap untuk membina Pelan Pemulihan Bencana (Disaster Recovery Plan - DRP) gred perusahaan bagi perniagaan di Malaysia.


1. Memahami Metrik Utama: RTO dan RPO

Setiap Pelan Pemulihan Bencana yang berkesan diukur berasaskan dua metrik utama:

+--------------------------------------------------------------------+
|               GARIS MASA PEMULIHAN BENCANA (DRP)                   |
|                                                                    |
| <------------ RPO ------------> | <------------ RTO ------------>  |
| [ Sandaran Terakhir Sah ] ----> [ Bencana Berlaku ] -> [ Sistem Pulih]
| (Had Kehilangan Data Maksimum)  (Masa Henti Mula)      (Beroperasi Semula)
+--------------------------------------------------------------------+

1. Recovery Point Objective (RPO)

  • Definisi: Tempoh masa maksimum kehilangan data yang boleh diterima oleh perniagaan antara sandaran terakhir dan waktu berlakunya bencana.
  • Piawaian Web Korporat: RPO < 24 Jam (Sandaran Harian).
  • Platform E-Dagang / SaaS: RPO < 15 Minit (Replikasi Log Binari Berterusan / Sandaran Setiap Jam).

2. Recovery Time Objective (RTO)

  • Definisi: Tempoh masa maksimum yang diambil untuk memulihkan keseluruhan sistem sehingga kembali beroperasi sepenuhnya selepas insiden diisytiharkan.
  • Piawaian Web Korporat: RTO < 2 Jam.
  • Platform Misi Kritikal: RTO < 30 Minit.

2. Seni Bina Sandaran Luar Tapak 3-2-1

Untuk menjamin pemulihan data dalam sebarang senario bencana, laksanakan Peraturan Sandaran 3-2-1:

  • 3 Salinan Data: 1 Salinan Produksi + 2 Salinan Sandaran.
  • 2 Format Media Berbeza: Salinan setempat pelayan (rollback pantas) + Storan Objek Awan.
  • 1 Lokasi Luar Tapak Berasingan: Disimpan dalam akaun awan terpencil (contohnya AWS S3 Singapura / Cloudflare R2 / Google Cloud Storage) dengan kunci akses IAM berasingan.
+--------------------------------------------------------------------+
|                   TOPOLOGI SANDARAN 3-2-1                          |
|                                                                    |
| [ Pelayan Produksi Utama ]                                         |
| (cPanel / Cloud Run)                                               |
|         |                                                          |
|         +---> [ Sandaran Setempat Harian ] (Pemulihan Pantas)      |
|         |                                                          |
|         +---> [ Enkripsi AWS S3 / Cloudflare R2 ] (Bilik Kebal SG) |
|               (Akaun Terpencil dengan Enkripsi AES-256)            |
+--------------------------------------------------------------------+

3. Skrip Bash Automatik untuk Sandaran Enkripsi Luar Tapak

Berikut adalah skrip automasi peringkat pengeluaran yang mengekstrak pangkalan data MySQL, memampatkan fail web, menyulitkannya menggunakan GPG (AES-256), dan memuat naiknya ke AWS S3 / Cloudflare R2:

#!/bin/bash
# ==============================================================================
# Skrip Sandaran Pemulihan Bencana Automatik JagaWeb
# ==============================================================================
set -euo pipefail

# Konfigurasi Sistem
NAMA_LAMAN="syarikat_saya"
DIREKTORI_WEB="/home/username/public_html"
NAMA_DB="db_produksi"
PENGGUNA_DB="db_backup_user"
KATALALUAN_DB="KatalaluanKukuh123!"
DIREKTORI_SEMENTARA="/tmp/backups"
CAP_MASA=$(date +"%Y%m%d_%H%M%S")
BALDI_S3="s3://sandaran-dr-syarikat-sg/harian"
KUNCI_GPG="FrasaRahsiaEnkripsiGPGAnda"

mkdir -p "$DIREKTORI_SEMENTARA"

echo "[1/4] Mengekstrak pangkalan data MySQL..."
mysqldump -u "$PENGGUNA_DB" -p"$KATALALUAN_DB" --single-transaction --quick "$NAMA_DB" > "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_db_${CAP_MASA}.sql"

echo "[2/4] Memampatkan fail web public_html..."
tar --exclude='wp-content/cache'     -czf "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_fail_${CAP_MASA}.tar.gz" -C "$DIREKTORI_WEB" .

echo "[3/4] Melakukan enkripsi arkib dengan GPG (AES-256)..."
tar -czf "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_lengkap_${CAP_MASA}.tar.gz" -C "$DIREKTORI_SEMENTARA"     "${NAMA_LAMAN}_db_${CAP_MASA}.sql" "${NAMA_LAMAN}_fail_${CAP_MASA}.tar.gz"

gpg --batch --yes --passphrase "$KUNCI_GPG" --symmetric --cipher-algo AES256     -o "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_disulitkan_${CAP_MASA}.tar.gz.gpg"     "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_lengkap_${CAP_MASA}.tar.gz"

echo "[4/4] Memuat naik ke Storan Awan Luar Tapak (AWS S3 / Cloudflare R2)..."
aws s3 cp "$DIREKTORI_SEMENTARA/${NAMA_LAMAN}_disulitkan_${CAP_MASA}.tar.gz.gpg" "$BALDI_S3/" --endpoint-url https://s3.ap-southeast-1.amazonaws.com

# Bersihkan fail sementara
rm -rf "$DIREKTORI_SEMENTARA"
echo "Sandaran pemulihan bencana berjaya dihantar ke storan luar tapak!"

Jadualkan skrip ini dalam Crontab untuk berjalan secara automatik setiap malam pada jam 2:00 pagi:

0 2 * * * /usr/local/bin/jagaweb-dr-backup.sh > /var/log/dr-backup.log 2>&1

4. Simulasi Pemulihan Bencana Suku Tahunan

Sandaran data yang tidak pernah diuji dalam simulasi pemulihan bukanlah sandaran sebenar—ia hanyalah andaian.

Laksanakan ujian pemulihan simulasi setiap suku tahun:

  1. Lancarkan pelayan VPS pementasan (staging) kosong pada penyedia pengehosan yang berbeza.
  2. Muat turun fail arkib terenkripsi terkini daripada AWS S3.
  3. Nyahsulit dan import pangkalan data serta fail media.
  4. Uji fungsi transaksi jualan, keselamatan SSL, dan integriti data.
  5. Catat masa keseluruhan yang diambil untuk memastikan sasaran RTO < 2 Jam dipenuhi.

Matriks Kesiapsiagaan Bencana

+----------------------------+-----------------------+-----------------------+
| Ciri Perlindungan          | Hosting Kongsi Tradisional | JagaWeb Enterprise DR|
+----------------------------+-----------------------+-----------------------+
| Lokasi Storan Sandaran     | Pelayan cPanel Sama   | Encrypted AWS S3 / R2 |
| Enkripsi Data              | Tiada (Teks Biasa)    | AES-256 (GPG)         |
| Kelajuan Pemulihan         | 24 - 72 Jam (Perlahan)| < 30 - 60 Minit       |
| Ketahanan Ransomware       | Sangat Terdedah       | Kunci S3 Tidak Boleh Ubah|
| Ujian Simulasi Berkala     | Tiada                 | Suku Tahunan Disahkan |
+----------------------------+-----------------------+-----------------------+

Lindungi Aset Digital Teras Perniagaan Anda Bersama JagaWeb

Jangan tunggu sehingga pelayan ranap sepenuhnya atau akaun dikunci penjenayah siber baru menyedari bahawa fail sandaran anda rosak.

JagaWeb mereka bentuk, membina, dan menguruskan seni bina Pemulihan Bencana automatik untuk syarikat terkemuka di Malaysia.

  • Semakan Seni Bina, Pemilikan & DR RM5,000: Kami mengaudit kelemahan pelayan semasa, memasang automasi sandaran luar tapak S3 berenkripsi, dan menetapkan Pelan Pemulihan Bencana yang diperakui.
  • Pelan Penjagaan Terurus RM450/bulan: Sandaran harian automatik, pemantauan masa operasi 24/7, penampalan keselamatan, dan jaminan pelaksanaan pemulihan bencana.

Bina Pelan Pemulihan Bencana Laman Web Anda Hari Ini.

WhatsApp