# 🛡️ DOKUMEN KEBIJAKAN STRATEGI BACKUP DATABASE & PEMULIHAN BENCANA (DISASTER RECOVERY PLAN)

> **SISTEM ERP EVEREST**  
> **Standar Acuan:** ISO/IEC 27001:2022 (Klausul A.8.13 - Information Backup) & ISO 22301:2019 (Business Continuity Management System)  
> **Versi Dokumen:** 1.0  
> **Status:** Draft Kebijakan Strategis  

---

## 1. Pendahuluan & Tujuan Dokumen

Dokumen ini menetapkan standar operasional baku mengenai **Strategi Backup Database** dan **Prosedur Pemulihan Bencana (*Disaster Recovery Plan / DRP*)** untuk Sistem ERP Everest.

Tujuan utama kebijakan ini adalah:
1. **Menjamin Kelangsungan Bisnis (*Business Continuity*):** Memastikan sistem ERP dapat dipulihkan secara cepat dan akurat saat terjadi kegagalan perangkat keras, bencana alam, serangan siber (*ransomware*), atau kerusakan data (*data corruption*).
2. **Kepatuhan Audit & ISO:** Memenuhi standar akuntabilitas data ISO 9001 (Klausul 8.5.4 Preservasi Output), ISO 27001 (Keamanan Informasi), dan ISO 22301 (Manajemen Kelangsungan Bisnis).
3. **Pencegahan Kehilangan Data Transaksi:** Menjaga integritas data finansial, persediaan gudang, dan komitmen bisnis agar tidak terjadi *data gap* atau transaksi hilang.

---

## 2. Ruang Lingkup Data Sistem ERP Everest

Sistem Everest menggunakan arsitektur penyimpanan data hibrida (*Hybrid Data Store*). Seluruh elemen data terbagi menjadi 3 kategori kritis yang wajib masuk dalam lingkup backup:

```mermaid
graph TD
    A[Sistem ERP Everest] --> B[1. Relational Database MariaDB/MySQL]
    A --> C[2. NoSQL Database MongoDB]
    A --> D[3. Storage File System Uploads]
    
    B --> B1[Header & Detail Transaksi]
    B --> B2[Jurnal Akuntansi & COA]
    B --> B3[Kartu Stok & Locker State]
    
    C --> C1[Draf Belanja Auto-save]
    C --> C2[Log Audit Dinamis]
    
    D --> D1[Lampiran Bukti Bayar / Nota]
    D --> D2[Scan Kuitansi & Sertifikat]
```

1. **Relational Database (MariaDB / MySQL):**
   * Menyimpan entitas data transaksional utama (`transaksi`, `transaksi_values`, `transaksi_data`, `transaksi_data_values`, `transaksi_sign`, `transaksi_extstep`, `transaksi_data_registry`, `MdlLockerTransaksi`, master data, dan GL Jurnal).
2. **NoSQL Database (MongoDB):**
   * Menyimpan draf belanja sementara pengguna (`saveDraftAjax`) dan riwayat log audit dinamis (`ComTransaksi_log_mongo`).
3. **Storage File System (`uploads/` & Media Assets):**
   * Menyimpan berkas fisik lampiran transaksi (nota pembelian, kuitansi, bukti transfer bank, dan scan sertifikat).

---

## 3. Matriks Target Pemulihan Data (RPO & RTO)

Dalam merancang strategi pemulihan, ditetapkan dua metrik batas toleransi kegagalan:

| Metrik | Definisi | Target Toleransi ERP Everest |
| :--- | :--- | :--- |
| **RPO (*Recovery Point Objective*)** | Batas maksimal waktu kehilangan data yang dapat ditoleransi saat bencana terjadi. | **$\le$ 5 Menit** (Menggunakan *Binary Log Streaming / Oplog Tail*) |
| **RTO (*Recovery Time Objective*)** | Batas maksimal durasi waktu penanganan (*downtime*) untuk memulihkan sistem kembali aktif. | **$\le$ 60 Menit** (Menggunakan *Automated Disaster Recovery Script*) |

---

## 4. Strategi & Jadwal Backup Hibrida

