Inlägg

Nibe brukar ha en svag knappt kännbar upphöjning/klack eller skrovlighet på skalan på panelen bakom termostatratten där det motsvarar 60 grader C och man skall inte ställa den kallare än så pga. legionellarisken (som är störst när man duschar iom. kan inandas små dim-droppar med bakterierna i sig medans risken är mindre om vattnet är för handtvätt eller bad utan att använda duschen) - max uppvriden brukar det stanna på 85 - 90 grader C.

På beredarens vattenintag bruka det finnas en blandningsventil som blandar ut den heta vattnet (viktigt när den är ställd på 85 grader) och en säkerhetsventil - ökar du temperaturen på beredaren så bör också blandningsventilen justeras så att varmvattnet som går mot duschen och varmvattenkranarna att det ligger på ca 55 grader C efter en kort tids spolande för att det inte skall vara skållningsrisk om man bara tappar hetvatten utan kallvatteninblandning i tappstället/duschen, men det skall heller inte vara kallare än 50 grader C då risken för legionella-tillväxt ökar fort med även några grader kallare varmvatten i rören.

Samtidigt skall man kolla och spola genom säkerhetsventilen (en svart ratt man vrider med fjädrande känsla moturs på och tills man hör att det börja spola) då och då så att den fungera som tänkt, men också kolla avtappningsrörets ända att den inte börja småläcka och droppa pga. kalkpåslag i ventilen - missar man sådant under lång tid så kan sådan läckage ge väsentligt högre elräkning om det sipprar varmvatten hela tiden.

Just detta att varmvattnet inte är tillräckligt varm hela vägen i rören tillräckligt ofta mot rummen/lägenheter i typisk inkvartering och hotell och även på färjor är orsaken till legionella-larmen man ser då och då. Detta gäller också i fastigheter med långa sträckor mellan panncentral till tappställen - speciellt där det sällan används (sällan använda rum).

Elelementet som värmer vattnet är i regel samma med samma resistans oavsett om det är enfaskopplat (230 Volt - 1 kW) eller kopplad mellan två faser i en tre-fas system (400 Volt - 3 kW) - om en säkring är gången oavsett enfas eller den ena av trefas så slutar det med att det är ingen värme alls i beredaren.

Kalkningsrisken (pannsten) finns alltid om vattnet är hårt och den ökar med varmare vatten och när effekten ökar på samma elementyta mot vatten - dvs. 3 kW värmning med 2 av de tre faserna gör att kalkbildningen ökar mer på elementslingan än om man kör på en-fas med 1 kW värme. - och det kan bli väldigt mycket kalk i en beredare - jag mins från när jag var liten och på vägghängd 300 liters beredare i ladugården med element-haveri att vid byte av elementet så ramlade det ut mer än en hink med kalkbitar från elementet, ursprungligen och i slutet innan haveriet var elementet i stort sett begravd i en stor hög med kalkbitar som med tiden hade sprättats/sprängs iväg från elementet i ångexplosioner.

En teknisk miniräknare har funktionen Y^x - vilket menas Y*Y*Y*...*Y x antal gånger (och tillåter också att x kan vara flyttal)

alla skrivbara ASCII-tecken räknas till 95 st - 94 st om mellanslag undantas

Så för 12 tecken password kan skrivas som 94¹² - dvs 94*94*94*...*94 tolv gånger vilket ger en entropi på 425.9*10²¹ olika möjliga kombinationer. Dela detta med 1*10¹² (tester per sekund) * 3600 (antal sekunder på en timme) * 24 (timmar på dygn) * 365 (antal dagar på året) = 15091 år och för 50% chans att hitta rätt så måste man ha räknat igenom halva mängden kombinationer dvs. 7546 år om man gör 1000 miljarder tester i sekunden.

Skulle man prova med 13 tecken så är det 94 gånger mer kombinationer än vid 12 tecken, dvs. 94¹³ ger 447*10²³ olika kombinationer.

