🔄 完整重置 Fail2ban(快速清空封鎖與規則)

當出現大量誤封、測試結束、或規則混亂時,
可以將 Fail2ban 重置回乾淨狀態。

以下是最直接的完整重置方法。


⚠️ 注意

此操作會:

  • 清空所有被封鎖 IP
  • 刪除封鎖歷史資料
  • 清空所有 f2b-* 防火牆規則
  • 重新建立 jail 規則

請確保你仍有伺服器存取權限。


✅ 重置步驟

1️⃣ 停止 Fail2ban

systemctl stop fail2ban

2️⃣ 刪除封鎖資料庫(關鍵)

rm -f /var/lib/fail2ban/fail2ban.sqlite3

這一步會清除所有封鎖歷史與 recidive 記錄。


3️⃣ 清空防火牆規則

iptables -F
iptables -X

清除所有自訂 chain(包括 f2b-*)。


4️⃣ 重新啟動 Fail2ban

systemctl start fail2ban

系統會:

  • 自動建立新的資料庫
  • 重新載入 jail
  • 重建 f2b-* chain

✅ 可選:清空 fail2ban log(僅為閱讀乾淨)

truncate -s 0 /var/log/fail2ban.log

注意:
這不影響封鎖狀態,只是清空顯示紀錄。


✅ 完整指令總結

systemctl stop fail2ban
rm -f /var/lib/fail2ban/fail2ban.sqlite3
iptables -F
iptables -X
systemctl start fail2ban

✅ 結語

當規則混亂或測試過程造成大量封鎖時,
回到乾淨狀態,往往比逐條排錯更有效率。

清楚、可控、可驗證,
才是穩定運行的基礎。

🔐 如何檢查及解除 Fail2ban 封鎖的 IP(實戰步驟)

在管理伺服器時,偶爾會遇到某個 IP 被 Fail2ban 封鎖的情況。
這篇文章介紹如何:

  • ✅ 查出是否被封
  • ✅ 找出是哪個 jail 封鎖
  • ✅ 正確解除封鎖
  • ✅ 驗證是否完全清除

以下示例 IP 使用:

X.X.X.X

請替換為實際需要查詢的 IP。


✅ 第一步:查看 Fail2ban log

先從日誌確認是否曾被封鎖:

grep X.X.X.X /var/log/fail2ban.log

如果看到類似:

[sshd] Ban X.X.X.X

代表該 IP 曾被某個 jail 封鎖。


✅ 第二步:確認目前是否仍被封鎖

使用 fail2ban 內建查詢指令:

fail2ban-client banned X.X.X.X

如果該 IP 仍在封鎖名單中,會顯示對應 jail 名稱。

如果沒有任何輸出,代表目前沒有被 Fail2ban 封鎖。


✅ 第三步:解除封鎖(Unban)

若確認需要解除封鎖:

fail2ban-client unban X.X.X.X

這條指令會:

  • 從所有 jail 中移除該 IP
  • 同時更新防火牆規則

✅ 第四步:確認 firewall 是否已清除

Fail2ban 會透過 iptables 或 nftables 進行封鎖。

如果系統使用 iptables,可檢查:

iptables -L -n | grep X.X.X.X

若沒有任何輸出,表示防火牆規則已移除。


✅ 建議完整排查流程

grep X.X.X.X /var/log/fail2ban.log
fail2ban-client banned X.X.X.X
fail2ban-client unban X.X.X.X
fail2ban-client banned X.X.X.X
iptables -L -n | grep X.X.X.X

✅ 補充說明

  • Fail2ban 只負責管理封鎖名單
  • 真正丟棄封包的是防火牆規則
  • 若 unban 後仍無法連線,應檢查是否有其他防火牆或 CDN 層封鎖

✅ 結語

正確的排查順序應為:

  1. 查 log
  2. 查 jail 狀態
  3. 執行 unban
  4. 驗證防火牆

避免直接重啟服務或修改設定,
精準排錯才是穩定運行的關鍵。

WordPress 檔案權限標準設定整理

以下是 WordPress 建議的標準檔案權限設定方式,適合大多數主機環境使用。


一、整個網站權限

# 設定資料夾
find /你的wordpress路徑/ -type d -exec chmod 755 {} \;

