Niet booten na stroomstoring: Einde verhaal?

[Sando]

In de meterkast hangt al een jaar of vijf een klein Super Micro bordje met NVMe opslag. In theorie is zo'n ding op een gegeven moment wel afgeschreven, maar de load is niet hoog, en de specs zijn voor mijn gebruik nog wel prima. Het gaat om een pricewatch: Supermicro X10SDV-4C-TLN4F met Debian Linux.

Na het uitvallen van de stroom start het servertje niet meer op. Op de oude VGA-monitor die ik erbij heb gesleept staat het volgende:

code:

Intel(R) Boot Agent GE v1.5.13
Copyright (C) 1997-2013, Intel Corporation

PXE-E61: Media test failure, check cable
PXE-M0F: Exiting Intel Boot Agent

Reboot and Select proper Boot device
or Insert Boot Media in selected boot device and press a key

Er gebeurt normaliter geen PXE boot. Waarschijnlijk probeert hij dat als fallback omdat het boot device niet gevonden kan worden. Ik kan wel starten vanaf een USB-stick. Dus volgens mij is het probleem met de NVMe-opslag of het BIOS gedeelte dat het opstarten daarvan regelt.

Ik wil graag weten wat ik kan proberen om antwoord te krijgen op de vraag: Is dit einde verhaal van dit bord, einde verhaal van deze NVMe, of nog geen einde verhaal?

---

Ik heb dit probleem de afgelopen jaren een keer of drie vier eerder gehad na een stroomstoring, en dan moest de computer een (paar) uur (geheel) van het stroom af waarna het weer werkte. Hoewel ik er inmiddels aan gewend was geraakt, kan ik niet verklaren waarom dat zo is. Ik weet wel dat 10 minuten wachten onvoldoende was. Mijn hypothese - gebaseerd een klein beetje kennis van elektrotechniek in combinatie met een groot gebrek aan kennis van moederborden - was dat dit bordje misschien in een verkeerde staat terecht is gekomen, en dat alle condensators geheel moeten ontladen voordat het moederbord weer compleet gereset is.

Bij dit type moederbord kom je in het boot menu door op F11 te drukken, en in de BIOS door op DEL te drukken en geduldig te zijn want die Super Micro bordjes van toen starten erg traag op. Ik heb handmatig van de verschillende opslagmedia proberen te starten, en ook proberen te starten zonder randapparatuur maar alleen de NVMe. Van de BIOS--instellingen zelf moet ik eerlijk zeggen dat ik er niet zoveel van begrijp.

Overigens heb ik bij de zoveelste stroomstoring een UPS besteld, alleen had ik dat in mijn enthousiasme bij Indiegogo gedaan, en die heb ik na een jaar nog steeds niet binnen. Het schijnt dat de eerste mensen hem deze maand ontvangen, maar dat was voor mij dus net even te laat.

[Lelletje]

Hij kan niet booten van de harde schijf. Daarom zoekt ie dan de PXE op (volgende in boot volgorde). Denk dat je NVME overleden is, je zou proberen met een andere schijf alles opnieuw erop te zetten om te kijken of alles goed blijft werken?

[Sando]

Lelletje schreef op maandag 28 maart 2022 @ 14:58:
Denk dat je NVME overleden is

Ik zou dus eigenlijk een soort externe USB NVMe-reader voor mijn laptop moeten hebben zoals je vroeger van die PATA- en SATA-connectors voor USB had, om dat nu als volgende stap te controleren. Ik zal even zoeken of dat ook bestaat voor een prijs die hoort bij iets wat je maar eens per jaar gebruikt.

edit:

Wow, je hebt dus echt heel veel soorten en maten USB-NVMe readers. Ik loop een beetje achter.

[ Voor 15% gewijzigd door Sando op 28-03-2022 15:17 ]

[Sando]

Update:

De NVMe is een SSDSCKJW120H6 pricewatch: Intel 535 M.2 80mm SSD 120GB

