Flytta många Gb mellan 2 nas (Qnap)?

Permalänk

Flytta många Gb mellan 2 nas (Qnap)?

Hur fasen är det enklast utan att blanda in en stationär burk emellan, båda sitter på samma nät?

Permalänk
Medlem

På synology gör man det via web gui bara.. Genom att logga in via webbläsaren på systemet alltså..
Ja vet inte hur qnap funkar men när du gör det via Windows så går det ju genom din dator... Vilket jag antar att du märkt och därför du gör denna tråden..
Mitt inlägg kanske inte hjälper dig på nåt sätt inser jag nu men confirmar varje fall problemet med att göra det via Windows utforskaren

Skickades från m.sweclockers.com

Visa signatur

Citera för svar!

Permalänk
Medlem

Kan tillägga att jag inte provat själv.

Men du borde kunna använda File station och göra en "Create remote connection" till ditt andra NAS. Som enligt QNAPs dokument.

https://www.qnap.com/en/how-to/tutorial/article/how-to-use-fi...

Historiskt har jag använt FTP to FTP (Kallas även FXP), dvs man kör en FTP klient el dyl och kopierar information mellan deras FTP:er (behövs kanske konfigureras dock)

Permalänk
Medlem

De flesta nas borde ju ha ssh support så jag hade bara sshat in och sen kört rsync i en screen. Så sköter der sig själv.

Så om du vill kopiera en folder till nasen du sshar in till

screen rsync -v -e ssh username@X.X.X.X:/path/to/copy/ /a/path/on/this/nas/

Permalänk
Skrivet av Azathoth:

Kan tillägga att jag inte provat själv.

Men du borde kunna använda File station och göra en "Create remote connection" till ditt andra NAS. Som enligt QNAPs dokument.

https://www.qnap.com/en/how-to/tutorial/article/how-to-use-fi...

Historiskt har jag använt FTP to FTP (Kallas även FXP), dvs man kör en FTP klient el dyl och kopierar information mellan deras FTP:er (behövs kanske konfigureras dock)

Yeep verkar gå via ftp mellan 2 nas så ska kika på det, tack för hjälpen hade inte ens kikat på alla möjligheter via "file station".

Permalänk
Medlem

Den ena kör 'rsync' mot den andre - ofta finns färdiga lösningar för backup eller liknande i NAS mot annan NAS av samma fabrikat och bakom skalet så är det nästan till 100% just rsync som gör jobbet.

Är det mot andra linux/unixbaserade datorer så kanske man får i SSH-terminal manuellt köra rsync mot annan burk och en kommando kan ses liknande

rsync -avPH - i -e ssh användarnamn@192.168.x.x:backupdir1/ /filträd_man_vill_göra_backup_från

(du får söka på 'rsync' vad flaggorna betyder)

Mottagande dator måste ha en ssh-konto för användaren och överföringen går då krypterat mellan och relativt processorsvaga NAS och kanske inte stöd för HW-kryptering så kan man inte räkna med någon högre hastighet utan i området 10 - 30 MByte/s. rättigheterna är samma som användarkontots rättigheter.

Fördelen med ssh är att du med certifikat kan göra scriptad backup utan att behöva passa in passord var gång innan backuppen kommer igång eller att denna finns i klarspråk som variabel i Shell, lika så att köra över publik Internet om den andre NAS:en är åtkomlig den vägen då överföringen är krypterad.

Den andra vägen är att man sätter upp en rsync-demon vilket många NAS stöder att sätta upp i sitt GUI - kan göras lösenordskyddat men överföringen är inte krypterad och därmed inte lämplig att köra utanför sin lokala nät.

där är kommandot modell

rsync -avPH - i -e ssh användarnamn@192.168.x.x::backup1 /filträd_man_vill_göra_backup_från

där 'backup1' är en instans var filerna läggs och bestäms av hur det hela är satt upp i mottagande servern/NAS och likaså vilka rättigheter man ger för läsning och skrivning (dvs en användare kan få rot-rättigheter om så när det gäller att skriva och läsa filer via rsync - så man får tänka sig för och inte öppna dörrar i onödan säkerhetsmässigt).

notera skillnaden mellan ':' och '::' i adresseringen då de ger olika beteenden

---

varför rsync?

Jo den är smart och skrevs vid tiden när man flyttade över data via modem och därmed väldigt långsamt - fokus lades på att inte skicka mer data än nödvändigt för att synka direktory-trän, vilket gör att förutom att kolla tidstämplar (och skippa de som är samma tid om man inte använder flaggan '-c'), sändande och mottagande burken kör rullande checksummor på sina respektive filer på var sin sida och summorna skickas mellan och är det bitar som skiljer så skickar man bara de bitar som behöver uppdateras - dvs jättestora filer patchas på plats utan att hela filen behöver sändas om igen.

dvs är det jättestor databasbas fil där bara några poster ändrats sedan förra synkningen - så skickas bara ändringarna över för uppdatering - inte hela filen igen.