svårigheten att räkna igenom alla alternativ ökar markant - istället för 7546 år för att komma igenom 50% vid 1000 miljarder tester per sekund så tar det med 13 tecken nu 1.4 miljoner år att nå 50% för att man la till ett enda tecken i sin password.

Med diceware-passfras är det samma sak - där har man en ord-alfabete (ordlista) på 7776 poster att välja mellan

med 6 ord blir det då 7776⁶ = 221.1 * 10²¹ ger att det tar 7010 år att räkna igenom hela volymen med 1000 miljarder tester i sekunden och man når 50% vid 3505 år. - även om använda ordlista är publik och alla känner till den och vet att den användes för att skapa passfrasen - så hjälper det inte i försöken att kunna hacka det fortare om passfrasen är sant slumpmässigt framtagen.

skulle vi ha 7 ords passfras - slumpade ur diceware-alfabetet så blir det 7776⁷ = 1.719 * 10²⁷ kombinationer - om vi kör hela raddan ovan igen så är vi uppe i 54.5 miljoner år för att räkna igenom alla kombinationer och för 50% ligger man då 27.26 miljoner år.

med andra ord antalet tecken i password och antalet ord i passfrasen är kung när det gäller att göra det svårhackat - så länge man låter dessa slumpas fram maskinellt eller med fysiska processer som vitt brus i grunden (eller med fysiska tärningskast vilket var dicewares idé när det gäller att välja passfras).

- så fort hjärnan skall hitta på något 'slumpmässigt' så kanske angreppet bara tar dagar och veckor... då algoritmerna, reglerna och filtren i hashcat, john the ripper och en bunt till har med olika analyser av befintliga läckor hittat huvuddragen hur folk gör när de skapar password och provar med det först och lyckas väldigt ofta - för vi människor gör ungefär på samma sätt vid samma situationer och undviker väldigt många alternativ som man tror att man inte kan lära sig utantill (vilket är korrekt) vilket gör att en 85 bitar starkt password om det är maskinslumpat hamnar under 50 bitar i styrka och kan knäckas på dagar och veckor när den tänks ut av hjärnor för att vi för ofta tänker på samma sätt när vi forceras att skapa 'slumpmässiga' password och passfraser.

tillägg:

enligt https://haveibeenpwned.com så är det nu ca 12.96 miljarder läckta unika password

det motsvarar att man utnyttjat 0.00000000000002723 (2.723 * 10⁻¹⁴) -del av antalet möjliga kombinationer som har läckt gentemot antalet möjliga kombinationer som går att skapa med en 12-teckens password.

Det fins alltså ordentligt med armbågsutrymme för nya varianter av password på 12 tecken storlek som _inte_ fins med i listan innan man börja krocka med någon annan som skapar en likadan kombination.

Som tidigare nämnts är bra password något som maskingenereras - inte någon hittepå från huvudet - det ironiska är att en del passwordsregler faktiskt kan rejekta fullt valida slumpässigt genererade password då att få en sekvens som saknar symbol, siffror eller inte blandar stor och små tecken är faktiskt rätt stor - och reglerna som införs minskar passwords möjliga entropi just för att man styr hur det skall utformas.

Själv kör jag på https://www.passwordcard.org/en och utskrivna i kreditkortformat (dubbelsidigt med och utan symboler och flera stycken inklusive rena nummerserie för numeriska pinkoder att välja mellan) och inplastat som källa när jag behöver får fram en slumpsekvens för password som inte är tillverkad av en hjärna och ändå 'har den kvar' om något skulle strula senare. att kunna sådana saker utantill är orimligt utan man låter browsern eller en passwordshanterar hantera detta.

det är flera gånger jag har fått byta rad/kolumn just för att 'passwordseglerna' rejektar sekvens för att de inte uppfyller kraven fast det är fullt valida och lika möjliga slumpvisa teckenserier rent etropimässigt.

För tjänster man kan göra reset på så låter jag ofta browsern själv generera passordet och komma ihåg detta..

för mer viktiga password som till sin huvudsakliga mailbox och bör kunna lära sig utantill så använder jag av mig passfraser genererade av

https://diceware.rempe.us/#swedish

