Ersätta HDD i Xpenology server med större diskar

Permalänk
Medlem

Ersätta HDD i Xpenology server med större diskar

Hejsan,

Kör idag en Xpenology server på en äldre Microserver N36 med fyra stycken WD 4tb Red diskar. Jag har nu köpt fyra stycken WD Elements Desktop 12tb som jag tänkte shucka och byta ut mot.

Hur gör jag detta enklast? Nedan är saxat från Synologys hemsida.

Replace Drive to Expand Storage Capacity
In the steps below, we will provide an example of replacing the drives of an SHR storage pool.

To replace drives:
Launch Storage Manager.
Go to Storage Pool to see which existing drive is the smallest.
Power off your Synology NAS. (Skip this step if your Synology NAS supports hot-swapping.)
Remove the smallest of the member drives and install a new, larger drive.
Note: To avoid harming yourself or damaging your Synology NAS, please follow the drive installation instructions found in the Hardware Installation Guide for your Synology product.
Power on your Synology NAS.
Launch Storage Manager again.
Go to HDD/SSD to make sure the new drive is recognized.
The status of your storage pool should be Degraded. Select the storage pool, click Repair from the Action drop-down menu.
Select the replacement drive to add to the storage pool. Then follow the steps of the wizard to finish.
Repeat the above process until all desired drives have been replaced with larger ones.

Tack!

Permalänk
Medlem

Enklast är precis som du står. Du ska rycka ur en disk, sätta i en ny, reparera raiden (tar ett antal timmar). Rycka en till disk, reparera raiden. O.s.v tills du bytt alla diskar.

Ett annat alternativ, om N36 har stöd för fler diskar, är att du sätter upp en parallell volym med de nya diskarna och bara flyttar över datan, men jag tror den bara har plats för 4 diskar..

Ett tredje alternativ är att bara plugga in de nya diskarna, sätta upp volymen som du önskar och sedan återläsa backup till dem. Det är nog absolut snabbast.

Permalänk
Medlem
Skrivet av Kamouflage:

Enklast är precis som du står. Du ska rycka ur en disk, sätta i en ny, reparera raiden (tar ett antal timmar). Rycka en till disk, reparera raiden. O.s.v tills du bytt alla diskar.

Ett annat alternativ, om N36 har stöd för fler diskar, är att du sätter upp en parallell volym med de nya diskarna och bara flyttar över datan, men jag tror den bara har plats för 4 diskar..

Ett tredje alternativ är att bara plugga in de nya diskarna, sätta upp volymen som du önskar och sedan återläsa backup till dem. Det är nog absolut snabbast.

Tack för förslagen Kamouflage.

Står mellan alternativ 1 och 3 då N36 endast har plats för 4 diskar. Jag hänger inte riktigt med på alternativ 3, du menar jag skapar en backup på min data, rycker ut alla fyra diskar, ersätter med de fyra nya och sen återläser backupen på de nya diskarna.

Hur gör man den backupen?

Tack!

Permalänk
Medlem
Skrivet av Xandyr:

Tack för förslagen Kamouflage.

Står mellan alternativ 1 och 3 då N36 endast har plats för 4 diskar. Jag hänger inte riktigt med på alternativ 3, du menar jag skapar en backup på min data, rycker ut alla fyra diskar, ersätter med de fyra nya och sen återläser backupen på de nya diskarna.

Hur gör man den backupen?

Tack!

Antagligen copy paste till en extern hårddisk och en backup på konfigurationen med den inbyggda funktionen

Permalänk
Medlem
Skrivet av Xandyr:

Hur gör man den backupen?

Det är viktigt att du har backup på din data även med alt 1. Det är stor risk att saker går på tok när du ska bygga om hela raiden fyra gånger.

Hur du gör den är väl valfritt, men du behöver ju en till disk. Kan rekommendera att du t.ex. pluggar in en USB-disk och använder synologys inbyggda hyper backup för att lägga en backup på den.
Koppla sedan ur dina gamla diskar och spara dem så du har minst två kopior av din data (backupen + dina gamla diskar). Plugga in nya, återläs från usb-disken via hyper backup.