# 設定檔案
find /你的wordpress路徑/ -type f -exec chmod 644 {} \;

二、uploads 資料夾

find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

三、wp-config.php

chmod 600 wp-config.php

或:

chmod 640 wp-config.php

四、檔案擁有者

確認網站檔案擁有者正確,例如:

chown -R www-data:www-data /你的wordpress路徑/

(依主機環境調整使用者名稱)


五、建議安全設定

wp-content/uploads 新增 .htaccess

<Files *.php>
deny from all
</Files>

以上為 WordPress 常見且建議的標準權限設定方式。

使用 Cloudflare WAF 保護 WordPress:阻止 wp-login 攻擊與封鎖 XMLRPC(完整教學)

當你的 WordPress 網站開啟 Cloudflare 橙色雲(Proxy)後,其實 HTTP 攻擊應該在 Cloudflare Edge 層解決,而不是在伺服器層解決

很多人仍然使用 Fail2ban 嘗試封鎖 wp-login 攻擊,但在橙雲模式下:

  • 真正連線來源是 Cloudflare IP
  • iptables 無法阻擋真實攻擊者
  • 即使封鎖 IP 仍然會有流量進來

✅ 正確做法是使用 Cloudflare WAF Custom Rules。

本教學會示範兩條最重要的規則:

  1. 保護 wp-login.php
  2. 封鎖 xmlrpc.php

✅ 第一條規則:保護 wp-login.php

為什麼需要?

WordPress 的登入頁面:

/wp-login.php

是全球機器人暴力破解的主要目標。

即使你沒有公開登入頁,掃描機器仍然會嘗試。


🔧 建立規則步驟

Step 1:進入 Cloudflare

  1. 登入 Cloudflare
  2. 選擇你的網站
  3. 點擊:
Security → WAF → Custom Rules
  1. 點擊:
Create rule

Step 2:設定 Rule Name

請填寫:

WP-Login Protection

Step 3:點擊「Edit expression」

不要使用上方 Select 下拉選單。

請點擊右側:

Edit expression

Step 4:貼上以下 Expression

(http.request.uri.path contains "/wp-login.php")

如果你希望自己的固定 IP 不被影響,可以使用:

(http.request.uri.path contains "/wp-login.php")
and not ip.src in {你的IP地址}

例如:

(http.request.uri.path contains "/wp-login.php")
and not ip.src in {1.2.3.4}

Step 5:選擇 Action

在「Then take action」中選擇:

Managed Challenge

不要使用 Block,除非你 100% 不需要外部登入。


Step 6:點擊 Deploy

完成 ✅


✅ 效果說明

設定後:

  • 大部分 bot 會被 Challenge 阻擋
  • 真人用戶幾乎無感
  • 攻擊流量不再直接打到伺服器
  • CPU 使用率會下降

✅ 第二條規則:封鎖 XMLRPC


為什麼需要?

WordPress 的:

/xmlrpc.php

經常被利用作:

  • 暴力破解
  • Pingback 攻擊
  • DDoS 放大攻擊

如果你沒有使用:

  • Jetpack
  • WordPress App
  • 遠端發佈功能

✅ 建議直接封鎖。


🔧 建立規則步驟

Step 1:Create rule

同樣進入:

Security → WAF → Custom Rules

點擊:

Create rule

Step 2:Rule Name

填寫:

Block XMLRPC

Step 3:Edit expression

貼上:

(http.request.uri.path contains "/xmlrpc.php")

Step 4:Action

選擇:

Block


Step 5:Deploy

完成 ✅


✅ 建議規則順序

在 Custom Rules 頁面,請確保順序如下:

  1. Block XMLRPC
  2. WP-Login Protection

Cloudflare 會由上而下執行規則。


✅ 設定完成後的架構

啟用後流量流程變成:

攻擊者 → Cloudflare WAF → 被挑戰/封鎖 → 無法到達伺服器

而不是:

攻擊者 → 伺服器 → Fail2ban 分析 → 再封鎖

✅ 安全性更高
✅ 伺服器負載更低
✅ 不再需要 Fail2ban API 同步


✅ 常見問題

Q1:會不會影響 Google?

不會。

