Dat is een behoorlijk moeilijke vraag, vooral ook vanwege het a-typische gebruik (disconnect voor een groot deel van de levensduur , wat ik opmaak uit je vraag ) .

https://www.howtogeek.com/322856/how-long-do-solid-state-drives-really-last/ lijkt wel iets samen te vatten, en linkt tenminste naar diverse papers/studies .
Alleen dat zijn allemaal wel gebruiks-situaties (google, facebook, backblaze ).

In principe slijten SSDs (wat) meer van schrijven - maar met een goede keuze ligt die grens zo hoog dat je heel hard moet werken om dat te bereiken. 1x per week een archief vullen gaat dat , met de natte vinger, totaal niet halen .

Voor (erg) langdurig off-line opslaan zou je wat zorgen kunnen hebben over SSDs , maar met 1x per week aan de stroom kom je daar niet aan.
Zelfs bij opslag is fors warme omgeving .

https://www.partitionwizard.com/clone-disk/is-ssd-good-for-long-term-storage.html
https://www.diskmfr.com/data-retention-of-ssd-leave-it-unused-and-lose-data/

Valbestendigheid ('oeps, backup drive viel op de grond' ) moet SSD goed winnen van HDD.

Ik zou schrijfsnelheid (streaming writes neem ik aan ? dat is de meest optimale case) overigens ook meenemen in het afweeg criterium , als de kandidaten allemaal "betrouwbaar genoeg" zijn .

Hoop dat ik mag inhaken...

Ik heb nog magnetische schijven van 1995 in prima staat (en in gebruik). Ik heb 3.5" festplatten van 2016-2020 zonder fouten.
2 op de 10 vertonen na 5 jaar uptime en anderen weer na 5000+ mounts (nonserver) wel enige errors in de smartlog. Maar met echte hardware errors heb ik geluk. Ik schat de levensduur bij mij op ca. 5 jaar en sommigen (enkelen) zijn na 20 a 30 jaar nog foutloos.

Daarintegen heb ik geen enkele USB stick (stuk of 40) of SD kaart ouder dan 3 a 4 jaar. En SSDs die worden bij mij ook niet oud.

Je moet niet alleen oppassen met de atime optie in de fstab en wear levelling, maar ook proper trimmen. En je moet SSDs en NVMEs ook af en toe van voltage voorzien.

Veel betrouwbaar is magnetische tape. Die overleven gemakkelijk tientallen jaren.

CD writables zijn ook goed voor 15 jaar.

Maar SSD end NVME is niet geschikt als offline storage m.i. tenzij je ze elke 2 jaar saneert. Neem wel een moderne MLC en geen oude SLC/TLC type NAND chips. Er heerst een misvatting dat SLC NANDs (als je ze nog kan vinden) slijtagevast zijn. Dat is een denkfout. In de praktijk gaan de MLC chips langer mee door betere spreiding en verbeterde firmwares van de SSD/NVME.

Maak altijd een backup van de backup. Er is geen ideale superoplossing tenzij het on MBs gaat en je met tapes in de weer wil gaan.

Zolang je backups hebt van de data is het een kosten/prestatie overweging, heb je veel data (prijs per GB) zijn het grote of juist heel veel kleine bestanden(prestaties).

Elk van de genoemde opslag media kan zomaar de geest geven, dus maak je geen backups koop er dan twee en synchroniseer (e.g met Rsync / TeraCopy).

Een HDD kan op den duur misschien wat mank gaan lopen met wat data corruptie, en een SSD zal eerder totaal onbenaderbaar worden, raadpleeg een aantal keer per jaar de S.M.A.R.T data van de schijven(als dit wordt ondersteund door de USB controller) om de levensduur te bepalen, vervang tijdig.

Persoonlijk zou ik voor een SSD gaan, zeker als de opslag capaciteit geen grote rol speelt, en je er wekelijks mee aan de haal gaat.

*Ik heb hier zelf een enkele Transcent TS1TESD370C in gebruik voor archivering van Virtuele Machines daar dit allemaal niet op mijn laptop past(hier worden wel backup's van gemaakt).
Deze presteert ook voldoende om direct de minder gebruikte VM's vanaf te draaien, de snelheid stort wat in bij grote write overdrachten maar is acceptabel(vele malen sneller dan over ons netwerk heen en weer pompen, bespaart me een hoop tijd).

Toevallig heb ik hier afgelopen week ook naar gekeken voor mijn privé-backups.

Oudere harddisks gaan vaak zeer lang mee, maar met recente grote (> ca. 1TB) heb ik slechte ervaringen, vooral met "SMR" harddisk (grote bestanden schrijven is onacceptabel traag en ze gaan extra snel stuk). Dat is ook geen wonder, de informatiedichtheid is gewoon te hoog geworden voor wat je betrouwbaar "mechanisch" kunt lezen én schrijven: de lees/schrijfkoppen moeten steeds dichter boven het schijfoppervlak zweven waardoor elk miniscuul stofdeeltje wat daartussen komt funest is, en er enorme eisen aan de "motor" worden gesteld die de arm met koppen laat bewegen (maar ook aan de lagering van de spindel met de schijven).

Ook van schijven bestemd voor datacenters (neem ik aan) loopt de levenduur terug met de grootte: https://arstechnica.com/gadgets/2023/05/hdds-typically-fail-in-under-3-years-backblaze-study-of-17155-drives-finds/.

Ik gebruik een (vóór 2000 zelfgeschreven) synchronisatietool om te back-uppen, waardoor alleen nieuwe en gewijzigde bestanden worden geschreven: voor de levensduur van SSD's zou dat geen enkel probleen zijn. Of en hoe goed TRIM werkt op via USB aangesloten SSD's weet ik niet.


Als ik nu een back-up schijf zou moeten kopen, zou ik denk ik toch gaan voor een SSD (een inbouwmodel, die zijn wat duurder maar waarschijnlijk betrouwbaarder en hebben meer reserveblokken) en uitzoeken of TRIM werkt bij gebruik van mijn USB3 naar 2,5" SATA converter.

Hoe lang spanningsloze SSD's gegevens bewaren, weet ik niet. Dus zou ik ook cryptografische hashes van de opgeslagen bestanden berekenen en die erbij bewaren (zodat ik altijd achteraf beschadigingen kan constateren - door uitsluitend te lezen). Op SD-kaartjes heb ik gezien dat bestanden, zonder foutmeldingen, beschadigd kunnen raken waarbij in "sectors" (blokken van 512 bytes of een veelvoud daarvan, beginnend op offset 0, 512, 1024 etc.) alle bits 0 of 1 zijn geworden (de bytes dus 0 of hexadecimaal 0xFF, decimaal 255).

Overigens versleutel ik al mijn privéschijven met Veracrypt, en zou dat ook doen bij een externe SSD. Ik had vorige week een back-up HDD die defect raakte en nog nauwelijks benaderbaar was: die kan ik niet meer wissen. Doordat de sectors erop versleuteld zijn, maak ik mij geen zorgen als ik deze weggooi (bij het elektronische afval).

Ik heb een andere ervaring. Bij mij rotten die rewritable CDs na ongeveer 5 jaar. Dat is me meerdere keren gebeurd.
Bad sectors, waardoor bestanden niet meer leesbaar zijn en ook niet meer grecovered konden worden.
De CDs werden op kamertemperatuur (met alle schommelingen van dien) bewaard.

Tegenwoordig gebruik ik opslag op 3,5" SATA HDs in een NAS met voldoende redundantie (raid 5 en offsite backup) zodat belangrijke bestanden niet 1,2,3 verloren gaan. HDs zijn "24/7" up met dagelijkse IO en gaan ruim 5 jaar mee.

In mijn specifieke situatie werkt dit het fijnste.

Klopt als een redelijke hobby oplossing.

Archief of backup? Want 1 archief is russisch roulette spelen met je data.

SSD, als ze kapot zijn, is er ook echt niets meer mee te beginnen. Gewone harddisks kunnen nog wel hersteld worden.

Een hardware-based RAID (redundant array of independent disks) op basis van FreeBSD en met Btrfs of OpenZFS.

https://en.wikipedia.org/wiki/RAID


Optioneel: opgesteld in een bewaakte atoombunker met stikstofgas. Niet te verwarren met de Franse anti-terreurbrigade.

Je bedoelt neem ik aan >10TB?


Vroeger gebruikte ik ook zelfgeschreven tools maar tegenwoordig niet meer. Ik heb intern in de machine 2 SSD's
in RAID-1 staan, en gebruik BTRFS. Daar maak ik vanuit een cronjob snaphots mee. Dat wil zeggen dat ik altijd een
periode terug kan en per ongeluk verwijderde, overschreven of anderszins verprutste files kan terughalen zoals ze
waren op het moment van een snapshot. Omdat een snapshot niet meer ruimte kost dan wat er GEWIJZIGD is
sinds die snapshot, het is dus geen copie, kan ik heel veel snaphots bewaren.

Voor de offline backup gebruik ik een externe HD ook met BTRFS. Ik gebruik rsync om de interne SSD (exclusief
de snapshots) te synchroniseren met de externe schijf. Daarna maak ik op die externe schijf ook weer een snapshot.
Dus ik hoef niet op te letten hoeveel generaties backup ik bewaar, copietjes weg te gooien, etc, dat regelt BTRFS
allemaal voor me. Ik kan dus zo een file van een jaar terug van die schijf halen. Pas als die schijf vol is moet ik
snapshots gaan verwijderen.

De backupschijf is een 12TB SMR schijf, maar omdat rsync alleen gewijzigde files overzet werkt het toch wel op
acceptabele snelheid. Daarnaast maak ik dan nog een backup via internet ergens naar een remote disk.

De vraag ging over welke harde schijven!

Ze beweren dat een M-Disc geschikt hoort te zijn voor vele jaren back archief, als dit waar is ik weet het niet misschien
heeft iemand hier ervaring mee.

https://gathering.tweakers.net/forum/list_messages/1471807

Je springt nu wel van CD naar DVD naar M-Disc.
Aangezien ik mijn problemen (het rotten) al had met zelfgebrandde CDs, heb ik zelfgebrandde DVDs maar beperkt gebruikt en M-Disc is nieuw voor me. (nooit op mijn radar gekomen)

Ik werk nu al een 10-tal + jaren met HDs in een RAID-5 configuratie. Dat is IMHO uiteindelijk efficienter.

Ben je op de hoogte van "btrfs send" en "btrfs receive"? Je kan met "btrfs send" het verschil tussen twee snapshots produceren, en dat kan door "btrfs receive" weer tot de volledige tweede snapshot op de ontvangende schijf worden verwerkt als daar de eerste snapshot al op staat. Het verschil kan via een pipe van "btrfs send" aan "btrfs receive" worden doorgegeven. De verschillen bouwt "btrfs send" op vanuit de structuren van het filesysteem, zonder daarvoor afzonderlijke bestanden te moeten vergelijken. Het maken van een backup komt dan neer op het maken van een nieuwe snapshot en die op de genoemde wijze reproduceren op de backupschijf. Oudere snapshots (die niet meer voor het bepalen van verschillen nodig zijn) kan je veilig verwijderen van de backupschijf. Alleen bij de eerste backup die je met deze werkwijze maakt wordt een volledige snapshot overgedragen.

Dit is door een andere anoniem geschreven.

Of je nu SSD, HDD, backup tape of CD/DVD gebruikt, veel hangt af van de kwaliteit van het gebruikte materiaal en waar je ze bewaart. (liefst op een donkere, droge, koele plek en een temperatuur die niet teveel varieert)
Mijn eerste gebrande CD's en DVD's waren ook bagger, maar later kwamen er CDs en DVDs en branders die wél goed waren.

Pas op voor zogenaamde Enterprise SSDs. Het kan zijn dat ze "professioneler" en sneller zijn,
maar mogelijk kunnen ze minder lang zonder stroom.
Pas ook op voor SSDs die al veel zijn gebruikt, want die houden vanwege het vele gebruik de opgeslagen bits
minder lang vast dan een nieuwe SSD, en moeten daarom vaker aan de stroom om de data te behouden.

Ik meen mij te herinneren dat officieel een consumenten-SSD minstens een jaar lang zonder stroom
de data moet kunnen vasthouden bij een temperatuur van 30 graden Celsius.
Hogere temperaturen verkorten bij een SSD de houdbaarbaarheid van de data!
Een lagere temperatuur dan 30 C verlengt daarentegen de houdbaarheid van de data.

Ik zou een SSD-met-backup vochtvrij in een plastic zak doen, de lucht er zoveel mogelijk uitstrijken en de plastic zak hermetisch afsluiten en in de koelkast bewaren.
Dan hoef je hem veel minder vaak aan de stroom te hangen.om de data op te frissen,
Bijv. eens in de 5 á 10 jaar of zo.

Nee (wel ga ik uit van 2,5").

Sterker, voor 2,5" met 7200 RPM roterende schijven, denk ik dat 500GB de grens is waarbij alles daarboven snel stuk gaat, en meestal meteen zodanig dat je niets meer van de complete HDD afkrijgt (wellicht dat een HDD-rescue-bedrijf, dat de schijven er -in een zeer stofarme ruimte- uit haalt en met eigen leesapparatuur werkt, er nog wat vanaf kan halen, maar zo'n actie kost vaak heel veel geld).

Ik heb (privé) nu drie versleutelde externe (USB) HDD's waar ik omstebeurt back-ups op bijwerk. Die disks bewaar ik op verschillende plaatsen. Af en toe doe ik een full binary compare en zie daar zeer zelden foutmeldingen bij, en die zijn altijd te verklaren.

Mijn eerste HDD was 30MB (voor Atari ST). Op het werk hadden we IBM AT's met 20MB en XT's met 10MB (allemaal 5,25 "bakbeesten"). Vanuit die laatste bezien: 10TB is 1 miljoen keer zo veel data. Onvermijdelijk loop je dan tegen allerlei grenzen op. Sinds een groot deel van de firmware voor de in de HDD ingebouwde controller op de schijf zelf wordt opgeslagen, is de kans dat je een schijf geheel niet meer kunt benaderen (en je na aanzetten alleen wat geklik hoort) enorm toegenomen. Ik heb vroeger diverse low-level tools geschreven om zoveel mogelijk (belangrijke) bestanden van HDD's met bad blocks te kunnen recoveren, maar daar heb ik feitelijk bijna nooit meer wat aan.

En hoe groter de HDD, hoe groter de kans dat in één keer héél erg veel bytes ontoegankelijk zijn.

Meerdere HDDs gebruiken in een raid-5/6 constructie (en dat dan 1 of 2 keer reproduceren als backup). Mocht 1 schijf van een raid-set kapot gaan, dan is de data nog steeds te recoveren. De kans dat meerdere schijven tegelijk kapot gaan is klein. Daar heb je dan de backup sets weer voor.
Hoe belangrijker de data, hoe belangrijker redundatie is. Ongeacht het medium wat gekozen wordt. Zelfs al zouden dat nog floppy's of ponskaarten zijn. :-)

Wat als je zou kiezen tussen:

5 losse harddisks, elk jaar eentje vernieuwen. 5 onafhankelijke mirrosr


of

een Synologie bak met 5 disks in raid0+1 en een reserve


Wat zouden jullie dan doen?

Waarom Raid 0+1, bij 2 defecte disken verlies je nog steeds alles direct. Ga dan direct voor een RAID6 + spare.
Maar beter is Syno + Offsite backup.

Ik heb meegemaakt dat, op dezelfde rit, beide dimlichten (nog met gloeidraden) van mijn auto kapotgingen - die ik eerder tegelijkertijd had vervangen (omdat ik daarvoor extra felle lampen gebruikte, die wel heel snel stukgingen, en ik niet met twee verschillende koplampen wilde rijden).

Ook heb ik in een ver verleden een "terugroep-actie" van 1,6GB Western Digital harddisks (WDAC31600) meegemaakt vanwege een verhoogde kans op defectraken. En, niet lang daarna (1997), ontdekte ik een bug in een 2,1GB Quantum Fireball harddisk die tot dataverlies kon leiden (ik heb Quantum toen geholpen met het reproduceren en fixen van het probleem, zie https://www.computercraft.com/docs/qfbtmbug.shtml - opmerkelijk genoeg nog steeds online).

Ook voor SSD's van diverse fabrikanten zijn firmware-updates uitgebracht om ernstige problemen te helpen voorkómen.

Met andere woorden: in twee of meer "identieke" (bij harddisks vooral kort na elkaar in dezelfde fabriek geproduceerde) disks kan, op nagenoeg hetzelfde moment, dezelfde fout optreden. En een doos met nieuwe schijven kan tijdens transport aan flinke G-krachten zijn blootgesteld, zonder dat dit tot zichtbare schade leidt. Ten slotte kan ook een RAID-controller stuk gaan of "in de war raken". Ik zou de kans op het nagenoeg gelijktijdig uitvallen van meerdere disks of van de hele RAID-array dus niet bij voorbaat "klein" willen noemen.

Bovendien: tijdens synchronisatie, vooral indien automatisch gestart, kun je (delen van) jouw back-up kwijtraken bij problemen met de te back-uppen opslag, zoals na het per ongeluk verwijderen of door een technisch probleem ontoegankelijk worden van een mapstructuur, besmet raken van bestanden met malware of versleuteld worden van bestanden door ransomware. Sowieso als jouw RAID-systeem altijd online is, loop je relatief grote risico's als aanvallers toegang krijgen tot jouw netwerk.

Één back-up, vooral als deze altijd online is, is voor mij niet goed genoeg. Ik synchroniseer altijd handmatig (met alle netwerkverbindingen van mijn computer onderbroken) en doe eerst een "dry run" om te zien wat er verwijderd of vervangen gaat worden. Pas nadat ik heb vastgesteld dat er niets onverwachts zal gebeuren, start ik de synchronisatie. Door back-upschijven te rouleren verklein ik de kans dat ik in één keer ál mijn bestanden kwijtraak (met een beetje pech wel recent toegevoegde of gewijzigde).

vwb RAID0+1 (RAID 10):


Advantages of RAID 10

The advantages of RAID 10 include the following:
- Cost-effective. RAID 10 is an economical and technically simple approach to data protection paired with a boost in performance.
- Full redundancy. Data is fully redundant in a RAID 10 environment.
- Fast recovery. Because it does not rely on parity to rebuild any data elements lost during a drive failure or disk fails, recovering data in a RAID 10 array is fast, resulting in little downtime.
- Performance boost for some applications. RAID 10's basic data striping is an effective way to improve performance for applications that don't require large amounts of data.


Drawbacks of RAID 10

Some of the disadvantages of RAID 10 include these:
- Large capacity penalty. Because RAID 10 requires 100% capacity overhead, it is not an ideal RAID implementation for large amounts of data. The capacity penalty for other forms of RAID -- notably those that are parity based -- is much smaller.
- Limited scalability. RAID 10 is an effective alternative for smaller applications, but it doesn't scale well.
- Time-consuming recovery. If a disk array has to switch over to the mirror drives, a new mirror must be created as soon as possible to ensure continuous data protection. Copying all the original data to a new drive or set of drives can be time-consuming and may hinder ongoing operations that rely on the data.


En lees daarna dit nog even door:

https://www.salvagedata.com/raid-configuration/

Dit legt de verschillende RAID configuraties uit.

Het zal eraan liggen wat je ermee doet, en hoeveel handmatig werk je wilt doen.

Bij een NAS in raid opzet, wordt het werk daarna voor je gedaan door de NAS in realtime.

Bij losse schijven zul je zelf iets op moeten zetten om te synchroniseren, en dat frequent moeten bijhouden.
Er is dan altijd een risico van dataverlies als je hoofdschijf kapot gaat en de laatste data nog niet gekopieerd is naar een van de mirrors.

Als het voor archief doeleinden is, en je maar af en toe data moet toevoegen, is een losse opzet waarschijnlijk het risico waard.
Wil je geen enkel risico lopen op verlies, dan zul je na moeten denken over een raid-cluster. Mogelijk zelfs 2 en een extra backup optie. Als je het risico echt zo laag mogelijk wilt houden.
Naast de beschikbaarheid van de data, speelt ook de hoeveelheid data hier een rol bij. (en de kosten die je wilt maken).

Elke situatie is anders.

Nou ik vind die verhalen over grote disks wel heel pessimistisch, maar dat komt misschien omdat ik altijd al disks
van wel 10 keer de size die "de gewone man" "groot" vond gebruikte... in mijn eeste Linux machine in 1992 had ik
een disk van 820MB, terwijl de meesten toen een 40MB disk hadden.
In mijn Atari ST had ik een disk van 250MB (Hitachi) en dat systeem heb ik een tijdje geleden verkocht en die disk
deed het nog prima.
In mijn latere systemen heb ik altijd RAID-1 gebruikt, maar nooit echt gebruik van moeten maken om data te redden.
Maar nu heb ik SSD's en dan hoor je overal "RAID is niet meer nodig hoor!" echter NU heb ik wel last van slechte
blokken, wat ik op HDD's nooit had... maar de RAID-1 fixed dat gelukkig.
Wat dat betreft is de in BTRFS ingebouwde RAID-1 ook beter dan het gebruiken van mdraid (Linux RAID) in combinatie
met een filesystem wat niet RAID-aware is. Plus dat BTRFS nog extra een checksum opslaat van de diskblokken,
dus een extra laag bovenop de errordetectie/correctie van de drive zelf.

In de oude tijd heb ik disks van allerlei merken gehad die vaak stuk gegaan zijn, maar sinds ik alleen nog maar Hitachi
(HGST) kocht had ik daar nooit meer last van. Wel jammer dat je nu weer afhankelijk bent van rotzooi merken.
Nu heb ik SSD's en HDD's van Samsung. Is weer afwachten hoe dat gaat, maar zo slecht als Seagate kan het niet zijn.

Inderdaad. Ik kan me herinneren dat ik al vele jaren geleden (makkelijk 10-15 jaar geleden, schat ik) een artikel tegenkwam waarin precies dat werd geconstateerd: in RAID-systemen die met schijven van hetzelfde model uit dezelfde partij zijn opgebouwd, en waarvan omdat ze deel uitmaken van hetzelfde RAID-systeem het gebruik ook nog gelijk opgaat, is de kans aanwezig dat schijven zo snel na elkaar de geest geven dat als een tweede het begeeft de opbouw van de vervangende schijf voor de eerste nog niet is afgerond. Het hoeft niet zo snel achter elkaar te gaan, maar het kan wel, en de kans daarop is groot genoeg om de typische berekeningen over wat RAID aan betrouwbaarheid oplevert veel te optimistisch te maken.

Net als jij gebruik ik drie externe versleutelde HDD's voor backups. Ik heb voor schijven met stootabsorberende behuizingen gekozen van verschillende merken. Van die drie schijven:
• ligt er altijd één op een ander adres (bij vrienden waar ik vaak over de vloer kom);
• ligt er altijd één thuis;
• heb ik er altijd één bij me (die woont in het rugzakje dat ik altijd bij me heb).
De schijven zijn nooit alle drie op dezelfde plaats. Ik rouleer ze voortdurend tussen die drie "woonplaatsen". Er zijn er altijd twee die (vrijwel) dagelijks backups ontvangen, het schijfje dat elders "logeert" ontvangt weer backups als die verwisseld is voor een van de andere.


Omdat de data waarvan ik backups maak meer dan 1TB beslaat gebruik ik schijven van 2TB. Ik heb niet paraat hoeveel toeren per minuut ze maken, maar ik denk niet dat het per se de snelste zijn, daar heb ik ze niet op geselecteerd in ieder geval. Hoe dan ook, ik heb niet de ervaring dat ze snel kapot gaan (ik houd de SMART-attributen in de gaten en test af en toe of alles nog goed gelezen wordt en inhoudelijk klopt). Ooit gebruikte ik dezelfde methodiek met losse inbouwschijven die ik in een dock plaatste, en daar had ik veel sneller problemen mee omdat ze zonder stootabsorberdende behuizing veel te gevoelig zijn voor schokken, en hoe voorzichtig ik ook probeer te zijn, elk ongelukje vermijden lukt me niet.

Door de omvang van de schijven die ik nodig heb vind ik SSD's nog te duur (hoewel ik zie dat dat gedaald is sinds de vorige keer dat ik ernaar keek; maar externe SSD's van 2TB zijn nog schaars en sommige zijn nog wel extreem duur).

Voor sommige hier; een backup != archief

Ik begrijp waarom je het versleuteld, maar geeft dat aan de andere kant juist niet problemen als er enkele sectoren defect zijn? Er zijn file recovery tools die in ieder geval delen kunnen herstellen, maar die werken dan denk ik niet op een (met Veracrypt) versleutelde schijf?

Wat veel reacties en veel goede tips, dank daarvoor!

Ik moet alle info even rustig laten bezinken. Erg interessant om te lezen dat SSD schijven regelmatig "aan de stroom" moeten, dat wist ik helemaal niet.

We neigen voor het archiveren nu naar HD schijven. Maakt het nog verschil in stabiliteit tussen een 3,5inch HD schijf (op stroom) of een portable HD? Of is dat niet relevant en gaat het vooral om het verschil HD versus SSD?

Voor wat betreft de 'moet niet extreem lang offline' is het SSD vs magneet ,ongeacht 2.5 of 3.5" .

Maar nogmaals - lees de linken uit mijn eerste post 5-5 14:33 ) . Als je het plan van 1x per week gebruiken vasthoudt heb je totaal geen last van het vervliegen van data op een SSD .
Dat gaat pas spelen bij vele maanden op een warme plank .

Ik ben geen gegevens tegen gekomen mbt tot verschil in betrouwbaarheid (voor lange termijn opslag) tussen 3.5 en 2.5" magneet disken.
Ik heb een soort van vooroordeel dat fysiek groter misschien wat beter is (hoeft niet extreem dicht te zijn) - maar aan de andere kant , fysiek klein is wel wat voordeliger qua schok (/val) bestendigheid .
Mogelijk wel een verschil in levensduur bij druk gebruik - alleen dat speelt bij jou totaal niet .

Leuk om te lezen dat meer mensen zo'n strategie gebruiken!

Als alleen een back-up HDD kapot gaat, is dat geen groot probleem - zolang ik het origineel nog maar heb (naast de andere twee back-ups).

Vervelender is het als er "bad blocks" zouden ontstaan op de SSD in mijn computer (waar ook back-ups van o.a. mijn smartphones op staan, die meegaan in de reguliere back-ups naar de 3 externe HDD's).

Het is dan vooral lastiger te bepalen in welke files (of mapinhouden) die bad blocks zitten. Ik probeer dat toe te lichten, maar daarbij is het handig als je weet hoe FDE (Full Disk Encryption) werkt.

Full-disk encryption zit eenvoudiger in elkaar dan veel mensen denken: elke "sector" wordt onafhankelijk van de rest versleuteld. Effectief wordt het sectornummer (LBA = Logical Block Address) als "nonce" (number used once) gebruikt voor het bepalen van de "IV" (Initialisatie Vector) voor het te versleutelen blok. Dat zorgt ervoor dat als je twee (onversleutelde) sectors met identieke inhoud hebt, en deze met dezelde encryption-key versleutelt, de versleutelde sectors niet identiek zijn.

Zonder die, voor elke sector andere, IV zou sprake zijn van "ECB" (Electronic Cookbook Mode) en zou je, bijv. in een versleuteld plaatje van een penguin, kunnen zien dat het om een penguin gaat: https://words.filippo.io/the-ecb-penguin/ (tip: scroll naar beneden voor mooiere plaatjes!). Veiliger zou het zijn als je, voor elke te versleutelen sector, ergens bijv. 8 bytes opslag zou hebben waar je een random IV in zou kunnen opslaan - maar disks met blokken van 520 (i.p.v. 512) bytes worden, vziw, niet gemaakt. FDE is dus een compromis. Meestal wordt de XTS versleutelingsmodus gebruikt, zie https://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_(XTS) (met verhelderende plaatjes).

En er is nog een probleem: je hebt ook geen extra ruimte voor een cryptografische hash of (H)MAC (per sector, of evt. groep daarvan) om de integriteit mee te verifiëren. FDE is er dus uitsluitend voor het redelijk garanderen van vertrouwelijkheid.

Terzijde, essentieel daarbij is natuurlijk dat de gebruikte sleutel niet eenvoudig in verkeerde handen kan vallen. Als die sleutel onversleuteld, of zwak versleuteld met een PIN-code, in een kraakbare TPM staat (zie https://security.nl/posting/795475), dan heb je niet meer dan schijnveiligheid. En bij kortere/zwakke wachtwoorden speelt de gebruikte KDF (Key Derivation Function) en eventuele instellingen daarvan een grotere rol. Recentelijk bleek de eerste versie van LUKS dat, naar de huidige maatstaven, dat niet goed voor elkaar te hebben, zie "PSA: upgrade your LUKS key derivation function" in https://mjg59.dreamwidth.org/66429.html (bron: https://www.heise.de/news/Alte-LUKS-Container-unsicher-Ein-kleiner-Update-Ratgeber-8981054.html).

Terug naar "recovery": in elk geval bij oudere harde schijven was het zo dat als je leesfouten had op een sector, de schijf die niet automatisch remapte - totdat je een schrijfopdracht deed naar die sector. Nb. intern in harddisks zijn sectors groter dan 512 bytes, op z'n minst volgt er een CRC-code (Cyclic Redundancy Check, een "slimme" checksum) maar vaak ECC data (Error Correction Code) om kleine leesfouten on-the-fly te kunnen herstellen. Zonder speciale tools is het, op andere dan stokoude schijven, nauwelijks mogelijk om dat soort informatie van buiten de HDD uit te lezen, laat staan te wijzigen.

Hoe dan ook, het hangt af van het niveau waarop je recovery wilt doen. Als je bestanden wilt kunnen herstellen (op z'n minst uitvinden welke bestanden (deels) onleesbaar of beschadigd zijn), zal dit moeten gebeuren terwijl een besturingssysteem decrypted sectors leest, met de FDE driver actief dus.

Mocht mijn "basis SSD" leesproblemen krijgen met enkele sectors, dan kan ik zonder FDE driver actief scannen op bad blocks en die blokken proberen te remappen door er nullen (of willekeurige bytes) naar toe te schrijven (decrypted wordt dat sowieso semi-random). Daarna opstarten (FDE driver actief) en uitzoeken welke bestanden zijn gewijzigd of toegevoegd sinds de laatste back-up, en die "handmatig" inspecteren.

Als ik die SSD verder zou willen blijven gebruiken (onwaarschijnlijk) zou ik alle bestanden binair kunnen vergelijken met de laatste back-up, om uit te vinden welke beschadigd zijn; dan zou ik, vanaf die back-up, die bestanden moet terugzetten (en zo de corrupt geraakte versies overschrijven).

Kortom, ik maak mij geen grote zorgen (zolang ik maar vaak genoeg back-ups maak - en dat kan altijd beter ;-).

Waarom gebruik je dan geen filesystem wat hier wel voorzieningen voor heeft, zoals BTRFS?
Ik zou met moderne consumentenspullen zonder deugdelijke errorcorrectie ook niet zonder filesystem-level integrity
check willen hoor...

Ik gebruik voor bepaalde programma’s of OS geen usb maar een cd of dvd schijf dit om dat je daar niet meer
op kunt schrijven. Ik was aan het zoeken naar een dvd speler en kwam op onderstaande site terecht, dus lees
eens wat zij hier over schrijven. Ik wist niet dat die er waren en zijn ook niet interessant voor mij maar wie weet
misschien wel voor iemand anders daarom dat berichtje. Als je bijvoorbeeld een bekende Linux OS wilt gebruiken
is het veiliger om een dvd te gebruiken inplaats van waar het hier overgaat.

https://www.megekko.nl/product/2940/1710784/DVD-ReWriter-Extern/ASUS-Optical-ZenDrive-U9M-Goud

De vraag is wat de belangrijkste oorzaak (of oorzaken) van dat vroegtijdig "stuk" gaan is.

Bij voorkeur dien je bij SMR-drives alleen bestanden toe te voegen, dus wat dat betreft geschikt voor die manier van backuppen (incremental backup).
Maar wis je ook regelmatig bestanden dan wordt de boekhouding van zo'n type drive al snel bewerkelijk,
en gaat het schrijven langzamer, zodat het allemaal wel eens langer tot veel langer duurt dan je zelf denkt.
De kans bestaat dan dat je de PC al uitzet omdat jij zou denken dat het klaar is, terwijl in werkelijkheid de SMR HDD met zijn extra grote cache nog altijd bezig is met reorganiseren van de schijf om alle data goed op zijn plek te krijgen.
Zoiets kan kwalijke gevolgen hebben, want het schrijven en reorganiseren wordt plotseling afgebroken als de drive opeens zonder stroom komt te zitten, en er bestaat een kans dat de drive "helemaal de draad kwijt is". De firmware van de SMR-HDD moet daarom perfect zijn, en de status moet voortdurend worden bijgehouden en opgeslagen (in non voltile memory om later de draad weer op te kunnen pakken als er weer stroom is).
Bovendien krijgt zo'n drive het extra warm van al dat extra werk, en mijn ervaring is dat warmere drives eerder problemen gaan geven.

Voor de geïnteresseerden die zich afvragen waar de betrouwbaarste HDDs vandaan komen:
https://arstechnica.com/gadgets/2023/03/hdds-arent-as-durable-as-they-used-to-be-study-of-2007-damaged-drives-suggests/ waaruit ondermeer deze woorden:
(zoals ik dus al verwachtte)

Een filesystem zit op een ander niveau dan een block-device.

Wat ik bedoelde is dat een "evil maid", naast of in plaats van de boot-code te wijzigen, "blind" willekeurige sectors kan overschrijven (blind omdat die sectors versleuteld zijn en de aanvaller er geen idee van heeft tot welke onversleutelde inhoud een gewijzigde sector leidt). Het is waarschijnlijk vooral een theoretisch probleem, maar op het niveau van de FDE-driver vindt er, bij lezen, geen integriteitscheck plaats. We realiseren ons het wellicht niet, maar bij veel soorten versleuteling is zo'n check tevens "ingebouwd"; bij FDE is daar -letterlijk- geen ruimte voor (als een niet-versleutelde sector 512 bytes groot is, is een versleutelde sector dat ook).

Moderne en betaalbare consumentenspullen hebben bijvoorbeeld geen ECC DRAM-geheugen (en blijken o.a. kwetsbaar voor rowhammer attacks, zie bijv. https://arxiv.org/abs/2110.10291). Dus ná het lezen uit een filesystem kan een bestand alsnog -zonder waarschuwingen- corrupt raken.

Heel lang geleden had een kennis van mij grote problemen met een CD-lezer/brander. Na een hoop uitzoekwerk bleek buffergeheugen daarin defect: 1 bit wilde niet van waarde veranderen, waardoor dit zich, bij het lezen en branden van grotere bestanden, in elke 64KB of zo (ik weet de grootte niet meer precies) kon manifesteren. Als je een beetje nadenkt over de complexiteit en datadichtheid van moderne opslag, is het een wonder hoeveel er goed gaat.

Je weet dan waarschijnlijk niet dat BTRFS een "checksum" (je kunt het algorithme zelf kiezen) van ieder blok kan
bewaren in de filesystem data structuur. Dus als iets of iemand een datablok overschrijft dan zal als dit blok door
de applicatie gelezen wordt, BTRFS constateren dat deze checksum niet meer klopt en een error retourneren.
En als je RAID-1 hebt (binnen BTRFS, dus niet Linux-RAID) dan zal hij automatisch het blok proberen van de andere
disk te lezen, en als het daar nog wel goed is dan zal ie dat gebruiken en het andere blok repareren.
Je kunt ook een "scrub" operatie draaien die alle blokken controleert en waar mogelijk fixed.
Die checksum staat dus totaal ergens anders dan in het datablok zelf.


Precies, voor serieus gebruik moet je zeker ECC geheugen hebben. Mijn huidige systeem heeft dat niet, maar mijn
vorige systemen wel (ECC of Parity) en als ik weer wat nieuws ga kopen dan komt dat er zeker weer in.
Inderdaad jammer dat dit in desktop systemen niet gebruikelijk is, je komt er dan toch snel op om een ATX "server"
bord te moeten kopen.

Waarom geen FS waarbij de betrouwbaarheid van de disk minder belangrijk is?
Waarom geen RAID die niet klakkeloos non-stop inefficient coppieerd en enkel de disk verslijt?
Waarom geen checksums op data, zodat bij een fout te achterhalen valt wat juist is - i.p.v. fout kunnen gokken?

Niet te mooi om waar te zijn: ik kan het enkel hebben over ZFS' zraid
(danwel de cloon die Solaris' opkoper Oracle daar nog uit geforked heeft)

Bij mijn vorige NAS met 2x 3.5" in RAID1 gingen beide 1TB schijven 100.000+ uur mee.
Pas na 103.400 uur begon 1 van de 2 WD RED schijven slechts een paar bad sectors te vertonen.
De NAS wordt nu niet meer ondersteund, en werd erg traag, vandaar mijn nieuwe opzet:
- RAID6 op 4x 3.5" HDD (4T), waarvan 2 redundant (Ironwolf, maar WD was minder risicovol geweest)
- BRTFS voor 'zelfreparerend' bestandssysteem
- ECC 'zelfreparerend' geheugen
- NAS met alarmfuncties (smart-status, virusscanning, configuratie, firmware, etc)
- prullenbak functie (bestanden niet meteen weg wanneer je ze per abuis wist)

De 'key takeaway' is dat je er juist van uit moet gaan dat je schijven stuk gaan, waarbij je moet zorgen dat je op tijd zult zijn met vervanging.

Op het werk hebben we voor wat backups een Synology NAS met een WD en een Seagate schijf in RAID-1 (BTRFS).
Dan is de kans dat ze beiden ongeveer tegelijk stuk gaan veel kleiner.

Mee eens met Erik van Straten:
Redundantie in backups is uiterst belangrijk. Ik backup zelf op vier verschillende, vaak oudere, HDD schijven. Ik heb ze met VeraCrypt versleuteld en controleer regelmatig de SMART attributen. De HDD's zijn 3 tot 10 jaar oud en zijn tot dusver (voor zover ik kan nagaan) foutloos.

Ik gebruik de gewone 3,5 inch harde schijven die ik in een USB-BAY plaats. Uiterste voorzichtigheid is geboden vanwege de kwetsbaarheid van deze 3,5 inch schijven. Mij gaat dit goed af maar ik kan me voorstellen dat er mensen zijn die liever deze schijven in beschermende behuizingen zien.

In het verleden heb ik behoorlijk wat defecte HDD's gehad. Waren allemaal van SeaGate. Twee van deze SeaGate schijven gebruikten de SMR techniek en waren wel héél vlug defect.Ik waak er sindsdien voor deze techniek te mijden en speur in de specs voor ik een HDD aanschaf.

Vanwege de noodzaak SSD's regelmatig aan de stroom te moeten hangen backup ik er niet op. Ik heb verschillende malen problemen met SSD's gehad waardoor ik vermoed dat ze na een paar jaar minder betrouwbaar zijn. Jonge exemplaren zitten wel in mijn computer en dragen mijn originele files. Ik gebruik CrystalDiskInfo om de conditie van de schijven en SSD's te monitoren. Zodra er Bad Blocks optreden vervang ik de schijf of SSD direct en met urgentie.


Succes met backuppen!

@iemand hierboven


Btrfs staat bekend on mindere stabiliteit dan ext4fs.

Aan snapshots heb je niets als je filesystem zelf corrupt raakt door een Btrfs stabiliteitsissue.


Ik zou dit fs afraden voor stabiele backups. Het is wel handig op een desktop of ontwikkelomgeving waar je snel terug kan via Dr Btrfs snapshots. Maar maak nog steeds backups... You never know


Groetjes, satan333

Naar aanleiding van alle reacties het genoemde programma CrystalDiskInfo gedownload en mijn externe harde schijven hierin getest. Alle schijven "Goed" behalve eentje, deze geeft de volgende waarschuwingen:

- Rellocated sectors count = 2624
- Curent pending sector count = 16
- Uncorrectable secor count = 16

Heb me er in proberen te verdiepen online, en kom tot de conclussie dat vooral het hoge aantal Rellocated sectors counts betekent dat ik deze schijf beter zo snel mogelijk kan vervangen?

Ja dat zeiden ze ook altijd van ReiserFS. Ik weet niet waar dat dan vandaan komt, maar ik ben zowel met ReiserFS
(SuSE gepatchde versie) als met BTRFS (Synology en Debian) nog nooit wat kwijt geraakt. Ondanks veelvuldig gebruik
op allerlei verschillende systemen.
Misschien komen die verhalen uit landen waar 2 keer per dag de stroom uitvalt, dat is het scenario waarmee ik nooit
getest heb. Maar los daarvan geen centje pijn dus.

Andere mensen zweren weer bij ZFS maar "daar heb ik ook wel slechte verhalen over gehoord".
En ohja, toen ik voor het eerst BTRFS probeerde (vrij vroege versie) toen was nog een issue dat als je een hoop files
verwijderde, die ruimte niet meteen beschikbaar kwam voor nieuwe files. Daar moest dan eerst een of ander background
proces overheen, en dat ging even slapen als je druk aan het schrijven was. Dus dat kon problemen geven als je een
disk als bestemming voor backups gebruikte (zonder snapshots).
Maar dit heb ik al jaren niet meer gezien, ook omdat ik nu geen "bijna volle schijven" en "veel files verwijderen en nieuwe
erop zetten" scenario's bij de hand heb. Maar in dat geval werkte ext4fs beter (en Reiser nog beter!).

Ja dit zijn wel precise de fouttypes die failure aangeven. Of het begin van.


@satan333: Btrfs zou ik ook niet in een productie omgeving gebruiken. Het is een enorme zooi in de code en als de stabiliteit nu nog niet goed is dan is er iets fundamenteel mis met Btrfs. Genoeg mensen hebben zich gebrand. Gebruik liever xfs wat took snapshots kan...

Niet om te zeuren, maar het is relocated. De meeste schijven hebben reserve-sectors (in het langzaamste gebied van de schijf). Stel dat de controller in de harde schijf denkt dat sector nummer 123 onherstelbaar defect is ("pending"), en je schrijft ernaar, dan wordt deze "geremapped" naar één van de reservesectors (bijvoorbeeld met intern (fysiek) sectornummer 375926). Dit wordt reloceren (de locatie wijzigt) genoemd.

In een vertaaltabel (in Flash-geheugen, of, met veel risico, ergens op de schijf) wordt opgenomen dat als het besturingssysteem om sector 123 vraagt, dat intern sector 375926 gebruikt moet worden.

In jouw schijf zijn 16 "toegankelijke" sectors onleesbaar en, tot dusver, oncorrigeerbaar. Zodra je die overschrijft zullen ook die worden geremapped (relocated), mits er voldoende reservesectors zijn.

Een "uncorrectable" sector hoeft niet te betekenen dat een sector fysiek beschadigd is. Als je tijdens het schrijven de voedingsspanning weghaalt, kan het ook gebeuren dat 1 of meer sectors "niet afgemaakt" worden. Als die later worden gelezen zal dat vaak tot dezelfde foutmelding lijden: uncorrectable read.

Ik heb hier (vorige eeuw) ooit mee geëxperimenteerd, met een BIOS en een HDD die beiden "long read" en "long write" ondersteunden: daarmee lees en schrijf je inclusief de correctiedata, en bij lezen wordt er niets gecorrigeerd. Door opzettelijk een sector met hartstikke foute correctiedata te schrijven, en de sector daarna normaal te lezen, meldde de schijf "uncorrectable read" en werd de sector als "pending" geregistreerd. Door er vervolgens op de normale manier naar te schrijven, werd deze sector geremapped - terwijl er fysiek helemaal niets mis mee was.

Om te zorgen dat een schijf "uitgeschreven is", is het essentieel dat je externe schijven "unmount" voordat je de USB-stekker eruit trekt en wacht tot het besturingssysteem meldt dat de write-cache (in de computer) "geflushed" is (geheel naar schijf is weggeschreven). Ik vermoed dat als de schijf een interne write-cache heeft, dat de unmount ook niet lukt zolang die write cache niet geflushed is. Waarschijnlijk is de energie opgeslagen in één of meer condensatoren in de HDD, evt. gecombineerd met het als dynamo gebruiken van de nog draaiende schijven, net genoeg om de koppen in een veilige positie (los van de schijven) te parkeren, maar niet om eerst een write-cache leeg te schrijven.

Ik weet niet wat er met jouw schijf gebeurd is, maar reeds 2624 sectors geremapped klinkt wel veel. Als dat veroorzaakt wordt door mechanische problemen, een beschadigd schijfoppervlak en/of beschadigde lees/schrijfkoppen, kan de schijf ineens de geest geven. Als dat komt door onjuiste "unmounts", zou de schijf wellicht nog jaren mee kunnen gaan.

Wel is het zo dat je nu 16 onleesbare sectors hebt met mogelijk belangrijke data, en wat er mogelijk met die 2624 sectors (van waarschijnlijk 512 bytes elk) ooit verloren is gegaan, weet je ook niet.

Met bijvoorbeeld Total Commander (shareware, ik heb al jaren een licentie) kun je directory trees vergelijken, waarbij je ook "compare content" aan kunt zetten (dat kan vele uren duren, vooral bij langzame/oude USB). Door dat te draaien zie je wat de verschillen zijn tussen het origineel en de back-up (en als je bovenaan op het "=" symbooltje klikt verdwijnen alle regels voor identieke bestanden, en zie je de verschillen. Een rode "=' met een schuine streep erdoor betekent zelfde datum en tijd van laatste wijziging, maar binair verschillend. Als de bestanden even groot zijn kan één van de twee "beschadigd" zijn (alhoewel TC die rode = met schuine streep erdoor ook laat zien als TC geen leesrechten heeft op een van de bestanden (of beide), en bestanden kunnen zijn gewijzigd zonder dat de datum en tijd van laatste wijziging wordt bijgewerkt; o.a. Excel had hier vroeger (nu?) een handje van als je een bestand opende en niet bewust wegschreef).

Als de data op de schijf niet (meer) boeit, en je geen low-level testtool hebt, zou ik deze geheel overschrijven (eerst alle mappen en bestanden verwijderen en de prullenmand leegmaken, of een quick format doen) met H2TestW (gratis, [1]) en tevens daarmee testen op leesfouten. Dat programma is geschreven om te checken of een geheugenstick van opgegeven grootte daadwerkelijk zoveel flashgeheugen bevat, maar is ook erg handig om harddisks mee te testen (als je daar geen speciale tool voor hebt), of om de resterende schijfruimte (grotendeels) te overschrijven om zo de oude inhoud van "gewiste" bestanden ontoegankelijk te maken.

H2TestW werkt door, in een opgegeven map (een map aanmaken is verstandig, die kun je na afloop in 1x weggooien met inhoud), bestanden met een speciaal byte-patroon te schrijven - tot de schijf vol is (of totdat Windows liegt dat de schijf vol is om nog een beetje vrije ruimte over te laten). Daarna gaat H2TestW die bestanden lezen en meldt het als het verwachte byte-patroon niet klopt (waarbij Windows wel zal piepen bij een echte leesfout van de schijf).

Na H2TestW kun je CrystalDiskInfo nogmaals draaien: als relocated niet hoger is dan 2624 + 16 = 2640, en er geen nieuwe uncorrectables zijn bijgekomen, gaat de schijf mogelijk nog lang mee. Je kunt de schijf ook leegmaken en de tests herhalen.

[1] https://www.heise.de/download/product/h2testw-50539.

Iedereen die in de afgelopen jaren een Synology NAS gekocht heeft en in gebruik genomen heeft met default settings
die werkt met BTRFS. Als daar grote problemen mee waren dan zou dat wel algemeen bekend zijn.
Of het "een enorme zooi in de code is" dat is wat mij betreft geen criterium, het is een opinie ipv een feit, en
veel programmeurs vinden ALLE code die ze niet zelf gemaakt hebben "een enorme zooi".
Hetzelfde werd gezegd van ReiserFS en beiden heb ik tot zeer grote tevredenheid en zonder enig probleem gebruikt.

Zie: https://harddrivegeek.com/reallocated-sector-count/ :

Daarom concludeer ik voorzichtig het volgende:
Een paar dozijn reallocated sectors op je HDD hoeft geen enkel probleem te zijn. Maar let op dat het aantal niet snel groeit. Want zo'n snel groeiende toename kan een teken zijn van een HDD die zijn levenseinde dicht is genaderd.

Verder noem je een aantal reallocated sectors dat veel meer is dan een paar dozijn.
Het kan m.i. wijzen op de volgende oorzaken:

1. Misschien schakelde een gebruiker wel eens de stroom botweg uit terwijl computer/HDD nog niet helemaal klaar waren
en/of de stroom is uitgevallen terwijl de PC/HDD aan stond.
2. Bij één of meerdere niet-fatale disk-crash(es) is een flink aantal sectoren van de betreffende HDD beschadigd.
3. De levensduur van de HDD nadert mogelijk zijn einde al snel

Waar je op moet letten, is dat je de stroom niet uitschakelt vóórdat computer en HDD allebei helemaal klaar zijn.
Gebruik dus niet de power-knop om PC/HDD uit te schakelen, maar sluit eerst netjes af.

Als dit in orde is en het aantal reallocated sectors blijft snel verder groeien,
dan wordt waarschijnlijk dat de HDD zijn levensduur al behoorlijk is genaderd.

( Een vraagje: zit de betreffende HDD in de computerkast ingebouwd of betreft het een externe HDD? )

Stond in de eerste regel van z'n update :

Ik ken CrystalDiskInfo niet maar gebruik (op Linux) gsmartcontrol. Ik zie op de screenshots op hun website dat CrystalDiskInfo bij de S.M.A.R.T.-attributen de kolommen "current", "worst", "threshold" en "Raw values" toont. Gsmartcontrol geeft de eerste kolom een andere naam ("norm-ed value"), maar het komt op het zelfde neer, en dat programma geeft aan dat de raw value de echte telling is en de anderen door de schijfcontroller eruit zijn berekend. Het is de bedoeling is dat de eerste twee waarden niet op of onder de "threshold" komen. "Worst" is, zoals je zou verwachten, de slechtste waarde die is opgetreden gedurende de levensduur van de schijf. Als je daarnaar kijkt moet je een aardige indruk kunnen krijgen van hoe dicht je bij de gevarenzone zit.

Kijk ook een tijdje actief naar hoe de waarden zich ontwikkelen. Ik herinner me zelf een schijf te hebben gehad waar de "reallocated sector count" hoog was maar nog niet in de gevarenzone zat. Omdat ik niet goed wist of ik er al op moest reageren heb ik toen zowat dagelijks gekeken naar die waarde en zag ik dat die met de dag opliep, verontrustend snel dus. Dat maakte heel duidelijk dat ik die schijf snel moest vervangen, wat ik dan ook meteen heb gedaan.

Dit sluit aan bij wat anoniem van gisteren 22:26 schreef, maar ik heb een kanttekening bij:
De power-knoppen van systeemkasten en laptops zijn al heel lang geen simpele aan/uit-schakelaars meer. Als ik erop druk doet mijn systeem een nette shutdown, maar wat er precies gebeurt is configureerbaar. Een externe aan/uitschakelaar (bijvoorbeeld op een stekkerblok) is een ander verhaal, die moet je pas gebruiken als het systeem inderdaad netjes is afgesloten.

Ruk dus ook niet zomaar USB-drives eruit, maar ontkoppel die eerst netjes in je besturingssysteem, zodat je zeker weet dat je geen lopende schrijfacties afbreekt, en trek dan pas de stekker eruit (wat ook al is gezegd hierboven).

Is wel een heel oude computer als de boel niet netjes afgesloten wordt als je op de powerknop drukt...
(of je moet bedoelen de powerknop 5 seconden ingedrukt houden...)

Rellocated sector count is de naam van dit attribute in S.M.A.R.T.
Kan zijn dat je het er niet mee eens bent dat ze het zo noemen, maar het is wel normaal dat tooltjes om die attributes
weer te geven de officiele namen gebruiken... je komt dit overal tegen.

https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices
The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.


https://www.reddit.com/r/btrfs/comments/ybsqp0/is_btrfs_raid6_ok_now_in_2022/

Ik ga liever voor ZFS.

Oh, eerst had je het over BTRFS in het algemeen en nou heb je het over "corner cases in raid5/6".
Maar ik gebruik raid-1.


https://itsfoss.com/linus-torvalds-zfs/

Jullie slaan allebei de plank mis: het is reallocated.

Het beste is .....


ZFS met ZRAID-RAIDz1 of beter (raidz2/3)

Je hebt dan geen fsck meer nodig. Het is een zelfreparerend fs.

Je hebt het dan niet meer over schijven maar over pools.

Gaan er een paar stuk dan vervang je die. Elke 5 jaar alles vervangen.

ZFS is het enige 128 bit filesystem. Met snapshotting en zelfreparerend.

Je verliest dus bijna nooit data als je iets delete of verkeerd edit mits je snapshots inplant.


XFS is leuk maar mist bepaalde functionaliteit.

Bttrfs is onstabiel en het zal ook nooit wat worden..

Ext4fs is oud en vertrouwd maar kan in theorie nog crashen en dan moet je repairs gaan doen. Ook heeft dit traditionele fs geen COW.


COW is wel iets wat je anno 2023 zou moeten gebruiken. Ik werk zelf nog met ext4fs maar ik heb geen euro te besteden en mijn enige pc is uit 2012 .... Als ik geld had wist ik wel hoe ik iets in zou richten.

Gelukkig heb ik geen belangrijke data maar ik zou zfs doen met raidz1

ARS meldt problemen met recente SanDisk SDD's: https://arstechnica.com/gadgets/2023/05/sandisk-extreme-ssds-keep-abruptly-failing-firmware-fix-for-only-some-promised/

Thanks

Jakkes, dat ziet er niet best uit. Dit illustreert duidelijk waarom je jezelf niet van één apparaat en ook niet van één model apparaat afhankelijk moet maken, en ook op moet passen met verschillende modellen uit dezelfde familie.

Daarbij is SanDisk niet een of ander obscuur derderangs merk. Dit illustreert dus ook dat het niet zo simpel is als "met merk X zit je goed", het illustreert dat ook bij een goed merk wel eens iets grondig misgaat.

@topicstarter: Je moet dus niet je hele hebben en houwen op één paard wedden maar risico spreiden. Gebruik meerdere schijven, van verschillende merken en types, om dezelfde data meerdere keren te archiveren. Controleer periodiek of alles nog leesbaar is en inhoudelijk klopt, of de S.M.A.R.T.-attributen van de schijven aangeven dat er problemen zijn, en zet als daar aanleiding toe is de inhoud van een archiefschijf over naar een nieuwe.

De vraag of een specifiek type schijf nou wel of niet het beste is wat je kan krijgen is veel minder belangrijk dan de vraag of je bij verlies van zo'n schijf nog andere schijven hebt waar al je data op staat. Je werkwijze is belangrijker dan de precieze apparaten! Als jij goed in staat bent om op te vangen dat een schijf het begeeft dan is het daarmee meteen niet meer zo erg als die schijf het begeeft. Natuurlijk moet je ook niet bewust kiezen voor iets waarvan je makkelijk kan vinden dat het een model met problemen is, je moet problemen ook weer niet gaan opzoeken, maar ik maak mezelf liever afhankelijk van drie verschillende(!) schijven die op het oog wel behoorlijk uit de bus lijken te komen dan van één schijf die supergeweldig scoort.

Ik liep hier net tegen aan:

Fabrikant Verbatim kwam laatst met een speciale "write once"-SSD voor het maken van backups, die "by design"
maar één keer kan worden beschreven.
De verwachte overlevingsduur van de gebackupte data op deze drive is 10 jaar bij max. 55 graden celsius.
(bij voor de mens aangename temperaturen is de overlevingsduur naar mijn verwachting nog vele malen langer:
De hoge kwaliteit MLC geheugencellen die op deze SSD worden gebruikt, verouderen namelijk nauwelijks,
omdat elke geheugencel maar éénmaal kan worden beschreven.

De geheugencellen kunnen "by design" eenmalig worden beschreven met Windows 10 of 11 met speciaal geïnstalleerde software. Het heeft dus wel iets van een eenmalig beschrijfbare DVD, maar er past veeeeeel meer data op (128GB) en is robuuster.
(voorlopig alleen bij Verbatim Japan te verkrijgen?)

https://www.pcmag.com/news/verbatim-launches-a-write-once-128gb-portable-ssd
https://www.techspot.com/news/94447-verbatim-introduces-write-protected-external-ssd-10-year.html

Dank!

Over de zin/onzin van waterkoeling voor SSD's: https://www.theregister.com/2023/05/27/liquid_cooled_ssd/.

M.i. ook interessant leesvoer m.b.t. voedingsspanningsloze dataretentie: https://harddrivetalk.com/how-long-can-an-ssd-store-data-without-power/. Daaruit:
Ik heb er overigens geen idee van of dat klopt. Wel zal gelden: hoe vaker een cel is gewist en beschreven, hoe meer schade aan de isolatielaag van "de condensator" en dus hoe meer er van de (weinige, en bij nieuwere SSD's steeds minder) elektronen er kunnen weglekken - een effect dat wordt versterkt door hogere temperaturen.

Wat ik me afvraag of Industrial Grade WD hdds beter zijn.

Je hebt WD schijven in allerlei kleurtjes:

WD green - energiezuinig
WD black
WD red
WD purple
WD blue

en dit zijn de consumer schijven. Bijvoorbeeld de NAS schijven zijn niet bedoeld voor constant aan/uit zetten zoals de Desktop schijven. De desktop schijven zijn weer niet optimized om 24/7 te laten draaien of voor constante reads

Dan heb je ook de WD industrial schijven, die hetzelfde zijn als de kleurtjes hierboven maar betere kwaliteit componenten hebben op de print.

WD Gold en WD Black zijn de beste