*edit*
Du kan bygga en SHR-1 med tre diskar och använda den fjärde befintliga nya disken som mellanlagring. När du lagt över filerna till NASen igen kan du plugga in fjärde disken i NASen, lägga till den i SHRen och reparera raiden.

Permalänk
Medlem

Ingen minns en fegis...
Förutom Orlando när han sköt Pitt i foten... Fortfarande sur på det

Permalänk
Medlem
Skrivet av jocke92:

Antagligen copy paste till en extern hårddisk och en backup på konfigurationen med den inbyggda funktionen

Låter rätt tidskrävande och jag har inte någon extern hårddisk på 12tb (om vi nu bortser från de shuckade WD Elements jag har).

Skrivet av Kamouflage:

Det är viktigt att du har backup på din data även med alt 1. Det är stor risk att saker går på tok när du ska bygga om hela raiden fyra gånger.

Hur du gör den är väl valfritt, men du behöver ju en till disk. Kan rekommendera att du t.ex. pluggar in en USB-disk och använder synologys inbyggda hyper backup för att lägga en backup på den.
Koppla sedan ur dina gamla diskar och spara dem så du har minst två kopior av din data (backupen + dina gamla diskar). Plugga in nya, återläs från usb-disken via hyper backup.

*edit*
Du kan bygga en SHR-1 med tre diskar och använda den fjärde befintliga nya disken som mellanlagring. När du lagt över filerna till NASen igen kan du plugga in fjärde disken i NASen, lägga till den i SHRen och reparera raiden.

Jag kör idag SHR-1 (heter bara SHR när jag tittar) men det är tre diskar i raid med en disk redundans. Jag är fortfarande inte helt säker på hur jag ska göra. Jag funderade på att backa upp min viktigaste data, typ filer och bilder och sen testar jag byta en hårddisk i taget. Eller det är för riskabelt?

Permalänk
Medlem
Skrivet av Xandyr:

Hejsan,

Kör idag en Xpenology server på en äldre Microserver N36 med fyra stycken WD 4tb Red diskar. Jag har nu köpt fyra stycken WD Elements Desktop 12tb som jag tänkte shucka och byta ut mot.

Hur gör jag detta enklast? Nedan är saxat från Synologys hemsida.

Replace Drive to Expand Storage Capacity
In the steps below, we will provide an example of replacing the drives of an SHR storage pool.

To replace drives:
Launch Storage Manager.
Go to Storage Pool to see which existing drive is the smallest.
Power off your Synology NAS. (Skip this step if your Synology NAS supports hot-swapping.)
Remove the smallest of the member drives and install a new, larger drive.
Note: To avoid harming yourself or damaging your Synology NAS, please follow the drive installation instructions found in the Hardware Installation Guide for your Synology product.
Power on your Synology NAS.
Launch Storage Manager again.
Go to HDD/SSD to make sure the new drive is recognized.
The status of your storage pool should be Degraded. Select the storage pool, click Repair from the Action drop-down menu.
Select the replacement drive to add to the storage pool. Then follow the steps of the wizard to finish.
Repeat the above process until all desired drives have been replaced with larger ones.

Tack!

Ja, så enkelt är det. Men räkna med att det tar rätt många timmar att bygga om raiden på en disk, och eftersom du ska byta alla fyra diskarna är det fyra gånger tiden för en disk som kommer att krävas totalt. Lagrar man viktig data så ska man alltid ha backup, oavsett hur man lagrar informationen.

Är det något specifikt i guiden ovan du fastnat på?

Permalänk
Medlem
Skrivet av whisky:

Ja, så enkelt är det. Men räkna med att det tar rätt många timmar att bygga om raiden på en disk, och eftersom du ska byta alla fyra diskarna är det fyra gånger tiden för en disk som kommer att krävas totalt. Lagrar man viktig data så ska man alltid ha backup, oavsett hur man lagrar informationen.

