Beror på hur denna GB skrivs - om det är i tusentals småfiler eller i ett enda sammanhängande block som skrivs på en gång.
men 1 GB/dygn är ganska modest och ger något över 1TBW per 3 år och sådana här klarar många 10-tal TB, tom över 100 TBW om det är kvalitets SD och hyffat stort SD-minne (typ minst 8 GB)
I RPi-sammanhang verkar Samsung evo plus och sandisk extreme och sandisk extreme pro ligga bra till, sandisk ultra kan nog också fungera.
Skall du jobba mycket mot databas på SD:n så är det tydligen stor skillnad mellan µSD och standard SD även om de i övrigt heter lika - typ faktor 100 till µSD nackdel. Kort sagt det är trångt på µSD både för minne och controller medans i standard-SD kan de breda ut sig lite mer och förmodligen också kan avge mer värme och därmed högre prestanda på kontrollern.
En svaghet med RPI och konsument SD är att vid för brusig strömmatning från tex. USB-väggvårtan (av billigaste möjliga kinesium...) så kan det bli fel av den orsaken och inte att SD:n i sig gått sönder.
Antingen fixar man fram väluppfostrad filtrerad kraft eller så får man titta på SD av industriell klass - och då åker priset upp med nästan en nolla, men då har de bättre skydd vid tex. dålig/brusig spänning under skrivning, ESD-skydd - mycket mer skrivtålighet och utökad temperaturområde + en knippe faktorer till...
slutligen:
SD har en tråkig egenskap - den säger inte till när den av olika orsaker har korrupta sektorer utan levererar dessa lika glatt som korrekta sektorer - ingen märker skillnaden under läsningen. Det finns ingen kontrollmekanism för detta på samma sätt som SSD som har felhantering med IO-error och icke levererad data vid korrupt data med arv från hårddiskar och optomedia.
De beror på en tidig filosofi och av de som skapade SD-formatet först att man hade åsikten att flashminne gör inte fel och därmed inga kontrollmekanismer för det. Det fins dock CRC-summa på själva överföringen - men ingen checkumma eller annan kontroll på själva minnesinnehållet (mer än det som minneschipen själva har för sin egna ECC) och blir det fel så har interna flashminnena ingen väg att meddela uppåt i gränssnittet - det finns register numera definierad i SD där sådan går att läsa av - men det är ingen på SD-läsarchipet som bryr sig om att läsa sådant samtidigt i överföringen och varna programmet när IO-error dyker upp... - de som håller på med dataprylar i enterprise-klass gillar inte tankesättet alls, det finns inget som aldrig gör några fel någon gång (om inte annat så hindrar Shannon det med sin datakapacitetslag med signalering med begränsad dynamik och i brusig/störd miljö), och när det blir fel så vill man veta det så att man kan göra åtgärd!.
Har man viktig data på SD:n nu när lågnivå feldetekteringen inte fungerar så bör man ha checksummande filsystem för att just upptäcka när det börja komma korrupta sektorer vid läsning och det som en RPI orkar med hyfsat i den vägen är då BTRFS medans ZFS är för tung och minneskrävande.
I BTRFs kan man dessutom sätta datat i 'DUP' i filsystemet - vilket innebär att allt finns i 2 exemplar av all data som skrivs i volymen, lite som på RAID1 men på samma fysiska disk och en chans till rättning lokalt när en sektor läses felaktigt - annars på SD och en USB-sticka så kan man göra två speglande diskar i RAID1...