### A. Strategi Backup MariaDB / MySQL (Data Transaksional & Finansial)

```mermaid
sequenceDiagram
    participant DB as MariaDB Primary
    participant Binlog as Binary Logs (Continuous)
    participant Daily as Full Physical Dump (Daily 00:00)
    participant Offsite as Cold Storage / Cloud

    DB->>Binlog: Stream setiap pergerakan data (Real-time / PITR)
    DB->>Daily: Eksekusi mariadb-backup / mysqldump (Setiap Jam 00:00)
    Daily->>Offsite: Replikasi terenkripsi (AES-256) ke Server Offsite
    Binlog->>Offsite: Sync Binary Logs per 5 Menit
```

1. **Full Database Dump (Harian - Jam 00:00 WIB):**
   * Mengeksekusi *Online Physical Backup* menggunakan `mariadb-backup` atau `mysqldump --single-transaction --quick`.
   * Berkas hasil kompresi dienkripsi dengan standar **AES-256**.
2. **Point-in-Time Recovery / PITR (Continuous / Real-Time):**
   * Mengaktifkan fitur `log_bin` pada MariaDB (`binlog_format = ROW`).
   * Berkas *binary log* disinkronisasikan ke server backup terpisah setiap **5 menit** untuk menjamin RPO $\le$ 5 menit.

### B. Strategi Backup MongoDB (Draf & Log Audit)

1. **Dump Harian (Jam 01:00 WIB):**
   * Mengeksekusi `mongodump --gzip --archive=/backup/mongo_$(date +%Y%m%d).gz`.
2. **Oplog Backup (Opsional untuk Replica Set):**
   * Jika menggunakan MongoDB Replica Set, tailing `oplog.rs` dijalankan secara terus-menerus untuk mendukung pemulihan titik waktu (*Point-in-Time*).

### C. Strategi Backup File Uploads (`uploads/`)

1. **Sync Incremental Harian:**
   * Menggunakan `rsync -avz --delete /var/www/everest/uploads/ /backup/uploads/` atau replikasi otomatis ke S3-Compatible Object Storage.

### D. Arsitektur Proteksi Data 3-Tier Enterprise (Gold Standard)

```mermaid
graph TD
    A[Data Transaksi MariaDB] --> B[Tier 1: MariaBackup GFS Physical Baseline]
    A --> C[Tier 2: BINLOG Archiving PITR Per Jam / Real-time]
    A --> D[Tier 3: Replikasi Replication Master-Replica]
    
    B --> B1[Full 1x/Minggu + Inc 1x/Hari 02:00 WIB]
    C --> C1[Merekam Query Detik Demi Detik - RPO 0]
    D --> D1[Automatic Failover RTO 5 Detik]
```

#### 🏛️ Technical Rationale & Evaluasi Frekuensi Incremental:

1. **Mengapa MariaBackup Incremental Tidak Dijalankan Per Jam?**
   * Jika MariaBackup Incremental dijalankan per jam, akan terbentuk 144 berkas incremental dalam 1 minggu. Saat bencana terjadi, pemrosesan 144 file log perantara akan memakan waktu sangat lama (*RTO membengkak*).
   * MariaBackup GFS paling tepat dijalankan **1x Sehari (Pukul 02:00 WIB)** sebagai pondasi data fisik (*Physical Baseline*) agar RTO tetap super cepat (hanya menempelkan 1-6 file incremental harian).

3. **Peran Tier 3: High-Availability (HA) Real-Time Replication & Failover (< 5 Detik RTO):**
   * Untuk mengatasi kondisi di mana Server Primary DB (`192.168.11.100`) Mati Total / Rusak Fisik, Server Secondary DB (`192.168.11.101`) disinkronkan secara *real-time* via **GTID Replication**.
   * Jika Master mati, Virtual IP (VIP) berpindah ke Server Secondary dalam < 5 detik sehingga sistem ERP Everest tetap aktif tanpa perlu menunggu *restore* fisik!

### E. Spesifikasi Arsitektur Tier 3: High-Availability (HA) Real-Time Replication