Är det något specifikt i guiden ovan du fastnat på?

Hej,

Ok det är ju toppen! Mm förstår att det kommer ta tid att bygga om raiden. Och gällande datan så har jag idag den viktigaste på en extern disk som jag kopplar in lite då och då och för över till.

Det jag fastnade på var väl egentligen om jag fortfarande kan följa guiden trots att jag inte kör en renodlad Synology server utan istället en Xpenology server på en Microserver.

Permalänk
Medlem
Skrivet av Xandyr:

Hej,

Ok det är ju toppen! Mm förstår att det kommer ta tid att bygga om raiden. Och gällande datan så har jag idag den viktigaste på en extern disk som jag kopplar in lite då och då och för över till.

Det jag fastnade på var väl egentligen om jag fortfarande kan följa guiden trots att jag inte kör en renodlad Synology server utan istället en Xpenology server på en Microserver.

Xpenology är egentligen bara en bootloader för DSM (Disk Station Manager). Det mesta fungerar precis som på en riktig Synology, det jag inte fått att fungera fullt ut på min N54L var quickconnect och att uppdateringar av DSM inte alltid ville ladda ner. Diskhanteringen är identisk som om du skulle kört samma DSM-version på Synology-hårdvara.

Permalänk
Medlem
Skrivet av whisky:

Xpenology är egentligen bara en bootloader för DSM (Disk Station Manager). Det mesta fungerar precis som på en riktig Synology, det jag inte fått att fungera fullt ut på min N54L var quickconnect och att uppdateringar av DSM inte alltid ville ladda ner. Diskhanteringen är identisk som om du skulle kört samma DSM-version på Synology-hårdvara.

Ok låter bra. Då tar jag och testar (och håller tummarna) att det funkar med guiden jag skrev i första inlägget. Ska dock görs en backup på mina viktiga filer och bilder.

Permalänk
Medlem

Nu har jag gått igenom processen med att byta ut mina fyra 4 TB diskar mot 4x12TB. Ersatte en disk efter en och gjorde repair efter varje och det tog cirka en vecka för mina fyra diskar.

Nu visar mina diskar grönt / Normal och jag ser rätt storlek på alla fyra diskar i Synologys Storage Manager. Men jag kan kan inte expandera den totala sizen, när jag testar Storage Manager - Manage - Expand the volume with unallocated disk space så händer det inget.

Permalänk
Medlem

Har du startat om NAS:en ??

På annan NAS-tillverkare jag har så krävdes omstart innan en expansion kunde påbörjas och har förmodligen med att man vill ha filsystemet offline som i början vid uppstart då partitioner skall skapas om för de större volymer och sedan monteras filsystemet och därefter utökas ext4-filsystemet för att fylla ut partitioner.

Under alla fina GUI-skal som användare använder så är det i slutändan mdadm som gör grovjobbet för RAID-delen, sedan ext4 olika hjälpprogram för att expandera själva filsystemet. - med andra ord bakom klick-knapparna i GUI så är det scriptar som körs och anropar mdadm, ext4-verktyg mm. med rätt parametrar och händelseordning

Att tänka på är att ext4 kan bara expanderas till 4 ggr dess initiala ursprungliga storlek när det formaterades (var det 4TB så kan det bli max 16 TB, var det 8TB så kan det bli 32 TB max etc.) och är det en NAS med 32-bitars OS så är det inte rekommendabelt att ha större logiska volymer än 16 TB då det har varit problem med detta tidigare. Vart fall bör man hålla sig med nyuppdaterad backup hela tiden om volymerna är större än 16 TB tills det har bevisat sig vara stabilt. En lämplig övning är att fylla hela NAS:en med olika filer tills det tar stopp och sedan radera igen och se att det sköter sig utan att filsystemet kraschar eller överdriven slöhet[1] innan man börja köra in skarpa filer