Man kan få rsync att ta bort filer som är borttagna på sändsidan om man passar in flaggan '--delete' - men var försiktig, man kan snabbt haverera väldigt mycket filer på ingen tid alls om man missar en 'direktory/' och det blev 'direktory' i kommandoraden - har man NAS där man kan göra snapshot - använd denna _innan_ man provar att köra rsync med modifierad kommandorad på en befintlig uppsättning filer på mottagande sida.

Precis som många andra Unix och Linux kommandoradsverktyg så är de skarpa och väldigt bra på det som de är gjorda för och man blir snabbt blodig och massiva mängder förlorad data på mycket kort tid om man inte har riktig koll på hur man använder dem... det är ingen som lägger fingrarna mellan om man klantar sig!!

Permalänk
Skrivet av xxargs:

Den ena kör 'rsync' mot den andre - ofta finns färdiga lösningar för backup eller liknande i NAS mot annan NAS av samma fabrikat och bakom skalet så är det nästan till 100% just rsync som gör jobbet.

Är det mot andra linux/unixbaserade datorer så kanske man får i SSH-terminal manuellt köra rsync mot annan burk och en kommando kan ses liknande

rsync -avPH - i -e ssh användarnamn@192.168.x.x:backupdir1/ /filträd_man_vill_göra_backup_från

(du får söka på 'rsync' vad flaggorna betyder)

Mottagande dator måste ha en ssh-konto för användaren och överföringen går då krypterat mellan och relativt processorsvaga NAS och kanske inte stöd för HW-kryptering så kan man inte räkna med någon högre hastighet utan i området 10 - 30 MByte/s. rättigheterna är samma som användarkontots rättigheter.

Fördelen med ssh är att du med certifikat kan göra scriptad backup utan att behöva passa in passord var gång innan backuppen kommer igång eller att denna finns i klarspråk som variabel i Shell, lika så att köra över publik Internet om den andre NAS:en är åtkomlig den vägen då överföringen är krypterad.

Den andra vägen är att man sätter upp en rsync-demon vilket många NAS stöder att sätta upp i sitt GUI - kan göras lösenordskyddat men överföringen är inte krypterad och därmed inte lämplig att köra utanför sin lokala nät.

där är kommandot modell

rsync -avPH - i -e ssh användarnamn@192.168.x.x::backup1 /filträd_man_vill_göra_backup_från

där 'backup1' är en instans var filerna läggs och bestäms av hur det hela är satt upp i mottagande servern/NAS och likaså vilka rättigheter man ger för läsning och skrivning (dvs en användare kan få rot-rättigheter om så när det gäller att skriva och läsa filer via rsync - så man får tänka sig för och inte öppna dörrar i onödan säkerhetsmässigt).

notera skillnaden mellan ':' och '::' i adresseringen då de ger olika beteenden

---

varför rsync?

Jo den är smart och skrevs vid tiden när man flyttade över data via modem och därmed väldigt långsamt - fokus lades på att inte skicka mer data än nödvändigt för att synka direktory-trän, vilket gör att förutom att kolla tidstämplar (och skippa de som är samma tid om man inte använder flaggan '-c'), sändande och mottagande burken kör rullande checksummor på sina respektive filer på var sin sida och summorna skickas mellan och är det bitar som skiljer så skickar man bara de bitar som behöver uppdateras - dvs jättestora filer patchas på plats utan att hela filen behöver sändas om igen.

dvs är det jättestor databasbas fil där bara några poster ändrats sedan förra synkningen - så skickas bara ändringarna över för uppdatering - inte hela filen igen.

Man kan få rsync att ta bort filer som är borttagna på sändsidan om man passar in flaggan '--delete' - men var försiktig, man kan snabbt haverera väldigt mycket filer på ingen tid alls om man missar en 'direktory/' och det blev 'direktory' i kommandoraden - har man NAS där man kan göra snapshot - använd denna _innan_ man provar att köra rsync med modifierad kommandorad på en befintlig uppsättning filer på mottagande sida.

Precis som många andra Unix och Linux kommandoradsverktyg så är de skarpa och väldigt bra på det som de är gjorda för och man blir snabbt blodig och massiva mängder förlorad data på mycket kort tid om man inte har riktig koll på hur man använder dem... det är ingen som lägger fingrarna mellan om man klantar sig!!

Tack för ett långt svar, jo ssh finns på båda men gick köra ftp rakt av emellan båda. Jäkligt enkelt då jag inte ska kopiera allt utan endast vissa kataloger.

Tackar tackar alla.

Permalänk
Medlem
Skrivet av xxargs:

Den ena kör 'rsync' mot den andre - ofta finns färdiga lösningar för backup eller liknande i NAS mot annan NAS av samma fabrikat och bakom skalet så är det nästan till 100% just rsync som gör jobbet.

Är det mot andra linux/unixbaserade datorer så kanske man får i SSH-terminal manuellt köra rsync mot annan burk och en kommando kan ses liknande

