Kräver det mycket processorkraft att kopiera bilder?

Flyttar du mellan två USB anslutna diskar så brukar jag först kopiera bilderna till datorn som är ansluten och sen föra över till nästa disk. Men ja det brukar gå långsamt att flytta många småfiler mellan externa HDDs

kolla först att det verkligen kör på USB3 och inte degraderat till USB2-körning för att sladdarna inte är 100% - USB2 kan ge max ca 35 MB/s - i linux kan man titta i 'dmesg | less' som root hur de olika USB-kanalerna har initierat sig.

Normal flytt skall inte ta speciellt mycket CPU (normalt DMA-drivet) och i princip flytta upp till 500 MB/s via SATA och USB3 om man kör mot SSD-lagring vid stora filer och till snurrdiskarnas maxhastighet (75 - 300 MB/s - en typisk WD-book/WD-elemen med WD-green diskar ala 2010 -2015 140 - 70 MB/s) vid kopiering av stora filer (flera GB styck) och det även när man kör mellan 2 diskdockor på 2 olika USB-bussar på 2 olika USB-kontroller men kanske 250 MB/s om man kör på samma (en USB-kontroller servar upp till 4 USB-portar/enheter och bandbredden fördelas på alla 4 portar och på en laptop finns minst 2 och ibland 3 USB-controller då kamera, klösbräda, SD-läsare och extra knappar och tangentbordsbakrundbelysning också ofta är USB-enheter internt i laptopen).

Vad fins kvar att testa - eftersom du kör linux så skulle jag installera 'atop' med "apt install atop" och sedan starta den med 'atop -fF 1' på tillräcklig stor terminalfönster (förstora så visas mer info) och ger då 1 sekunds uppdatering - du ser processorlaster individuellt men för kopieringen titta ungefär mitten och som börjar med DSK (disk) och det som är intressant att titta på är 'busy' (som ofta är 100% vid olika diskaktiviteter) och sedan lite lägre till höger dataflöden i MB/s och nästan helt till höger 'avq' (kommandokölängder mot disken) och avio (tid för var kommando som bearbetas)

Och sedan starta kopiering - använd kopiering (cp) och inte 'mv' då man tar inte bort originalet förrän man vet att kopian är OK

Titta sedan i atop på vilka resurser som belastas.

Det som är förväntat är att 'busy' går mot 100%, att antal MB/s för läs och skriv är rimligt högt, att 'avio' ligger på några och ibland enstaka 10-tal ms-området (läs söktiden) - vid skrivning kan kölängden (avq) vara ganska stor i området 10-100 (skrivkön är att disken har tagit emot ett antal skrivkommandon med data som väntar på att skrivas och skrivordningen optimerad för att minimera skriv/läsarmsrörelserna så mycket det går under skrivningen/läsningen)

Det som kan vara intressant är om en enda kärna ligger på 100% hela tiden - NTFS i sin metadatahantering (dvs filsystemet själv) och uppdatering och modifiering av $MFT är enkeltrådat och bränner rätt ordentligt med CPU när det skall skapa och skriva filer, medans läsning går oftast fortare - nu har jag inte senaste linuxen och NTFS kan gå via FUSE fortfarande, men en praktisk skivhastighet att skriva mot NTFS-formaterad disk med stora filer via linux är typ 130-150 MB/s medans läsning går betydligt fortare.

Om disken har läsproblem så ser man det genom att 'avio' sticker iväg i tid - istället för några och kanske någon eller ett par 10-tal ms och lästiden istället är över 50 ms och högre så tyder det på att disken håller på med omläsning av svårläsbar data medans är busy 100%, överföringshastigheten låg räknat i MB/s och avio fortfarande inom några och ett par 10-tal ms så är det nog den krassa orsaken att filerna är hårt fragmenterad i NTFS-filsystemet.

Jag skulle göra detta för ~10 år sen, d.v.s säkerhetskopiera flera hundra gigabyte småfiler.

Jag kopierade från SSD till en disk ansluten till USB3. Det hela gick i skaplig fart tills disken jag kopierade till överhettade i sådan grad så att plattorna* nöp!

Flera år senare "lagade" jag disken genom att bruka så mycket våld som krävdes.

*Lagret antar jag snarare än själva plattorna

Oftast betydligt bättre att lägga småfiler i en större fil med t.ex rar om man skall säkerhetskopiera.
Framförallt USB får ju problem men mängder av filer.

Nej jag knackade bara över centrum på disken så hoppade den igång.

