System Optimization, Backup và Restore cho Docker LCMP Multisite WordPress Minimal

Mới qua dùng docker, cũng không quá quen cách vận hành của nó, tiện vừa thử backup và restore các trang tạo ra bằng Docker LCMP Multisite WordPress Minimal nên viết 1 bài từ cấu hình server tới các bước tạo backup và restore

Mình sẽ tách nhỏ thành 3 phần là System Optimization, Backup và Restore

System Optimization

sudo wget https://raw.githubusercontent.com/bibicadotnet/Docker-LCMP-Multisite-WordPress-Minimal/main/system_optimization.sh -O system_optimization.sh && sudo chmod +x system_optimization.sh && sudo ./system_optimization.sh

Docker LCMP Multisite WordPress Minimal trừ Alpine chưa hoàn thiện code, cơ bản các OS thông dụng đều có thể dùng, cá nhân dạo này thích Debian 11, vì chúng dùng ít RAM, lại thông dụng, phần code tự setup này viết trên nền tảng đó 😀 ai dùng Debian và Ubuntu có thể dùng

Các bước bao gồm

• Cập nhập hostname (vài nhà cung cấp VPS mình dùng như UpCloud, đôi lúc cài vào nó hostname nó không tự đưa vào file hosts, đôi lúc chạy nó cứ hiện cảnh báo)
• Update và nâng cấp hệ thống, sử dụng ở chế độ DEBIAN_FRONTEND=noninteractive để không cần trả lời yes/no gì cả
• Tắt firewall nếu đã cài đặt (vì mặc định Oracle Ubuntu 22.04 chặn hết các ports)
• Tắt IPv6 vì mình không thấy bất cứ lợi ích nào
• Cài đặt múi giờ Việt Nam
• DNS Server dùng DNS của Cloudflare, Google, thông dụng, nhanh, an toàn
• Bật TCP BBR
• Tạo swapfile và tùy chỉnh Sysctl dựa theo dung lượng RAM của VPS
• Cài đặt các ứng dụng cơ bản curl wget git htop unzip nano zip zstd
• Cài đặt Docker và tối ưu hóa hiệu suất Docker

Swapfile thường ở các VPS ít RAM khá hiệu quả, còn trên các VPS nhiều RAM thì gần như không có tác dụng, mình giới hạn tối đa dùng 4GB thôi

RAM < 1GB: Tạo swapfile 1 Gb
RAM ≤ 1GB: Tạo swapfile 1 Gb
RAM ≤ 2GB: Tạo swapfile 1 Gb
RAM ≤ 4GB: Tạo swapfile 2 Gb
RAM ≤ 8GB: Tạo swapfile 4 Gb
RAM ≤ 24GB: Tạo swapfile 4 Gb

Sysctl tùy chỉnh các giá trị bên dưới, đa phần sẽ khá giống mặc định, trừ VPS cấu hình cho RAM < 1GB khác nhiều, cơ bản vẫn duy trì lưu mọi thứ vào RAM nhiều nhất có thể, nhưng tăng thời gian ghi ra đĩa nhiều hơn để lấy thêm RAM trống cho các dịch vụ quan trọng PHP, Mariadb, Caddy, lý thuyết dùng cấu hình này, bạn sẽ thấy lượng RAM còn thừa thường sẽ nhiều hơn 1 chút so với mặc định

vm.swappiness=10"
vm.dirty_ratio=5"
vm.dirty_background_ratio=2"
vm.dirty_expire_centisecs=1000"
vm.dirty_writeback_centisecs=200"
vm.vfs_cache_pressure=200"
fs.file-max=30000"

Cài đặt Docker mình vẫn dùng bộ công cụ trực tiếp từ hãng, để luôn tự cài đặt bản mới nhất, tùy chỉnh râu ria thêm thì giới hạn ghi log vừa phải, tăng thêm các kết nối khi download images về, dùng DNS của Cloudflare, Google

