Forum Datorer och system Server Tråd Inlägg

Flytta gamla diskar till nytt NAS

1
Skriv svar
Permalänk
Medlem
●

Flytta gamla diskar till nytt NAS

Hej

Jag hade en Synology Diskstation DS1515+ som säcka ihop. Nu vill jag köpa ett nytt NAS och tittar t.ex. på en QNAP TS-653D-4G. Vad jag har förstått så behöver jag i det här läget formattera om diskarna innan de kan användas. Jag vill spara min data.

Hur räddar jag den? Behöver jag först plugga in mina gamla diskar i en annan Synology för att mellanlanda min data? (är det också isf så enkelt?). Eller kan det gå att konfa en Linux VM på min Windows desktop och spara undan min data därigenom istället?

Det är 3sr diskar och jag minns inte vilken RAID konfig jag satte dem i.

Tacksam för hjälp.

Visa signatur

AMD Athlon 64 3k+, ASUS A8N-SLI deluxe, NVIDIA GeForce 6200 TurboCache, Q-TEC PSU 650W, NVIDIA nForce nätverkskort, SB Audigy 2, 2 x 1GB Corsair PC3000 DDR-SDRAM, WD Raptor 36.7GB SATA 8MB 10k RPM och Maxtor 200GB SATA

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Tja

Synology har en rätt bra supportartikel på exakt detta

https://kb.synology.com/en-my/DSM/tutorial/How_can_I_recover_...

Edit:

Detta kanske är mer vad du vill göra, om du vill ha en annan Synology dvs

https://kb.synology.com/sv-se/DSM/tutorial/How_to_migrate_bet...

Senast redigerat
Visa signatur

Every mammal on this planet instinctively develops a natural equilibrium with the surrounding environment; but you humans do not. Instead you multiply, and multiply, until every resource is consumed.
There is another organism on this planet that follows the same pattern... a virus.
CITERA CITERA CITERA

Redigera
Citera flera Citera
Permalänk
Medlem
●

Tack för svar mini-ryttge

Ja jag såg den första artikeln och inser att det nog är bäst att gå vägen med att fixa en Ubuntu då. Hade mest hoppats kunna slippa det steget om jag bara hade kunnat jacka upp diskarna till ett nytt NAS, även om det NAS:et då är en QNAP.

Andra artikeln ser ju lovande ut om mitt nya NAS nu blir en Synology igen ja, tack för det!

Visa signatur

AMD Athlon 64 3k+, ASUS A8N-SLI deluxe, NVIDIA GeForce 6200 TurboCache, Q-TEC PSU 650W, NVIDIA nForce nätverkskort, SB Audigy 2, 2 x 1GB Corsair PC3000 DDR-SDRAM, WD Raptor 36.7GB SATA 8MB 10k RPM och Maxtor 200GB SATA

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Räkna alltid med att dina diskar blir rensade när man stoppar in diskar från en NAS-tillverkares kabinett till en annan NAS-tillverkares kabinett.

Visst, det är linux i alla dessa men skripten som gör jobbet för en viss tillverkare beter sig inte på samma sätt som för en annan tillverkare och en okänd disk betraktas som ny och 'tom' i de flesta fallen, möjligen kan man få en chans att avbryta processen om den ser att disken har en gammal partition i sig

Redigera
Citera flera Citera
Permalänk
Medlem
●

Ok, tack för det xxargs - bra att ta med sig. Får se till att min co-location backup är bättre uppdaterad till nästa gång.

Visa signatur

AMD Athlon 64 3k+, ASUS A8N-SLI deluxe, NVIDIA GeForce 6200 TurboCache, Q-TEC PSU 650W, NVIDIA nForce nätverkskort, SB Audigy 2, 2 x 1GB Corsair PC3000 DDR-SDRAM, WD Raptor 36.7GB SATA 8MB 10k RPM och Maxtor 200GB SATA

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

förr eller senare får man ta den dagen att köpa sin 18 - 22T jättedisk och sedan göra backup/kopia (tömning) på sin gamla nas och sedan har friheten att kasta in de gamla diskarna i den nya kabinettet utan att gruva sig över dataförluster och när alla RAID är byggda - så får man kopiera tillbaka dem från jättedisken och sedan har jättedisken som en 3'-backup som kopplas in mer sällan och synkas.

se till att mappstrukturer etc. är lika i backupdisk och NAS så det är enkelt att köra 'rsync' för att hålla det uppdaterat - och det går att ssh:a in från en annan dator så det behöver inte anslutas alls över huvudtaget till NAS:en ifråga.

jag rekommenderar att man använder BTRFS på sin jättedisk då man kan göra snapshot (även som readonly) utan att det tar extra plats innan tex. en ny synkning och skulle den gå åt pipan för man slant med sista '/' i sina sökvägar så har man alla de gamla kvar - orörd.

Men för det bör du nog göra din backup via en linuxdator som kör disken med SSH eller via NFS kör synkningarna med rsync. och rsync kan arbeta över ssh då det är om en vanlig sökväg fast den startar med user@host:~/sökväg_inom Usermapp_i_NAS/mapp/ - ibland kan det behöva föregå med '-e ssh' - har man lagt in open-SSHnycklar på klient och serversidan så är det en passwordsfri historia och bara fungerar - dock kanske inte 100 MB/s om det är en klenare CPU på NAS-sidan - kryptering kostar kraft.