Cloudflare 會識別合法 bot,Managed Challenge 不會影響正常搜尋引擎。


Q2:是否還需要 Fail2ban?

建議:

  • 保留 Fail2ban 用於 SSH
  • 保護未使用 Cloudflare 的網站
  • 保護 API 服務

但對 HTTP WordPress 攻擊,可以完全交給 Cloudflare。


✅ 總結

只需兩條規則,你就可以:

  • 阻止 90% WordPress 掃描攻擊
  • 減少伺服器負載
  • 不再依賴 API 封鎖
  • 架構更清晰

Cloudflare WAF 應該成為橙雲網站的第一層防線,而不是伺服器。

WordPress 手動安裝教學(Linux 主機)

以下示範如何在 Linux 主機上手動下載並安裝 WordPress。

✅ 前置需求

  • 已安裝 Apache / Nginx
  • 已安裝 PHP
  • 已安裝 MySQL 或 MariaDB
  • 已建立資料庫與資料庫帳號

📥 步驟一:下載 WordPress

cd /tmp
wget https://wordpress.org/latest.tar.gz

說明:
進入 /tmp 目錄並下載最新版 WordPress 壓縮檔。


📦 步驟二:解壓縮檔案

tar -vxf latest.tar.gz

解壓縮後會產生 wordpress 目錄。


📂 步驟三:複製檔案到網站目錄

rsync -av wordpress/ /var/www/html/

說明:
將 WordPress 檔案同步到網站根目錄(此處以 /var/www/html/ 為例)。

⚠️ 如果你的網站目錄不同,請修改為實際目錄路徑。


🔐 步驟四:修改檔案權限

chown -R apache:apache /var/www/html/

說明:
將檔案擁有者改為 Apache 使用者(CentOS / RHEL 常用 apache)。

🔎 如果是 Ubuntu / Debian 系統:

chown -R www-data:www-data /var/www/html/

🗄️ 步驟五:建立資料庫

登入 MySQL:

mysql -u root -p

建立資料庫與使用者:

CREATE DATABASE wordpress;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

🌐 步驟六:完成網頁安裝

  1. 開啟瀏覽器
  2. 前往你的網域或 IP,例如: http://your-server-ip/
  3. 依照畫面輸入資料庫資訊
  4. 完成安裝 🎉

✅ 安裝完成

成功後即可登入後台:

http://your-domain/wp-admin

[Fix] PHP Server Monitor Shows “Online” for Failed Pings on Newer Linux Distros

I recently deployed PHP Server Monitor v3.5.2 on my server to keep track of my hosting status. However, right after setting it up, I noticed a very bizarre issue:

I purposely added a completely unreachable, invalid IP to test the Ping monitoring, but the system reported it as “Online” with a latency of 0ms!

I checked the system error logs, but they were completely clean—no error messages at all. A monitoring system that fails to alert you when a server goes down is virtually useless. To fix this fatal flaw, I began a deep dive to troubleshoot the issue.

🕵️‍♂️ The Diagnosis: Where did it go wrong?

Initially, I suspected the server’s PHP security settings (like disable_functions in php.ini) might be restricting the execution of system commands. If the exec() function is disabled, PHP wouldn’t be able to run the system’s ping command.

To test this theory, I wrote a simple PHP diagnostic script (test_ping.php) to check the underlying connection:

<?php
$test_ip = "192.168.255.255"; 
$cmd = "ping -c 1 -w 2 " . escapeshellarg($test_ip) . " 2>&1";
exec($cmd, $output, $return_var);

echo "Return Code: " . $return_var . "<br>";
print_r($output);
?>

The execution results were eye-opening:

  • Return Code: 1 (which means failure)
  • Actual Terminal Output: It clearly printed 2 packets transmitted, 0 received, 100% packet loss, time 1016ms.

This proved that the server environment and permissions were perfectly fine! The system successfully sent the packets and accurately recognized that the IP was unreachable (100% packet loss). The environment was not the culprit.

💡 The Root Cause: Outdated Regex vs. Modern Linux

With the environment ruled out, the root of the problem pointed directly to a bug within PHP Server Monitor v3.5.2 itself.