6 ord med skiljetecken mellan orden ger styrka för motsvarande 3000 års angreppstid med 1000 miljard försök per sekund. och är det keystretching i funktionen som tar emot passwordet även med bara några tusen iteringar så blir det snabbt orimligt att försöka göra attack på det även med väldigt stor budget - inte minst kostnaden för energiförbrukning för angreppet...

Dessa har jag också skrivit ut i excel och dubbelsidigt på samma sätt som passwordcard gjort en stor antal rader att välja mellan på båda sidor och man bestämmer själv vilken rad, kolumn, flera korta rader, diagonalt, några från varsin sida etc. vilken man faktiskt använder, vilket gör att en sådan upphittat kort så är det fortfarande svårt att kunna användas av någon annan då man också måste veta vad som används till vilken situation. Med andra ord nål i höstacksprincipen att vet man inte var nålen är placerad så är det mycket att leta.

Att sätta upp en kompileringsmiljö så att den fungerar med alla PATH:ar (vilket är troligen ditt problem om den inte hittar .c och .h-filer och senare olika .lib-filer) kan vara rätt styvt jobb bara det och kostar mycket mer av tiden än att senare kompilera själva koden...

På den tiden var det typ Borlands kompileringamiljöer som många använde medans 'Bloodshed Dev' är inget jag någonsin hört talas om och har säkert sina egenheter att fixa innan den kompileringsmiljön snurrar - du får läsa dess manualer helt enkelt för att se hur du sätter upp kompileringsmiljön...

Det är en av de stora fördelarna i Unix/linux-världen sedan historisk tid är att det nästan alltid fanns en CLI version av C-kompilator som fungerar med alla sina sökvägar korrekta (för det mesta i alla fall) medans i DOS och windows-världen har det aldrig funnits någon utvecklingsmiljö för C-kod som fungerar utan alltid i form av på den tiden ganska dyra köpevaror.

och skulle man försöka med GNU-C så var det oftast via cygwin det fick köras.

Det läggs säkert in en massa gucka i UEFI-partitionen som speglar den gamla installationen och därför återvänder till den föregående setupen även vid ominstallation.

Därför måste partitionerna bort helt och helst göra 'zerofill' en bit in, ja kanske hela disken för att ta bort alla spår av gammal data som windows kan upptäcka igen och försöka återanvända igen under installationen. Det är en gammal regel ända sedan DOS-tiden när DOS och winistallationer inte fungerar som det skall trots flertal ominstallationsförsök och oftast så fungerar det efter att en zerofill gjorts i början av disken - orsak okänd varför...

En annan destruktiv kommando för att ta bort gammal oönskad data för just ssd/nvme är att köra 'blkdiscard' i linuxmiljö - då skickar det 'TRIM'/discard-kommando för lagringens hela LBA-adressområde och är så nära en secure erase man kan komma utan att just göra det.

8 tecken är alldeles för lite, ger 52,4 bit entropi om man räknar med alla skrivbara ascii-tecken utom blanktecken (94⁸)

det kör man igenom fullständigt på 1 timme och 42 minute med en större GPU-rigg som kan testa 1000 miljarder tester i sekunden, några veckor på enklare riggar med kralliga GPU:er

redan vid 12 tecken maskinslumpat så tar det mer än 3000 år att komma igenom till hälften med 1000 miljarder tester i sekunden

minst 15 tecken, helst maskinslumpade om du kör på windowsdator av olika historiska orsaker där brytpunkten till (stor) osäkerhet är vid 14 tecken pga. historisk NTLM V.1 och SMB V.1 infrastruktur i windows.

Har du provat med annan OS startad från USB-sticka (tex ubuntu live) och se om problemet kvarstår, kvarstår problemet så är det förmodligen en HW-fel eller skada på den tryckkänsliga skärmen som till och ifrån trycker iväg tecken repetitivt eller med flerpunktstryck samtidigt blockerar dina tryck. Detta kan interferera även om du kopplar in annan extern tangentbord.

