Backup Nginx Proxy Manager: Tránh Mất Cấu Hình Proxy

Backup và khôi phục Nginx Proxy Manager đúng cách để tránh mất cấu hình proxy

Một ngày đẹp trời, VPS lỗi disk. Container không lên. Domain vẫn trỏ đúng IP nhưng toàn bộ proxy host trong Nginx Proxy Manager biến mất. SSL mất. Access List mất. Custom Nginx config mất. Website nội bộ, dashboard, API, Home Assistant, Git, tất cả cùng “chết” sau một lần docker compose down -v hoặc xóa nhầm thư mục volume.

Vấn đề không nằm ở Nginx Proxy Manager. Vấn đề nằm ở cách backup.

Nginx Proxy Manager, gọi tắt là NPM, rất tiện: giao diện web, quản lý proxy host, SSL Let’s Encrypt, redirect, access list. Nhưng tiện quá dễ khiến ta quên rằng toàn bộ cấu hình sống trong vài thư mục dữ liệu. Mất chúng → dựng lại thủ công từ đầu.

Bài này tập trung vào cách backup/restore NPM đúng: đủ dữ liệu, ít rủi ro, dễ kiểm tra, dễ khôi phục.

NPM lưu dữ liệu ở đâu?

Với Docker Compose phổ biến, NPM thường dùng 2 volume/thư mục chính:

volumes:
  - ./data:/data
  - ./letsencrypt:/etc/letsencrypt

Ý nghĩa:

– /data: database SQLite hoặc cấu hình app, proxy hosts, users, access lists, certificates metadata, logs, custom config. – /etc/letsencrypt: certificate thật, private key, renewal config từ Let’s Encrypt.

Nếu dùng MariaDB/MySQL riêng, dữ liệu proxy không nằm hết trong /data, mà nằm trong DB. Khi đó phải backup thêm DB.

Sai lầm phổ biến:

– Chỉ backup file docker-compose.yml. – Chỉ backup /etc/letsencrypt, quên /data. – Backup khi container đang ghi DB → file SQLite có thể không nhất quán. – Dùng docker compose down -v → xóa volume. – Không test restore → backup “có vẻ” tồn tại nhưng không dùng được.

Nguyên tắc backup đúng

1. Backup cả cấu hình lẫn chứng chỉ

Backup tối thiểu với NPM dùng SQLite:

docker-compose.yml
.env nếu có
data/
letsencrypt/

Nếu dùng DB ngoài:

docker-compose.yml
.env
data/
letsencrypt/
database dump

Không cần backup image Docker. Image kéo lại được. Dữ liệu thì không.

2. Backup nhất quán

SQLite không thích bị copy giữa lúc đang ghi. Cách đơn giản nhất:

docker compose stop
tar -czf npm-backup-$(date +%F).tar.gz docker-compose.yml .env data letsencrypt
docker compose start

Downtime ngắn, đổi lại backup sạch.

Nếu site quan trọng, chạy nhiều proxy production, dùng snapshot filesystem hoặc backup DB bằng công cụ chuẩn. Nhưng đa số homelab/VPS nhỏ: stop → tar → start là đủ.

3. Backup ra ngoài máy chủ

Backup nằm cùng VPS không phải backup. Đó chỉ là bản sao chờ chết cùng ổ cứng.

Nên có ít nhất một bản ngoài máy:

– máy local qua scp – NAS – S3-compatible storage – Backblaze B2 – Google Drive/Rclone – server khác

Quy tắc thực tế: 3-2-1

– 3 bản dữ liệu – 2 loại lưu trữ khác nhau – 1 bản offsite

Không cần cầu kỳ ngay từ đầu. Nhưng tối thiểu: backup nén + kéo về máy cá nhân.

Quy trình backup thủ công an toàn

Giả sử NPM nằm tại:

/opt/nginx-proxy-manager

Chạy:

cd /opt/nginx-proxy-manager

docker compose stop

tar -czf /root/npm-backup-$(date +%F-%H%M).tar.gz 
  docker-compose.yml 
  .env 
  data 
  letsencrypt