After digging into the official GitHub repository, I realized the software hasn’t seen a major active update since around 2021. The old codebase uses a very rigid method to determine ping status: it uses Regular Expressions (Regex) to parse the text output of the terminal. If it spots the keyword time anywhere in the output string, it blindly assumes “there’s a response time, so the host must be Online.”

In older Linux distributions, a failed ping (100% packet loss) usually wouldn’t print the time taken at the end of the output. However! In newer Linux distributions (like recent Debian versions), the ping command reliably prints out time 1016ms at the very end, even if every single packet is dropped.

Because of this simple phrase—time 1016ms—the outdated code in PHP Server Monitor gets completely confused. It ignores the glaring 100% packet loss right next to it and falsely reports the server as Online. This is also exactly why the “fix” available in the official development branch still fails on newer Linux systems.

🛠️ The Ultimate Solution: Rewriting the Core Logic

Since official maintenance has stalled, the most reliable way forward is to rewrite the validation logic ourselves. Instead of relying on the app to parse terminal text—which can constantly change depending on the Linux distribution—we should just grab the most honest metric the OS provides: the Return Code (0 means success, anything else means failure).

How to apply the fix:

  1. Access your PHP Server Monitor web directory via SSH or FTP.
  2. Locate and open this specific file: src/psm/Util/Server/Updater/StatusUpdater.php
  3. Search for the protected function updatePing function inside the file (it should be roughly past the middle).
  4. Replace the entire updatePing function block with this updated, precise version:
    protected function updatePing($max_runs, $run = 1) {
        $starttime = microtime(true);
        $ip = $this->server['ip'];
        $os_is_windows = strtoupper(substr(PHP_OS, 0, 3)) === 'WIN';
        
        if ($os_is_windows) {
            // Windows Ping: -n 1 (1 packet), -w 2000 (2000ms timeout)
            exec('ping -n 1 -w 2000 ' . escapeshellarg($ip), $output, $result);
            $output_str = implode("", $output);
            // Windows ping notoriously returns 0 on unreachable hosts. Verify with "TTL="
            $status = ($result === 0 && stripos($output_str, 'TTL=') !== false) ? true : false;
        } else {
            // Linux/Unix Ping: -c 1 (1 packet), -w 2 (2s timeout), capture stderr
            exec('ping -c 1 -w 2 ' . escapeshellarg($ip) . ' 2>&1', $output, $result);
            // Core fix for Linux: Only trust the Return Code! (0 is success)
            $status = ($result === 0) ? true : false;
        }
        
        // Record the response time
        $this->rtime = (microtime(true) - $starttime);

        // If it fails and we haven't reached max retries, try again
        if(!$status && $run < $max_runs) {
            return $this->updatePing($max_runs, $run + 1);
        }
        
        return $status;
    }

Save the file and head back to your PHP Server Monitor dashboard. Test that invalid IP again, and the system will finally behave as it should, properly displaying a red “Offline” status!

📝 Conclusion

Sometimes, when running older open-source software on modern operating systems, official patches might not be enough to resolve bugs caused by OS-level changes. In situations like this, writing a simple script to test the underlying commands directly can help cut through the confusion and point you toward the most effective fix.

If you are using PHP Server Monitor and experiencing this “Fake Online” bug, give this fix a try!

Tags: PHP Server Monitor, Bug Fix, Server Monitoring, Ping, Linux

Linux ZFS 指令大全(OpenZFS 實戰版)

適用:

  • Ubuntu 22.04 / 24.04
  • Debian 12
  • Rocky Linux / AlmaLinux 9
  • OpenZFS 2.x

本文適用於現代 Linux 系統(OpenZFS 2.x)


一、安裝 ZFS(Linux)

✅ Ubuntu / Debian

sudo apt update
sudo apt install zfsutils-linux

✅ Rocky / AlmaLinux

sudo dnf install epel-release
sudo dnf install zfs

啟用模組:

sudo modprobe zfs

確認版本:

zfs --version

二、Zpool(儲存池)管理


✅ 建立 ZFS 儲存池(Mirror)

sudo zpool create -o ashift=12 mpool mirror /dev/sdb /dev/sdc

📌 說明:

  • ashift=12 → 4K 磁碟最佳化(強烈建議)
  • mirror → 類似 RAID1

