Snelste manier om data tussen 2 lokale Synology's te delen?

[Sjeefr]

Helaas is mijn Primaire schijf van mijn primaire NAS (DS216+) gecrasht (vastgelopen). De data is wel toegankelijk, maar volledig read-only (gelukkig?). Ik heb al een paar jaar een off-site NAS (DS213j) voor zulke situaties, dus dat is fijn. Nu heb ik vandaag een nieuwe 6TB schijf gekocht en in de DS216+ geplaatst, naast de gecrashte 4TB en in SHR gezet, daar ik ergens in januari een tweede 6TB voor mirroring zal plaatsen. Gedurende het terugplaatsen van alle data heb ik de oude DS213j lokaal in dezelfde kamer geplaatst.

Nu wil ik dus zo snel mogelijk de oude ~ 3.2TB aan data overzetten. Het gaat mij echter niet bepaald snel.
Een paar feiten en statistieken op een rij:

• Beide NAS'n zijn aangesloten op hetzelfde netwerk via CAT.5e kabels
• Allemaal WD REDs
• Transfers tussen de gecrashte 4TB en nieuwe 6TB op dezelfde NAS gaat met ~ 8MB/s
• Transfers via FTP met de 213j gaat met ~10-15MB/s
• Transfers via CIFS met de 213j gaat met ~20-35MB/s

Op een gigabit switch, gigabit ethernet poorten en gigabit-geschikte kabels zou ik toch wel wat meer pieken van 80MB/s willen zien, maar dat doe ik dus niet.

Daarom mijn vraag: Wat is de beste/snelste manier om
- Data van mijn gecrashte 4TB schijf te kopiëren naar de 6TB?
- (indien de crash verantwoordelijk is voor de trage snelheid: ) Diezelfde data van de oude NAS te kopiëren naar de nieuwe?

^{Nu met de nieuwe 6TB kan ik, als goed is, weer apps installeren (zoals Hyper Backup} en wat je ook wilt e.d.).

[ Voor 3% gewijzigd door Sjeefr op 05-12-2017 08:42 ]

[Tortelli]

Ik neem aan dat op je offside 213j precies dezelfde data staat als op je 216+?. Dan zou mijn voorkeur zijn de data van de 213j te halen.

Schijven welke half en heel kapot zijn worden vaak erg sloom (vooral met write acties), je kunt de data ook niet helemaal vertrouwen (er is altijd een kans op een paar omgevallen bitjes).

Snelheid is sterk afhankelijk van gebruikte protocol (SSL?), type bestanden (bestanden van x GB/stuk gaan sneller dan miljoenen bestandjes van een paar KB) en de performance van de NAS. De 213j zal met SSL (encryptie) geen geweldige snelheden halen; de 215j die bij mijn offside backup is piekt rond de 20MB/s op FTP met SSL aan bijvoorbeeld, Hyper backup op intern netwerk is ook niet enorm snel.

HDD en Gbit netwerk zal hierbij niet de bottleneck moeten vormen. Via CIFS zal dit zo'n 1-2 dagen duren dus..... denk dat je gewoon wat geduld moet hebben in deze.

[jeroen3]

Je kunt via DSM zelf een remote map mounten via FTP of NFS.
Dan loopt het direct NAS-NAS ipv NAS-PC-NAS.

[Sjeefr]

jeroen3 schreef op dinsdag 5 december 2017 @ 10:54:
Je kunt via DSM zelf een remote map mounten via FTP of NFS.
Dan loopt het direct NAS-NAS ipv NAS-PC-NAS.

Al mijn schijven zijn gecodeerd, dus NFS is geen optie. FTP gaat niet bepaald snel, maar beetje bij beetje gaat het z'n gangetje.

[MAX3400]

Domme opmerking maar kan je niet als "admin" inloggen op de commandline, de inhoud van de mountpoints zien en dan een rsync naar de andere kant starten?

[Tortelli]

Vilscon schreef op dinsdag 5 december 2017 @ 12:22:
[...]


Al mijn schijven zijn gecodeerd, dus NFS is geen optie. FTP gaat niet bepaald snel, maar beetje bij beetje gaat het z'n gangetje.

Je verlies bij FTP heel veel tijd door het connecten etc (commands die je pc feitelijk uitvoert), werkelijke transfers zullen wel behoorlijk hard gaan. Gewoon 3-4 connecties tergelijk laten lopen (van verschillende mappen natuurlijk).

Al denk ik dat rsync hier inderdaad de oplossing is?. Of SCP?, dat zou ook vrij vlot moeten gaan?.

[MAX3400]

Tortelli schreef op dinsdag 5 december 2017 @ 13:07:
[...]


Je verlies bij FTP heel veel tijd door het connecten etc (commands die je pc feitelijk uitvoert), werkelijke transfers zullen wel behoorlijk hard gaan. Gewoon 3-4 connecties tergelijk laten lopen (van verschillende mappen natuurlijk).

Al denk ik dat rsync hier inderdaad de oplossing is?. Of SCP?, dat zou ook vrij vlot moeten gaan?.

