Kopiera Array på 14TB från en dator till en annan

Permalänk
Medlem

Kopiera Array på 14TB från en dator till en annan

Något bra tips på ett bra sätt att kopiera filer från en array på en dator till en array på en anan dator, massvis med filer, stora som små, totalt ca 12TB. Sist jag gjorde något liknande var det xcopy som gällde (som man fick köra fler ggr). Något annat inbyggt trevligt i windows 10 med verifiering eller är det bättre med någon tredjepartsmjukvara?

Källan, är skröplig och kraschar lite då och då, dessutom har jag en tvåkärnig Celeron på den så helst vill jag undvika last på den, någon mjukvara går väl att installera men inte om den kör komprimering på CPU.

Permalänk
Rekordmedlem

Använd backupen Det var förresten tips på 14 TByte hdder i fyndtråden, perfekt tillfälle att göra backup till en sådan för att sedan återställa den på den nya datorn.
Om du inte har en sån är det antagligen snabbast att temporärt flytta diskarna så du kan köra datan med sata fart så sparar du nått dygn i kopieringstid.

Visa signatur

R5 5600G, Asus ROG STRIX X470-F Gaming, WD SN850X 2TB, Seasonic Focus+ Gold 650W, Aerocool Graphite v3, Tittar på en Acer ET430Kbmiippx 43" 4K. Lyssnar på Behringer DCX2496, Truth B3031A, Truth B2092A. Har också oscilloskop, mätmikrofon och colorimeter.

Permalänk
Quizmaster Göteborg 2023

rsync är vägen att gå

Permalänk
Medlem

Ska testa gamla hederliga SyncToy, fungerar inte det blir det rsync. Har problem att skapa Storage Spaces av mina 4st 8TB drives och 1st 500GB Samsung 860 Pro. Datat finns ingen backup av som helhet, mycket är förlorbart, resten synkas till molnet.

Permalänk
Tangentbordskonnässör

Jag skulle köra rsync genom windows linux terminal, det har fungerat klockrent för mig.
Alla windows forkar av rsync har alltid strulat tyvärr.

Nu har jag kontinueliga backups var 5e min mellan mina maskiner med rsync, men initialt var det drygt 4TB som skulle flyttas, vilket gick smärtfritt!

Permalänk
Medlem
Skrivet av huttala:

Jag skulle köra rsync genom windows linux terminal, det har fungerat klockrent för mig.
Alla windows forkar av rsync har alltid strulat tyvärr.

Nu har jag kontinueliga backups var 5e min mellan mina maskiner med rsync, men initialt var det drygt 4TB som skulle flyttas, vilket gick smärtfritt!

Finns det en guide för idioter som jag? Var evigheter sedan jag använde rsync.

Permalänk
Tangentbordskonnässör
Skrivet av Mordekai:

Finns det en guide för idioter som jag? Var evigheter sedan jag använde rsync.

Ptja, först måste du ju installera en linux dist från Microsoft Store.
Sedan starta den.

Efter det är de bara att följa tex denna guide:
https://thedatafrog.com/en/articles/backup-rsync-windows-wsl/

Permalänk
Medlem

Freefilesync - enkel o går köra fasta jobb schemalägga MFL samt aktivt underhållen. Synctoy - gammal ej underhållen MFL fel. Xcopy krånglig att komma igång för nybörjaren. Rsync om man kör Linux givetvis.

Permalänk
Medlem

xcopy funkar, varför krångla till det, växeln /z ger "resume" funktionalitet om källan skulle krascha så återupptar den överföringen när anslutningen är tillbaka

https://docs.microsoft.com/en-us/windows-server/administratio...

Visa signatur

3600, 1080ti, predator 27" IPS, Rift

Permalänk
Medlem
Permalänk
Medlem
Skrivet av huttala:

Ptja, först måste du ju installera en linux dist från Microsoft Store.
Sedan starta den.

Efter det är de bara att följa tex denna guide:
https://thedatafrog.com/en/articles/backup-rsync-windows-wsl/

Ja, ok, det känns lite väl mastigt, så bra är inte rsync.

Permalänk
Medlem
Skrivet av bizon:

Oh the memories...

Permalänk
Medlem

Bidrar med denna.
https://www.gurusquad.com/GSRICHCOPY360

Skulle helst ha en client/serverlösning så man slapp sambas seghet.

Permalänk
Medlem

Rsync kan köras i en client-server-roll utan att behöva underliggande SMB eller NFS.

Man konfigurerar upp på serversidan en instans, vilka IP som är tillåtna att använda porten och en enklare passordsförfarande om man vill innan tjänsten kan användas. Säkerheten är inte hög eller att överföringen är krypterad (och passord går i klarspråk och kan sniffas) så det används endast inom LAN eller skyddad VPN-länk mellan burkarna.

från klientsidan kan då kommandot se liknande