✅ 建立 RAIDZ1

sudo zpool create -o ashift=12 mpool raidz /dev/sdb /dev/sdc /dev/sdd

✅ 建立 RAIDZ2

sudo zpool create -o ashift=12 mpool raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

✅ 查看儲存池

sudo zpool list
sudo zpool status

✅ 增加容量(新增 vdev)

⚠️ 注意:ZFS 無法擴充單一 vdev,只能新增一組 vdev

sudo zpool add mpool mirror /dev/sde /dev/sdf

✅ 加入 Hot Spare

sudo zpool add mpool spare /dev/sdg

✅ 更換故障磁碟

sudo zpool replace mpool /dev/sdb /dev/sdh

✅ Scrub(資料一致性檢查)

sudo zpool scrub mpool

查看進度:

sudo zpool status mpool

建議每月執行一次。


✅ 匯出 / 匯入 Pool

匯出(卸載):

sudo zpool export mpool

匯入:

sudo zpool import mpool

✅ 刪除 Pool(⚠️ 會刪除所有資料)

sudo zpool destroy mpool

三、ZFS 檔案系統管理


✅ 建立檔案系統

sudo zfs create mpool/data

✅ 設定掛載目錄

sudo zfs set mountpoint=/data mpool/data

✅ 建立子檔案系統

sudo zfs create mpool/data/projects

✅ 刪除檔案系統

sudo zfs destroy mpool/data/projects

✅ 查看檔案系統

sudo zfs list

四、Snapshot(快照)

ZFS 最強功能之一 ✅


✅ 建立 Snapshot

sudo zfs snapshot mpool/data@2026-05-06

✅ 查看 Snapshot

sudo zfs list -t snapshot

✅ 還原 Snapshot

sudo zfs rollback -r mpool/data@2026-05-06

✅ 刪除 Snapshot

sudo zfs destroy mpool/data@2026-05-06

✅ 建立可寫 Clone

sudo zfs clone mpool/data@2026-05-06 mpool/testclone

五、壓縮與空間管理


✅ 啟用壓縮(推薦)

sudo zfs set compression=lz4 mpool/data

✅ lz4 幾乎無效能損耗,強烈建議開啟。


✅ 關閉壓縮

sudo zfs set compression=off mpool/data

✅ 設定容量限制(Quota)

sudo zfs set quota=100G mpool/data

✅ 設定保留空間(Reservation)

sudo zfs set reservation=20G mpool/data

六、ZFS Volume(區塊設備)

類似虛擬磁碟,可給 iSCSI / VM 使用。


✅ 建立 Volume

sudo zfs create -V 10G mpool/vm_disk

✅ 查看裝置

ls -l /dev/zvol/mpool/

✅ 刪除 Volume

sudo zfs destroy mpool/vm_disk

七、Linux 最佳實務建議 ✅


✅ 使用磁碟 ID(避免重開機順序改變)

查看:

ls -l /dev/disk/by-id/

建立 pool 範例:

sudo zpool create -o ashift=12 mpool mirror \
/dev/disk/by-id/ata-Samsung_SSD_1 \
/dev/disk/by-id/ata-Samsung_SSD_2

✅ 強烈建議使用 by-id 而非 /dev/sdX


✅ 查看磁碟

lsblk

✅ 自動開機掛載(ZFS 會自動處理)

sudo systemctl enable zfs-import-cache
sudo systemctl enable zfs-mount

八、常用維護指令總整理

功能指令
查看 Poolzpool list
查看 Pool 狀態zpool status
查看 Datasetzfs list
查看 Snapshotzfs list -t snapshot
開始 Scrubzpool scrub mpool
查看 I/Ozpool iostat 2

✅ 結語

ZFS 在 Linux 上已非常成熟,適合:

  • NAS
  • VM 主機
  • Docker 儲存
  • 資料備份伺服器
  • Home Lab
  • 企業儲存環境

測電筆 使用說明書

YITOLI 易之力
DWGR-2897+ PRO MAX


⚠ 警告

使用前請仔細閱讀使用說明書,並嚴格遵守安全規則和使用說明書所列的小心、注意、警告等事項。


安全須知