om du kan stänga av tryckkänsliga skärmen (eller stänga av dess drivrutin) - blir det annorlunda ??

Vad får du för IP om du genom 5G-routern fråga på https://www.myip.com/ eller motsvarande med en browser - är det olika gentemot vad router själv säger i IP-adress så kör du genom ett CGNAT:at nät i någon led och därmed inga möjlighet att öppna publika portar.

Disken har bara varit igång 6000 timmar drygt - det är inget tid att tala om då de flesta brukar lätt passera 45000 timmar och relativt många kan nå både 80 och 90000 timmar - det under förutsättning att disken inte stängs av och startas hela tiden utan går kontinuerligt och när de stängs av så är de avstängda för en längre period per gång och när de varva upp så är det igång en längre period. - just start och stopp ofta, sliter... - om man ser dina värden verkar du ha kört 3 timmar och 52 minuter per gång.

nu skall det tåla fler starter än så innan problem - men att man inte låter disken bara gå och gå är en tänkbar faktor till den korta livslängden.

Den andra är vibrationer i chassie från tex. fläktar och/eller flertal inte så välbalanserade snurrdiskar samtidigt - här skiljer det sig mellan server och enterprise-diskar och konsumentdiskar i avseende tålighet mot vibrationer. Som redan nämnt så är det lagret bär läs/skriv armen som till slut får pitting i lagerbanorna mot kulorna när det står och skakar på samma läsposition hela tiden - dock brukar det inte ske märkbart inom 6000 timmar...

Om man tittar vidare i SMART så verkar det vara skrivning som skiter sig sista tiden - det fins inget om läsfel registrerat som inte har kunna felrättas till korrekt data (C6), sedan har det hittat 24 sektorer som upplevs veka men fortfarande läsbara (C5) - dessa försvinner igen om man skriver över sagda sektorer med ny data och resultat är endera lyckad skrivning eller reallokerad sektor.

På SATA-diskar så rättas tveksamma läsbara sektorer enbart direkt vid skrivning då det verifieras samtidigt som det skrivs med ett läshuvud bakom skrivhuvudet ett antal hundra nanometrar i avstånd - aldrig senare efter skrivning när det väl är gjort, hur många omläsningar som görs senare på en vek svårläsbar men rättningsbar sektor - skall man ha sådana funktioner med automatisk rättning av veka men läsbara sektorer så får man titta på SAS-diskar.

Med tanke på att C5 och C4 har skjutit ordentligt iväg i antal och förmodligen mestadels bara dina sista timmar så låter det som läshuvudfel eller att man har problem med skivans yta - och ett problem som existerat är tex. avdunstad olja från spindelmotorn försegling och labyrint-tätning - även om dessa droppar är extremt små så är dess storlek många gånger högre än läshuvudets normala flyghöjd (mindre än 10 nanometer) över diskytan och ställer till stora problem liknade att man kör en Ferrari på en motorcrossbana i +200 km/h

om man kör i linux i terminal med 'smartctrl -x /dev/sdx' där sdx är någon av sda, sdb sdc etc. och alternativen av vilka lagringar man har och kallas, kan fås fram med 'lsblk', så får man ofta ut mer information än standard SMART då det också fins en extended version av SMART som ibland kan berätta lite mer info.

---

Rädda ut så många filer du kan och när du nått värdens ända så blir det att försöka med 'ddrescue' under linux att få ut en diskimage av disken - se till att det är 3 filargument - inte 2, den tredje filargumentet håller reda på var den sökte sist och inte läser om redan läst data (som i nästa försök kan vara oläsbar) - utan den så börja den från början vid var start.

ddrescue är tillräckligt smart att hoppa över en bit vid områden som visar läsfel och försöker ta datat som är läsbar en bit efter och först i slutet av processen ger sig tillbaka på områdena med läsproblem och saxar sig in tätare och tätare till att det kanske är bara enskilda sektorer kvar som inte går att läsa oavsett antal försök.

det fins de som kört ddrescue halvårsvis på snurrdisk, som vid första skanning bara gav 50% läsbart - men ett halvår senare har nått 99.999% och bara fåtal sektorer den inte kunna tagit, vilket i många fall är betydelselösa och kan vara oanvänd utrymme på filsystemet.