'rsync -avPH --delete /media/användare/detmanvillbackupa backup@servernamn::media_1/'

Där 'backup' som användare och 'media_1' är en fördefinierad plats på servern med sin configfil.

Behöver man gå över osäker förbindning så kan rsync arbeta via ssh istället och där används också klient/server-modellen för att minimera mängden överförd data.

en typisk sådan rad jag använder via ssh är 'rsync -avPH -i --delete -e ssh sökväg/till/det/som/skall/backupas backupanvändare@servernamn:/sökväg/backupdir/'

skall man hämta data från en server till lokalt så byter man bara plats på sökvägarna till
'rsync -avPH -i --delete -e ssh backupanvändare@servernamn:/sökväg/backupdir/ sökväg/till/där/det/skall/lagras '

Observera de olika beteende om det är dubbel-kolon eller enkel-kolon

Konfigurerar man upp ssh med certifikat så kan det göras passordslöst för rsync programmet - annars kommer frågan om passord upp för kontot var gång man försöker köra detta.

faktum är att rsync alltid kör klient/server även om det är på samma dator och mellan 2 diskar, men är då att programmet delar (forkar) sig i två delar där ena har klientrollen och den andra server-rollen i filhanterandet.

rsync har massor av saker och tex. med

rsync -vtrp -0 --remove-source-file --compare-dest=/master_filträd /direktory_man_vill_tömma /dir_för_filer_som_inte_är_lika_mot_master_filträd

dvs. man jämför en filträd mot en master-träd i avsikt för att tömma denna (tex. tömma en disk med gammal backup) - alla filer som är lika med masterträdet raderas och de som är olika hamna i mappen '/dir_för_filer_som_inte_är_lika_mot_master_filträd'

En sak att ha klart för sig 'rsync' är mycket kraftfullt men det kan bli mycket blodigt om man gör fel, -speciellt om man har flaggan '--delete' i kommandoraden - klassiska felet är med eller utan '/' i slutet av varje sökväg och det hinner radera väääldigt många filer per sekund om man gör fel - prova gärna med '--dry-run' först eller om man har filsystem som BTRFS/ZFS - gör en snapshot först - prova sedan.

rmlint kan göra liknade saker i avsikt att leta filer (för senare radering) med samma innehåll och där hashar allt medans ovanstående med rsync jämför bara fildatum och storlek (och rätt plats inom filträdet) såvida man inte använder flaggan '-c' - då gås varenda fil igenom med både rullande hash och hashvärden innan det tas bort något - men det är tungt då alla filer måste läsas fullständigt igenom på båda sidor.

rmlint gör samma sak men där kan man få den att spara tidstämpel och hashvärde som xattr (i linuxfilsystem) för varje fil och vid nästa körning så används den redan beräknade hashvärdet (blake2) för jämförelse - är det 8TB då är det från över dygns körning till under 5 minuter för att jämföra två mappträn som är körd minst 1 gång av rmlint och med flaggorna -C -U, jo en sak till, xattr-värdena följer med även i BTRFS snapshot - att jämföra 2 snapshot mot varandra går då rätt fort - att bashfilen som sedan raderar den ena snapshotet man vill tömma kan dock ta lite tid, speciellt om det är > 8TB stor och över 4 miljoner filer i denna.

en typisk rad för att verifiera en backupdisk äldre version mot nyare version av backup är

rmlint -U -C -T df -g -r -b -m -k dir_som_skall_tömmas // dir_att_jämföra_med_rörs_ej

med detta så om man kör bildade scriptet' så töms "dir_som_skall_tömmas" alla filer som finns som identisk exemplar någonstans i "dir_att_jämföra_med_rörs_ej" - detta oavsett trädstruktur på respektive sidan - det som är efter '//' är skyddade filträd och inget raderas där även om det finns många likadana filer inom filträden.

not: rmlint raderar inga filer när det körs - den skapar shellscript som sedan när det körs kan radera filer, deduplicera filer med mjuka eller hårda länkar och på BTRFS filmässig deduplicering med 'clone' och '--reflink' om filerna ligger på samma disk/filsystem.

Permalänk
Medlem
Skrivet av xxargs:

Rsync kan köras i en client-server-roll utan att behöva underliggande SMB eller NFS.

Man konfigurerar upp på serversidan en instans, vilka IP som är tillåtna att använda porten och en enklare passordsförfarande om man vill innan tjänsten kan användas. Säkerheten är inte hög eller att överföringen är krypterad (och passord går i klarspråk och kan sniffas) så det används endast inom LAN eller skyddad VPN-länk mellan burkarna.

från klientsidan kan då kommandot se liknande

'rsync -avPH --delete /media/användare/detmanvillbackupa backup@servernamn::media_1/'

Där 'backup' som användare och 'media_1' är en fördefinierad plats på servern med sin configfil.

