顯示具有 nas 標籤的文章。 顯示所有文章
顯示具有 nas 標籤的文章。 顯示所有文章

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

2024/09/16

之前換nas的時侯發生 filesystem有問題的情況
使用 xfs_repair 修完後 出現有user的mail不見的情況
當時是使用 PhotoRec 撈了好几天 把資料還給user 
而且也無法確認是否完整

這几天在使用rsync 備分 /home 時 
出現好几次做到一半就會卡住的情況
看了一下才發現竟然出現 超級大檔案 

-rw-------  1 user mailnull 9007199254766339 Aug  4  2023 1691146737.V811I2821a77dbM603030.mail:2,S

只能砍了
而且砍完就正常了
反正就一邊做一邊發現問題一邊砍

2023/01/10

前一陣子發生了一件很OX的事

試了很久 現在做個記錄

因為有幫別的部門架了一台proxmox

而且那個部門也有一台nas

因此我就在那台nas上開了nfs然後用pbs備份

他老兄在某一天竟然進到nas把我備分用的那個nfs裡的資料砍了

然後第二天就出現了如下的error

ProxmoxBackup Server 2.3-2

2022-12-29T00:00:00+08:00: starting garbage collection on store nfs418

2022-12-29T00:00:00+08:00: task triggered by schedule 'daily'

2022-12-29T00:00:00+08:00: Start GC phase1 (mark used chunks)

2022-12-29T00:01:03+08:00: marked 5% (1 of 17 index files)

2022-12-29T00:04:14+08:00: marked 11% (2 of 17 index files)

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk c3fe251560dcd2cc5aef7cfbd6669d0dd9ca7491c455f537efc6d319b09892ec, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 6dc29793341c20c7c80910a73893501b034a0e29c14a444d214d835ccffc0d16, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 1f81c244f9b7816ab37d3ef7ffdcd10443eb1bddb3fa44e036186b73f1fee33a, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 95c7e6747d43b5b516e1768a1f258f352aeb47b23fd46575440dc3d820d1b253, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 9513a7e5c650245d3344115115b21285cc8f426e5284fa04159ea96e49856535, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 68b2b40dd3bacba9e649c67862011934bc7f048d8ea2d35fbd95c39f9d5cf7c4, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 494608d49f57039fd7a8378e1a2a2cf6bb0688773a525addc2f54507a94cd11d, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 09eab384d5f3cbf657db1c0750ef52be2f1dbdf134f977a24dc095382b6e25ed, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 9c1208d43242276c75a4f65f41054e4bc0e7e1144a61c951902bb8df94f055c9, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx" 

..........................................

後面還一大堆

本來是想說把pbs上的datastore砍了重建應該可以解決問題

forum上也是醬說的

結果不是

我砍了datastore重建

甚至在nas上再開另一個nfs後再重建datastore

過沒几天又會出現如上的錯誤

最後的解決方法是直接重裝一台新的pbs

問題才解決

無言中

2021/10/21

升到 promox 7 後

有几台guest都出現了以下的問題






可是使用  badblocks xfs_repair  進行檢查

都沒有發現任何錯誤

而且看了一下nas各個HD的資訊

也沒有發現任何狀況

還在找原因

之前有一台是發生在swap 區

目前把swap 關掉

然後把 ram 從2G調到 4G

觀察到現在沒有異常

不知道是不是ram 的問題


2021/10/24 更新

發生狀況的有四台几器 共同的情況是這些guest的io都很大

分別處理如下

ntopng因為升版後 system id 變了 所以移至 LXC 後 重新要了新key

librenms 下載了新版的vm 把資料移轉到新几器上

https://docs.librenms.org/Support/FAQ/#how-do-i-move-my-librenms-install-to-another-server


剩下cacti 跟 syslog

從log來看是 write 時候的問題

目前所有的guest hd 預設都是使用 no cache

想說會不會是效能的問題

https://adminkk.blogspot.com/2016/05/wsus-proxmox-winmount-nfs-wsus-iscsi.html


於是把上面二台

一台調成 write back

一台調成 write through

 到目前跑了二天

持續觀察中


2019/05/23

之前發過一篇有關如何在graylog利用ip在地圖上顯示的方法
本來是有使用
但自從上次nas 掛二個HD GG後
graylog重裝 這個功能就沒有再加上去了
直到最近有人提到說想看類似的圖
才想說再起起來
沒想到由於目前收的log筆數太多
功能起起來後 因為會去解析所有進到graylog的ip
系統資源無法負荷
所以只好關掉再想別的辦法
剛好最近玩的grafana有個worldmap pannel 的plugin
想說來試看看
這個plugin支援滿多的datasource

Graphite
InfluxDB
OpenTSDB
Prometheus
MySQL
Postgres
MSSQL
Elasticsearch

想說就拿influxDB來用

首先每五分鐘到graylog取回這段時間被block的ip
取回後
再利用 geoiplookup 來把ip的地理位置取出來
在centos 7 上安裝

yum install GeoIP

裝好後就可以使用了
語法是
geoiplookup 8.8.8.8

GeoIP Country Edition: US, United States

我只想用國家來畫 所以以上資的資料就夠了
有二個原因
因為worldmap panel 直接支援用國碼來畫圖
再來就是如果要用座標來畫 一天的資料可能就會把HD撐爆了