Inderdaad; FileZilla kan bijvoorbeeld meerdere "panes" open hebben die allemaal los van elkaar transferren. Uiteindelijk zal je inderdaad een soort multi-thread hebben maar je zit wel met de intermediate node die alles weer moet wegsturen.

Geen idee of FXP ook out-of-box kan met een Synology maar dat lijkt me het snelste "GUI alternatief".

[Tortelli]

FXP werkt gewoon, al moet je dit wel in de opties aanzetten. Daarnaast is de basis van de FTP server behoorlijk verouderd en ondersteund hij bepaalde recente SSL certificaten niet (SSL zou ik intern sowieso niet gebruiken...).

Filezilla is een goeie optie inderdaad.

[ Voor 9% gewijzigd door Tortelli op 05-12-2017 13:18 ]

[ThinkPad]

Ik heb dit ook wel eens gedaan en een rsync-taak instellen in de webinterface van de Synology (DSM) werkte het beste. Daarmee was het in een paar uur gepiept.

[Tortelli]

ThinkPadd schreef op dinsdag 5 december 2017 @ 13:30:
Ik heb dit ook wel eens gedaan en een rsync-taak instellen in de webinterface van de Synology (DSM) werkte het beste. Daarmee was het in een paar uur gepiept.

Enige waar geen echt goeie optie voor is, is een nieuwe synology met nieuwe schijven in 1x overzetten volgens mij (incl applicaties etc). Volgens mij moet je dat altijd handmatig doen?.

[ThinkPad]

Met nieuwe schijven kan dat volgens mij niet nee. Als je de schijven van Synology A in Synology B zet dan zal hij dat (als het goed is) wel oppakken.

[Sjeefr]

Maar hoe start ik dan een rsync proces op de NAS zelf, i.p.v. m'n Mac's terminal schermpje?
Op dit moment doet ie een deel via FTP, map voor map.. Hyper Backup werkt niet hé.. Niet op de nieuwe NAS in ieder geval.

En als het even kan.. Wellicht een voorgekauwde rsync commando? Volledige bestand moet behouden worden, inclusief timestamps en ownership als het even kan..

Maar vooral dus Rsync op de nas zelf

En dan uiteraard dat ie niet stopt zodra je je terminal window sluit en/of dat ie in ieder geval pauzeert.

[ Voor 20% gewijzigd door Sjeefr op 05-12-2017 16:35 ]

[Tortelli]

Je kunt via SSH (programma als putty) inloggen op je Synology (je moet dit aanvinken in de admin interface!). Je moet een admin (?) account op beide apparaten hebben met SSH rechten.
Let op; als je DSM 6 draai moet je eerst inloggen onder je gebruikersnaam met admin rechten (niet met gebruiker "admin" of "root".

Login met je ip adres en poort in putty (of de OSX variant daarvan). Om admin rechten te krijgen op de NAS voer je het volgende commando uit:

code:

sudo -i

(vervolgens moet je een keer je admin wachtwoord invoeren).

Kunt hetzelfde met SCP doen volgens mij;

code:

scp -r username@hostname:/path/from/destination /path/to/destination

Meer info hier.
Zou eea eerst even testen met een kleine map en controlleren of ook daadwerkelijk alles overgezet wordt. . Zou het uiteindelijk per shared folder uitvoeren.

Geen ervaring met rsync, volgens mij kun je daar basically hetzelfde mee doen; https://www.tecmint.com/r...synchronization-commands/ of https://www.computerhope.com/unix/rsync.htm

[ Voor 17% gewijzigd door Tortelli op 05-12-2017 16:11 ]

[Sjeefr]

Nadeel is dat via rsync en diverse, gestart vanaf een externe machine (i.e. je eigen pc), dat de rsync/scp stopt zodra je de ssh-verbinding sluit.


Update: TMUX werkt ook. Heuj. =)

[ Voor 13% gewijzigd door Sjeefr op 05-12-2017 16:45 ]

[MAX3400]

Vilscon schreef op dinsdag 5 december 2017 @ 16:36:
Nadeel is dat via rsync en diverse, gestart vanaf een externe machine (i.e. je eigen pc), dat de rsync/scp stopt zodra je de ssh-verbinding sluit.

Leren lezen helpt ook? Zowel in dit topic als in de handleiding van beide Synology staat duidelijk dat je met Putty (of een ander programma) moet inloggen op de Synology zelf.

Daar start je rsync of een ander proces. Dan kan je daarna bij wijze van spreken je Mac verkopen; zolang de 2 Syno's aan staan, blijven de processen daar dus op draaien.

[Paul]

MAX3400 schreef op dinsdag 5 december 2017 @ 17:52:
Leren lezen helpt ook? Zowel in dit topic als in de handleiding van beide Synology staat duidelijk dat je met Putty (of een ander programma) moet inloggen op de Synology zelf.

Ook dan stoppen child-processes van je SSH-sessie als je deze sluit

M.b.v. tmux (door TS al gevonden) of de oudere `screen` of er simpelweg een & achter te plakken los je dit op.