"How to" migreren van data van een 1815+ naar een 1821+

[Pipo10]

Heb zojuist een nieuwe DS1821+ met 4x16Tb operationeel gemaakt.
Nu heb ik wat vragen waar bij jullie mij misschien op weg kunnen helpen.

1.Kan ik de DSM  configuratie backup van de 1815 op de 1821 zetten, hoef ik dan niet alle mappen en gebruikers opnieuw te configureren?
De 1821 wordt de hoofd machine en de 1815 de backup machine. De 1815 wil ik zijn oude naam laten houden en de nieuwe krijgt een nieuwe naam, kun je dan de DSM configuratie terug zetten op de 1821

2. Welke software kan ik het best gebruiken om de data van de 1815 naar de 1821 te copieeren?
Edit: Getest met Map synchronisatie.  Wat ik nog niet doorzie, als ik van de bron 1815 naar doel 1821 ga, kan ik daarna de 1821 dan als nieuwe bron bebruiken. Geeft dit geen map autorisatie problemen.
Edit: Of is migration assistant dan een beter optie om de eerste kopie slag te maken van 1815->1821?

3. Kan ik de van de vier 1Gb LAN poorten, op beide machines, een bond van maken naar elkaar, zodat de copier slag over 4 poorten tegelijk gaat.
Immers beide systemen draaien op linux die een bond met 4 x zo hoge data doorvoer accepteren.
edit:met gedeelde map syncronisatie een paar mappen gecopieerd, een bond geeft nog steeds 1Gb   

4. de 1815 heeft 4x12TB en 2x4TGB disken. de 2x4TB zijn al 6 jaar oud en die wil ik eruit halen.
Kan ik nadat de data gecopieerd is naar de 1821 de 2 disken van 4TB uit de 1815 halen. Daarna opnieuw fabrieks reset doen, DSM Config terug schrijven en daarna de kopieer slag van de 1821 naar de 1815 opstarten?

Hoop dat jullie wat tips hebben
Vast dank hiervoor.

edit 1x
edit GB->TB

[Pipo10]

Helaas erg stil op het forum, met hulp 

Ben ondertussen met migratie assistent begonnen
Eerst 1,5 dag een SHR1 aangemaakt.
Migratie opgestart geen enkel probleem alles loopt als een zonnetje
Proces bestaat uit 4 stappen na 3 dagen en 11 uur zijn de 29TB gemigreerd en is hij met punt 3 begonnen, overzetten van de parameters
Helaas na 5 minuten "migration failed" message neem contact op met technisch support 
Verder in geen enkele log iets te vinden geen message geen code 

Zondag ticket aangemaakt vanmorgen om 5:36 antwoord, vraag allebij de Nassen openzetten voor inloggen.
Kan van mijn 1815 niet de 2 traps verificatie uitzetten omdat de migratie nog loopt. Software wise restarten of uitzetten gaat niet, hij zegt dat ie druk is met migreren.
Wil de migratie op de 1821 nog niet cancellen, ben dan ook mijn volume waar ik 1,5 dag over heb gedaan om te maken kwijt zegt ie 
Eerst afwachten wat support zegt...

Heb om een representative in regio CET gevraagd, op deze manier duurd iedere vraag/antwoord 24 uur.
 

[zandhaas]

OK,

Punt 1, 2 en 3 zijn dus al lopende.
Ben wel benieuw wat Synology zegt.

Wat punt 4 betreft kun je inderdaad op de manier die jij aangeeft die oude disken verwijderen.
Ik neem alleen aan dat het TB disken zijn en geen GB disken 

[Pipo10]

Na een week wachten is er werkelijk niets gebeurd aan mijn ticket.
Afgelopen zondag middag ticket aangemaakt op maandag 5:30 is hij op gepakt.
Moest de beide NAS'sen toegankelijk maken van buiten af en de SSH openzetten, plus admin password gegeven.

Heb alleen de standaard migratie assistent gebruikt op twee look allikes met ieder 6 disken erin.
Al het voor werk gelezen beide zijn ondersteund en had geen problemen verwacht
Proces loopt stuk zonder enige melding na 3 dagen en bijna 12 uur.

Het enige wat je te horen krijg is verontschuldigingen dat ze het erg druk hebben met calls en verontschuldigingen voor het feit dat ze in Taiwan GMT+8 zijn.
Dit houdt in dat als wij gaan slapen zij rond 24u beginnen en als wij opstaan zij naar huis zijn.
De meest simpele vraag kost dus 24 uur en er gebeurd visueel niet veel heb ze wel eens ingelogd gezien op SSH maar respons ho maar. Afgelopen 36uur geen enkele beweging meer.
Nog gevraagd of er niet ergens anders op de wereld met een geschiktere tijdzone een support centrum was maar geen respons.

Hoop dat jullie de support desk zo min mogelijk nodig hebben, want veel lol zul je er niet van hebben.