In de BIOS wordt deze weergegeven als Sandforce{200026bb} met 32kb opslagruimte. Dat is interessant. Toevallig kom ik met duckduckgo het volgende tegen:

I have a 535 ssd bought in Feb, 2016. Now my PC may reboot suddenly and in BIOS I see my drive's name becomes sandforce(200026BB)0.0GB.

I tried to shut down my pc's power for a while, and the ssd could be accessed again.

Interessant, dat is precies wat ik beschrijf. Alleen dit keer gaat het niet 'vanzelf over'. Iemand reageert:

I've got hundreds of Intel 535 SSDs and they randomly start having this occur after 1+ years of use. The "fix" seems to be to install a firmware that disables the DevSleep feature.

Het advies van Intel is om met deze flashtool de DevSleep modus van de NVMe uit te zetten.

Helaas is mijn NVMe nu niet meer te detecteren, dus werkt de tool niet. Ik denk dat de NVMe inderdaad kapot is. Ik wacht nog even op een NVMe-USB reader om het op een andere computer te proberen.

To be continued.

[Uszka]

Sando schreef op dinsdag 29 maart 2022 @ 02:21:
Update:

De NVMe is een SSDSCKJW120H6 pricewatch: Intel 535 M.2 80mm SSD 120GB

Dat is geen NVME maar een SATA M2 SSD dus mogelijk gaat het niet eens werken met een NVME-USB reader. Waarom stop je er niet gewoon een nieuwe , iets grotere NVME in? Zo heel veel kosten ze niet.

[ Voor 5% gewijzigd door Uszka op 29-03-2022 07:56 ]

[vanaalten]

Kan het zo iets simpels zijn als de BIOS die wat instellingen vergeten is zoals UEFI-boot of zo en hij een UEFI-schijf op ouderwetse BIOS-bootmanier probeert te starten?

[dion_b]

Dit gaat niet over Processors, Moederborden of Geheugen, maar over Opslag - en daar hebben we een apart subforum voor, Opslag & Backup:

Move PMG -> OB


Verder inhoudelijk:
Ik lees nergens dat je een CMOS clear of ESCD reset gedaan hebt. Gezien je zegt dat dit eerder gebeurde en de PC lang uit laten het probleem verhielp zou ik sowieos met ESCD reset (spanning van voeding, dan powerknop >10 sec ingedrukt houden) beginnen. Helpt dat niet, dan een CMOS clear (geheid met jumpertje).
Als dat alles niet helpt klinkt het als mogelijk defecte SATA (niet NVMe!) M.2 SSD, maar gezien eerdere problemen zou het ook een compatibility issue kunnen zijn. Ik zie alvast dit type niet op de M.2 QVL staan van Supermicro voor dit bord.

[FastFred]

Meestal als een SSD zijn einde bereikt heeft dan blijft die functioneren tot je een reboot doet, dan is ie gewoon stuk en is data niet meer benaderbaar. Dan krijg je dus ook die 'reboot or select proper boot device'

Interessant leesvoer: https://techreport.com/re...ssd-endurance-experiment/
En het vervolg waar bij diverse SSD's vermeld wordt wat er gebeurd als ze aan hun einde komen: https://techreport.com/re...periment-theyre-all-dead/

Intel’s 335 Series failed much earlier, though to be fair, it pulled the trigger itself. The drive’s media wear indicator ran out shortly after 700TB, signaling that the NAND’s write tolerance had been exceeded. Intel doesn’t have confidence in the drive at that point, so the 335 Series is designed to shift into read-only mode and then to brick itself when the power is cycled. Despite suffering just one reallocated sector, our sample dutifully followed the script. Data was accessible until a reboot prompted the drive to swallow its virtual cyanide pill.

[ Voor 52% gewijzigd door FastFred op 29-03-2022 13:57 ]

[Ben(V)]

Maak een bootable usb stick en boot daarvan je systeem.
Daarna kun je proberen of het uitzetten van die Devsleep helpt zoals intel adviseert.

[Sando]

Uszka schreef op dinsdag 29 maart 2022 @ 07:42:
[...]

