Källanvändarens problem var inte bara att ”två ZimaOS-enheter inte kan kopiera data”. De flyttade ungefär 600 GB mellan system som körde ZimaOS 1.5.x, och Files-överföringen avbröts upprepade gånger med meddelandet ”host is down”, trots att båda servrarna fortfarande var online.
Det historiska beteendet bör skiljas från aktuella ZimaOS. IceWhale rekommenderar nu uttryckligen LAN Storage i Files när data flyttas från en annan NAS, medan den aktuella Backup-appen kan använda en annan Zima-enhet som mål och erbjuder återupptagbara, feltåliga jobb. För en mycket stor överföring väljer du metod utifrån om du vill ha en engångskopia som syns direkt, en återupptagbar skyddsuppgift eller den snabbaste fysiska flytten.
Källans filöverföring återställdes upprepade gånger medan båda värdarna förblev online
Användaren försökte i båda riktningarna: skicka från den gamla ZimaOS-enheten och hämta från den nya. I båda fallen stoppades det webbläsarbaserade Files-arbetsflödet till slut, trots att källans instrumentpanel fortfarande gick att nå.
Gemenskapen rekommenderade rsync som det mest återupptagbara CLI-alternativet
Ett svar från gemenskapen föreslog rsync över SSH med stöd för delvisa överföringar, så att en avbruten kopiering kunde köras igen utan att börja om. Det är användbar avancerad vägledning, men den publicerades inte av IceWhale-personal, och källanvändaren bekräftade inte att den användes.
Aktuell vägledning från IceWhale använder fortfarande Files för NAS-till-NAS-migrering
Aktuell ZimaOS-dokumentation rekommenderar att den gamla NAS-enheten läggs till som LAN Storage i Files och att mappar kopieras till den nya ZimaOS-lagringen. Det innebär att tidsgränsfelet i 1.5.x inte bör generaliseras till att man ”aldrig ska använda Files för stora migreringar”.
Använd det aktuella migreringsarbetsflödet med LAN Storage för en vanlig synlig kopiering.
Aktuell Backup kan använda en annan Zima-enhet som mål
För långvariga överföringar där möjligheten att återuppta är viktigare än att manuellt bläddra i målet har den aktuella Backup-appen stöd för en annan Zima-enhet som destination. IceWhale beskriver schemaläggning, förlopp i realtid, återupptagning och feltålighet.
Se det aktuella återupptagbara Zima-till-Zima-backuparbetsflödet.
SMB är ett enkelt alternativ till webbläsarbaserad kopieringslogik
Källans gemenskap rekommenderade också att källans SMB-utdelning monteras på destinationen och att kopieringen görs från destinationssidan. Användaren hade tidigare lyckats flytta data från en äldre NAS till ZimaOS med monterade SMB-utdelningar.
En USB- eller NVMe-enhet kan vara snabbast när enheterna står nära varandra fysiskt
För hundratals gigabyte eller flera terabyte kan en snabb extern SSD/NVMe eliminera alla nätverksrelaterade variabler. Nackdelen är två kopieringssteg: först från källan till den externa enheten och sedan från den externa enheten till destinationen.
Många små filer kan få migreringen att verka mycket långsammare
AppData, miniatyrbilder, sidofiler för foton, kodträd och andra metadataintensiva dataset kan flyttas betydligt långsammare än stora mediefiler, eftersom varje fil kräver åtgärder för öppning, skapande och metadata.
Verifiera innan du tar bort källan
Efter en migrering bör du jämföra representativa mappar och, när det är praktiskt möjligt, antalet filer samt öppna viktiga filer på destinationen. Behåll källan intakt tills den nya enheten har använts utan problem och en säkerhetskopia finns.
Files och Backup löser olika migreringsbehov
Files är det tydligare valet när du vill bläddra i källan, välja specifika mappar och omedelbart se de kopierade filerna på destinationen. Backup är bättre när överföringen förväntas pågå i timmar eller dagar och du värdesätter återupptagning, feltålighet, schemaläggning och en återställningsbar aktivitetshistorik.
Beskriv inte ett Backup-jobb som en transparent ”flytt”. Det skapar en skyddad kopia med egna återställningsregler. Bekräfta destinationsstrukturen innan du tar bort källan.
Kontrollera nätverksvägen innan du optimerar kopieringsverktyget
På en nominell 1 GbE-länk bör du kontrollera att båda maskinerna faktiskt har förhandlat fram Gigabit Ethernet, att ingen Wi-Fi- eller 100 Mb/s-segment ingår och att switch och kablage fungerar korrekt. Ett kopieringsverktyg kan inte överträffa en långsam fysisk länk.
Testa sedan med en stor fil. Om en stor fil överförs snabbt men ett katalogträd är långsamt är det troligen datasetets filantal och metadataomkostnader som spelar större roll än den råa nätverksbandbredden.
Användarfiler och aktiva AppData kräver olika hantering
Filmer, foton och dokument kan vanligtvis kopieras som vanliga filer. Aktiva programdatabaser och AppData kan kräva att programmet stoppas, exporteras eller migreras med programanpassade metoder så att kopian blir internt konsekvent.
Utgå inte från att en kopiering av en aktiv databaskatalog mellan två enheter ger en giltig program migrering.
Bevara eller återskapa delningsbehörigheter medvetet
Även när varje byte kommer fram har destinationsenheten med ZimaOS egna användare, delningsdefinitioner och containermappningar. Återskapa de Samba-behörigheter och appsökvägar för volymer som krävs och testa sedan åtkomsten som den avsedda användaren utan administratörsbehörighet.
Använd en övergång i två faser för viktiga data
Vid en stor aktiv NAS-migrering kopierar du först huvuddatan medan den gamla enheten fortfarande är aktiv. Inför övergången stoppar eller pausar du skrivningar, kör en sista inkrementell/återupptagbar kopiering, verifierar destinationen och byter sedan klienterna till den nya enheten. Det minskar driftstoppet och förhindrar att den enda fungerande kopian tas bort för tidigt.
Vanliga frågor om migrering mellan ZimaOS-enheter
Bevisade källan att Files alltid är opålitligt vid stora kopieringar?
Nej. Den dokumenterade ett fel i 1.5.x. Aktuell vägledning från IceWhale använder fortfarande Files/LAN Storage för NAS-migrering.
Vilket aktuellt alternativ stöder återupptagbara överföringar mellan Zima-enheter?
Den aktuella Backup-appen kan använda en annan Zima-enhet som mål och har stöd för återupptagning och feltålighet.
Var rsync den bekräftade slutliga metoden som källanvändaren använde?
Nej. rsync var ett råd från gemenskapen. Användaren uppgav senare att migreringen var klar utan att dokumentera den slutliga överföringsmetoden.
