用這麼久真的沒碰過
不過因為他們是從vmware轉到 pve
查了好几天
真的是vmware的問題
vmware把vss元件reg檔某個值改過了
所以linux發起fsfreeze-freeze的時候沒有權限可以執行
導致vss會報錯
然後出現timeout
但vss雖然有報錯但是有凍結db
也不知道怎麼搞得sql的tempdb就毀了
導致sql服務起不來
解決方法
磁碟檢查修正磁碟
然後把tempdb重建
vss權限加回network service
醬就正常了
2026/08/13
2026/07/20
今天早上來看到昨天的PVE備份沒成功
備分到 192.168 段nas的都沒成功
因為我的几器也是 192.168
一樣ping不到pbs
但跟host在同一段的ip使用都沒問題
第一次碰到這種
可能的原因應該是上週 kernel 升到 7.0.14-5
但在某些 host 又沒問題
先把guest移到沒問題的host
再把有問題host先開回舊kernel試看看
使用 proxmox-boot-tool
列出目前 kernel
proxmox-boot-tool kernel list
pin 回舊kernel
proxmox-boot-tool kernel pin 7.0.14-4-pve proxmox-boot-tool refresh reboot
之後要解除使用 unpinproxmox-boot-tool kernel unpin proxmox-boot-tool refresh
反覆試了几次 看起來也不是kernel的問題
目前只剩一台guest有問題 只能跑在固定的host
先醬 再觀察看看吧
最後查到是arp的問題
到網路設備 clear arp
2026/07/02
2026/06/10
2026/05/21
2026/05/18
2026/02/25
2026/02/14
2025/11/27
昨天 pbs 出了 4.1.0 版
release note 有一點 感覺有點有趣
Allow to control parallelism of verify jobs.
Backup snapshot verification is both an IO- and CPU-heavy workload, as it needs to read chunks from disk and verify their checksums.
The number of threads used for reading from disk and for checksum verification can now be customized.
In some setups, customizing the number of threads can significantly decrease the overall runtime of the verify job.
升級後 跑了一下 竟然省了一半的時間
該期間cpu使用率如下
預設是 read 1 verify 4
找時間再來調大看看會不會效果更好
2025/11/15
之前反應的 docker 無法啟動的問題
到今天升到 docker ce 29.0.1 還是沒解決
看了一下systemctl status docker 發現
Nov 15 05:21:45 n8n-almalinux9 dockerd[160]: time="2025-11-15T05:21:45.778838547+08:00" level=error msg="failed to start container" container=52ba4237fbaed18fdb341674d6569b331080be432ca7bb70d5237719417d40ac error="failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied"
然後再找了一下資料 發現不是 docker的問題
原因出在 pve的lxc
討論串上是說用 pve-test 裡的版本能解決
再等等吧 目前不打算使用 pve-test
2025/11/05
早上死掉一台synology的nas
因為是mount nfs 給pbs 備分用
所以要先把備分移到別台nas
然後在pbs上disable datastore
指令如下
Set to Offline (Disables all access)
proxmox-backup-manager datastore update <datastore-name> --maintenance-mode offline
Set to Read-Only (Allows restores, no new backups)
proxmox-backup-manager datastore update <datastore-name> --maintenance-mode read-only
Re-enable (Go Online)
proxmox-backup-manager datastore update <datastore-name> --delete maintenance-mode
再來修改 /etc/fstab 先把該nfs mount point 註解
重開几
讓pbs繼續運作
PVE上的storage也要先disable 然後把備分改到其他storage
等修好後再 enable
2025/11/04
graylog 7 昨天發布
比較大的改變是不再使用 opensearch 而改用 graylog-datanode
照著官方文件安裝沒什麼問題
如果是在PVE上安裝
因為 mongodb 必須使用到cpu的 avx 功能
所以cpu type 至少要選 x86-64-v3 以上
這個在graylog 5 安裝時就有這個要求了
特別要注意的是以下流程跟之前不同
安裝完後必須 cat /var/log/graylog-server/server.log
找到首次進入系統的帳號密碼及連結
如下範例
http://admin:ghWgeIAkKl@10.0.0.1:9000按照畫面上的流程步驟 使用預設值一直下一步即可
目前先把netflow轉到新版了 觀察一陣子看看
https://go2docs.graylog.org/current/setting_up_graylog/web_interface.htm#Prefligh
https://go2docs.graylog.org/current/downloading_and_installing_graylog/red_hat_installation.htm
2025/08/12
2025/07/17
2025/06/01
almalinux 10 几天前release
今天在proxmox (PVE) 上安裝時 用iso開几就出現 kernel panic
解決的方法就是cpu不要使用預設的 x86-64-v2-AES
也不要用 x86-64-v2
使用 x86-64-v3 或 x86-64-v4 就沒問題了
不過要注意的是 比較舊的host 可能無法支援這二個type 而無法 migrate
官方網站有提到
With RHEL 10, Red Hat will only support x86-64-v3 and higher
不過也有提到
AlmaLinux OS 10 has followed Red Hat’s decision to ship x86-64-v3 optimized binaries by default, but we will also provide an additional x86-64-v2 architecture, allowing users on that older hardware to continue to receive security updates for another 10 years.
所以如果一定要使用 x86-64-v2
就要下載另一個iso
2025/05/25
今天再度測試了一下PVE的firewall功能
發現只要打開cluster的firewall
預設就會載入很多firewall的rule 而且無法刪除
但在測試過程中發現竟然有 guest 原本提供服務的https 打不開了
而且原本使用 nmap做的一些測試也被擋了
最後決定在每台host直接下iptables 指令
#!/bin/bash
######## 以下是防護 host ##############
/usr/sbin/iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -p tcp -s 0/0 --dport 22 -j DROP
/usr/sbin/iptables -A INPUT -p tcp -s 0/0 --dport 8006 -j DROP
######## 以下是防護 guest 視需求新增 port #############
/usr/sbin/iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 22 -j DROP
/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 8006 -j DROP
/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 8007 -j DROP
記得寫在 crontab @reboot
2024/11/29
2024/10/08
延續昨天的問題
昨天修好後當下沒問題
但今天管理介面打不開了
直接倒回去颱風前一天的備分
目前看來運作正常
持續觀察
順便看看還有那些有問題
dmesg|grep "fsck"|grep dm
[ 82.486238] EXT4-fs (dm-6): warning: mounting fs with errors, running e2fsck is recommended
[ 139.304759] EXT4-fs (dm-11): warning: mounting fs with errors, running e2fsck is recommended
[ 398.955415] EXT4-fs (dm-6): error count since last fsck: 2
[ 464.490594] EXT4-fs (dm-11): error count since last fsck: 3769411
[55841.695354] EXT4-fs (dm-12): error count since last fsck: 2
[88379.937761] EXT4-fs (dm-6): error count since last fsck: 2
[88547.518964] EXT4-fs (dm-6): warning: mounting fs with errors, running e2fsck is recommended
[88871.451957] EXT4-fs (dm-6): error count since last fsck: 3
共三台
先到 /dev/mapper 查看是那個guest
lrwxrwxrwx 1 root root 7 Oct 7 23:45 pve-vm--116--disk--0 -> ../dm-6
lrwxrwxrwx 1 root root 8 Oct 8 00:08 pve-vm--124--disk--0 -> ../dm-11
lrwxrwxrwx 1 root root 8 Oct 8 09:04 pve-vm--140--disk--0 -> ../dm-12
一起倒備分吧
不想修了
訂閱：
文章 (Atom)