Det säkra tillvägagångssättet är att behandla seriella nummer för enhetsmappning och beständiga ID:n som en följd av observerbara kontrollpunkter: byt ut en bekräftad medlem och verifiera sedan återuppbyggnaden och den ursprungliga arbetsbelastningen, i stället för att förlita sig på ett enda kommando.
På en Linux-baserad hem-NAS med ZFS, mdraid eller Btrfs är den praktiska risken att behöva byta ut en NAS-enhet utan att blanda ihop de föränderliga Linux-enhetsbokstäverna. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar någon annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan är inte slutfört förrän den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.
Skapa en mappning mellan serienummer och diskfack
Spara status för arrayen eller poolen, enhetstopologin, SMART-identiteten, kapslingsplatsen, serienumret, WWN:et och den symboliska länken i /dev/disk/by-id för varje medlem. Linux-enhetsbokstäver kan ändras efter omstart eller hot-plug, så /dev/sdX är en observation för den här uppstarten, inte den beständiga identitet som används i ersättningsdokumentationen.
En praktisk ZFS-guide för hemservrar visar hur man utför ett byte med en beständig by-id-sökväg och övervakar resilveringen i stället för att lita på en tillfällig enhetsbokstav. Samma identitetsprincip gäller för mdraid och Btrfs, även om deras byteskommandon skiljer sig åt.
Matcha den felaktiga medlemmen i programvaran mot den fysiska etiketten två gånger: en gång innan du tar den offline och igen innan du tar bort maskinvaran. Stoppa om seriell genomkoppling saknas, om två platser rapporterar samma bryggidentitet eller om poolen inte tål att ytterligare en medlem tas offline.
Förbered ersättningsenheten utan att minska redundansen i förtid
Bekräfta att den nya enheten har minst lika många användbara sektorer, använder det förväntade sektorformatet och klarar grundläggande hälsokontroller utanför arrayen när det är möjligt. Dokumentera serienumret och by-id-sökvägen innan den sätts i. För krypterade eller startbara medlemmar ska du även bevara den partitionslayout, de nycklar och de startmetadata som krävs av plattformen.
Använd ZimaSpace-diskussionen om olika sektorstorlekar i en ZFS-spegel när en ersättningsenhet rapporterar en annan logisk eller fysisk sektorstorlek. Kapaciteten som anges på förpackningen räcker inte; den faktiska storleken, förväntningarna på ashift eller justering, partitionstabellen och NAS-plattformens regler avgör om bytet är giltigt.
Byt endast ut en enhet åt gången. Om den gamla disken fortfarande går att läsa och plattformen stöder anslutning före frånkoppling kan det bevara redundansen. Annars tar du den bekräftade medlemmen offline, stänger av när chassit inte är säkert för hot-swap och märker den borttagna disken omedelbart.
Starta och övervaka den plattformsspecifika återuppbyggnaden
Använd den identitet för pool- eller arraymedlemmen som visas av dess eget statuskommando, tillsammans med den nya beständiga by-id-sökvägen. Klistra inte in ett generiskt kommando utan att verifiera topologin: byte av en ZFS-spegel, tillägg av en mdraid-medlem och byte av en Btrfs-enhet har olika tillståndsmaskiner och felbeteenden.
Övervaka förloppet, läsfel, checksummeåtgärder, SMART-förändringar, temperatur och återställningar av styrenheten. En oberoende beskrivning av ett byte betonar att man ska dokumentera serienumret på den felaktiga disken och vänta på att resilveringen slutförs innan nästa medlem byts ut.
Om den nya disken försvinner, om felen ökar på en överlevande medlem eller om återuppbyggnaden startar om upprepade gånger ska du stoppa icke nödvändig belastning och bevara loggarna. Ta inte bort ytterligare en disk, rensa inte fel och tvinga inte fram ett slutförande innan den felande komponenten och den aktuella redundansen är förstådda.
Verifiera den reparerade NAS-enheten innan du avvecklar den gamla disken
Ett slutfört förloppsfält är nödvändigt men inte tillräckligt. Bekräfta att poolen eller arrayen är frisk, att varje avsedd medlem använder den förväntade beständiga identiteten, att ingen partition fortfarande är för liten och att schemalagda monteringar, utdelningar, containrar och säkerhetskopior överlever två omstarter.
Kör plattformens integritetskontroll eller scrub efter återuppbyggnaden enligt dess säkra arbetsflöde. Återställ sedan en representativ fil och återskapa den arbetsbelastning som avslöjade felet. Kontrollera att felräknarna förblir stabila under ihållande läsningar och skrivningar.
Håll den gamla disken offline och märkt tills den nya medlemmen har klarat en normal arbetsbelastning och en säkerhetskopieringscykel. Återställningen är klar när topologi, datakontroller, enhetshälsa och programsökvägar alla är godkända. Eskalera om identiteten fortfarande är oklar eller om någon överlevande medlem utvecklar nya fel under återuppbyggnaden.
Support och tips
Mer att läsa

Migreringsguide för Borg Backup för att flytta ett arkiv till ny lagring
Flytta ett Borg-arkiv som ett enhetligt objekt: stoppa skrivningar, bevara nycklar och identitet, verifiera återställningar och uppdatera sedan klienterna samtidigt som källan behålls.

Arbetsflöde för underhåll av Restic-arkiv: kontrollera, rensa, komprimera och testa återställning
Restic har inget separat kompaktkommando: prune utför ompaketering. Skydda lås och ledigt utrymme, kontrollera igen efteråt och avsluta med en isolerad återställning.

Guide för återställning av Time Machine-NAS vid trasig eller övergiven säkerhetskopieringshistorik
Behåll det gamla paketet. Separera NAS-åtkomst, destinationsidentitet, bildskador och övergiven historik innan du väljer reparation eller en ny kedja.