{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "max-concurrent-downloads": 10,
  "max-concurrent-uploads": 10,
  "dns": ["8.8.8.8", "1.1.1.1"]
}

Vài thứ như swapfile thời hay dùng VPS 1 GB mình cài theo thói quen, không hẳn là có nhiều tác dụng, nhưng tối thiểu thì cũng không sai 😀

Bạn có thể bỏ qua công đoạn System Optimization này, dùng như mặc định khi cài đặt OS ban đầu vào cũng thừa tốt và ổn định, các tinh chỉnh râu ria thêm vào thường tăng hiệu năng không đáng kể

Mình do thường xuyên chuyển đổi qua lại nhiều cấu hình 1-8-24GB RAM, nên tranh thủ lần này làm phần auto cấu hình luôn, sau cứ thế chạy là được

Backup

https://github.com/bibicadotnet/Docker-LCMP-Multisite-WordPress-Minimal/blob/main/backup.sh#L27

Bản backup ban đầu mình cũng viết script để tùy chỉnh, nhưng càng thêm nhiều tính năng vào thấy nó càng loạn, càng phải xử lý các lỗi và các trường hợp khác nhau, nên thôi, quay lại copy, paste thủ công cho khỏe

Do mọi trang đều nằm cùng 1 thư mục, muốn backup toàn bộ các cấu hình, data, database, cấu hình php, mariadb, domain … chỉ cần download thư mục gốc là đủ (như của mình là thư mục /home)

Mình chuyển các file .sh liên quan tới backup, retore, monitor … này nọ vào 1 thư mục bên trong luôn để khi backup cho tiện

Tiếp theo là file crontab để chạy 1 số yêu cầu theo giờ, … vị trí file crontab thường nằm ở /var/spool/cron/crontabs/root

# Tạo backup mỗi ngày trên VPS
mkdir -p /var/backups/lcmp
rm -f /var/backups/lcmp/backup_$(/bin/date +%d.%m.%Y).tar.zst
tar -cpf - /home /var/spool/cron/crontabs/root | zstd -1 -o /var/backups/lcmp/backup_$(/bin/date +%d.%m.%Y).tar.zst

Bản backup này mình dùng thuật toán và thư viện nén được phát triển bởi Facebook là Zstandard (zstd), khá nhanh và tỷ lệ nén tốt, cụ thể thì toàn bộ data của thèng bibica.net, dùng tar thông thường không nén thì còn 1.6GB, dùng zstd ở chế độ nhanh nhất mất tầm 4s để tạo ra 1 file khoảng 1GB, hài lòng về tốc độ và tỷ lệ nén của zstd

Chú ý dùng cấu trúc chính xác là -cpf, có thêm -p vào nó giữ lại các thuộc tính của các file, kiểu thư mục, file nào của www-data là giữ lại, sau khi restore đỡ phải chmod lại ….

Sau khi tạo backup ở localhost là chuyển sang các dịch vụ cloud như Google, Microsoft, Amazon, Cloudflare …. dùng Rclone là được, trừ lần đầu lấy thông số cấu hình hơi lâu, còn có rồi thì cứ thế dùng, các công nghệ, cơ chế liên quan tới tốc độ, bảo mật, độ ổn định của họ rất cao, rất đáng dùng

# Chuyển backup mỗi ngày vào Google Drive
rclone copy /var/backups/lcmp/backup_$(/bin/date +%d.%m.%Y).tar.zst google-drive:bibica-net/_docker_full_backup_daily --progress
rclone delete google-drive:bibica-net/_docker_full_backup_daily --min-age 10d --progress

# Tạo thêm 1 bản backup mới nhất vào _docker_direct_link_setup
rclone copy google-drive:bibica-net/_docker_full_backup_daily/backup_$(/bin/date +%d.%m.%Y).tar.zst google-drive:bibica-net/_docker_direct_link_setup --progress
rclone moveto google-drive:bibica-net/_docker_direct_link_setup/backup_$(/bin/date +%d.%m.%Y).tar.zst google-drive:bibica-net/_docker_direct_link_setup/backup.tar.zst --progress