Kan du 7zip:a eller annan arkiverande kompressionsprogram ihop hela trädet och sedan lägga den på roten av USB-stickan, fungerar det då men inte filträdet som det är, så har du troligen problem med träd-djupen.

De flesta komprimerande arkiveringsprogram har också checksummor i sig så du märker om arkivet gått trasigt när du packar upp igen eller kör en integritetstest på arkivet.

lagring som ger fel på filer är bara att kasta eller att reklamera om det är värt besväret (dvs. om den är tillräckligt dyr).

Se upp också med fejk-lagring som är stora i lagringsmängd till orimligt lågt pris då dessa kan vika ned skrivningar till att de börjar skriva över från början och skriva över det som redan är skrivet i typiska i någon av när man skriver förbi 8,16 ,32 ,64, 128 GB gränser. - detta ger att slå länge du bara skriver en mindre mängd data så ser minnet att fungera men går korrupt så fort du skriver över 1/8, 1/4, 1/2 av storleken som stickan anger i utrymme...

om inköpet/märket är tveksam kolla med lämpliga program som testar för fejkade USB-stickor och SD-minnen som registrerar sig med större storlek än vad de egentligen är då dessa lägger ut olika mönster tills lagringen är full och sedan kontrollerar om samma datamönster dyker upp igen på annan LBA-adress där det inte borde...

Till och börja med - vad är det för extern disk, är det 3.5" eller 2.5"

I stort sett alla externa USB-diskar på 3.5" har en separat USB/SATA-kort injackad på diskens egentliga SATA-anslutning och får man krångel på en sådan så är det mycket större sannolikhet att det är adapterkortet som börja krångla än disken själv.

Är det krångel - tar ur disken och koppla in på din stationära dators standard SATA-anslutning - dock kan det finnas problem med sektorstorlekar om diskarna har sin härkomst typ 2012 - 2015 och överstiger 2 TB storlek där man använde logiska 4k-sektorer istället genererad av disken USB-chip för diskens fysiska 512-bytes sektorer och det är trixit att få ut data den vägen om det handlar om att rädda data - ja om man inte bara skall formatera om disken och har den som fast disk i datorn

Adapterkortet matas i regel med enbart 12 Volt och på kortet finns också en mindre spänningsomvandlare som ordnar fram 5 Volt för diskens logik - man tar inget eller väldigt lite ström från USB-anslutningen och är också förklaringen varför 3.5" diskar är okänsliga för långa USB-kablar.

Är det 2.5" disk så måste USB3-kabeln vara kort - inte längre än den som följde med när disken köptes ny - det fins en orsak varför kabeln alltid skickas med disken då så korta USB3-kablar kan vara knepiga att hitta i handeln, även när man behöver köpa ny i reserv då dessa kablar slits lite väl fort IMHO.

Krångel med USB 2.5" disk med oklar funktion beror ofta på att använda USB-kabeln börja glappa eller att man bytt till en längre sådan och det är för hög spänningsfall i kabeln (pga. dess längd då man inte har kompenserat den större längden med lika många gånger grövre koppar-area på ledarna som längden har ökats) eller dess kontakter för att disken skall ha tillräckligt hög och rätt spänning för att fungera bra.

Om kabeln är bytt och korrekt med kort längd så är nästa steg som kan krångla att det är USB/SATA-adaptern på disken och här är det val av märke väldigt avgörande om man kan rädda det hela - om vi tar det kort - är det Seagates diskar så kan man ta ur dessa diskar och koppla in dessa till en standard SATA-anslutning och datat fins okrypterat på disken - är det WD eller Toshiba så kan man inte göra det då dels har man USB/SATA-chipet intergrerat på diskkontrollerkortet och även om man kapar ledare efter USB/SATA-chipet och löder in tvinnade virtrådar (en per SATA-signalpar) på en SATA-kontakt så kommer man finna att all data på disken är krypterad. det går förstås att skriva ny data över det gamla men inte att avkoda det som redan finns där då krypteringen görs i själva USB/SATA-chipet med en upplevd falsk säkerhet men egentligen har så många kryphål planterade av olika länders säkerhetstjänster att det bara skyddar mot simpel okvalificerad stöld men inte avancerad angrepp från myndighetsnivå från vilken land vi än talar om...