Dat is geen NVME maar een SATA M2 SSD dus mogelijk gaat het niet eens werken met een NVME-USB reader.

Goed dat je het zegt! Ik bedoel, het is al te laat, er ligt thuis al een pakketje op de mat. Maar nu moet ik even goed opletten als ik een vervanging aanschaf.

Waarom stop je er niet gewoon een nieuwe , iets grotere NVME in? Zo heel veel kosten ze niet.

Omdat ik overweeg dan maar te wachten op de NUC 12 Pro of Performance. En/of op Ubuntu 22.04. De specs van mijn oude Super Micro zijn goed genoeg, maar wil er te zijner tijd eigenlijk wel een paar videocamera's op gaan aansluiten, misschien een stukje machine learning toepassen. Maar dit is plan B. Dan moet ik wel even goed opletten dat ik iets koop wat wel compatibel is met dit oude moederbord. Ik heb mogelijk ook al een verkeerde NVMe-USB-reader gekocht. 😅

dion_b schreef op dinsdag 29 maart 2022 @ 12:50:
Move PMG -> OB

Excuses. Toen ik dit topic begon dacht ik nog dat het aan het BIOS lag, en dat was in het verleden ook zo; Intel zegt in de gelinkte oplossing voor het Sandforce-probleem dat hun SSD-fix slechts een workaround is voor een fout in het BIOS op sommige moederborden: "On some motherboards the BIOS and OS are enabling the feature on affected drives, but the motherboard does not signal to wake the SSD back." Inmiddels lijkt inderdaad wel degelijk de SSD kapot te zijn.

[Ik zou] met ESCD reset (spanning van voeding, dan powerknop >10 sec ingedrukt houden) beginnen. Helpt dat niet, dan een CMOS clear (geheid met jumpertje).

Bedankt voor de tip! Ik ga thuis even kijken of die externe reader ook compatible is met deze SSD, want dat is makkelijker (omdat ik dan niet al mijn fan-profiles en andere vergeten instellingen kwijt ben). En zo niet dan is dit nu het nieuwe plan b.

[Het zou] ook een compatibility issue kunnen zijn. Ik zie alvast dit type niet op de M.2 QVL staan van Supermicro voor dit bord.

Dit linkje is handig bij de koop van een eventueel nieuwe opslag! Hiermee geef je meteen antwoord op de vraag die ik drie paragrafen terug stel. Ik heb er helemaal niet aan gedacht om dit op te zoeken. (5 jaar geleden ook niet.)

FastFred schreef op dinsdag 29 maart 2022 @ 13:30:
Meestal als een SSD zijn einde bereikt heeft dan blijft die functioneren tot je een reboot doet, dan is ie gewoon stuk en is data niet meer benaderbaar.

Wat lullig eigenlijk. De geheugenchips werken dan nog prima, maar de controller wil gewoon niet meer booten? Dit zou dan de derde SSD zijn van mij die zonder aanwijzing stuk gaat in een jaar of 10. Ik had me nog zo voorgenomen om het dit keer goed in te gaten te houden, maar heb het niet zien aankomen.

Zijn er al nieuwe best practices met SMART monitoring? Anders dan uiteraard backups maken. Ik heb wel backups van de belangrijke data, maar geen images gemaakt van het systeem. Ik zat er dus niet op te wachten om weer helemaal een OS te gaan installeren en uit te zoeken hoe ik de overige NICs ook alweer geconfigureerd had. Oh en de CRON-jobs. Ik moet toch wat meer systeem-instellingen in de backups gaan betrekken als ik geen images kan maken (24/7 online), want dat bespaart toch tijd!


To be continued.

[Sando]

@Uszka @dion_b overigens bedenk ik me dat ik nog ergens een backup NVMe van Samsung heb liggen, redelijk nieuw. Weet uit mijn hoofd niet welke precies. Maar er staan geen Samsungs op die lijst. Is het dan een slecht idee om te proberen?

[StarWing]