Mình thích tạo 1 ngày 1 bản backup, đặt tên file theo định dạng ngày tháng của Việt Nam, ví dụ backup_16.08.2024.tar.zst, nói dễ hiểu là trong 1 ngày, bất kể bạn backup bao nhiêu lần, nó đều tạo thành 1 tên file theo ngày đó -> chỉ có 1 bản backup cho 1 ngày, có thể backup lúc 1h sáng hàng ngày

Dòng tiếp theo delete --min-age 10d, là xóa các file nếu chúng đã tồn tại ít nhất 10 ngày, theo cách backup như trên, hiểu đơn giản là giữ 10 bản backup cho 10 ngày gần nhất, các ngày cũ hơn sẽ xóa đi

Tiếp theo là chuyển file backup mới nhất sang 1 thư mục riêng, đổi tên thành backup.tar.zst, lý do cho việc này là …. lười thôi, mặc định file backup.tar.zst luôn là file mới nhất, tên nó không đổi, nên khi đổi VPS, cần restore chỉ việc download 1 link cố định google-drive:bibica-net/_docker_direct_link_setup/backup.tar.zst là xong, đỡ phải xem file nào ngày nào, bạn nào không quan trọng vấn đề này có thể bỏ 3 dòng cuối ở trên, tạo backup 1 bản theo ngày là đủ

Backup theo mình tối thiểu nên để ở 2 dịch vụ, phòng khi 1 nơi có vấn đề thì còn 1 nơi sơ cua, nó chạy auto cả nên cứ thêm vào cho an tâm

Xong xuôi thì xóa các file tại VPS đi cho sạch sẽ, tùy chỉnh lưu bao nhiêu bản, sang bao nhiêu dịch vụ thì tùy nhu cầu mọi người, dùng RClone thì cấu trúc nó như nhau, copy các dòng ở trên xuống đổi sang tên dịch vụ khác là được

Restore

https://github.com/bibicadotnet/Docker-LCMP-Multisite-WordPress-Minimal/blob/main/restore.sh#L228

Restore thì có thể nói là tổng hợp của phần System Optimization, bổ xung bước thêm download giải nén file backup cũ về

# Cài đặt rclone
curl https://rclone.org/install.sh | bash
rclone version
wget --no-check-certificate https://xxxxxxxxxxxxxxxx/rclone.conf -O /root/.config/rclone/rclone.conf

# Download về bản backup mới nhất từ Google Drive hoặc Cloudflare R2
mkdir -p /var/backups/lcmp
rclone copyto google-drive:bibica-net/_docker_direct_link_setup/backup.tar.zst /var/backups/lcmp/backup.tar.zst --progress

# Tạo thư mục tạm thời để giải nén bản sao lưu.
mkdir -p /var/backups/lcmp/tmp
# Giải nén dữ liệu
zstd -d /var/backups/lcmp/backup.tar.zst --stdout | tar -xvf - -C /var/backups/lcmp/tmp
# Khôi phục dữ liệu về vị trí cũ
cp -a /var/backups/lcmp/tmp/home/ /
cp -a /var/backups/lcmp/tmp/var/spool/cron/crontabs/root /var/spool/cron/crontabs/
# Xóa tất cả file backup và file rác cho sạch sẽ VPS mới  
rm -rf /var/backups/lcmp

Công đoạn khôi phục dữ liệu khá nhàn, cài đặt Rclone, vứt cái file cấu hình cũ vào, rồi kéo trực tiếp bản backup mới nhất về, xả nén, chép lại các vị trí cũ

Tiếp theo là công đoạn khởi động lại toàn bộ các container