just att man i BTRFS kan göra snapshot (och sedan kan tas bort i valfri ordning utan låsning mellan varandra) är det jag skulle sakna mest om man inte kunde göra det och ZFS farfar, far och son - låsning för deras snapshot gillar jag inte alls då det är inget annat än tar-arkiv med några generationer inkremetell backup efter varandra och man kan aldrig slänga huvudbackuppen (farfar) eller några snapshot i mitten i kedjan (far) trots att mycket av det blivit obsolet och bara behålla sonen - utan man måste kopiera alltihop till en ny dataset innan man kan göra sig av med gamla dödköttet och återvinna diskplats. - medans i BTRFS är data som inte längre har någon koppling till några av subvolymerna pga. radering är något som städas bort efter ett tag och diskytan blir tillgänglig igen..

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av xxargs:

förr eller senare får man ta den dagen att köpa sin 18 - 22T jättedisk och sedan göra backup/kopia (tömning) på sin gamla nas och sedan har friheten att kasta in de gamla diskarna i den nya kabinettet utan att gruva sig över dataförluster och när alla RAID är byggda - så får man kopiera tillbaka dem från jättedisken och sedan har jättedisken som en 3'-backup som kopplas in mer sällan och synkas.

se till att mappstrukturer etc. är lika i backupdisk och NAS så det är enkelt att köra 'rsync' för att hålla det uppdaterat - och det går att ssh:a in från en annan dator så det behöver inte anslutas alls över huvudtaget till NAS:en ifråga.

Gå till inlägget

Just det där jag funderar på kring min nästa NAS. Vill gärna ha alla diskar i en volym så man slipper flytta runt grejer om en volym börjar bli full, men en annan volym har plats. Blir dock problem om denna volym är dubbelt så stor som de diskar man har till offline backup.

Går så klart att fylla diskarna en efter en, men tappar mycket tid jämfört med att kunna köra rsync volym 1 till disk 1, och rsync volym 2 till disk 2.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CymbalCrasher:

Just det där jag funderar på kring min nästa NAS. Vill gärna ha alla diskar i en volym så man slipper flytta runt grejer om en volym börjar bli full, men en annan volym har plats. Blir dock problem om denna volym är dubbelt så stor som de diskar man har till offline backup.

Går så klart att fylla diskarna en efter en, men tappar mycket tid jämfört med att kunna köra rsync volym 1 till disk 1, och rsync volym 2 till disk 2.

Gå till inlägget

Blir till att ha en nas till då att köra backup mot då

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det är värt att lägga lite tid och tester på att lära sig BTRFS som filsystem om det skall användas till arkivering.
det är enkelt att utöka BTFS-volymen i storlek genom att addera extra disk till volymen när det börjar bli trångt och den vägen får större volym och att det kan göras medans kopieringen pågår för fullt.

många filsystem är rätt fixa på den biten och volymstorleken bestämdes när filsystemet skapades och kräver att filsystemet är avmonterad och modifieras utifrån av externa program om den skall ändras (somliga bara växa men kan inte krympa)

BTRFS har egen multi-disk hantering och volymen kan både öka (med fler diskar) och minska (ta bort diskar) i storlek online och under full användande och det mesta filsystemunderhållen och modifieringarna görs också i online och monterad form. det går också att ändra RAID-moder under användande med 'balance' så inget är hugget i sten när det gäller RAID-layout eller paritets-skydd. snapshot/subvolymer och att man kan få smidigt fungerande komprimerande filsystem är två av de riktigt viktiga nyckelpunkter för filsystemet.

BTRFS är 1 av de för närvarande 3 existerande filsystemen som har checksumma på all sin data och metadata - dom andra två är ZFS och ReFS (dock formateras nästan alltid med checksumman avstängd i praktiken för att default är så och ingen intresserad att leta reda vilka flaggor som krävs för att det skall aktiveras i samband med formateringen - problemet är att folk tror att den är aktiverad i drift tills den berömda kraschen väl har inträffat och sanningen kommer fram... i BTRFS går det att stänga av checksumme-kontrollen på filnivå - oftast att man stänger av COW-funktionen för ofta modifierade filer för att det inte skall fragmentera sig för mycket över tid, men då missa man en del funktioner som snapshot och komprimerande filsystem mm. Situationer där det kan behövas är tex databasfiler och i OS-sammanhang för utökade swap och page-filer och det var förs när man fixade detta som det var möjligt att bygga Linux-systemdisk baserat på nära 100% BTRFS, annars var det alltid i någon del baserat på ext4 för just OS-delen

---

Har typ använt BTRFS i snart 10 år och har aldrig förlorat data på den formatet - samma sak kan jag inte säga om NTFS... (som jag genuint hatar av nyss nämnda orsak då det sved ordentligt) - men jag har också blivit mer noga att lagra viktig data på mer än en enda fysisk exemplar och beror mycket på att lagringen har blivit relativt billigt, så var det inte förr..

Senast redigerat
Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara