Söker billig SSD med hög uthållighet (Endurance/TBW) till Home Assistant.

HA har ju integrationer med precis allt, känns extremt osannolikt att det inte skulle finnas en för i princip alla märken av UPS på marknaden oavsett hur obskyra de är.

Seagate Firecuda har ju bra TBW. Mina Firecuda 520 2TB har ~3600 TBW. Så de håller ju ett bra tag.
Bör vara billiga nu också då de är PCI-E 3.0.

Sedan är det mer att tänka på - tex val av filsystem, om programmet öppnar och stänger filer för var rad som skrivs och att det syncas, vad händer om strömavbrottet kommer mitt i den millisekunden som en skrivoperation görs - hur mycket förloras då? - hela filen kastas för att den lämnades öppen eller bara en transaktionspunkt till förra raden som skrevs om inte sista raden skrevs komplett?? - sedan har man variabeln med writecache på lagringen som OS inte har någon kontroll över - vad händer då med datat som väntas på att placeras ut i lagringen - eller om man vill hur många kör med writecache avstängd på sin lagring eller använder sig av batteribackuppad HBA med egen RAM-cache?? - det fins anledning vaför enterprise-servrar har sådana batteribackuppade HBA och all inkopplad lagring körs utan writecache påslagen eller har inte sådan alls (enterprise-lagring) och att man idag använder SSD/SAS-SSD istället för snurrdisk förändrar inte saken eftersom de också har writecache som är osäker vid plötslig strömavbrott!

En annan sak att tänka på är tex. filsystemens egenhet vad som händer när en loggfil öppnas och stänger hela tiden i tex. NTFS kommer det att fragmentera och NTFS har bara ett begränsat antal fragment per fil - sedan skriver det inte mer och det är inte säkert att det felmeddelandet fångas upp när det slutar att skriva då det inte ger normala fel som att filen inte kan öppnas, disk full etc. utan data helt enkelt inte fylls på och fastnar i filen längre och förloras.

Med andra ord loggrotation kommer att vara viktigt så att var loggfil inte blir för stor och tappar så mycket om det skulle haverera mitt under en skrivning.

Helst behöver du använda en COW-filsystem som inte skriver över redan skriven data och med transaktionspunkter som BTRFS, ZFS och möjligen ReFS. De har också större överlevnadschans vid oväntade stopp än de mer klassiska filsystemet samt har checksumma på all sin data och metadata och hittar punkten där det gick fel vid tex. en icke färdiggjort skrivning och gör en rollback till en datamässigt säker punkt strax innan.

NTFS har en usel journalföring där man har förlorat mycket datasäkerhet i jakten på filsystemprestanda redan på hårddisk-tiden (eller snarare därför), ext4 har en fungerande Journal men på flashmedia som inte har global wearlevling (läs SD-minnen och USB-minnen) så kan man slita ut en ö inom lagringens LBA-adressområde då denna är fastlagd på viss LBA-adressområde i samband när filsystemet skapades.

Till detta är att moderna OS skriver inte direkt till filsystemet fast programmet använder 'sync' när den skriver i en fil - undersystemet som synkar data i RAM mot disk kan ha helt annan synkningsmekanism och intervall och snabbar/kortare intervall måste kanske styras med pararmetrar mot kärnan (som i linux) eller eget program som forceras disksynk i högre takt och inte kan beställas direkt av applikationen som skapar loggfilerna...

databaser och databasmotorer har slagits med situationen länge med dom egenheter underliggande filsystemen som erbjuds då de skall klara en strömavbrott utan förvarning (och det är bara typ de sista 10 åren man verkligen har säkrat det och det beror på införande av snapshot-funktioner (som VSS eller i folkmun kallad Shadowcopy i windowsmiljö) och filsystem och VM-maskiner där man kan göra snapshot under drift och imagen som då skapas är då i läget i hur det ser ut vid en plötsligt strömavbrott.

Det fins en anledning varför man har transaktioner i en databasmotor och nu också i filsystem som BTRFS, ZFS och ReFS.

En genomförd transaktion är samma sak som att nu är datat hugget i sten på lagringen medans det som inte är det - finns inte kvar efter en strömavbrott.

Klarar man inte av även den lilla databortfallet efter en genomförd transaktion efter tex. strömavbrott - ja då får man helt enkelt se till att maskinen aldrig stannar med UPS och andra arragemang - men UPS är en felkälla i sig som i många fall ger mer trubbel än faktiska strömavbrott, och inte sällan av handavandefel och bristande förvaltning och underhåll där batterierna lägger av i förtid eller byts inte ut planerad intervall och intervalltiden med hänsyn tagen till av faktisk rumstemperatur (teknikrum är ofta varma och kan mer än halvera tänkta batterilivstid för att det är 25 grader C istället för 20 grader C).

och inte att förglömma - utrustning med höga upptidskrav har också dubbla nätaggregat - en till UPS och en utan - del för att möjliggöra flytt av utrustning utan att stänga av den och att kunna göra service eller utbyte av UPS under drift utan att stänga av maskinen.

I grunden skulle jag titta på TBW och hur lång garanti det är. Samsung är bra märke och har inte haft några problem med dom jag skaffade in redan när första Ryzen släpptes.

För övrigt så är det val av OS / filsystem och vilka backuprutiner man använder.

När det gäller UPS så är det i praktiken en bärbar dator kopplad till en UPS, som skulle ge tre nivåer av skydd, elnät -> UPS -> inbyggt batteri. Men också fler felkällor / krångligare att underhålla som @xxargs säger.

Det är inte hur många plåster du kan sätta på utan hur bra läkare du har när du slår dig illa som ger bäst skydd.

En kombination är en ramdisk som dumpas till disk med jämna mellanrum och när systemet tas ner. I så fall kan en UPS utföra en säker skrivning vid strömavbrott då den säger åt systemet att göra en säker avstängning.

Det här skyddar även en SSD från att nötas ut och är dessutom snabbare än en nvme-enhet. Behöver du bättre skydd än så för elen så borde du byta elleverantör eller nätaggregat alternativt hyra in dig i en serverhall.

Sedan måste man ändå ha en alternativ lösning för var händer när moderkort eller CPU går sönder och systemet rasar? Hotswap, RAID och moderna filsystem kan byta el och diskar online men ju närmare CPU / RAM / MB du kommer desto svårare.

Nästa steg är i så fall cluster och system där du kör duplicerade system, inte bara diskar utan hela system som parallellt gör samma sak.

Min full home assistant backup är 60 MB, skicka över till valfri usb minne, cloud eller egen server dagligen så förlorar du som mest 24h data.

Vilken ssd du än köper så kan den dö närsom helst om man får ett dåligt ex, eller så håller den många år.

Home assistant har en inbyggd backup funktion som sparar all statistik, data, inställningar osv. Och versioner på HA olika delar och addons som laddas ner vid återställning, så det tar inte så mycket plats.

Seagates Firecudadiskar verkar ha rejält höga TBW-värden överlag.
Mina Firecuda 510 2 TB har 2 600 TBW och aktuella Firecuda 530 2 TB har 2 550 TBW.
Det är betydligt högre än de flesta diskar i samma storlek. Men Firecuda 520 2 TB verkar spela i en helt egen liga med 3 600 TBW.

Några av Crucials tidiga MX-serie SATA-diskar var utrustade med kondensatorer för att flusha DRAM till Flash.

Tror ärligt att du inte behöver stirra dig blind på TBW. Även en billig disk med "bara" 100TBW skall enligt tillverkaren klara strax över 25Gb/dag i 10 år. 25Gb är VÄLDIGT mycket data sålänge det inte är media (foton, musik, video). Jag kan se efter när jag kommer hem hur stor min är. Jag kör ZFS på databasen med snapshots var 15 minut, så i princip varje skrivning som görs går att summera ihop över flera månader.

Skulle jag vara i dina skor skulle jag försöka göra vägen från krash så smärtfri som möjligt, alternativt ha någon form av redundans istället för att leta "odödlig" hårdvara. All hårdvara kan kasta in handuken utan förvarning, eller så kan du göra något dumt som pajjar den.

Har haft ovanligt många NV2 som dött jämfört med andra märken/modeller, så den hade jag inte köpt om man vill ha driftsäkerhet.

Såvitt jag begriper är det fortfarande så för https://www.amazon.com/Crucial-MX500-NAND-SATA-Internal/dp/B0...
"Integrated power loss immunity preserves all your saved work if the power unexpectedly gets cut"

Annars har jag några äldre Intel-som har det (S3500, 320, etc), kan inte vara fel att ha på systemdisk eller som del i en Fusion Drive (MacOS) tänker jag.

Att man med Home Assistant skulle skriva sönder en vettig SSD känns osannolikt? Jag har en kompis som typ tankar torrents till SSDer (av rimlig kvalitet, inte QLC)

Men SSDer av premiumkvalitet kan ju ändå förväntas hålla bättre, även om de inte skrivs sönder. De SSD jag har som faktiskt HAR gått sönder har nog inte gjort det pga skrivningar utan pga annat.

Kör docker container bara? Det gör jag, tar schedulerad backup.

Man kan även optimera skrivandet, t ex alla sensorer kanske inte behövs osv

Man uppdaterat hela containern, det är det fina med docker imo. Ja add ons funkar ej men jag saknar inget där ännu.

Jag kör med watchtower och ett schema som uppdaterar mina containers en gång i veckan.

Vad är det du egentligen vill göra? Den här diskussionen ser ganska spretig ut, eftersom ditt första inlägg diskuterar både användandet och driftsäkerheten.

Det här ser ut som att du vill köra en dedikerad server med redundans för mig och att du i princip skriver tusentals GB dagligen.

Det jag kör är Linux Mint Cinnamon med en ramdisk på 16GiB där jag lägger filer som behöver ändras ofta (av mig själv). som synkas av rsync när systemet stängs av. Det vill säga endast ändringar skrivs om, orörda saker petas det inte på. Vilket också gynnar SSD:er och hastighet.

Eftersom Linux kör COW på sina filsystem så sparas bara ändringar, inte hela filen självt. Vilket gör att skrivningen minimeras och sliter extremt lite på en SSD, speciellt med filsystemet BTRFS då detta är optimerat för enheter med minneskretsar.

Sedan 2010 har jag haft 3 strömavbrott. Samtliga var föranmälda av vattenfall, så man visste om dom. Det första var när lägenheten totalrenoverades, stambyte, nytt kök etc. och man hade en ersättningslägenhet under tiden.

Att krascha ett linuxsystem skulle jag säga är näst inpå omöjligt om du inte tar till fysiskt våld. Nedslitningen på mina SSD / M.2 är fortfarande 0%.

Linux har extremt bra cache-logik, vilket gör att snurrande hårddiskar optimeras till max-hastighet. Kör du en Seagate ironwolf pro disk får du runt 250MB/sekund i hastighet. Anropar du ofta så läggs disken i cache, där bra med ram ger fördelar. Har du mer än 32GB ram så körs hela OS-installationen i din cache automatiskt, då en grundinstallation tar runt 16GB - 20GB diskutrymme. Systemet är igång på någon sekund. Men kan ta upp till 10 minuter innan systemet är helt cachat. Men inget du behöver vänta på, om du inte är benchmark-torsk vill säga.

M.2 med nvme börjar på 1GB per sekund. Det är 60GB per minut eller 3,6 TB per timme. Om du har filer med den storleken så kör du NASA-projekt i princip.
Om du har filer som ändras så mycket så loggar du fel saker helt enkelt.

80 tecken på 800 000 rader är 64 miljoner tecken. Vilket är 64MB vid 8 bitars djup. Kan du läsa en rad i sekunden tar det mer än 9 dagar.

(MS-DOS har 80 tecken x 25 rader på skärmen som referens, vilket är 2 000 tecken).

MX500 är en 6 år gammal SSD så det är iaf en "tidigare" enhet.