docker compose start

Kiểm tra file:

ls -lh /root/npm-backup-*.tar.gz
tar -tzf /root/npm-backup-2026-07-08-1200.tar.gz | head

Copy ra ngoài:

scp /root/npm-backup-2026-07-08-1200.tar.gz user@backup-server:/backups/npm/

Hoặc kéo về máy local:

scp root@your-server:/root/npm-backup-2026-07-08-1200.tar.gz .

Sau đó xóa bớt bản cũ trên VPS nếu disk nhỏ.

Tự động hóa backup bằng script tối giản

Tạo file:

nano /usr/local/bin/backup-npm.sh

Nội dung:

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/nginx-proxy-manager"
BACKUP_DIR="/root/backups/npm"
STAMP="$(date +%F-%H%M)"
FILE="$BACKUP_DIR/npm-$STAMP.tar.gz"

mkdir -p "$BACKUP_DIR"

cd "$APP_DIR"
docker compose stop
tar -czf "$FILE" docker-compose.yml .env data letsencrypt
docker compose start

find "$BACKUP_DIR" -type f -name 'npm-*.tar.gz' -mtime +14 -delete

Phân quyền:

chmod +x /usr/local/bin/backup-npm.sh

Test:

/usr/local/bin/backup-npm.sh

Thêm cron:

crontab -e

Chạy mỗi ngày lúc 02:30:

30 2   * /usr/local/bin/backup-npm.sh >> /var/log/backup-npm.log 2>&1

Lưu ý: script trên chỉ backup local. Nên thêm bước sync ra ngoài bằng scp, rsync, hoặc rclone.

Ví dụ với rsync:

rsync -av --ignore-existing "$BACKUP_DIR/" user@backup-server:/backups/npm/

Nếu NPM dùng MariaDB/MySQL

Một số setup dùng DB riêng:

environment:
  DB_MYSQL_HOST: db
  DB_MYSQL_PORT: 3306
  DB_MYSQL_USER: npm
  DB_MYSQL_PASSWORD: ...
  DB_MYSQL_NAME: npm

Khi đó backup thư mục chưa đủ. Phải dump DB.

Ví dụ container DB tên npm-db-1:

docker exec npm-db-1 mysqldump -u npm -p'npm_password' npm > npm-db.sql

Backup gồm:

docker compose stop
tar -czf npm-backup.tar.gz docker-compose.yml .env data letsencrypt npm-db.sql
docker compose start

Nhưng tốt hơn: dump DB trước, rồi backup toàn bộ:

cd /opt/nginx-proxy-manager

docker exec npm-db-1 mysqldump -u npm -p'npm_password' npm > npm-db.sql

docker compose stop
tar -czf /root/npm-backup-$(date +%F-%H%M).tar.gz 
  docker-compose.yml .env data letsencrypt npm-db.sql
docker compose start

Không commit .env hoặc SQL dump lên Git public. Chúng có thể chứa password, token, private key.

Quy trình khôi phục NPM

Khôi phục nên làm trên máy mới hoặc thư mục sạch.

1. Cài Docker

Ubuntu/Debian:

apt update
apt install -y docker.io docker-compose-plugin
systemctl enable --now docker

2. Copy backup lên server

scp npm-backup-2026-07-08-1200.tar.gz root@new-server:/opt/

3. Giải nén

mkdir -p /opt/nginx-proxy-manager
cd /opt/nginx-proxy-manager
tar -xzf /opt/npm-backup-2026-07-08-1200.tar.gz

Kiểm tra:

ls -la

Phải thấy:

docker-compose.yml
data/
letsencrypt/
.env

4. Start container

docker compose up -d

Xem log:

docker compose logs -f

Mở giao diện NPM. Proxy hosts, certificates, access lists phải xuất hiện lại.

5. Kiểm tra DNS và firewall

Nếu khôi phục sang VPS khác, IP đổi. Cần sửa DNS A/AAAA record về IP mới.

Kiểm tra port:

– 80/tcp – 443/tcp – 81/tcp nếu dùng admin UI mặc định

