Det som plågat RPI 1 och 2 är att SD-minnena brickas lätt om strömmatningen inte har varit stabil, pga. långa sladdar och spänningsfall pga. av detta, dåligt med strömmarginaler i använda 5V adapter eller inte har god reglering vid varierande last. RPI3 och RPi4 har man förbättrat det med egen regulator för själva SD-minnena.
Att också använda bättre kvalitets SD-minne som Sandisk ultra och Sandisk extrem eller samsung EVO+ - dom är de snabbare än idag vid 4K-skrivningar då SD-minnen och USB-stickor är extremt dåliga på detta i jämförelse med tex. SSD-minne även om det går via USB. Är det höga krav på driftsäkerhet så får man titta på 'industrial grade' SD-minne med ruggad kontroller och minnen av SLC eller MLC-typ, men de är inte billiga då tex. 16 GB SD-minne av den kvaliteten kostar runt 3000:-
SD-minne är byggd för rätt stora blockskrivningar på ganska många MB i stöten (läs lagra bilder från en kamera) och tillverkarna räknar kallt att en SD-minne får sin diskyta omskriven max 5-10 ggr i sin livstid. Med 4K-skrivningar (minsta storleken som en filsystem skriver med) hackande tusentals på samma ställe (inods-uppdateringar, journalskrivning i ext4) så är det inte säkert att den rätt primitiva wearlevlingen jobbar så bra eller inte alls i billigare SD-minne och man får ganska snabbt att sektorer börja läsas fel (SD-minne har inte alls samma felrättning och och om det misslyckad, blockering av korrupta sektorer som SSD har - man glömde den detaljen då när SD-standarden skrevs då man hade filosofin att SD-minne aldrig gjorde fel - och det kanske stämde med SLC-minnen för hundra år sedan, men inte med dagens TLC-minne - därför kan man läsa korrupta sektorer ur SD-minne utan något skulle indikera att det är felaktingt medans på SSD/NVMe så får man IO-error.)
Checksummande filsystem som BTRFS är inget dåligt val alls då reagerar vid felläsning (ger IO-error... precis som SSD) samt sprider ut sitt skrivande på helt annat sätt än ext4 mha. COW-filosofin. dvs. alla ändringar görs alltid på nya sektorer och man modifierar inte de redan skrivna - och det gäller också metadatat som inod-listor. - det gör att diskytan på SSD/USB-stickan kommer att nyttjas fullt ut innan den börja skriva på de äldsta lediga sektorerna igen.
BTRFS har också funktioner att kunna spara all sin data i 'DUP' dvs. i 2 kopior på olika ställen i SD-minnet vilket gör att om den ena läses fel (vilket kollas av checksumman) så kan den använda kopian för att ge programmen rätt data samt rätta den fellästa sektorn (går automagiskt). Ändra raid-läge gör man med 'balance' och görs under drift/användande och man kan konvertera tillbaka igen om man inte gillade att filerna tar dubbelt med plats som när man kör i single-disk eller RAID-0.
Detta går också att göra RAID1 mellan en SD-minne och en USB-sticka av samma storlek. Dock kan man inte garantera att starten fungerar i RAID1 vid felaktighet på någon av media då detta är styrd av uboot-rutinen på RPI vilka enheter den provar i startfasen och var den gör ifall den inte kan läsa endera av lagringen (man har samma problem med vanliga BIOS)