een bedroefde Synology gebruiker

[Pipo10]

BEDROEFEND.   

Vanaf 11 maart 03:05 geen enkele respons meer voor mijn ticket vanuit taiwan.
In totaal loopt de migratie nu 12 dagen, na 3,5 dag is het proces gefailed.
Support heeft af en toe ingelogd, het proces lijkt wel weer op gang geholpen te zijn door support vanuit de situatie "failed"
Echter staat hij al 4,5 dag in een scherm met de vraag wat ik verder wil doen.
Wilde wachten op wat support zou aangegeven, om hoe nu verder gegaan moet worden, maar geen enkele respons.

"Life verslag"
Heb zo juist het proces "opnieuw starten vereist" toch maar doorgestart, met de optie laat de processen op de bron NAS maar lopen.
Hij is nu bezig met controle gegevensconsistentie.
(je mocht de source NAS gewoon blijven gebruiken (ik heb niet geschreven op de source nas) ,ik neem aan dat hij nu kijkt of ik nog geschreven heb op de Source NAS. Zo ja dan doet hij dat ook nog update'n)

Consistentie controle is na 20 minuten klaar
De nieuwe Bron NAS start nu opnieuw op, dit opstarten duurde 10 minuten
Kan weer inloggen op beide NAS'sen  eindelijk na 12 dagen.

Ga nu alles controleren.
 

[Birdy]

Zo te lezen is het probleem wel goed opgelost.
Wel jammer dat de communicatie slecht was.
Ik heb die ervaring niet gehad, tot dusver.

[Pipo10]

Ik kan wel zeggen dat ik nog een parallel ticket in nederland heb geopend waarbij stond dat het lang kon duren maar zij reageren binnen een uur.
Ze wilde alleen niet de taiwan ticket overnemen alleen als het nog dagen stil zou blijven..

Ben nm wel benieuwd wat de root cause is van het vast lopen van de migratie job

[Pipo10]

Dan eindelijk toch na 5 dagen antwoord... Hij had vrij..

Maar goed ik lees nu dat de mogelijke oorzaak van het vastlopen van het migratie proces gekomen is door een mis match van  het SSH poort nummer tussen Source en Target NAS. Maar het is mij niet duidelijk of dit het origenele probleem was of dat dit probleem ontstaan is tijdens de ticket afhandeling toen support op mijn beide NASsen hadden ingelogd en het vast gelopen proces weer hadden vlot getrokken.

Jaren terug had ik op de oude NAS ook een ticket gemaakt en de SSH poort aangepast van 22 naar 2111
Op de nieuwe NAS zal deze nog wel standaard gestaan hebben op 22.
Wat ik niet helemaal begrijp is of deze poort ook tijdens het migratie proces gebruikt wordt, of alleen voor remote access.
Tijdens de migratie waren ze 2111 en 22 maar tijdens remote inloggen van support stonden ze beide op 2111
Wel vervelend dat het pas na 3,5 dag migratie boven water komt en dat dat niet gechecked wordt bij aanvang of in de voorbereiding staat geschreven.

[Birdy]

Maar goed ik lees nu dat de mogelijke oorzaak van het vastlopen van het migratie proces gekomen is door een mis match van  het SSH poort nummer tussen Source en Target NAS.

De enige relatie die ik kan vinden in de procedure is:

De volgende handelingen kunnen tijdens het migratieproces NIET worden uitgevoerd:
Het uitschakelen van de SSH-service op het bronapparaat.

Hieruit begrijp ik dat SSH nodig is voor de Migration Assistant methode.

Dus, ik begrijp uit het verhaal van Synology, dat als de SSH poort van de Source afwijkt van de Target, dat het niet gaat werken.
M.a.w., ik zie dit als een bug in de Migration Assistant software of ze moeten duidelijk vermelden dat de SSH poorten gelijk moeten zijn.

[Pipo10]

Ben het met je eens.
Toen de migratie begon had hij nog een opmerking over een test folder op de target die moest eraf, dat heb ik gedaan. Kortom hij checked één en ander. Maar blijkbaar niet de SSH poorten op beide.
Of checken of beschrijven in de setup van de migratie zou ik denken.

Als je op je NAS de Secutity Advisor draait stelt die voor dat je de SSH poort veranderd en niet op 22 laat staan.
Op mijn oude NAS was dat gebeurd.
Maar op de nieuwe NAS heb ik niet veel gedaan alleen het Volume aangemaakt en nog geen Security advisor gedraait. Ben eerst begonnen met de migratie.

[Briolet]

Ik ben ook niet zo'n fan van het aanpassen van standaard poorten. Voor je het weet zit je jezelf in de weg omdat je dit vergeten bent, of omdat je een keer software gebruikt die perse de standaard poorten wil gebruiken.

Ik beperk de toegang liever via de firewall.

[Pipo10]

Blijkt ook naar aanleiding van mijn verhaal, de betere keuze.