Någon kanske reagerar på detta men det är i princip ingen OS - vare sig kommersiellt eller open source som rekommenderar lagring över 16 TB logisk volym på 32-bits plattformar - en del tom. har sagt att man skall inte ligga över 8TB (dvs risk för 'signed' på 32-bits variabel) och det beror på rädslan av ej upptäckta buggar i libbar i det som hanterar filsystemen[2], att man har för kort ordlängd (32-bitar) någonstans som tex. hanterar adressering av LBA i filsystem och det blir rollover och det börja skriva över början av filsystemet när man skriver förbi 16 TB gränsen och det trashar hela filsystemet till oräddningsbar nivå. - när ni råkat på detta för att OS upptäcker det så småningom (det går fortare med checksummande filsystem som BTRFS) och gått i read-only mode på filsystem - stäng inte av NAS:en eller gör omboot innan ni har gjort backup på det som går att göra backup - för då räddar man med det som är kvar i RAM när det gäller filsystemsstruktur - men nästa omstart så är allt bortglömt då filsystemet inte ens hittar sig själv för att början av denna har skrivits över med data som lades över 16 TB-nivån.

Denna typ av katastrof-fel är förmodligen och förhoppningsvis hittat idag men jag har råkat på det för ett antal år sedan och man skall komma ihåg att nästan alla dagens NAS-tillverkare kör samma Linux-version/distribution så är det sådan fel som ovan skrivet i sin KöpeNAS med ARM-propp så är det med stor sannolikhet lika på alla de andra också samtidigt.

Det finns dock inget i Linux som hindrar/varnar att skapa större volym än 16 TB även om OS 'bara' är 32-bitars - men det kan ge plötsliga problem och risk för förlorad data. Är OS baserad på 64-bis OS så är det inte några kända problem och många ARM-versioner klara faktiskt 64-bitar-stöd i sig men hos NAS-tillverkare med NAS med ARM-processorer (de billigare modellerna) är det fortfarande 32-bitar OS...

Det är ju bara sista halvåret 64-bitas stöd har kommit för tex. Rasberry PI och det lär släpa minst 1 år innan NAS-tillverkarnas ARM-versioner börja stöda 64 Bit i sina OS.

Intel-versionerna av produkterna har dock nästa alltid körts i 64-bits mode då det har varit standard på OS-sidan länge i Intel-världen.

[1] en känd effekt i många köpeNAS för +5 år sedan att när man fyllde en bit över 80% så kunde det bli oerhör slött och det kunde ta minuter per ny fil med med exponentiell ökad tid för varje ny fil och hade att göra med ext4 journal-hantering - tog flera år innan det löstes då NAS-tillverkarna tittade på varandra och hoppades att någon annan skulle göra jobbet - och när det till slut väl löstes efter flera år så hade alla NAS-tillverkar fixat problemen nästan dagen när samtidigt...

[2] det som är oerhört svårt att testa över ~80% av koden som aldrig används, mer än just vid fel - alltså felhanteringen, det är där de glömda variablerna med kort ordlängd (32-bitar istället för 64 bitar) gömmer sig och signed variabel fast det skulle vara unsigned... och skulle någon av dom anropas för att ta ett sällan förekommande felläge (tex att en disk tar lite för lång tid på sig att svara) så kan de åtgärder de gör totalt haverera hela filsystemet... kodarna har gjort vad de kan för att rensa upp det, men är det inte fel i koden så kanske det är någon använd libb istället och i princip måste det skita sig (och tillräckligt mycket loggar igång samtidigt) för att ha en chans att hitta dessa och det är ett evighetsarbete med mer och mer sällan inträffade händelse...

Permalänk
Medlem
Skrivet av xxargs:

Har du startat om NAS:en ??

På annan NAS-tillverkare jag har så krävdes omstart innan en expansion kunde påbörjas och har förmodligen med att man vill ha filsystemet offline som i början vid uppstart då partitioner skall skapas om för de större volymer och sedan monteras filsystemet och därefter utökas ext4-filsystemet för att fylla ut partitioner.