⚠ 警告
為避免可能發生的觸電或人身傷害:

  • 如未依照指示使用測電筆,則測電筆提供的保護功能可能會受到影響或失效。
  • 如果測電筆顯示屏無顯示,請勿使用。
  • 使用測電筆前,請在已知帶電的電源上進行測試,以確保測電筆處於良好的工作狀態。
  • 在使用測電筆時,即使無顯示或無聲音報警,仍然可能會有電壓存在。如果產品已經損壞,或者無法正常工作,請勿使用。如懷疑有問題,請及時送修。
  • 請勿施加超過測電筆上標記的額定電壓。
  • 測試交流 30 伏以上的電壓時,要格外小心,因為這樣的電壓有發生觸電的危險。
  • 遵守當地和國家的安全規範,依照當地或國家主管當局的規定使用適當的保護設備。

外表結構

  1. 探針(NCV 感應頭)
  2. 手電筒
  3. 開機/照明燈按鍵
  4. 顯示屏
  5. 接觸測量按鍵
  6. 導通/正極測量按鍵

操作說明

開機/關機

按下開機/照明燈按鍵,並保持大於 1 秒開機,蜂鳴響一聲,顯示屏點亮,進入開機狀態;
在開機狀態下,長按開機/照明燈按鍵 1 秒,關機。


手電筒

在開機狀態下,短按開機/照明燈按鍵,手電筒打開;
在手電筒打開狀態下,再短按開機/照明燈按鍵,則關閉手電筒。


感應模式測量

開機默認感應模式測量狀態。

將測電筆的探針放在靠近交流電壓源時,蜂鳴器響;蜂鳴器響的頻率有三檔,隨信號增強遞增。同時顯示屏會顯示「___U」,信號強時顯示「HI」。

以此功能,可查找電線斷點。


交流電壓探測

開機後,按住接觸測量按鍵,進入交流電壓測量模式,測電筆的探針接觸帶有交流電壓的導體時,顯示屏幕上顯示對應的交流電壓。此功能,可檢測交流電壓大小。


零火線測量

根據電壓的大小區分零火線,零線電壓約為 3~7V。


斷電檢測

在電池沒電時測量火線也會顯示高壓符號。


電線導通

開機後,右手按住測電筆導通/正極測量按鍵,左手捏住不帶電導線一端,用測電筆探針接觸導線另一端,如導線連通正常,則顯示屏顯示「___C」,蜂鳴器響,如電線開路,測電筆無反應。


電池正極檢測

開機後,右手按住測電筆導通/正極測量按鍵,左手電池負極,用測電筆探針接觸電池正極,如正常,則顯示屏顯示「___P」,蜂鳴器響,如接反,測電筆無反應。


一般情況下,背光亮紅色時,說明被測物體可能存在危險,需小心操作。


注意事項

注 1: 請確保人體與大地絕緣,請穿著絕緣性好的鞋子,或是站在絕緣墊上使用;如人體的某一部位接觸到帶電物體,或者是其他大面積的導電物體,或者是接觸到大地,會使測量結果偏大。

注 2: 本產品只能用於測量市電電壓,如測量其他經過處理的電源類電壓,誤差較大。

注 3: 由於插座的結構不同,當不能通過感應模式區分零火線時候,可切換到交流電壓檢測模式,一般可根據電筆探測到的電壓大小來區分。

注 4: 當使用感應模式分辨零火線時,如果零火線靠很近時,儘可能將兩根線分開來檢測;如實在不可分開,可根據探測到信號強弱來區分,信號強的一根是火線,信號弱的一根零線。

注 5: 因電筆測量需要人體接觸形成回路,所以請確保手指可以良好的接觸測電筆按鍵。

注 6: 因電筆的感應模式有極高的靈敏度,可以感應微弱的電場信號,所以在金屬探測頭直接接觸帶有微弱電場的物體時,觸發感應,屬正常現象。


自動關機

在約 3 分鐘無感應信號或無任何操作後,測電筆會自動關機,以延長電池壽命。


欠壓提示

當電池電壓不足時,顯示屏會顯示「電池符號」;當出現欠壓提示時,為了不影響檢測,請及時更換電池。


技術參數

工作電壓:
交流電壓:3~500V,50/60Hz

