BACKUP & RESTORE NGINX DI PRODUCTION Panduan Teknis Mendalam

Dokumen ini ditujukan untuk environment production kritikal, di mana NGINX berperan sebagai:

• reverse proxy utama
• load balancer
• TLS termination
• API gateway
• entry point microservices

Kegagalan NGINX = seluruh sistem tidak dapat diakses, sehingga backup & restore bukan opsional, melainkan bagian dari business continuity plan.

---

1. Filosofi Backup NGINX (Bukan Sekadar Copy File)

1.1 Kesalahan Pola Pikir Umum

Banyak engineer berpikir:

“NGINX tinggal install ulang, konfigurasi gampang”

Ini salah besar di production karena:

• Konfigurasi berkembang bertahun-tahun
• Banyak edge-case tersembunyi
• Rewrite & proxy rule saling bergantung
• SSL chain sering custom
• Human memory tidak bisa diandalkan saat incident

Backup NGINX bertujuan untuk:

• menghilangkan ketergantungan pada ingatan manusia
• memastikan recovery deterministik, bukan trial-error

---

2. Apa yang SEBENARNYA Perlu Dibackup (dan Alasannya)

2.1 Konfigurasi NGINX — Bukan Sekadar nginx.conf

Banyak kegagalan restore terjadi karena backup konfigurasi tidak utuh.

Struktur konfigurasi NGINX nyata di production:

/etc/nginx/
├── nginx.conf
├── conf.d/
│   ├── upstream.conf
│   ├── rate-limit.conf
│   └── security.conf
├── sites-available/
│   ├── app.conf
│   ├── api.conf
│   └── admin.conf
├── sites-enabled/
│   ├── app.conf -> ../sites-available/app.conf
│   └── api.conf -> ../sites-available/api.conf
├── snippets/
│   ├── ssl.conf
│   └── proxy.conf
└── modules-enabled/

❗ Masalah umum saat restore

• symlink hilang
• file snippet tidak ikut
• permission berubah
• modul tidak tersedia

➡️ Best practice
Backup SELURUH /etc/nginx, bukan file terpilih.

---

2.2 SSL / TLS — Area Paling Berbahaya

SSL adalah komponen paling sensitif.

Yang harus dibackup:

• private key
• certificate
• chain
• renewal config (Let’s Encrypt)

Lokasi nyata:

/etc/letsencrypt/
├── live/
├── archive/
├── renewal/
└── accounts/

❗ Kenapa backup Let’s Encrypt sering gagal?

• orang hanya backup /live
• padahal renewal butuh /archive dan /renewal

➡️ Jika hanya backup /live, HTTPS mungkin jalan, tapi renewal gagal.

---

2.3 File Website — Jangan Asumsikan Stateless

Walaupun aplikasi modern sering stateless, NGINX hampir selalu melayani file stateful, misalnya:

• upload user
• cache image
• static build frontend
• verification file (ACME challenge)

Jika ini hilang:

• website bisa error meskipun NGINX running

---

2.4 File Pendukung yang Sering Dilupakan

Ini yang paling sering menyebabkan “kok beda sama sebelumnya?”:

• .htpasswd
• custom error page
• GeoIP database
• Lua script (OpenResty)
• IP whitelist file
• cron job yang reload NGINX

➡️ Inventarisasi manual sangat penting.

---

3. Strategi Backup yang BENAR untuk Production

3.1 Kenapa Full Backup Lebih Aman untuk NGINX

Konfigurasi NGINX:

• kecil ukurannya
• kompleks relasinya
• berubah tidak terlalu sering

➡️ Incremental backup hampir tidak memberi manfaat, tapi menambah kompleksitas restore.

Kesimpulan:

Konfigurasi NGINX = SELALU full backup

---

3.2 Retention Policy Bukan Formalitas

Tanpa retention:

• disk penuh
• backup gagal
• tidak ada alert
• restore terakhir ternyata korup

Contoh kebijakan realistis:

• harian: rollback cepat
• mingguan: rollback konfigurasi lama
• bulanan: audit & compliance

---

3.3 Offsite Backup = Syarat Mutlak

Jika backup berada di server yang sama:

• disk corrupt → backup ikut rusak
• ransomware → backup ikut terenkripsi
• VM hilang → backup ikut hilang

➡️ Backup lokal tanpa offsite = bukan backup

---

4. Script Backup Production-Grade (Bukan Contoh Main-main)

#!/bin/bash
set -euo pipefail

DATE=$(date +%F)
HOST=$(hostname -f)
BASE_DIR="/backup/nginx"
WORK_DIR="$BASE_DIR/$HOST"
FILE="$WORK_DIR/nginx-$DATE.tar.gz"

mkdir -p "$WORK_DIR"

tar \
  --numeric-owner \
  --xattrs \
  -czf "$FILE" \
  /etc/nginx \
  /etc/ssl \
  /etc/letsencrypt \
  /var/www

chmod 600 "$FILE"

Kenapa flags ini penting?

• numeric-owner → user/group konsisten
• xattrs → extended attributes tidak hilang
• set -euo pipefail → script gagal jika ada error sekecil apa pun

---

5. RESTORE: BAGIAN PALING KRITIKAL (DAN PALING SERING GAGAL)

Backup tidak berguna tanpa restore yang benar.

---

6. Restore Parsial (Kasus Paling Umum)

Kasus Nyata:

• Engineer edit config
• reload gagal
• traffic mati

Langkah Aman:

systemctl stop nginx
mv /etc/nginx /etc/nginx.failed.$(date +%s)
tar -xzvf nginx-backup.tar.gz etc/nginx
nginx -t
systemctl start nginx

Kenapa mv bukan rm?

• untuk forensik
• rollback manual jika backup bermasalah

---

7. Restore SSL (Kasus Paling Berisiko)

SSL restore tidak boleh asal extract.

tar -xzvf nginx-backup.tar.gz etc/letsencrypt
chmod -R go-rwx /etc/letsencrypt
systemctl reload nginx

❗ Jika permission salah:

• NGINX gagal start
• atau lebih buruk: key bisa dibaca user lain

---

8. Restore Full (Server Masih Hidup)

Ini skenario rollback total.

systemctl stop nginx

mkdir /root/pre-restore
mv /etc/nginx /root/pre-restore/
mv /etc/letsencrypt /root/pre-restore/
mv /var/www /root/pre-restore/

tar -xzvf nginx-backup.tar.gz -C /
nginx -t
systemctl start nginx

---

9. Restore Total (Server Mati Total)

Ini yang membedakan engineer junior vs senior

Langkah nyata di incident:

1. Provision VM
2. Install OS minimal
3. Install NGINX versi kompatibel
4. Restore backup
5. Verifikasi
6. Cut traffic

Target realistis:

• 15–30 menit

Tanpa backup:

• bisa berjam-jam
• atau berhari-hari

---

10. Testing Restore (Wajib, Bukan Opsional)

Checklist minimal:

• nginx -t
• HTTPS handshake sukses
• proxy upstream hidup
• static file ter-load

Lakukan sebelum incident, bukan saat panic.

---

11. Kesalahan Fatal yang Sering Terjadi

❌ Backup config tapi lupa SSL
❌ Backup SSL tapi lupa renewal config
❌ Backup sukses tapi restore tidak pernah diuji
❌ Restore overwrite tanpa backup kondisi lama
❌ Backup tanpa enkripsi

---

12. Kesimpulan Akhir (Realita Production)

Backup bukan tentang menyimpan data
Restore adalah tentang menyelamatkan layanan

Engineer yang matang:

• tidak berharap server tidak pernah gagal
• bersiap untuk kegagalan