Under alla fina GUI-skal som användare använder så är det i slutändan mdadm som gör grovjobbet för RAID-delen, sedan ext4 olika hjälpprogram för att expandera själva filsystemet. - med andra ord bakom klick-knapparna i GUI så är det scriptar som körs och anropar mdadm, ext4-verktyg mm. med rätt parametrar och händelseordning

Att tänka på är att ext4 kan bara expanderas till 4 ggr dess initiala ursprungliga storlek när det formaterades (var det 4TB så kan det bli max 16 TB, var det 8TB så kan det bli 32 TB max etc.) och är det en NAS med 32-bitars OS så är det inte rekommendabelt att ha större logiska volymer än 16 TB då det har varit problem med detta tidigare. Vart fall bör man hålla sig med nyuppdaterad backup hela tiden om volymerna är större än 16 TB tills det har bevisat sig vara stabilt. En lämplig övning är att fylla hela NAS:en med olika filer tills det tar stopp och sedan radera igen och se att det sköter sig utan att filsystemet kraschar eller överdriven slöhet[1] innan man börja köra in skarpa filer

Någon kanske reagerar på detta men det är i princip ingen OS - vare sig kommersiellt eller open source som rekommenderar lagring över 16 TB logisk volym på 32-bits plattformar - en del tom. har sagt att man skall inte ligga över 8TB (dvs risk för 'signed' på 32-bits variabel) och det beror på rädslan av ej upptäckta buggar i libbar i det som hanterar filsystemen[2], att man har för kort ordlängd (32-bitar) någonstans som tex. hanterar adressering av LBA i filsystem och det blir rollover och det börja skriva över början av filsystemet när man skriver förbi 16 TB gränsen och det trashar hela filsystemet till oräddningsbar nivå. - när ni råkat på detta för att OS upptäcker det så småningom (det går fortare med checksummande filsystem som BTRFS) och gått i read-only mode på filsystem - stäng inte av NAS:en eller gör omboot innan ni har gjort backup på det som går att göra backup - för då räddar man med det som är kvar i RAM när det gäller filsystemsstruktur - men nästa omstart så är allt bortglömt då filsystemet inte ens hittar sig själv för att början av denna har skrivits över med data som lades över 16 TB-nivån.

Denna typ av katastrof-fel är förmodligen och förhoppningsvis hittat idag men jag har råkat på det för ett antal år sedan och man skall komma ihåg att nästan alla dagens NAS-tillverkare kör samma Linux-version/distribution så är det sådan fel som ovan skrivet i sin KöpeNAS med ARM-propp så är det med stor sannolikhet lika på alla de andra också samtidigt.

Det finns dock inget i Linux som hindrar/varnar att skapa större volym än 16 TB även om OS 'bara' är 32-bitars - men det kan ge plötsliga problem och risk för förlorad data. Är OS baserad på 64-bis OS så är det inte några kända problem och många ARM-versioner klara faktiskt 64-bitar-stöd i sig men hos NAS-tillverkare med NAS med ARM-processorer (de billigare modellerna) är det fortfarande 32-bitar OS...

Det är ju bara sista halvåret 64-bitas stöd har kommit för tex. Rasberry PI och det lär släpa minst 1 år innan NAS-tillverkarnas ARM-versioner börja stöda 64 Bit i sina OS.

Intel-versionerna av produkterna har dock nästa alltid körts i 64-bits mode då det har varit standard på OS-sidan länge i Intel-världen.

[1] en känd effekt i många köpeNAS för +5 år sedan att när man fyllde en bit över 80% så kunde det bli oerhör slött och det kunde ta minuter per ny fil med med exponentiell ökad tid för varje ny fil och hade att göra med ext4 journal-hantering - tog flera år innan det löstes då NAS-tillverkarna tittade på varandra och hoppades att någon annan skulle göra jobbet - och när det till slut väl löstes efter flera år så hade alla NAS-tillverkar fixat problemen nästan dagen när samtidigt...