Ik meen mij te herinneren dat er indertijd met bepaalde sandforce controllers nogal wat problemen waren.

[dion_b]

Sando schreef op dinsdag 29 maart 2022 @ 16:45:
@Uszka @dion_b overigens bedenk ik me dat ik nog ergens een backup NVMe van Samsung heb liggen, redelijk nieuw. Weet uit mijn hoofd niet welke precies. Maar er staan geen Samsungs op die lijst. Is het dan een slecht idee om te proberen?

Als definitieve oplossing als je weet dat het aan SSD ligt: allicht beter eentje van QVL te nemen, maar om even te testen is het een prima keuze. Nee heb je, ja kun je krijgen.

[Sando]

Update:

De externe reader is deze: pricewatch: Sabrent USB 3.2 Type-C Tool-Free Enclosure for M.2 PCIe NVMe and ...
Hij ondersteunt ook SSD.

Op mijn laptop geeft deze Intel 535 ook aan dat hij maar 32KB groot is.

code:

$ sudo smartctl --all -d scsi /dev/sdc
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.13.0-37-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               Sabrent
Product:              
Revision:             1.00
Compliance:           SPC-4
User Capacity:        32.768 bytes [32,7 KB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is fully provisioned
Rotation Rate:        Solid State Device
Logical Unit id:      0x3001237923792379
Serial number:        0000000000000000
Device type:          disk
Local Time is:        Tue Mar 29 21:29:27 2022 CEST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

Device does not support Self Test logging

Uiteraard via de USB-reader dus de Vendor is Sabrent, maar ik kan ook geen testdisk draaien op "lege ruimte" die er niet is om partities terug te halen, en met andere tools kan ik er ook vrij weinig mee. Dus inderdaad einde verhaal voor deze SSD. Kan ik plan b (CMOS reset) ook overslaan.

Tijd voor plan c: nieuwe SSD of NVMe. Ik wacht even twee dagen op de beta van Ubuntu 22.04, dan heb ik twee jaar langer updates. Ik gebruikte eerst Debian om gewoon door te rollen, maar iedere keer als er een belangrijke kernel update was, ging dat toch wel gepaard met de nodige hoofdpijn wegens ZFS die bij Ubuntu een stukje flexibeler is.

Ben wel benieuwd wat de makkelijkste manier is om snel en veilig up en running te zijn met al mijn docker containers, maar dat is niet hardwaregerelateerd dus ik zal even googlen.

Zou ook wel willen weten of deze SSD zoals @FastFred als mogelijkheid noemt gewoon pech kapot was en dat hij het na elke vorm van power off niet meer zou doen, of dat het toch de stroomstoring was die hem kapot heeft gemaakt. In dat laatste geval moet ik misschien even zoeken naar speciale veiligheidsstekkers omdat het nog wel een maand of meer kan duren voordat ik mijn UPS heb.

[ Voor 7% gewijzigd door Sando op 29-03-2022 21:53 ]

[Thralas]

Sando schreef op dinsdag 29 maart 2022 @ 16:41:
Dit zou dan de derde SSD zijn van mij die zonder aanwijzing stuk gaat in een jaar of 10. Ik had me nog zo voorgenomen om het dit keer goed in te gaten te houden, maar heb het niet zien aankomen.

De boude waarheid is: dan had je geen SSD met een SandForce-controller uit 2010 moeten kopen. Zoals @StarWing zegt, SandForce heeft veel problemen gehad in het verleden, zeker rond die tijd waar de controller uit stamt (2010). Veel van die drives zijn inherent onbetrouwbaar door dit soort fratsen.

De discussie over compatibility of QVLs hierboven is ook niet echt relevant: het kan best dat je BIOS/UEFI de juiste voorwaarden schept om een bug te triggeren, maar in de basis is het simpel: als een SSD spontaan overlijdt op deze manier dan ligt dat uiteindelijk altijd aan de SSD.

Er is vaak ook weinig aan te doen als een SSD zich op deze manier presenteert: als je opeens de naam van de controller vendor in een PCI ID of SATA identifier ziet dan weet je genoeg, de disk draait dan niet meer de reguliere firmware, maar is beland in eoa. failsafe of bootrom van de disk controller. Dat je dan de reguliere capaciteit ook niet meer ziet is volstrekt logisch.

Weinig wat je dan met je machine kunt doen dat het zomaar zou kunnen verhelpen. Er zijn maar een paar uitzonderingen waarin er eoa. recovery-proces gaande is waarna zo'n disk zichzelf weer tot leven wekt. In een USB dock steken gaat er dus ook niets aan veranderen.

Specifiek voor jouw controller vond ik nog dit: How to unbrick a SandForce SSD waar men beschrijft hoe je met gelekte vendor tools van SandForce sommige SSDs opnieuw kunt flashen. Specifiek voor de SandForce controller die toevallig ook in jouw disk zit, en dat zal geen toeval zijn. Je data ben je natuurlijk sowieso kwijt.

Een andere M.2 SATA SSD gaat natuurlijk gewoon werken, ook jouw Samsung. Of hij op QVL staat of niet boeit niet (het is SATA, dat werkt in principe altijd) - of de disk zelf betrouwbaar is, is veel belangrijker.

[Sando]

Thralas schreef op dinsdag 29 maart 2022 @ 22:03:
[...]

Specifiek voor jouw controller vond ik nog dit: How to unbrick a SandForce SSD waar men beschrijft hoe je met gelekte vendor tools van SandForce sommige SSDs opnieuw kunt flashen. Specifiek voor de SandForce controller die toevallig ook in jouw disk zit, en dat zal geen toeval zijn.

Gaaf! Ik ga eens kijken of ik dat ook werkt via de externe reader. Niet dat ik deze SSD nog terug ga zetten, maar gewoon omdat het kan (of niet). Wel lame dat ik precies die controller heb. Je verwacht toch niet dat Intel zo lang crap blijft verkopen?

dan had je geen SSD met een SandForce-controller uit 2010 moeten kopen. Zoals @StarWing zegt, SandForce heeft veel problemen gehad in het verleden, zeker rond die tijd waar de controller uit stamt (2010).

Dat zou de logische conclusie kunnen zijn, maar zoals ik al aangaf: Niet iedereen weet dat Intel ook crap verkoopt en/of dat je onderzoek moet doen naar de controller van een opslagmedium. Ik dacht juist: Dan koop ik dit keer geen vaag merk maar gewoon een Intel, dan zit het wel goed.

Overigens bedoelde ik met het "dit keer goed in te gaten" houden eigenlijk het opzoeken van een tool om SMART-tests in te plannen en de resultaten te vergelijken en te mailen bij toenemende afwijkingen. Maar verder dan smartmontools die steeds de zelfde cijfers emailde kwam ik niet.

[Thralas]

Sando schreef op dinsdag 29 maart 2022 @ 22:30:
Gaaf! Ik ga eens kijken of ik dat ook werkt via de externe reader.

Die kans is vrijwel uitgesloten. Een enclosure is vaak USB mass storage, daar gaan geen SCSI commands overheen. Je SSD is ook relatief nieuw, dus ik zou kijken of het model uberhaupt voorkomt in die spreadsheet (de meeste modellen lijken ouder).

Wel lame dat ik precies die controller heb. Je verwacht toch niet dat Intel zo lang crap blijft verkopen?

Klopt. Dat is wel verneukeratief, want Intel is in principe een betrouwbaar merk. Maar de realiteit is dat deze SSD niet heel veel minder SandForce is dan een OCZ Vertex II.

SandForce heeft de controller gemaakt en alle firmware geschreven. Intel heeft misschien meer mogelijkheden voor QA dan een OEM SSD-relabeler, maar zal alsnog zelf niet zoveel met de controller doen.

Overigens bedoelde ik met het "dit keer goed in te gaten" houden eigenlijk het opzoeken van een tool om SMART-tests in te plannen en de resultaten te vergelijken en te mailen bij toenemende afwijkingen. Maar verder dan smartmontools die steeds de zelfde cijfers emailde kwam ik niet.

Mja, probleem van SSDs is dat ze (anders dan HDDs) relatief vaker geheel corrupt lijken te gaan. Zonder waarschuwing van enige SMART-indicator. Nu is dat wel vooral een probleem van SSDs uit 2010 (of zoals in dit geval: een controller uit die tijd) - tegenwoordig zijn dat soort rampzalige controllers grotendeels verleden tijd.

Ik zou inzetten op backups. Je zegt dat je dat vooralsnog niet toereikend voor je is - misschien is dit het moment om daar nog eens goed over na te denken.

Je had het al over ZFS, dus overweeg om je hele root filesystem op ZFS te zetten. Regel een backuptarget waar je minstens iedere 24u een snapshot van al je root pools heen stuurt. Daarmee kun je zo je hele machine recoveren als het noodlot toeslaat.

[Sando]

Thralas schreef op dinsdag 29 maart 2022 @ 23:01:

Die kans is vrijwel uitgesloten. Een enclosure is vaak USB mass storage, daar gaan geen SCSI commands overheen.

Tegenwoordig, of eigenlijk al een tijdje, sinds USB 3.0 oid, kan je steeds vaker USB enclosures aansluiten als UAS en dan SCSI commands sturen:

code:

$ sudo smartctl --all -d scsi /dev/sdc

Het werkt heel snel en prettig. Sneller dan in USB mass storage mode. Mits je een chipset van Intel hebt, want bij AMD gaat sinds ZEN+ fout.

Maar ik heb het al opgegeven. De kleine M.2 heeft op de positie van de verbinding die je moet shorten veel meer contactpunten, en bovendien kan de enclosure niet open en aangesloten op de USB-kabel tegelijk waardoor ik ook niet kan experimenteren met verschillende punten shorten. Ik ga nu de nieuwe Samsung erin schroeven.

Ik zou inzetten op backups. Je zegt dat je dat vooralsnog niet toereikend voor je is - misschien is dit het moment om daar nog eens goed over na te denken.

Ja dat klopt. Belangrijke bestanden heb ik wel geback-upt. Daar zijn veel relatief simpele oplossingen voor. Maar het systeem zelf dus niet.

Je had het al over ZFS, dus overweeg om je hele root filesystem op ZFS te zetten. Regel een backuptarget waar je minstens iedere 24u een snapshot van al je root pools heen stuurt.

Ik gebruik ZFS voor mechanische HDD's in RAID voor big data. Daar is ZFS een beetje voor gemaakt. Is het geen slecht idee om ZFS op je non-raid NVMe/SSD te gebruiken voor root?

[dion_b]

Sando schreef op dinsdag 29 maart 2022 @ 21:48:
[...]

Hij ondersteunt ook SSD.
[...]

Tijd voor plan c: nieuwe SSD of NVMe.

Je haalt je termen weer door elkaar...

SSD= Solid State Drive, opslag zonder draaiende delen. Zegt nog niets over interface. Kan SATA, NVMe of andere (PATA, SAS, SCSI) zijn.

NVMe: 'nieuwe' interfacestandaard voor opslagapparaten (meestal SSD). Feitelijk een rechtstreekse PCIe interface.
SATA: oudere interfacestandaard voor opslagapparaten (zowel SSD als HDD). Geent op oudere technieken (deels IDE, deels SCSI) voor schijven. Snel, maar trager dan NVMe.

Beide interfaces worden ondersteund op M.2 slots.

Alles wat je anno 2022 overweegt voor toepassing in M.2 slot is SSD. Enige vraag is of het SATA gaat zijn (zoals huidige SSD) of NVMe (zoals nieuwere).

Enige voordeel van SATA boven NVMe is bredere compatibility (in theorie), op alle andere vlakken is NVMe superieur, en er is ondertussen ook nauwelijks nog een prijsverschil. Als je iets nieuws koopt, kijk op QVL van Supermicro en tenzij er zwaarwegende redenen zijn, kies een NVMe drive die op de lijst staat.

[Sando]

dion_b schreef op woensdag 30 maart 2022 @ 07:58:
Je haalt je termen weer door elkaar...

Sando schreef op dinsdag 29 maart 2022 @ 21:48:
Hij ondersteunt ook SSD M.2 SATA.
[...]
Tijd voor plan c: nieuwe SSD M.2 SATA of NVMe M.2 NVMe SSD.

Wat een geluk. Ik had een image gemaakt een paar maanden terug met CloneZilla voordat ik een partitie ging vergroten. Dit image heb ik teruggezet op de Samsung NVMe-SSD die ik nog had liggen. Daarmee wilde de Super Micro niet booten, omdat SATA in legacy mode startte en NVMe alleen wordt ondersteund in UEFI.

Dus heb ik de MBR omgezet naar GPT, een EFI- en Grub-partitie aangemaakt, en Grub-efi geinstalleerd vanuit een chroot-omgeving. Deze guide was daar erg handig bij. De server start weer als een paar maanden terug!

Nu moet ik voorzichtig de docker containers controleren, want een Seafile of Syncthing met een status van een paar maanden terug zomaar weer opstarten, dat lijkt me vragen om problemen.

Nu kan ik de hardware upgrade nog even uitstellen, en even nadenken voor een backup-strategie voor het systeem zelf. Idealiter wil je gewoon je services meteen op een ander apparaat deployen, dus misschien is het "dockerizen van alles" ook een strategie om mee te beginnen.

Bedankt voor het meedenken iedereen!

[ Voor 13% gewijzigd door Sando op 30-03-2022 18:15 ]

[Thralas]

Sando schreef op woensdag 30 maart 2022 @ 00:02:
Tegenwoordig, of eigenlijk al een tijdje, sinds USB 3.0 oid, kan je steeds vaker USB enclosures aansluiten als UAS en dan SCSI commands sturen:

code:

$ sudo smartctl --all -d scsi /dev/sdc

Dat is helemaal waar. Alleen is m'n ervaring dat zaken als trim dan nog niet altijd werken. Misschien een gevolg van ATA vs. SCSI - de exacte verschillen en details zou ik je ook niet zo kunnen vertellen. Het is nog steeds niet helemaal native heb ik de indruk, waardoor ik verwacht dat zulke vendor tools er alsnog niets mee kunnen (al was het maar omdat die vast aannames doen dat het écht native ATA is).

Ik gebruik ZFS voor mechanische HDD's in RAID voor big data. Daar is ZFS een beetje voor gemaakt. Is het geen slecht idee om ZFS op je non-raid NVMe/SSD te gebruiken voor root?

Het is zeker geen slecht idee en dat het veel gebruikt wordt voor grote storage setups betekent niet dat er iets mis mee is voor single disk use. Solaris gebruikte het al als default filesystem (dus ook root) in 2011.

Er zijn wel een paar mitsen en maren, die van belang kunnen zijn:
• Je hebt een OS nodig met goede ondersteuning voor ZFS, zodat je niet het risico loopt op een kernel die (even) geen ZFS ondersteunt. Zit met Ubuntu wel goed, geloof ik.
• ZFS ondersteunt geen overlayfs, waardoor de default storage backend van docker niet werkt (relevante issue). Kun je omheen werken door de devicemapper backend te gebruiken, maar die is deprecated. Alternatief is een zvol met ext4/xfs voor docker aanmaken.

Als je daar mee uit de voeten kunt, dan heb je daarna een machine die extreem simpel te backuppen is, en bovendien ook nog kan nagaan of je data nog intact is.

[Sando]

Thralas schreef op vrijdag 1 april 2022 @ 22:57:
[...]

Als je daar mee uit de voeten kunt, dan heb je daarna een machine die extreem simpel te backuppen is, en bovendien ook nog kan nagaan of je data nog intact is.

Dat is misschien wel een goed idee, en ik ga dit overwegen. Maar ik zie nog wel twee moeilijkheden.

Grootste struikelblok is dat ik fscrypt gebruikt voor een encrypted home, en dat werkt alleen op ext4. Voor zover ik weet is er (nog steeds) geen PAM integratie voor een encrypted ZFS volume als home directory waarbij je login wachtwoord automatisch je ZFS mount. fscrypt was nu juist het ideale gebruikersvriendelijke alternatief voor het oude ecryptfs.

Het tweede probleem is dat je EFI en GRUB stage1 partities respectievelijk FAT32 en RAW moeten zijn. Dus je zult toch af en toe een offline image moeten maken. Dat maakt het nog steeds een interessante oplossing voor je root partitie, maar het is geen volledige oplossing voor je hele machine als ik het goed begrijp.

Hoe zou jij het trouwens aanpakken? Elke dag een recursive snapshot met zfs snapshot -r en dan een incremental backup met zfs send -RI en zfs receive -u?

Overigens gebruik ik gewoon de zfs storage driver van Docker, maar die is alleen beschikbaar voor de community edition, niet voor enterprise, heel vreemd. Maar misschien ook wel vanwege de licentie.

[Thralas]

Sando schreef op zaterdag 2 april 2022 @ 01:17:
Grootste struikelblok is dat ik fscrypt gebruikt voor een encrypted home, en dat werkt alleen op ext4. Voor zover ik weet is er (nog steeds) geen PAM integratie voor een encrypted ZFS volume als home directory waarbij je login wachtwoord automatisch je ZFS mount. fscrypt was nu juist het ideale gebruikersvriendelijke alternatief voor het oude ecryptfs.

Dat is een lastige. Meest voor de hand liggende alternatief is LUKS. Als je de machine niet hoeft te delen is dat zeker een goede oplossing.

ZFS ondersteunt ook per-dataset crypto, maar daar zou ik terughoudender mee zijn - daar zijn recent wat onfortuinlijke bugs in opgelost.

Het tweede probleem is dat je EFI en GRUB stage1 partities respectievelijk FAT32 en RAW moeten zijn. Dus je zult toch af en toe een offline image moeten maken. Dat maakt het nog steeds een interessante oplossing voor je root partitie, maar het is geen volledige oplossing voor je hele machine als ik het goed begrijp.

Scherp. Daar staat natuurlijk in principe alleen een kernel en/of een bootloader, met een reinstall van de kernel + bootloader vanuit een rescue image ben je er dan wel (heb je toch al nodig als je toch een ZFS pool wilt recoveren). Maar wel iets om rekening mee te houden inderdaad. Als je dat echt heel vervelend vind kun je natuurlijk een pre-backup cronjob of timer gebruiken om je hele ESP naar een file of zvol te kopiëren zodat hij op je zpool staat en dus wordt meegenomen in de backup.

Hoe zou jij het trouwens aanpakken? Elke dag een recursive snapshot met zfs snapshot -r en dan een incremental backup met zfs send -RI en zfs receive -u?

Ik gebruik zrepl om alle machines met ZFS dagelijks te snapshotten en remote op te slaan. Retentie (zowel lokaal als remote) is daarbij ook ingebouwd. Werkt als een trein.

En by default alle datasets backuppen, dat levert een stukje peace of mind dat je backups daadwerkelijk compleet zijn en is de meest veilige workflow. Datasets die écht groot en onbelangrijk zijn sluit ik expliciet uit.

Overigens gebruik ik gewoon de zfs storage driver van Docker, maar die is alleen beschikbaar voor de community edition, niet voor enterprise, heel vreemd. Maar misschien ook wel vanwege de licentie.

Hmm. Ik meen dat die traag was - maar als je daar niet tegenaanloopt in de praktijk, dan is het natuurlijk een prima alternatief.

[Sando]

Thralas schreef op zaterdag 2 april 2022 @ 22:54:
[...]

Bedankt voor de extra tips.
zrepl kende ik nog niet. Lijkt me erg handig. Hier ga ik wat beter naar kijken.