Với UFW:

ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 81/tcp

Port admin 81 không nên mở public lâu dài. Tốt hơn: giới hạn IP, VPN, hoặc đặt sau Access List.

Các lỗi restore thường gặp

Sai đường dẫn volume

Compose cũ dùng:

- ./data:/data

Nhưng restore vào thư mục khác, chạy ở sai working directory → NPM tạo data mới rỗng.

Fix: luôn cd đúng thư mục chứa docker-compose.yml trước khi chạy:

cd /opt/nginx-proxy-manager
docker compose up -d

Mất certificate sau restore

Nguyên nhân: quên backup letsencrypt/.

Fix: restore lại từ bản có /etc/letsencrypt. Nếu không có, cấp lại cert trong NPM. Có thể bị rate limit Let’s Encrypt nếu làm nhiều lần.

Database lỗi quyền file

Container không đọc được file sau khi copy.

Fix thường dùng:

chown -R 1000:1000 data letsencrypt

Tùy image/version, UID có thể khác. Xem log trước, đừng chmod 777 bừa.

Admin UI lên nhưng proxy không hoạt động

Kiểm tra:

docker compose ps
docker compose logs
ss -tulpn | grep -E ':80|:443|:81'

Nguyên nhân hay gặp:

– port 80/443 bị service khác chiếm – firewall chặn – DNS chưa trỏ IP mới – upstream container/app backend chưa chạy – Docker network khác tên sau restore

Bảo mật backup

Backup NPM rất nhạy cảm. Nó chứa:

– SSL private keys – domain list – email Let’s Encrypt – access list – có thể chứa basic auth – config nội bộ

Do đó:

– Không upload lên nơi public. – Không gửi qua chat/email không mã hóa. – Nên mã hóa trước khi đưa lên cloud. – Giới hạn quyền đọc backup.

Mã hóa bằng gpg:

gpg -c npm-backup-2026-07-08-1200.tar.gz

Khôi phục:

gpg -d npm-backup-2026-07-08-1200.tar.gz.gpg > npm-backup-2026-07-08-1200.tar.gz

Nhớ lưu passphrase ở password manager. Mất passphrase → backup vô dụng.

Test restore: phần nhiều người bỏ qua

Backup chưa test không đáng tin.

Cách test nhẹ:

1. Tạo VM nhỏ/local server. 2. Copy backup sang. 3. Giải nén. 4. docker compose up -d. 5. Kiểm tra UI NPM có đủ proxy host. 6. Không cần đổi DNS thật; có thể sửa file hosts local để test domain.

Ví dụ trên máy test:

1.2.3.4 app.example.com

Trong đó 1.2.3.4 là IP máy test.

Nên test restore sau lần setup đầu tiên, sau mỗi thay đổi lớn, hoặc ít nhất mỗi vài tháng.

Checklist backup NPM thực tế

Dùng checklist này:

– [ ] Có backup docker-compose.yml – [ ] Có backup .env – [ ] Có backup data/ – [ ] Có backup letsencrypt/ – [ ] Nếu dùng MariaDB/MySQL: có dump DB – [ ] Backup chạy tự động – [ ] Backup được copy offsite – [ ] Backup cũ được rotate – [ ] Backup được mã hóa nếu đưa lên cloud – [ ] Đã test restore ít nhất một lần

Thiếu một mục không luôn gây thảm họa. Nhưng thiếu nhiều mục → restore rất dễ thành dựng lại từ đầu.

Kết luận

Nginx Proxy Manager dễ dùng, nhưng không tự bảo vệ bạn khỏi mất dữ liệu. Muốn tránh mất cấu hình proxy, hãy backup đúng thứ: data/, letsencrypt/, compose file, env file, và database nếu có.

Cách đơn giản, an toàn cho đa số trường hợp: dừng container ngắn, nén toàn bộ thư mục cấu hình, copy ra nơi khác, giữ vài bản gần nhất, thỉnh thoảng test restore.

Backup tốt không phải backup phức tạp. Backup tốt là backup khôi phục được.