測量誤差:
3~300V ±(5%+3)
300~500V ±(6%+5)

使用環境:
工作溫度:0~40℃
存儲溫度:-10~50℃
濕度:≤95%
海拔高度:≤2000 米

電源:1×1.5V AAA 電池


更換電池

如下圖所示推開電池蓋,然後取出舊電池,按電池正負指示裝入新電池。

⚠ 警告:
為避免電擊,電池蓋在扣好鎖緊前不要使用測電筆進行電壓探測。
為不影響檢測,請確保人體和大地絕緣。


清潔

用濕布進行清潔。
注意:清潔過後要待測電筆完全乾燥後才能使用。


山東易之力工具有限公司
SHANDONG YIZHILI TOOLS CO., LTD
地址:山東省臨沂市經開區沂河路與沃爾沃路交匯南
電話:400-8838-505

✅ How to Fix ISPConfig Manual SQL Backup Not Working (While Auto Backup Works)

Problem Overview

In ISPConfig 3.3 multi‑server setups, you may encounter the following issue:

  • ✅ Scheduled (Automatic) SQL backups work normally
  • ❌ Manual SQL backup does nothing
  • ❌ No error message appears
  • ❌ No backup folder is created
  • ✅ Some websites may work, others do not

This behavior can be confusing because everything seems healthy — but manual backups simply don’t trigger.

This article explains the root cause and provides the permanent fix.


Why This Happens

ISPConfig handles backups differently:

✅ Automatic Backup

Runs locally on the SQL server via cron and does not rely on datalog synchronization.

❌ Manual Backup

Uses this flow:

  1. The ISPConfig UI writes a task into sys_datalog (on the Master server)
  2. The SQL server reads the datalog entry
  3. server.sh processes the task
  4. Backup runs

If the datalog entry cannot be properly written or transmitted, the manual backup will silently fail.


The Real Cause: max_allowed_packet Too Small

In most cases, the issue is caused by a MariaDB configuration problem:

max_allowed_packet

On Debian 12/13 and many CentOS installs, the default is:

16M

In some cases, even:

1M

That is too small for ISPConfig 3.3 multi‑server environments.

Why?

Because sys_datalog may contain:

  • SSL certificate blobs
  • Large JSON configuration data
  • Backup metadata
  • Website configuration structures

If a datalog record exceeds max_allowed_packet, MariaDB silently rejects the transfer.

Result:

  • Small websites → manual backup works
  • Larger websites → manual backup does nothing
  • Auto backup still works

How to Check Your Current Value

Run on BOTH Master and SQL server:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

If you see:

16777216  (16M)

or smaller → this is your problem.


✅ The Permanent Fix (Debian 13 / MariaDB 10.11+)

Step 1 — Edit MariaDB Configuration

On Debian 13, edit:

/etc/mysql/mariadb.conf.d/50-server.cnf

Find the [mysqld] section and set:

max_allowed_packet = 256M
wait_timeout = 300
interactive_timeout = 300

Save the file.


Step 2 — Restart MariaDB

systemctl restart mariadb

Verify:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

You should now see:

268435456

Step 3 — Reset Stuck Datalog Entries

On the Master server:

mysql -u root -p dbispconfig

Run:

UPDATE sys_datalog SET processing = 0;

Then on the SQL server:

/usr/local/ispconfig/server/server.sh

After Fixing

Manual SQL backups should now:

  • ✅ Work for all websites
  • ✅ Create backup folders immediately
  • ✅ No longer silently fail

Why 256M Is Recommended

For ISPConfig multi‑server setups:

SettingRecommended Value
max_allowed_packet256M
wait_timeout300
interactive_timeout300

256M ensures large SSL or configuration payloads do not break datalog synchronization.


Important Notes

✅ You must update BOTH Master and SQL servers
✅ Restart MariaDB after changes
✅ Clear stuck datalog entries

If you only update one server, the problem may persist.


Final Thoughts

If you see:

  • Manual SQL backup does nothing
  • No error in UI
  • Auto backup works
  • Some sites succeed, others fail

The issue is almost certainly MariaDB’s max_allowed_packet.

Increasing it to 256M resolves the problem permanently in almost all ISPConfig 3.3 multi‑server environments.