Byte av hårddisk - full kopiering, köpråd mm.

Beroende på hur gammal och nära det är att disken ger upp kan det vara bra att ta det i etapper. Kör du all in på 3TB så kan det stressa disken att den dör innan det blir klart. Är det bara att du känner att det är dags kanske det inte är någon fara.

Robocopy i terminalen.

Med /mir för mirror

Men se mer på https://learn.microsoft.com/en-us/windows-server/administrati...

Använd en filhanterare där du kan pausa överföringen (typ Total Commander - finns säkert andra också för samma funktion), när det börja gå trögt så pausa runt en halvtimme och sedan kan du starta igen tills det går trögt igen - MS file-explorer har tyvärr inte den funktionen att kunna pausa när du väl har 'släppt mappen' på mottagande lagringen.

alternativt att kolla att mappträdet du släpper över inte är så stora räknat i antal GB eller i antal filer och tar det pö om pö.

Det är vid massor av småfiler i stora batcher som kommer vara bekymmer att det vill gå långsamt ganska snart medans stora filer som skrivs sekventiellt brukar fungera bättre. - och det har att göra i hur NTFS skriver och dess skrivordning av uppdateringar av metadatat mot disken som gör att det fungerar så illa med SMR-diskar.

---

Kör man icke MS-filsystem som BTRFS i Linux så stöter man nästan aldrig på problemet att det går långsamt med SMR-diskar, så det är i hög grad filsystemsberoende om SMR-disk är ett bekymmer eller inte.

Dessutom kan man i BTRFS slå på att den automatisk komprimerar filer[1] utan att man egentligen märker något av det (den är heuristic - dvs märker om en fil är komprimerbar eller inte - är den inte komprimerbar i dess börja så skiter den i att komprimera resten av filen då det antas att det är samma hela vägen - men det går att forcera kompression för hela filen om man vill)

[1] man skapar en mapp med kompressionsflagga satt med chattr +c filmapsnamn - och alla filer som läggs i den mapp och alla undermappar som sedan skapas kommer vara av komprimerande typ. Med NTFS skall man inte slå på någon filsystemskomprimering, då förvärras problemet mycket och dessutom fragmenteras filerna oerhört [i 64 kByte-block] och man kan nå fragmenterings-gränsen vid riktigt stora filer men om man inte använder filsystemskomprimering skulle klara sig (DET är NTFS stora akilleshäl som forcerade MS till att akut skapa ett alternativ som ReFS för storkunderna som körde huvudet i detta hela tiden). - Vilket är lite ledsamt om man har diskimage med stora tomma (0-fyllda) områden i sig, vilket är närmast standard om det är diskimages tagna från SSD/NVMe-lagring då TRIM ser till att områden som inte har data är nollad när den läses.

Om det första citatet stämmer, d.v.s. att disken är på väg att ge upp, så skulle jag föreslå att du genomför kloningen FÖRE du rensar bort grejer som du inte behöver eller vill ha. En kloning av allt bör gå snabbare/smidigare och slita mindre på disken än att först delvis rensa den och sedan klona den.

kloning är en väldigt rättfram körning där man både läser och skriver linjärt från och till lagringsmedia och för detta bör inte SMR-disk har några problem.

har för mig att macrium reflect hade en kloningsfunktion iom. att du känner till programsviten. - dock bör du välja 'raw' kloning och inte någon smart variant av det om du vill spara lagringen du läser ifrån ifråga om att minimera sökningar (= läsarmsrörelser).

lite överkurs:

Nu har jag inte koll på hur macrium reflect reagerar på om man har läsproblem på disken man läser ifrån - men om den står och stampar och inte kommer vidare så får man försöka med 'ddrecsue' i linuxmiljö då den är specifikt designad att lagring kan krångla och har en massa strategier man kan prova med och default om en sektor inte går att läsa och ger error eller timeout (efter mer eller mindre lång tid) så hoppar den förbi en bra bit av problemområdet och tar resten av disken och när det väl är gjort så går den tillbaka till den krångliga området och hela tiden saxar in sig till mindre och mindre områden och till slut kanske bara enstaka sektorer som inte går att läsa.

Att tänka på när det är aktuellt - ddrecue skall ha 3 filnamns-argument, inte 2 även om det fungerar med två - den tredje filargumentet är för logfilen så att den vet hur långt den har kommit i kopieringen och vad som är kvar vilket gör att man inte behöver köra om allt från början igen (och den lyxen har man ofta inte om det är en snurrdisk som är på väg att haverera) om man måste starta om (tex efter att lagring hängt sig - vilket inte är allt för sällan med SSD som börja ha problem) utan fortsätter där det slutade sist.

Med robocopy kan du avbryta när du vill, fort sätta sen. Köra en gång till för att vara säker på att allt är lika etc. Men det borde ta mindre än 1 dygn, kan väl inte säga så mycket mer utan att veta hur mycket små filer det är. Det kanske känns ovant att använda terminalen men kolla på iaf, du slipper andra 3dje part program och du får en kopia på allt.