```mermaid
sequenceDiagram
    participant App as ERP Everest App
    participant Master as Master DB (192.168.11.100)
    participant Replica as Replica DB (192.168.11.101)
    
    App->>Master: Write Transaction
    Master->>Replica: Stream GTID Binlog (Real-time Sync)
    Note over Master,Replica: Synchronous / Semi-Sync State (RPO = 0)
    
    Note over Master: Bencana / Hardware Crash!
    App->>Replica: Automatic Failover via VIP (RTO < 5 Detik)
```

1. **Konfigurasi Master Node (`192.168.11.100`):**
   * `server-id = 100`
   * `gtid_domain_id = 1`
   * `binlog_format = ROW`
2. **Konfigurasi Replica Node (`192.168.11.101`):**
   * `server-id = 101`
   * `gtid_domain_id = 1`
   * `read_only = 1`
3. **Mekanisme Automatic Failover:**
   * Menggunakan Virtual IP / Keepalived / HAProxy. Jika Master gagal menerima *heartbeat*, VIP beralih ke Replica dan `read_only` di-set `0`.

---

## 5. Prosedur Pemulihan Bencana (Disaster Recovery Procedure)

Jika terjadi bencana total (*total system failure*) atau kerusakan database, ikuti alur 4 langkah pemulihan berikut:

```mermaid
graph LR
    S1[1. Isolasi & Deklarasi Bencana] --> S2[2. Provisioning Server Baru / DR Server]
    S2 --> S3[3. Restore Data Hibrida]
    S3 --> S4[4. Verifikasi & Switch traffic]
```

### Langkah 1: Isolasi & Deklarasi Bencana
* Hentikan akses pengguna (*disable web server*) untuk mencegah masuknya transaksi baru yang korup.
* Catat *timestamp* tepat saat insiden terjadi.

### Langkah 2: Restore MariaDB (RDBMS)
1. Restore *Full Dump* terakhir (misal dump jam 00:00 WIB):
   ```bash
   mariadb-backup --prepare --target-dir=/backup/mariadb/full_latest
   mariadb-backup --copy-back --target-dir=/backup/mariadb/full_latest
   ```
2. Replay *Binary Logs* sampai titik waktu 1 menit sebelum bencana terjadi (PITR):
   ```bash
   mysqlbinlog --stop-datetime="2026-07-24 19:00:00" /backup/binlogs/binlog.000* | mysql -u root -p
   ```

### Langkah 3: Restore MongoDB & Berkas Upload
1. Restore MongoDB:
   ```bash
   mongorestore --gzip --archive=/backup/mongo/mongo_latest.gz
   ```
2. Restore Berkas Upload:
   ```bash
   rsync -avz /backup/uploads/ /var/www/everest/uploads/
   ```

### Langkah 4: Verifikasi & Pelepasan Akses
* Jalankan script otomatis pengecekan konsistensi data (cek saldo GL Jurnal vs Kartu Stok `LockerStock`).
* Lepaskan *hold locker* yang menggantung akibat insiden.
* Buka kembali akses web server untuk pengguna.

---

## 6. Pengujian Berkala & Audit Kepatuhan (Drill & Testing)

1. **Uji Coba Pemulihan Berkala (*Disaster Recovery Drill*):**
   * Tim IT wajib melakukan simulasi restore lengkap ke server *Staging/Sandbox* minimal **1 kali setiap 6 bulan**.
2. **Verifikasi Integritas Backup:**
   * Setiap berkas backup yang dihasilkan wajib diverifikasi nilai *hash checksum* (`sha256sum`) untuk memastikan tidak terjadi korupsi file saat transfer.
3. **Penyimpanan Berkas Offsite (3-2-1 Backup Rule):**
   * **3** Salinan data.
   * **2** Media penyimpanan berbeda (Local SSD Server & Local NAS Storage).
   * **1** Salinan di lokasi geografis berbeda (*Cloud / Remote Data Center Offsite*).

---

> **Persetujuan & Pengesahan:**  
> **Dibuat Oleh:** System Architect / Agent  
> **Disetujui Oleh:** Management / Lead Auditor