om ni tycker att det är obefogad skitsnack att dessa självkrypterade enheter ger falsk trygghet så kan ni alltid läsa i denna rapport - förvisso ett antal år gammal numera men att det skulle ha blivit bättre idag är osannolikt då det inte finns någon intresse att skjuta i sina egna fötter och försvåra för sig själva från olika nationers säkerhetsstjänster...

https://eprint.iacr.org/2015/1002.pdf

tex. sidan 16-17 visar hur man hackat slumptalsgeneratorn för att alla slumptal den ger för att skapa krypteringsnyckeln skall vara möjliga att prova igenom samtliga kombinationer den kan generera på rimlig tid utan kännedom av vare sig använda password eller hur det hashas med eller utan salt och var den placeras på disken - det finns mycket annan mer 'försvagningar' kamouflerad som dålig hantverk i sin kodskrivning och buggar som försvagar krypteringen avsevärt - ja, om man känner till dessa, och typ var stor nation har sin egen bakväg...

I brist på bättre - använd veracrypt för data som du verkligen vill ha för dig själv, även på lagringar som marknadför sig som 'säkra' med kryptering.

Största problemet är att hitta USB-kablar som inte har hårfina ledare för 0 och 5 Volt och tekniskt sett skall den dimensionen ökas lika många gånger i koppararea som kabeln förlängs gentemot de ca 2-3 dm som följer med sladdarna till USB-lagring (både för USB2.5" snurrdisk och eSSD liknande som Samsung T7 där båda tycker om mycket ström under korta pulser) - och det vet vi allihopa att det sker helt enkelt inte med de USB-kablar man köper i handeln.

Med fungerande PD/QC-förhandling så kompenseras spänningsfallet i sladden vid olika strömmar så att det är rätt spänning på mottagarsidan i alla lägen - men vid ej förhandlad 5V-spänning som är standard på USB så har man problem med spänningsfall när stora strömslukande förbrukare koppas in i andra ändan (som 2.5" snurrdisk eller i det här fallet RPI3+) med ibland problem och osäkerhet i funktion så fort man försöker med längre USB-kabel av den typen man köper i handeln.

Original spänningsaggregat till RPI3 och även tidigare så har jag uppfattat dessa som 'förstärkta' - dvs har lite större ledardiameter i sina kablar för strömförsörjningen än kablar som köps i gubbdagisar just för att klara driften av RPI på säkert sätt med dom kabellängden som det levereras med.

Dvs. det kan fungera bra med orginal-aggregatet med dess kabellängd, men det fungerar inte lika säkert med en köpt kabel till en USB-laddare med> 3 Ampere kapacitet och lika lång kabel till sin RPI3+ - just för att använda köpta USB-kabeln har tunnare ledare och det enda sättet att få det att fungera säkrare är att välja en kortare USB-kabel.

du får formatera stickan till ExFAT eller NTFS om du skall ha över filer större än 4 GB/st - sedan fins det lite andra begränsningar i FAT32/VFAT som max filnamnslängd inkluderat sökvägens längd totala djup räknat i antal tecken, antal filer per mapp etc.

du har förmodligen minst strul om du formaterar till NTFS så länge du hanterar filer inom windows-världen

Skall du har en sektor-exakt kopia så är det 'dd', 'ddrescue' och tex. clonezilla startad från en iso laddat på USB-sticka som gäller.

Det som microsoft själva skapar, macrium reflect och flera kommersiella backupprogram under windows som kan göra en återställningsimage så gäller det bara MS egna partitionstyper medans en linuxpartition som också kanske finns med på disken - ignoreras.

Dessutom är diskimage som skapas av windows en VSS-kopia (Volume Shadow copy System), diskimage av en eller flera partition i svit och i samma status som om man fick en strömavbrott och kräver alltid reparation av OS även när den senare återställs - detta gäller i stort sett alla 'snapshot'-system där man tar kopia 'på sig själv' på sin egna systemdisk under körning att det är i status som vid plötslig strömavbrott.

Program som Macrium Reflect och övriga i windows körbara kommersiella diskimage/backupprogram och MS egna verktyg för systemåterställning mfl. använder sig av VSS för att få fram de olika partitionerna i snapshot-form som sedans gör backup av dessa i sina egna format (macrium har sitt eget, MS själva skapar VHDx-image + en knippe med olika hjälpfiler som skall beskriva hur de olika VHDx-filerna skall relatera sig mot varandra när en ny GPT-partitionstabell skall skapas vid återskapning av ursprungliga disken (exklusive eventuella linuxpartitioner...) för att det skall se hyffsat lika ut som orginaldisken)

VSS är en slags virtuell filsystem som ligger ovanpå NTFS ordinarier filsystem för att kunna få till snapshot-punkterna - NTFS själv har ingen snapshot-funktion utan detta implementerades som ett mellanlager mellan lägre nivå filsystem och systemanropslagret som ropar på olika lagringsresurser - diffarna som skapas efter när en snapshot tas läggs i den gömda mappen 'System Volume Information' på roten av disken och oftast inte tillgänglig att titta eller läsa i ens som administrator.

Ovanstående inlägg från @jnsson med varning på nedersta klippen att den kanske inte kan göra backup beror på att det är så lite plats kvar på disken att när VSS gör snapshot så kan diff-filen av olika ändringar och nyskrivningar som sker efter denna tidpunkt medans backuppprogrammet förlöper, bli så stor att det plötsligt måste ta bort snapshoten innan backupprogrammet hinner bli klar och man får då en misslyckad backup - förhoppningsvis med en massa felmeddelande så att det står klart för den som startade backuppen att backuppen har misslyckats.

- Det är just sådana saker som skiter sig ofta när man börja köra backup schemalagt och tror att man kan glömma det hela... - ingen ser när det skiter sig förrän det är försent och man börja leta fel och en backuprutin kan ha varit nere i månader, just för att det var trång på disken för att kunna slutföra en backup...

har det inte satts upp någon kryptering av diskinnehållet (och det gjorde man ogärna om man ville ha mer än 12 MB/s i överföring) så är det bara inloggnings-password till ett konto i NAS-OS:t dvs. det som ligger under /etc/shadow med i dagens ögon en ganska dålig hashvärde som md5/sha1.

sedan brukar man kunna göra en återställning av password till default med reserknappen i ett litet hål bak i enheten någonstanns - läs på innan dock så att det görs rätt tex. i avseende om resetknappen skall vara intryckt vid strömpåslag eller som uppstartad i hur många sekunder det skall vara intryckt. det fins olika moder med tex. intryckningslängder där varav några är potentiellt destruktiva...

mdadm lär nog fungerande fortfarande då det är en del av linux-kärnan - dock hjälpprogrammen för att administrera och få automount att fungera med 'udev' kanske måste laddas ned separat, men även med dessa installerade du få ingen auto-mount av partitionerna om du inte kopplar in båda diskarna samtidigt (det går utmärkt via SATA-USB-dockor eller adaptrar - Linux bryr sig inte om det går via SATA eller USB - hanteras lika ändå), utan det är manuell mickel för få det att att acceptera när en enda singel disk skall bli monterad, annars väntar och så småningom klagar att den andra disken saknas.

diskarna kan också ha varit i jbod/RAID0 och då krävs båda diskarna, så härja inte runt med dessa för mycket och helst skall ni jobba på diskimage av dessa.

observer att allt måste göras i Linux - glöm windows för sådana saker och windows kan tom. förvärra så att diskinnehållet blir oläsbar om man trycker på fel ruta/knapp när det poppar upp ruta att ny okänd enhet hittats - vill du formatera? ...

Är 'norrlandsblanding' en okänd begrepp hos er - dvs. kör med outblandad spolarvätska! eller åtminstone med mindre del med vatten typ 30-40% av volymen (för att kunna lösa salter mm. vilket går dåligt med helt ren sprit/spolarvätska)

det krävs 30% etanol för fryspunkt kring -19 grader, över 38% för att klara -30 grader C och för att klara -40 grader C behöver etanoldelen vara över 57%

vid 94% klarar man nedåt -118 grader C men vid 100% så höjs temperaturen igen till -110 grader C igen.

Med andra ord behöver det vara rejält kallt innan dunken med konc. spolarvätska fryser och då har man andra bekymmer att ta hand om innan dess.

Om det är en SATA SSD-disk så kan du prova med att _bara_ ansluta den breda spänningskabeln - inte den smala datakabeln, över natten. Det får inte känna av att något är anslutet eller svarar på sina dataledare om den skall börja köra en eventuell recovery-funktion och kanske hoppar igång igen - dock ingen garanti att datat fortfarande är intakt även om det ofta är så.

Med PCIe NVMe vet jag inte om de har liknande rescue-mekanism på samma sätt som SATA-SSD har på en del modeller, dvs spänningssätta utan att det är någon logik inkopplad på dess PCIe dataledare (går alltså inte att göra direkt i en M.2-adapter eftersom chippet i denna svarar på M.2:s PCIe-pinnar)

Om det är en M.2-disk så lever de helt på att moderkortet har stor resevoar av kapacitans så att spänningen sjunker tillräckligt långsamt så att kontrollern inne i M.2 hinner stuva undan data och lägga sig i en säker startpunkt innan spänningen blir för låg - har man inte denna kapacitiva reservoar (som tex. samsung T7 har i sin kapsling i form av 50 st parallellt kopplade kapacitiva keramiska kondingar på en hel kortsidan i sin kapsling) så får man det läget som du beskriver.

Samsung T7 och motsvarande modeller även från andra tillverkare är (förhoppningsvis) gjord att klara strömförsörjningsglapp i USB-kabel, vilket 99% av de de köpta externa M.2-adapter-lådor som man själv sätter i M.2-diskar i från tex Icebox och många fler _inte_ har i sig.

Med andra ord har man M.2 i en USB-adapter så bör man själv löda dit en elektrolyt på > 50 µF 6.3 Volt över + och - över USB 5 Volt-matningen _i_ kapslingen då de oftast inte har några kondigar alls i dessa och därmed kan en USB-glapp i samband med i och uttag ge katastrofala effekter av den sorten som du råkat ut för.

Om du måste rädda innehållet på aktuella minne[1] blir det att kontakta diskräddningsföretag typ IBAS och det kan kosta från 10 till 100 kkr eller så om det inte är enkla fel. Att rädda data från SSD/NVMe är ofta mycket dyrare än att rädda data från krachade hårddiskar numera (vilket historiskt bruka ligga runt 10 kkr om det inte är ett känd standardfel som man rutinmässigt hanterar och det kan då ligga på ungefär halva pengarna).

- jag skulle inte hoppas på att bara byta tex. kontrollerchip från likadan annan M.2-minne då skadorna förmodligen är logiska och beror på halvfärdig skriven flashdata som nu är helt korrupt för att man ryckte undan spänningen mitt under skrivandet och det kan gälla metadatat/FTL-lagret i M.2 då det är sådant som hela tiden uppdateras när enheten används och blir det intregitetsproblem där så kan det hela hänga sig.

[1]
Om man behöver göra sådant så har man redan fel datahanteringsstrategi - viktig data skall alltid finnas i minst 3 olika oberoende media och man gör en extra kopia innan man tar bort från någon annan media - det gäller också när man flyttar data mellan datorer - aldrig ta bort data ur källdatorn innan man vet att datat fins i oskadad skick på måldatorn + en oberoende lagring till, då överföringen med USB-sticka/eSSD anses osäker och kan förloras på vägen precis när som helst - och med högre sannolikhet ju viktigare datat är enligt murphys lag!.