add update to proxmox and synology ha cluster
This commit is contained in:
109
content/post/first-try-synology-ha.md
Normal file
109
content/post/first-try-synology-ha.md
Normal file
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: "[筆記] 第一次玩 Synology High Availability / first try synology high availability"
|
||||
date: 2020-01-10T09:48:18+08:00
|
||||
draft: false
|
||||
noSummary: false
|
||||
categories: ['筆記']
|
||||
image: https://h.cowbay.org/images/post-default-13.jpg
|
||||
tags: ['synology']
|
||||
author: "Eric Chang"
|
||||
keywords:
|
||||
- synology
|
||||
- high availability
|
||||
---
|
||||
|
||||
上禮拜，原本擔任 proxmox cluster 的主要 storage 的 ds415+ 掛點了
|
||||
|
||||
原因應該就是之前的 intel c2000 series cpu 的 bug
|
||||
|
||||
只是不知道為什麼這台兩三年來都沒有關機的NAS
|
||||
|
||||
比其他三台多撐了那麼久 (已經有兩台送修回來，一台也是同樣症狀，被放在一邊)
|
||||
|
||||
趁著這次機會，看看網路上說的換電阻大法有沒有用！
|
||||
|
||||
如果有用，就拿這兩台來玩玩 synology high availability !
|
||||
|
||||
<!--more-->
|
||||
|
||||
先要感謝這一篇的作者！
|
||||
|
||||
https://www.mobile01.com/topicdetail.php?f=494&t=5600042
|
||||
|
||||
在網路上訂了一大包的 1/4 w 100Ω 的電阻 (100個才70塊，運費都要60了)
|
||||
|
||||
照著上面那篇的作法，把電阻焊上去，NAS就順利開機了！
|
||||
|
||||
__
|
||||
|
||||
架構圖很簡單，只是在做測試而已，又是第一次玩，先不要搞得太複雜
|
||||
|
||||
|
||||
|
||||
流程大致如下
|
||||
|
||||
設定好NAS Cluster 之後，建立NFS 服務
|
||||
|
||||
然後在proxmox 主機上掛載這個NFS 空間
|
||||
|
||||
接著在proxmox 上建立一台 VM ，存放在NFS 空間上
|
||||
|
||||
在這台VM裡面持續 ping NAS cluster VIP 192.168.11.85
|
||||
|
||||
接著拔掉 192.168.11.87 的兩條網路線，模擬NAS cluster 的主伺服器掛點的狀況
|
||||
|
||||
這時候VM 還活著，可以正常建立、刪除、檢視檔案，然後 ping 192.168.11.85 也還持續著
|
||||
|
||||
NAS的告警信件也正常發出
|
||||
|
||||
08:53 NAS High Availability 叢集 ds415cluster 已執行自動故障轉移。 [詳細資訊：無法偵測到 hqs087 (主伺服器)]
|
||||
08:58 NAS High Availability 叢集 ds415cluster 狀態異常 [詳細資訊：無法偵測到 hqs087 (副伺服器)]
|
||||
|
||||
9:08 接回hqs087的網路線
|
||||
|
||||
9:09 收到信件 NAS High Availability 叢集 ds415cluster 停止正常運作 [詳細資訊：Split-brain 錯誤]
|
||||
|
||||
登入管理界面(192.168.11.85:5000) ，操作 HA ，選擇恢復
|
||||
|
||||
這時候開始，VM 的檔案系統變成是 read only
|
||||
|
||||
雖然還活著，但是已經無法建立、刪除檔案，連 cat /var/log/syslog 也會卡住
|
||||
|
||||
9:14 VIP NAS cluster 恢復連線，本來卡住的 cat /var/log/syslog 也可以正常顯示內容了
|
||||
|
||||
但是系統還是 read only，reboot VM 之後才恢復正常。
|
||||
|
||||
有幾個問題
|
||||
|
||||
* split brain 錯誤
|
||||
|
||||
這個問題我想應該是因為只有兩台組成clsuter 造成的
|
||||
|
||||
如果有第三臺加入，應該就不會有這個split brain 的問題
|
||||
|
||||
* VM變成 read only
|
||||
|
||||
這個我就不知道為什麼了，照理說NAS Cluster 已經開始在恢復
|
||||
|
||||
在我的觀念裡，應該要能夠「正常」的持續服務
|
||||
|
||||
但是VM變成 read only ，而且必須要重新開機才能解決
|
||||
|
||||
那這樣NAS Cluster 等於沒有太大作用呀..
|
||||
|
||||
來問問看群暉客服好了
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
105
content/post/postgresql-pgbench-benchmark.md
Normal file
105
content/post/postgresql-pgbench-benchmark.md
Normal file
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: "[筆記] postgresql 效能測試 / postgresql benchmakr using pgbench"
|
||||
date: 2020-01-07T11:18:59+08:00
|
||||
draft: false
|
||||
noSummary: false
|
||||
categories: ['筆記']
|
||||
image: https://h.cowbay.org/images/post-default-17.jpg
|
||||
tags: ['postgresql','pgbench']
|
||||
author: "Eric Chang"
|
||||
keywords:
|
||||
- postgresql
|
||||
- pgbench
|
||||
---
|
||||
|
||||
昨天老闆在slack 上面問說現在的幾台 DB Server 有沒有跑過 pgbench
|
||||
|
||||
分數大概如何，想要跟他的筆電做個比較
|
||||
|
||||
之前有跑過幾次，這次就順便測試一下不同的硬體配置、以及不同的軟體版本
|
||||
|
||||
對於pgbench 跑分會有多大的影響
|
||||
|
||||
<!--more-->
|
||||
|
||||
OS: ubuntu 18.04.3 x64
|
||||
postgresql 版本： 10 / 11 / 12
|
||||
硬碟分成兩種，一個是透過 NFS 10G 網路存取的storage，一個是本機三顆硬碟組成的 zfs raidz
|
||||
|
||||
大概步驟就是安裝postgresql & tools ，然後initialize pgbench table 最後就跑pgbench 測試
|
||||
|
||||
### install tools for postgresql
|
||||
|
||||
sudo apt install postgresql-contrib
|
||||
|
||||
### su to postgres and initialize pgbench database
|
||||
|
||||
sudo su - postgres
|
||||
createdb pgbench
|
||||
pgbench -i -U postgres -s 10 pgbench
|
||||
|
||||
### running the test
|
||||
|
||||
pgbench -t 100 -c 100 -S -U postgres pgbench
|
||||
|
||||
|
||||
得出來的結果如下
|
||||
|
||||
| | 2 cores / 16G | 4 cores / 16G |
|
||||
| --- | --- | --- | PGTUNE | NO PGTUNE | PGTUNE | NO PGTUNE |
|
||||
| PSQL Version | 10G Storage | Local Raidz | 10G Storage | Local Raidz | 10G Storage | Local Raidz | 10G Storage | Local Raidz |
|
||||
| 10 | 9014.144993 | 9395.847239 | 9508.819462 | 10192.27069 | 13280.99918 | 13819.12767 | 15257.69002 | 15397.53475 |
|
||||
| 11 | 9418.477212 | 9333.790266 | 9070.990565 | 9071.182748 | 15455.80444 | 16079.6638 | 15710.24677 | 14274.59939 |
|
||||
| 12 | 8630.21746 | 8872.475173 | 9072.034237 | 9217.547833 | 16116.7502 | 12380.71452 | 17409.10363 | 14520.79393 |
|
||||
|
||||
Update: 喵的 Markdown 的表格不支援 colspan ，只好改用圖片方式呈現
|
||||
|
||||
|
||||
|
||||
|
||||
另外補上一個 2 cores / 2G RAM 的結果
|
||||
### postgresql 10 , 2G RAM , HDD on 10G Storage
|
||||
|
||||
```
|
||||
postgres@ubuntu:~$ pgbench -t 100 -c 100 -S -U postgres pgbench
|
||||
starting vacuum...end.
|
||||
transaction type: <builtin: select only>
|
||||
scaling factor: 10
|
||||
query mode: simple
|
||||
number of clients: 100
|
||||
number of threads: 1
|
||||
number of transactions per client: 100
|
||||
number of transactions actually processed: 10000/10000
|
||||
latency average = 11.583 ms
|
||||
tps = 8633.209610 (including connections establishing)
|
||||
tps = 8651.036900 (excluding connections establishing)
|
||||
```
|
||||
|
||||
有幾個地方值得注意
|
||||
|
||||
* 記憶體 2G->16G 效能的增加並沒有很明顯 tps 從 8633 略為上升到 9014
|
||||
|
||||
* 這個倒是讓我滿意外的，一直以來都認為postgresql 非常的需要記憶體，但是實際跑測試卻不是這樣
|
||||
|
||||
* pgtune 的影響不大，甚至可以說是會降低效能
|
||||
|
||||
* pgtune 是一個網頁服務，可以協助做出「理論上」建議使用的postgresql config
|
||||
https://pgtune.leopard.in.ua/#/
|
||||
* 從結果可以看出，使用pgtune 做出來的config ，跟完全使用預設值的config 相比，pgtune的效能大部分都略低於預設值
|
||||
* 這也讓我很好奇，或許要花更多時間去研究postgresql 的config，但是，幹！我不是 DBA 啊！
|
||||
* CPU 核心數很明顯地影響pgbench
|
||||
|
||||
* 從表格中可以看到，當CPU Cores 增加，pgbench的效能也明顯增加
|
||||
* 而我甚至還沒有指定用多核心去執行測試，如果要用多核心去測試，要把測試指令改成
|
||||
```
|
||||
pgbench -j 4 -t 100 -c 100 -S -U postgres pgbench
|
||||
|
||||
```
|
||||
|
||||
* 10G Storage和 3顆 2T SATA硬碟組成的 raidz 效能差不多
|
||||
|
||||
* 如果本機改用 SSD RAID 甚至是 NVME SSD RAID ，效能應該會提高更多
|
||||
* 10G的部份最多大概就是略低於 1000MB 左右
|
||||
* 如果換成 SSD ，效能應該是還會提昇，但是有限，畢竟10Gb的頻寬限制就在那邊(理論值1250MB左右)
|
||||
|
||||
|
||||
83
content/post/proxmox-with-synology-high-availability.md
Normal file
83
content/post/proxmox-with-synology-high-availability.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: "[筆記] 測試 proxmox 存取由 synology HA cluster 分享的NFS 目錄 / Proxmox With Synology High Availability"
|
||||
date: 2020-01-17T12:20:33+08:00
|
||||
draft: false
|
||||
noSummary: false
|
||||
categories: ['筆記']
|
||||
image: https://h.cowbay.org/images/post-default-18.jpg
|
||||
tags: ['synology','proxmox','high Availability']
|
||||
author: "Eric Chang"
|
||||
keywords:
|
||||
- synology
|
||||
- proxmox
|
||||
- 'high availability'
|
||||
---
|
||||
|
||||
前幾天修復了因為intel cpu bug 導致無法使用的 synology DS415+
|
||||
|
||||
詳情請看 https://h.cowbay.org/post/first-try-synology-ha/
|
||||
|
||||
今天趁尾牙前夕，手邊沒啥要緊事
|
||||
|
||||
就來玩玩看promox 加上 synology high availability 再加上 NFS share 的環境
|
||||
|
||||
<!--more-->
|
||||
|
||||
先上架構圖
|
||||
|
||||
|
||||
|
||||
架構很簡單，NAS設定一組NFS share， proxmox mount 進來，然後開一台VM在NFS 上
|
||||
|
||||
主要來談談proxmox 在碰到synology high availability 切換狀態、遇上腦裂(brain split)時候的狀況
|
||||
|
||||
觸發 brain split (說真的，我覺得腦裂很難聽 ...)的情況，在上面連結那篇文章裡面有提到，就不多說了
|
||||
|
||||
來講講後續的狀況
|
||||
|
||||
發生 brain split 時，可以預期管理者會登入管理界面去修復
|
||||
|
||||
關於修復brain split 可以看看群暉的這篇文章
|
||||
|
||||
https://www.synology.com/zh-tw/knowledgebase/DSM/help/HighAvailability/split_brain
|
||||
|
||||
而我選擇的是 [將兩台伺服器一同保留於叢集中]
|
||||
|
||||
在進行修復的過程中，會發現VM這邊會變成 read only
|
||||
|
||||
聽起來很合理，畢竟在修復時，所有服務幾乎都是停擺
|
||||
|
||||
但是呢，等到修復完成後，VM還是read only ，這就有點奇怪了
|
||||
|
||||
有跟群暉客服反應過這個狀況
|
||||
|
||||
所以在修復完成之後，在proxmox server 這邊直接對NFS 存取做測試
|
||||
|
||||
去下載一個template 是 OK 的，在console 裡面直接在NFS touch file 也是可以的
|
||||
|
||||
所以Synology high availability 是有正常發揮作用
|
||||
|
||||
而promox 這邊，在synology恢復之後，也可以正常存取NFS ，所以也沒有問題
|
||||
|
||||
|
||||
~~那問題就是在VM裡面了，當發生了某些狀況，讓系統進入read only ，就必須透過reboot 才能解決~~
|
||||
|
||||
~~或者是看看這個指令用fsck去檢查filesystem 看看有沒有幫助~~
|
||||
|
||||
```
|
||||
sudo fsck -Af -M
|
||||
```
|
||||
|
||||
UPDATE:
|
||||
|
||||
在proxmox 論壇上提出了這個問題，有回覆說要用 NFS Version 4.1
|
||||
|
||||
經過測試，在掛載NFS share folder 時，如果有指定 NFS Version 4.1
|
||||
|
||||
那在HA Cluster 恢復之後，VM也就跟著恢復正常
|
||||
|
||||
不必再重開機了！
|
||||
|
||||
所以這問題算是解決了！
|
||||
|
||||
|
||||
179
content/post/rescue-synology-nas-with-ubuntu-livecd.md
Normal file
179
content/post/rescue-synology-nas-with-ubuntu-livecd.md
Normal file
@@ -0,0 +1,179 @@
|
||||
---
|
||||
title: "[筆記] 用ubuntu livecd 救援群暉 synology NAS內的資料 / rescue synology nas with ubuntu livecd"
|
||||
date: 2020-01-03T15:43:45+08:00
|
||||
draft: false
|
||||
noSummary: false
|
||||
categories: ['筆記']
|
||||
image: https://h.cowbay.org/images/post-default-11.jpg
|
||||
tags: ['synology','nas']
|
||||
author: "Eric Chang"
|
||||
keywords:
|
||||
- synology
|
||||
- nas
|
||||
---
|
||||
|
||||
2020/01/02 , 2020年上工的第一天，群暉的 DS415+ NAS 掛了！
|
||||
|
||||
因為群暉的文件在最關鍵的一步寫得亂七八糟！
|
||||
|
||||
所以在這邊紀錄一下我操作的步驟！
|
||||
|
||||
<!--more-->
|
||||
|
||||
#### 建立可開機的ubuntu 隨身碟
|
||||
建立 bootable ubuntu flash 的步驟，請參考底下網頁介紹，這邊就不多說了
|
||||
|
||||
https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-ubuntu#0
|
||||
|
||||
#### 把NAS上的硬碟接上PC
|
||||
|
||||
還好這次的NAS只有四顆，如果有八顆，我去哪裡生可以接八顆硬碟的主機...
|
||||
|
||||
#### 用隨身碟開機進入ubuntu Live 環境
|
||||
|
||||
懶人沒截圖
|
||||
|
||||
#### 安裝必要套件
|
||||
|
||||
進入 ubuntu Live 之後，按 ctal + alt + t
|
||||
|
||||
開啟 terminal ，然後先安裝 mdadm & lvm2
|
||||
|
||||
```
|
||||
ubuntu@ubuntu:~$ sudo apt install mdadm lvm2
|
||||
Reading package lists... Done
|
||||
Building dependency tree
|
||||
Reading state information... Done
|
||||
Suggested packages:
|
||||
thin-provisioning-tools default-mta | mail-transport-agent dracut-core
|
||||
The following NEW packages will be installed:
|
||||
mdadm
|
||||
The following packages will be upgraded:
|
||||
lvm2
|
||||
1 upgraded, 1 newly installed, 0 to remove and 780 not upgraded.
|
||||
Need to get 1,346 kB of archives.
|
||||
After this operation, 1,237 kB of additional disk space will be used.
|
||||
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 lvm2 amd64 2.02.176-4.1ubuntu3.18.04.2 [930 kB]
|
||||
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 mdadm amd64 4.1~rc1-3~ubuntu18.04.2 [416 kB]
|
||||
Fetched 1,346 kB in 3s (501 kB/s)
|
||||
....
|
||||
...
|
||||
...
|
||||
以下省略
|
||||
```
|
||||
|
||||
#### scan raid and lvm
|
||||
|
||||
接下來先換成 root 操作
|
||||
```
|
||||
ubuntu@ubuntu:~$ sudo su -
|
||||
```
|
||||
|
||||
然後掃描 raid & LVM
|
||||
```
|
||||
root@ubuntu:~# mdadm -Asf && vgchange -ay
|
||||
mdadm: /dev/md/2 has been started with 4 drives.
|
||||
2 logical volume(s) in volume group "vg1" now active
|
||||
```
|
||||
|
||||
COOL！ 原本的VG出現了！
|
||||
|
||||
```
|
||||
root@ubuntu:~# vgdisplay
|
||||
--- Volume group ---
|
||||
VG Name vg1
|
||||
System ID
|
||||
Format lvm2
|
||||
Metadata Areas 1
|
||||
Metadata Sequence No 3
|
||||
VG Access read/write
|
||||
VG Status resizable
|
||||
MAX LV 0
|
||||
Cur LV 2
|
||||
Open LV 0
|
||||
Max PV 0
|
||||
Cur PV 1
|
||||
Act PV 1
|
||||
VG Size 5.44 TiB
|
||||
PE Size 4.00 MiB
|
||||
Total PE 1427264
|
||||
Alloc PE / Size 1427264 / 5.44 TiB
|
||||
Free PE / Size 0 / 0
|
||||
VG UUID O1c8Uw-JmKy-EiKt-92OB-3K3y-roMi-9NUZ6H
|
||||
```
|
||||
|
||||
也可以看到 RAID 資訊了！
|
||||
```
|
||||
root@ubuntu:~# mdadm -D /dev/md2
|
||||
/dev/md2:
|
||||
Version : 1.2
|
||||
Creation Time : Thu Oct 13 07:26:12 2016
|
||||
Raid Level : raid5
|
||||
Array Size : 5846077632 (5575.25 GiB 5986.38 GB)
|
||||
Used Dev Size : 1948692544 (1858.42 GiB 1995.46 GB)
|
||||
Raid Devices : 4
|
||||
Total Devices : 4
|
||||
Persistence : Superblock is persistent
|
||||
|
||||
Update Time : Thu Jan 2 01:48:34 2020
|
||||
State : clean
|
||||
Active Devices : 4
|
||||
Working Devices : 4
|
||||
Failed Devices : 0
|
||||
Spare Devices : 0
|
||||
|
||||
Layout : left-symmetric
|
||||
Chunk Size : 64K
|
||||
|
||||
Consistency Policy : resync
|
||||
|
||||
Name : video:2
|
||||
UUID : 18f6706d:91eaaec9:5b0ba8da:e32481e3
|
||||
Events : 96
|
||||
|
||||
Number Major Minor RaidDevice State
|
||||
0 8 51 0 active sync /dev/sdd3
|
||||
1 8 35 1 active sync /dev/sdc3
|
||||
2 8 19 2 active sync /dev/sdb3
|
||||
3 8 3 3 active sync /dev/sda3
|
||||
```
|
||||
|
||||
然後就會發生我之前寫的這篇的狀況
|
||||
|
||||
https://h.cowbay.org/post/what-a-piss-in-synology-document/
|
||||
|
||||
問題發生了，總是要想辦法解決
|
||||
|
||||
#### scan lv
|
||||
|
||||
```
|
||||
root@ubuntu:~# lvscan
|
||||
ACTIVE '/dev/vg1/syno_vg_reserved_area' [12.00 MiB] inherit
|
||||
ACTIVE '/dev/vg1/volume_1' [5.44 TiB] inherit
|
||||
```
|
||||
|
||||
OK ，在 vg1 底下有兩個 volume ，看大小來判斷，第二個是我們要的
|
||||
|
||||
用底下的指令就可以掛載了
|
||||
|
||||
```
|
||||
mount /dev/vg1/volume_1 /mnt
|
||||
```
|
||||
|
||||
請依照自己的環境，把第一個路徑改掉，如果要掛載到別的目錄，那也把第二個 /mnt 改掉
|
||||
|
||||
```
|
||||
root@ubuntu:/dev# mount /dev/vg1/volume_1 /mnt
|
||||
root@ubuntu:/dev# cd /mnt
|
||||
root@ubuntu:/mnt# ls
|
||||
@appstore @database @EP_trash @MailScanner @S2S
|
||||
aquota.group @download @iSCSITrg music synoquota.db
|
||||
aquota.user @eaDir lost+found nfsforprox @tmp
|
||||
@clamav @EP @maillog photo video
|
||||
```
|
||||
|
||||
OK，可以看到原本NAS 下的目錄了，接下來就可以進行檔案複製了！
|
||||
|
||||
|
||||
|
||||
|
||||
110
content/post/what-a-piss-in-synology-document.md
Normal file
110
content/post/what-a-piss-in-synology-document.md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: "[碎念] Synology 群暉的文件不知道在工三小 / what a piss in synology document"
|
||||
date: 2020-01-03T11:45:56+08:00
|
||||
draft: false
|
||||
noSummary: false
|
||||
categories: ['雜念']
|
||||
image: https://h.cowbay.org/images/post-default-16.jpg
|
||||
tags: ['synology']
|
||||
author: "Eric Chang"
|
||||
keywords:
|
||||
- synology
|
||||
---
|
||||
|
||||
2020/01/02 2020 上工的第一天，公司碩果僅存的唯一一台 Synology DS415+ 也終於掛了
|
||||
|
||||
開機沒多久就連不上，反覆幾次之後，出現了開機時所有燈號都狂閃的狀況
|
||||
|
||||
終於宣告不治
|
||||
|
||||
問題很明顯的就是Intel C2000 系列 CPU 的瑕疵
|
||||
|
||||
<!--more-->
|
||||
|
||||
總之，機器老早就過保了，上面放的是 proxmox 的 vm 檔案
|
||||
|
||||
在NAS掛點之後，就從備份檔把這些VM還原回來了
|
||||
|
||||
想說網路上很多文章說只要焊一個電阻上去就可以修復
|
||||
|
||||
就把機器和硬碟先放著，等有空再去買電阻回來玩玩看
|
||||
|
||||
結果user今天早上就在靠腰，說上面有一台開發用的VM上面的歷史紀錄很重要
|
||||
|
||||
幹，很重要是不會自己備份逆？
|
||||
|
||||
又不跟我說很重要，要備份，然後自己也不做備份
|
||||
|
||||
然後現在VM 不見了，再來靠腰？？
|
||||
|
||||
幹！真的不要以為資訊公司的員工就比較有sense ，屁！
|
||||
|
||||
不過呢，人微言輕，還是只好鼻子摸摸，想辦法救出來
|
||||
|
||||
然後就找到了群暉的這篇文章
|
||||
|
||||
https://www.synology.com/zh-tw/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC
|
||||
|
||||
```
|
||||
如何使用電腦復原存放在 Synology NAS 上的資料？
|
||||
|
||||
若您的 Synology NAS 故障，可以輕鬆透過電腦與 Ubuntu Live CD 復原資料。請確認 Synology NAS 硬碟上運行的檔案系統是 EXT4 或 Btrfs，並依照下列步驟來復原資料。此處將以 Ubuntu 18.04 版本作為範例：
|
||||
|
||||
1.準備一台電腦，該電腦必須具備足夠的硬碟插槽以安裝從 Synology NAS 取出的硬碟。
|
||||
2.將硬碟從 Synology NAS 取出，並安裝到電腦。若使用 RAID 或 SHR 配置，您必須將所有硬碟 (Hot Spare 硬碟除外) 同時安裝到電腦。
|
||||
3.按照此教學 Create a bootable USB stick on Windows 來建立 Ubuntu 環境。
|
||||
4.前往左下角的顯示應用程式選單。
|
||||
5.在搜尋欄位輸入 Terminal 並選擇終端機。
|
||||
6.若 Synology NAS 上的磁碟配置為 RAID 或 SHR，請依照步驟 7 到 10 操作；若您想復原的檔案位於僅使用一顆硬碟的基本儲存類型機種，請跳至步驟 10。
|
||||
7.輸入以下指令 (sudo 會將執行權限轉換為 root )。
|
||||
|
||||
Ubuntu@ubuntu:~$ sudo -i
|
||||
|
||||
8.輸入以下指令來安裝 mdadm 和 lvm2 (皆為 RAID 管理工具)。若沒有安裝 lvm2，vgchange 將無法運作。
|
||||
|
||||
root@ubuntu:~$ apt-get update
|
||||
root@ubuntu:~$ apt-get install -y mdadm lvm2
|
||||
|
||||
9.輸入以下指令來掛載所有從 Synology NAS 取出的硬碟，結果可能會因 Synology NAS 上的儲存集區配置而有所不同。
|
||||
|
||||
root@ubuntu:~$ mdadm -Asf && vgchange -ay
|
||||
|
||||
10.輸入以下指令來將所有硬碟掛載為唯讀以存取資料。在 ${device_path} 輸入裝置路徑，${mount_point} 輸入掛載點，您的資料將會被置於掛載點的路徑。
|
||||
|
||||
$ mount ${device_path} ${mount_point} -o ro
|
||||
```
|
||||
|
||||
好， 1-9 都沒什麼問題，但是有人可以幫忙翻譯翻譯 10 是在工三小？
|
||||
|
||||
當然，我能理解因為每一臺NAS的環境不同，所以會有一些不同的變數
|
||||
|
||||
但是假如你是一個單純的user ，只是想要救資料，好不容易找了臺電腦
|
||||
|
||||
把硬碟都接上去，用ubuntu liveCD 開機，乖乖做了1-9的步驟
|
||||
|
||||
接著一定會傻眼， 什麼是 ${device_path} ?? 什麼是 ${mount_point} ???
|
||||
|
||||
寫文件的人你就不能配合個圖片，去說明應該要怎麼辨別 device_path ? mount_point 又是什麼？
|
||||
|
||||
這很簡單呀！
|
||||
|
||||
做完 9 的指令，其實就會回復你 NAS 分割區的名稱
|
||||
|
||||
好像叫什麼 vg1 的 <---這個就是變數，可能每一臺都不同，但是你起碼做個範例給人家看啊！
|
||||
|
||||
然後會在 /dev/vg1 底下看到當初建立的磁區 (我的叫 volume_1)
|
||||
|
||||
至於 mount_point 就是看你要掛載到系統的哪個目錄底下
|
||||
|
||||
所以我就要執行
|
||||
```
|
||||
mount /dev/vg1/volume_1 /mnt
|
||||
```
|
||||
|
||||
這樣就可以把NAS上的分割給掛進liveCD ，就可以進行資料複製了！
|
||||
|
||||
連一份文件都做不好，真的是服了這些據說很高薪的「工程師」..
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user