接下來就是把以上取得的資料塞進influxdb
以下是程式碼

/bin/curl -u username:passwd 'http://10.10.10.10:9000/api/search/universal/keyword/export?query=source%3A10.10.10.20&keyword=last%205%20mins&batch_size=500&fields=message' > /tmp/5min_ipp
cat /tmp/5min_ipp |grep '\[' |awk '{print $2}'|cut -d ']' -f 1|cut -d '[' -f 2 > /tmp/5min_ip

rm /tmp/country

for i in `cat /tmp/5min_ip`
do
        country=`/bin/geoiplookup $i|awk '{print $4}'|cut -c 1-2`
        echo $country >> /tmp/country
done

cat /tmp/country|sort|uniq -c > /tmp/attack_data

while read line
do
#       echo $line
        /bin/influx -database "attacker" -execute "insert attack,name=`echo $line|awk '{print $2}'` value=`echo $line|awk '{print $1}'`"
done < /tmp/attack_data

attack 這個 Measurement只放了二個資料
國碼 這五分鐘的攻擊次數
如下

1558574202593759971 SG   9
1558574203886084275 SK   1
1558574205156245342 TH   3
1558574206520742362 TR   4

最後就是畫圖了 這也是搞最久的地方

設定influxdb 的datasource



























在dashbord上加上world map panel

再來設定相關資料
















紅色框一定要依据定義的field設對 不然圖就是出不來













location data 選擇country 以符合上面說明資料

如果設定正常 就會看到以下的圖了


















以上的程式在每五分鐘執行時會使用大量的cpu資源
請特別注意
另外可能要依据需求定時去清理influxdb的資料 以免占用太多HD空間


https://blog.csdn.net/Py_Wang/article/details/79186634


2019/05/21

一直以來為了減少graylog的loading
都會用shell批次把舊的index close
但今天跑完卻出現












把nas snapshot倒回去
再跑一次
還是一樣
這就有點怪了
於是手動一個一個關
然後關一個試一次
果然關到其中某一個後又出現
然後open又好了
看來也沒辦法了
只能留著
等到時間倒自然清掉吧

2018/02/06

1/28 存放graylog資料的nas發生當機的情況
隔天上班後nas重開graylog無法順利啟動
出現的錯誤訊息是mongodb無法啟動
試了很多方式還是無法修復
先把之前的backup倒回(只針對主程式)
還是無法啟動
重裝graylog也無法使用之前的資料

最後想到不久前升級graylog時有做了一個snapshot
這個snapshot是在關機時做的
利用這個snapshot回復
loss了一週的資料

接下來思考如果之後出現煩似的情況
要如何在捐失最少的資料進行回復
想到的方式是把graylog的主程式搬到跟資料同一個資料夾
然後利用nas定時snapshot的功能每半小時做一個snapshot(nas可支援到每五分鐘)
醬就可以把主程式跟資料一起snapshot在某一個時間點
這個有做這回復驗証 可以啟動graylog沒問題
只是在 system overview 會出現 Indexer failures的情況
但還是可以操作

目前graylog存放的資料是 4.5T 完全不可能備分
看來在大資料量的情況下
snapshot是少數可以利用的解決方案

2016/07/18

proxmox 升到4.2後又有新的狀況

設定完自動備份後
一直發生備份到一半
guest就不明原因的不正常關机
導致備分不成功
甚至有nas因此而當机
找了半天 看了原廠的forum也沒看到什縻解决方法
但在3.x版共沒有這個問題
原本以為只有自動排程會有問題
測了一下連手動也一樣
原本預設的備份會使用lzo壓縮備份檔
比對了一下3.x版的備份
發現預設並沒有使用lzo
所以用手動方式不壓縮先備份一次
正常沒問題
所以把自動排程的備份全部改成不壓縮
再觀察看看

2014/03/01

本來不太使用的coventive nas因為user的一個需求
必須在create一個帳號
但建完帳號發現quota無法設定
而且之前針對user設定的quota也都不見了
連絡原廠後原廠判定是home的file system有問題
而且原廠判定home的filesystem是xfs
而xfs的quota是記錄在filesystem內
所以做成以上結論
解決方法是找一個空間把home的資料co出來
重建home再放回去
我以xfs重建完home後
發現quota還是不能設定
找了一下coventive竟然沒有xfs_quota這個指令
再想一想應該還是使用ext3才對
繞了一大圈
最後總結應該是

把home裡的
.aquota.group
.aquota.user
這二個檔砍了
重跑quotacheck
再重新設定每個user 的quota應該就解決了
Orz

2013/08/06

最近二個月在新机器上出現了二次i/o的問題
今天打電話去原廠
本來是要問有沒有新的mirror box的產品
順便問了一下i/o的問題
原廠才提到使用在nas或mirror box上的硬碟必須有
TLER(time-limited error recovery)的功能
而目前市面上非企業級硬碟為了cost down
都把這個功能拿掉了
導致机器運作的過程中就會有問題
所以之後在買硬碟前
必須打電話回原廠
詢問有那些硬碟有這個功能
才能買囉
所以pc隨机出貨的硬碟大概也都不能用了
XD