Behöver man gå över osäker förbindning så kan rsync arbeta via ssh istället och där används också klient/server-modellen för att minimera mängden överförd data.

en typisk sådan rad jag använder via ssh är 'rsync -avPH -i --delete -e ssh sökväg/till/det/som/skall/backupas backupanvändare@servernamn:/sökväg/backupdir/'

skall man hämta data från en server till lokalt så byter man bara plats på sökvägarna till
'rsync -avPH -i --delete -e ssh backupanvändare@servernamn:/sökväg/backupdir/ sökväg/till/där/det/skall/lagras '

Observera de olika beteende om det är dubbel-kolon eller enkel-kolon

Konfigurerar man upp ssh med certifikat så kan det göras passordslöst för rsync programmet - annars kommer frågan om passord upp för kontot var gång man försöker köra detta.

faktum är att rsync alltid kör klient/server även om det är på samma dator och mellan 2 diskar, men är då att programmet delar (forkar) sig i två delar där ena har klientrollen och den andra server-rollen i filhanterandet.

rsync har massor av saker och tex. med

rsync -vtrp -0 --remove-source-file --compare-dest=/master_filträd /direktory_man_vill_tömma /dir_för_filer_som_inte_är_lika_mot_master_filträd

dvs. man jämför en filträd mot en master-träd i avsikt för att tömma denna (tex. tömma en disk med gammal backup) - alla filer som är lika med masterträdet raderas och de som är olika hamna i mappen '/dir_för_filer_som_inte_är_lika_mot_master_filträd'

En sak att ha klart för sig 'rsync' är mycket kraftfullt men det kan bli mycket blodigt om man gör fel, -speciellt om man har flaggan '--delete' i kommandoraden - klassiska felet är med eller utan '/' i slutet av varje sökväg och det hinner radera väääldigt många filer per sekund om man gör fel - prova gärna med '--dry-run' först eller om man har filsystem som BTRFS/ZFS - gör en snapshot först - prova sedan.

rmlint kan göra liknade saker i avsikt att leta filer (för senare radering) med samma innehåll och där hashar allt medans ovanstående med rsync jämför bara fildatum och storlek (och rätt plats inom filträdet) såvida man inte använder flaggan '-c' - då gås varenda fil igenom med både rullande hash och hashvärden innan det tas bort något - men det är tungt då alla filer måste läsas fullständigt igenom på båda sidor.

rmlint gör samma sak men där kan man få den att spara tidstämpel och hashvärde som xattr (i linuxfilsystem) för varje fil och vid nästa körning så används den redan beräknade hashvärdet (blake2) för jämförelse - är det 8TB då är det från över dygns körning till under 5 minuter för att jämföra två mappträn som är körd minst 1 gång av rmlint och med flaggorna -C -U, jo en sak till, xattr-värdena följer med även i BTRFS snapshot - att jämföra 2 snapshot mot varandra går då rätt fort - att bashfilen som sedan raderar den ena snapshotet man vill tömma kan dock ta lite tid, speciellt om det är > 8TB stor och över 4 miljoner filer i denna.

en typisk rad för att verifiera en backupdisk äldre version mot nyare version av backup är

rmlint -U -C -T df -g -r -b -m -k dir_som_skall_tömmas // dir_att_jämföra_med_rörs_ej

med detta så om man kör bildade scriptet' så töms "dir_som_skall_tömmas" alla filer som finns som identisk exemplar någonstans i "dir_att_jämföra_med_rörs_ej" - detta oavsett trädstruktur på respektive sidan - det som är efter '//' är skyddade filträd och inget raderas där även om det finns många likadana filer inom filträden.

not: rmlint raderar inga filer när det körs - den skapar shellscript som sedan när det körs kan radera filer, deduplicera filer med mjuka eller hårda länkar och på BTRFS filmässig deduplicering med 'clone' och '--reflink' om filerna ligger på samma disk/filsystem.

Bra utförligt inlägg! Saknar dock source/destination. Kommer dock inte använda det i detta case. Datorn jag kopierar från är på fallrepet och just nu klarar den inte att leverera mer än 200 Mbit/s i snitt över tid från arrayen. Det är en Intel chipset array som sakta efter en mängd systemkrascher återställer sig själv, ligger just nu på 80% initialized. kör synctoy från destinationsdatorn, fungerar men är inte klar förrän om ca 6 dygn.

Permalänk
Medlem

Verkar ofta vara trassel så fort det är (fake) HW-baserade RAID ala inbyggt moderkort eller liknande... - i alla fall om kortet som sådant inte närmar sig 7-8 papp bara den, med RAM-cache, batteri/konding/flash-backup etc. server-kvalitet.

mjukvaru-RAID och användande av LSI-HBA när inte SATA-portarna räcker till i antal verkar mer säker koncept - diskarna går att flytta till annan hårdvara och SATA-baserad RAID går att köa via USB-dockor om så - alla fall i linux-världen.