rsync -avPH - i -e ssh användarnamn@192.168.x.x:backupdir1/ /filträd_man_vill_göra_backup_från

(du får söka på 'rsync' vad flaggorna betyder)

Mottagande dator måste ha en ssh-konto för användaren och överföringen går då krypterat mellan och relativt processorsvaga NAS och kanske inte stöd för HW-kryptering så kan man inte räkna med någon högre hastighet utan i området 10 - 30 MByte/s. rättigheterna är samma som användarkontots rättigheter.

Fördelen med ssh är att du med certifikat kan göra scriptad backup utan att behöva passa in passord var gång innan backuppen kommer igång eller att denna finns i klarspråk som variabel i Shell, lika så att köra över publik Internet om den andre NAS:en är åtkomlig den vägen då överföringen är krypterad.

Den andra vägen är att man sätter upp en rsync-demon vilket många NAS stöder att sätta upp i sitt GUI - kan göras lösenordskyddat men överföringen är inte krypterad och därmed inte lämplig att köra utanför sin lokala nät.

där är kommandot modell

rsync -avPH - i -e ssh användarnamn@192.168.x.x::backup1 /filträd_man_vill_göra_backup_från

där 'backup1' är en instans var filerna läggs och bestäms av hur det hela är satt upp i mottagande servern/NAS och likaså vilka rättigheter man ger för läsning och skrivning (dvs en användare kan få rot-rättigheter om så när det gäller att skriva och läsa filer via rsync - så man får tänka sig för och inte öppna dörrar i onödan säkerhetsmässigt).

notera skillnaden mellan ':' och '::' i adresseringen då de ger olika beteenden

---

varför rsync?

Jo den är smart och skrevs vid tiden när man flyttade över data via modem och därmed väldigt långsamt - fokus lades på att inte skicka mer data än nödvändigt för att synka direktory-trän, vilket gör att förutom att kolla tidstämplar (och skippa de som är samma tid om man inte använder flaggan '-c'), sändande och mottagande burken kör rullande checksummor på sina respektive filer på var sin sida och summorna skickas mellan och är det bitar som skiljer så skickar man bara de bitar som behöver uppdateras - dvs jättestora filer patchas på plats utan att hela filen behöver sändas om igen.

dvs är det jättestor databasbas fil där bara några poster ändrats sedan förra synkningen - så skickas bara ändringarna över för uppdatering - inte hela filen igen.

Man kan få rsync att ta bort filer som är borttagna på sändsidan om man passar in flaggan '--delete' - men var försiktig, man kan snabbt haverera väldigt mycket filer på ingen tid alls om man missar en 'direktory/' och det blev 'direktory' i kommandoraden - har man NAS där man kan göra snapshot - använd denna _innan_ man provar att köra rsync med modifierad kommandorad på en befintlig uppsättning filer på mottagande sida.

Precis som många andra Unix och Linux kommandoradsverktyg så är de skarpa och väldigt bra på det som de är gjorda för och man blir snabbt blodig och massiva mängder förlorad data på mycket kort tid om man inte har riktig koll på hur man använder dem... det är ingen som lägger fingrarna mellan om man klantar sig!!

Håller helt med. Rsync över SSH alla dagar i veckan. Gör själv samma sak nu mellan två QNAPs på distans. 15TB totalt, har stått på i två veckor hittills för den initiala synken.

Fattar inte att folk fortfarande kör med FTP. Känns lite som 1800-talet. Högst osäkert protokoll.

GUIDE: https://www.techandme.se/qnap-and-rsync/

Visa signatur

Citera för svar

Stora Owncloud/Nextcloud-tråden: http://www.sweclockers.com/forum/122-server/1212245-officiell...
Jobb: Datacenter Manager
Grundare: https://www.hanssonit.se

Permalänk
Hedersmedlem

En annan lösning kan vara att köra iSCSI så länge ena enheten har iSCSI Target och den andra kan fungera som klient. Enligt mina erfarenheter av iSCSI är det ett mycket effektivt protokoll för filöverföring om det är stora mängder data.

Visa signatur

SWECLOCKERS.COM :: If Quake was done today ::
WS: Gigabyte Z690 UD DDR5 :: Core i5 12600K :: 32 GB RAM :: Geforce RTX 3060 Ti :: 10 GbE NIC :: AOC C32G1 32" :: Seagate FireCuda 530 1TB :: Deepcool Matrexx 55
NAS: SM X10-SLM-F :: Mellanox Connect2X SFP+ :: Intel XL710-QDA1 QSFP+

Permalänk
Medlem

Jo iSCSI kan förvisso använda - men ISCSI-enheter är virtuella diskar över nätverkskoppling som bara en dator i tagen kan använda (som i sin tur kan formateras med valfritt filsystem - om ISCSI monteras mot en widowsdator så formateras det oftast som NTFS) och är inte en lösning för publik åtkomst för många olika klienter samtidigt ala NAS då det är bara en OS i taget som får tillåtas att rota på disken.