Inte hårt men inte heller obetydligt.

Windows har en del strul att skriva mycket småfiler, i linux kan det vara en faktor mellan 6-10 ggr fortare med ext4/BTRFS i jämförelse med NTFS med riktigt små filer och det är ingen större skillnad mellan windows och Linux när det gäller att skapa samma småfiler på NTFS. kort sagt hanteringen är tung, är enkeltrådad och mycket overhead för var fil som skapas i NTFS, och har du i windows defender aktiv på den driven du skriver till kan det ta mer än dubbla tiden då defender skall 'smaka' på varje fil som skapas...

Är det USB3 så är det en 'bred platt µUSB' liknande https://www.teknikdelar.se/produkt/deltaco-micro-usb-30-2m-sv...

eller (men ganska sällsynt - oftast finns på USB3-diskdockor)

https://www.amazon.se/Cable-Matters-B-kabel-USB-C-svart/dp/B0...

och andra sidan mot datorn är då en USB-A med blå inredning eller USB-C

Är det vanlig mini och micro-USB (5-stifts) som inte är extra platt och bredare (med 9 stift) så går det bara med ca 35 MByte/s (något fortare i Linux) i USB2 (det behövs 2 par/4 extra ledare för att klara +500 MByte/s fart som USB3 jobbar med) och visar datorn mer kapacitet så är det nog felräkning eller att du har NTFS fil och mapp-komprimering påslaget - och då är det inte konstigt om det går trögt då det fragmenterar väldigt mycket (1 fragment per 64kByte) även om filen skrivs sekventiellt. och vid stora filer så kan fragmenten ta slut innan filen är färdigöverförd

- försök inte med komprimerande mode på tex. diskimages med fil och diskkomprimering påslaget under NTFS då en fil kan maximalt ha ca 1.5 miljoner fragment och vid 64k-block (som är NTFS native kompressions-blockstorlek) så tar det stopp vid ca 93 GB storlek före kompression. Detta är NTFS akilles-häl och det går inte att göra något åt det (det var därför MS gjorde ReFS för att kunna hantera större fragmenterade filer men inte gjorde den komplett så att det är dugligt att ha som system och OS-filsystem, tyvärr).

100 MB styck är nog lite lite, området 500 MB - 5 GB är nog bättre eller rentav något under 4.7 GB styck så att det passar att brännas på DVD+/-R(W) skivor för arkivering.

Problemet med zip, rar, 7-zip arkiv - även om den är uppdelad i flera delar så räcker det med 1 bitfel för att allt efter bitfelet inte längre skall vara uppackningsbart då checksummor inte stämmer - uppackningsprogrammet signalerar error och du förlorar datat allt efter felstället.

Det är inte så ofta det händer men när det händer så har du förlorat arkivet, och jag själv har känt på det hårdhänt när det visade sig att jag hade ett RAM-fel i min dator som packade filerna och checksumman stämde inte efter kopiering till ny media, och i en modern OS studsar det runt i flertal buffrar efter skapandet innan det slutligen skrivs på lagringen och mappas RAM-segmentet med felet i sig då och då in i bland i kopieringsprocessen så har man en korrupt arkivfil... - för mig var det typ 1 fel per 1 - 5 GB filstorlek och långt ifrån alla filer utan kanske 5 av 100 st - sådant är jätteirriterande, speciellt när man kört ett halvår på det och man upptäcker försent att somliga av sina backuppfiler är paj...

Några av komprimeringsformaten kan man sätta en flagga så att det är reparerbart (dvs komprimeringsblocken är tydligt avskilda så att avkodningen kan starta på en ny kula efter en felaktig segment med egen checksumma ) så att man inte förlorar allt.

Är det jätteviktiga filer så skulle jag arkivera i TAR utan kompression, där kan bitfel ge att enstaka skador på enskilda filer men hela arkivet ryker inte på samma sätt som med zip, rar, 7zip mfl. om man skulle få bitfel i början av arkiv-filen - nackdelen är att den inte har någon alls integritetskoll på filerna utan det får verifieras på annat sätt.

I linux-världen så är borg-backup en favorit-arkiverare så det både deduplicerar och komprimerar samt att bitarna lagras i chunk och allt är checksummat i små segment - visst korrupt fil/chunk ger konsekvenser även där men man förlorar inte allt och det är reparerbar - speciellt om man någonstans har orginalfilerna kvar någon annan stans så kan det reparera skadorna för alla upplagor av sessioner som finns inom arkivet.