# Khởi động Caddy trong thư mục /home/reverse_proxy/ trước tiên
if [ -f /home/reverse_proxy/compose.yml ]; then
    docker compose -f /home/reverse_proxy/compose.yml up -d
fi

# Sau đó khởi động lại toàn bộ các compose.yml khác trong thư mục /home
BASE_DIR="/home"
# Lưu thư mục gốc
ORIG_DIR="$(pwd)"

# Tìm tất cả các file compose.yml trong thư mục chính và các thư mục con
for dir in $(find "$BASE_DIR" -name compose.yml -exec dirname {} ;); do
    echo "Khởi động lại các container trong thư mục: $dir"
    cd "$dir" || exit
    docker compose up -d
    # Quay lại thư mục gốc
    cd "$ORIG_DIR" || exit
done

# Chạy lại lcmp.sh lần đầu sau đó thoát ra để tự tạo phím tắt
echo "0" | /home/lcmp.sh

Chú ý duy nhất là cần chạy thèng reverse_proxy trước, vì nó chứa mạng reverse_proxy cho toàn bộ các trang, ít trang có thể làm thủ công, kiểu cd tới thư mục cụ thể, rồi docker compose up -d

Mình có vài trang thôi, có điều luôn giả sử kiểu có 100 trang thì sao, vào bật lại chắc què tay, nên thôi để code nó chạy từng thư mục, đọc thấy file compose.yml thì chạy docker compose up -d

Tổng thời gian làm tất cả mọi chuyện, từ cập nhập hệ thống, cho tới kéo backup cũ về, giải nén, chạy lại, thường không quá 5 phút cho dữ liệu khoảng 1-2GB

Tiếp theo nếu rỗi rãi có thể bảo mật căn bản 1 chút cho VPS sau khi restore lại, firewall nó chỉ hơi phiền nếu bạn không rõ hệ thống đang dùng port nào thì dễ chặn nhầm, còn ai hiểu hệ thống, quản lý firewall tốt thì rất hiệu quả

Nếu cài đặt Docker LCMP Multisite WordPress Minimal chạy WordPress thì chỉ cần mở port mặc định là 80 và 443, thêm 1 port cho SSH nữa là đủ

Công đoạn backup, restore mình rười viết, vì nói thật là chính mình cũng chẳng bao giờ ngồi đọc, chi chít các thứ nhìn nhức đầu, thường mình khoán hết cho Telegram, thấy có tin nhắn báo hàng ngày nghĩa là biết công đoạn backup vẫn đang ổn định, còn hôm nào không thấy tin nhắn mới vào xem coi lỗi do cái gì 😀

Kiểm tra kết quả

Sau khi chạy thử 1 ngày, mọi thứ hoạt động khá ổn định

Cloudflare R2 duy trì 2 bản, Google Driver duy trì 10 bản gần nhất, RClone chạy ổn định

Thời gian tạo backup trên VPS khá nhanh, tầm 5s, thời gian upload sang Cloudflare R2 và Google Driver hơi lâu, trung bình hoàn thành xong mất gần 5 phút, vấn đề này thì đành chịu, vì lệ thuộc vào tốc độ VPS tới 2 dịch vụ này

Kết luận

Trong 3 phần mình nghĩ phần System Optimization có thể sử dụng đa năng nhất, chạy là xong, rất tiện vì bổ xung sẵn cấu hình theo RAM, 2 phần backup và restore phải sửa lại đường dẫn các thư mục cần backup, số lượng lưu trữ … ông nào dùng tới tầm docker thì kinh nghiệm đầy mình rồi, chẳng rỗi hơi backup thủ công kiểu này

Các công đoạn backup, restore mình hài lòng với hiệu quả đạt được, đa phần mất vài phút là xong, sau khi tùy chỉnh lần đầu gần như chẳng bao giờ phải nhìn lại cái này, muốn restore thì upload file restore lên VPS, chạy là tự động hết mọi công đoạn