[2] det som är oerhört svårt att testa över ~80% av koden som aldrig används, mer än just vid fel - alltså felhanteringen, det är där de glömda variablerna med kort ordlängd (32-bitar istället för 64 bitar) gömmer sig och signed variabel fast det skulle vara unsigned... och skulle någon av dom anropas för att ta ett sällan förekommande felläge (tex att en disk tar lite för lång tid på sig att svara) så kan de åtgärder de gör totalt haverera hela filsystemet... kodarna har gjort vad de kan för att rensa upp det, men är det inte fel i koden så kanske det är någon använd libb istället och i princip måste det skita sig (och tillräckligt mycket loggar igång samtidigt) för att ha en chans att hitta dessa och det är ett evighetsarbete med mer och mer sällan inträffade händelse...

Tack för info, jag har start om den men inget händer och jag kan fortfarande inte expandera volymen. Den start och står på 0% sen efter kanske 10-15 sekunder så försvinner det.

Mitt OS är 64-bit så borde vara ok tycker jag.

Volume-->Action--->Configure-->Click on Max. It will add up to the current allocated volume. Detta har jag läst på flera ställen ska lösa det hela men i mitt fall har jag ingen knapp för Action...

Permalänk
Medlem
Skrivet av Xandyr:

Detta har jag läst på flera ställen ska lösa det hela men i mitt fall har jag ingen knapp för Action...

Saknas alltså den här knappen helt? https://i.imgur.com/7fTTyQx.png

Permalänk
Medlem
Skrivet av Kamouflage:

Saknas alltså den här knappen helt? https://i.imgur.com/7fTTyQx.png

Ja precis!

Ska nämna jag kör xpenology DSM 5.0 på en USB sticka i min Microserver N36L.

Edit: Fick det inte att funka att expandera via DSM men hittade en gammal tråd på Xpenologys forum där man använt Ubuntu och kört ett antal kommandon och manuellt expanderat kapaciteten och nu funkar det galant!

Guide och länk (används på egen risk) https://xpenology.com/forum/topic/1957-guide-how-to-expand-th...

Why does my volume not expand?

Even after several tried I'm not sure what the reason is that DSM does not expand. The only thing I can confirm is that there is NO 16TB limit, even though I thought so in the beginning. The log files either show that you are out of reserved GDT blocks or that the volume has expanded successfully even though it didn't. DSM is basically just using LVM and mdadm so it's not a problem to expand it by hand in a safe way. Most guides on the web tell you to do this through SSH, but since most people struggle just to unmount the volume, here's a much easier way.

How to expand your volume

These guidelines are tested with SHR2 and a single volume only, no disk group! SHR should be fine too, but normal raid-setups do not use lvm as far as I know. Even thought the concept would be the same, the commands would differ (instead of expanding though lvm you would probably just use mdadm).

Anyway....

1. The first step is to download Ubuntu Desktop 64-bits and boot it up. This way we do not have to try to stop all the Synology services running. How this is done depends on your hardware and if you are running DSM on a physical or virtual machine. Basically just download the ISO and either burn it to a CD or make a bootable USB-drive from it. Then insert and boot it on the machine running DSM.

http://www.ubuntu.com/download/desktop
http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-...

2. Once booted up, we need to install mdadm as it's not included by default. Just accept the default values, they don't matter in this case:

sudo apt-get install mdadm

3. Now we need to assemble the raid. Once done it should tell you that the raid is assembled.

sudo mdadm --assemble --scan

4. We now need to get lvm to load the volume. Run the following commands in the right sequence. What it does is: load necessary module, scan for lvm volumes, activate volume and find local volume:

sudo modprobe dm-mod
sudo vgscan
sudo vgchange -ay vg1000
sudo lvs

5. Now we can run the file system check. This may take some time:

sudo fsck.ext4 -fvp /dev/vg1000/lv

6. Now we expand the volume. This may take a while! You may open a new terminal window and use "top" in order to see what's going on:

sudo resize2fs -fpF /dev/vg1000/lv

7. Just reboot the system, remove the CD and boot into DSM. It should be all green, no crashed volume!