[avrn]

Niisiis, on valmis teinud. Aga md0-ist on saanud md127 taaskord, osalisteks nüüd mõlemad kettad.
demesg-ist leidsin sellised read, mida nende ketastega oskan seostada:

Spoiler

scsi 4:0:0:0: Direct-Access ATA WDC WD60EFAX-68J 0A83 PQ: 0 ANSI: 5
[ 4.937543] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 4.937544] sd 4:0:0:0: [sdb] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 4.937545] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[ 4.937550] sd 4:0:0:0: [sdb] Write Protect is off
[ 4.937551] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 4.937559] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.937625] scsi 5:0:0:0: Direct-Access ATA WDC WD60EFAX-68J 0A83 PQ: 0 ANSI: 5
[ 4.937725] sd 5:0:0:0: [sdc] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 4.937726] sd 5:0:0:0: [sdc] 4096-byte physical blocks
[ 4.937731] sd 5:0:0:0: [sdc] Write Protect is off
[ 4.937732] sd 5:0:0:0: Attached scsi generic sg3 type 0
[ 4.937733] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 4.937740] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.970381] sd 4:0:0:0: [sdb] Attached SCSI disk
[ 4.971801] sd 5:0:0:0: [sdc] Attached SCSI disk
[ 5.043617] md/raid1:md127: not clean -- starting background reconstruction
[ 5.043618] md/raid1:md127: active with 2 out of 2 mirrors
[ 5.046240] random: fast init done
[ 5.049591] md127: detected capacity change from 0 to 6001039835136

Ei enamat. Samas ketastega tundub minu silma jaoks kõik õige olevat, kui see nimemuutus välja arvata.

Spoiler

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T disk
└─sda1 3,7T ext4 part /mnt/salv
sdb 5,5T linux_raid_member disk
└─md127 5,5T ext4 raid1
sdc 5,5T linux_raid_member disk
└─md127 5,5T ext4 raid1
sr0 1024M rom
nvme0n1 238,5G disk
├─nvme0n1p1 476M vfat part /boot/efi
├─nvme0n1p2 46,6G ext4 part /
└─nvme0n1p3 167,7G ext4 part /home
....................................................................................
sudo mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Sun Feb 18 15:56:18 2024
Raid Level : raid1
Array Size : 5860390464 (5588.90 GiB 6001.04 GB)
Used Dev Size : 5860390464 (5588.90 GiB 6001.04 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Mon Feb 19 05:45:06 2024
State : clean, resyncing (PENDING)
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : bitmap

Name : tvserver0:0 (local to host tvserver0)
UUID : 21bddd64:b85d3ce4:7c2f3c21:2d9f10be
Events : 71540

Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc

Ununes mainida, et masinas oli enne ka Raid1 väiksemate ketastega. fstabist vaatasin oli mountitud md0-na. Selle ma lammutasin ära eespool juba lingitud õpetuse järgi. Ehk võis sellest midagi maha jääda, mis anomaaliaid põhjustas?

[kaabakas]

See md0, md127 misiganes nimi ei ole väga püsiv, ära sellesse kiindu. Kasuta massiivi UUID, mitte nime järgi.
Mis seal lõppeks täpselt sassi läks, kes seda enam siin telefonimänguga kindlaks teeb.

[Dogbert]

Minu tagasihoidlike kogemuste järgi, kui ma õigesti mäletan, genereerib mdadm sellise nimega massiive automaatselt, kui leiab (bootimisel?) mingeid tundmatuid või hüljatud, aga superblocki sisaldavaid partitsioone. Ta võib neid äkki hüljatuks või tundmatuks pidada ehk ka siis, kui neid initrd.img sees sisalduvast mdadm.conf-ist ei leia bootimisel. Ei mäleta kahjuks nii detailselt.

Kui genereeritud /etc/mdadm/mdadm.conf failis on olemas kõik massiivid oma õigete nimede ja UUID-dega

Ja kustutad kasutamata partitsioonidelt superblockid, siis uuendad initramfs-i: update-initramfs -u

Siis vist selliseid kummitusi rohkem ei tekkinud...

Ahh, sa teed RAID-iks terved füüsilised kettad. Ma ei märganud seda.
Ma tavaliselt teen partitsioonidest.
Mitte et see midagi oluliselt muudaks.

[avrn]

Pole paar päeva olnud mahti tegelda .....
Kui ma seda /etc/mdadm/mdadm.conf uurisin, ei leidunud massiivide kohta mingit juttu.
Kas sellist infot hoitakse veel kuskil?

Seni olen jah terved kettad teinud raidiks. Kas ses mõttes on mingi vahe ka, kas teha kettad või partitsioonid? On emmal-kummal mingi eelis/miinus?

[napoleon]

/etc/mdadm.conf võiks miskit sellist sisaldada. See on näide, ära seda copy-paste kuna see ei tööta sul
ARRAY /dev/md0 metadata=1.2 name=ubuntu-server:0 UUID=cace0f92:58852682:b77b5e10:544425b0
ARRAY /dev/md1 metadata=1.2 name=ubuntu-server:1 UUID=910a2f03:6a9bd74d:e9b3109a:b05ec65e
ARRAY /dev/md2 metadata=1.2 name=ubuntu-server:2 UUID=10944e5d:61664682:624e7c53:093c7d22

mdadm --detail /dev/md0 või siis hetkel mdadm --detail /dev/md127 võiks sulle selle UUID anda, mis sinna käima peaks. (sudo ette kui vaja, ma ise ei viitsi enamasti käsureal nii toimetada, et iga käsu ette sudo panna kuna muud asja kui masina konfi näppima mul sinna nagunii pole väga)

[avrn]

Nüüd on jälle md0-ks tagasi keeranud end. Vahepeal on masin paar shutdowni ja starti üle elanud.

Lisan: Nüüd on igatahes ilusti toimetanud, rohkem pole end võõra nimega maskeerinud. Arvuti tunneb massiivi õigesti ära, väljajagatud kaustad on kenasti olemas ja kättesaadavad seal, kus vaja. Vaikselt asustan videomaterjaliga. Võib vist joone alla tõmmata.
Tänan kõiki, kes nõu andsid ja kaasa mõtlesid.

[Dogbert]

Automaatselt genereerib terve mdadm.conf faili skript /usr/share/mdadm/mkconf

/etc/mdadm/mdadm.conf ongi mdadm-i "mälu", kus ta muuhulgas massiivide nimesid hoiab. Kui seda ei salvesta, siis püsib loodud mdadm seadistus vaid järgmise rebootimiseni. Seejuures peab see konf sisalduma ka initramfs-is.
Bootimisel üritab mdadm avastatud superblockide järgi massiivi automaatselt taastada ja annab talle automaatselt nime, kui ta initramfs-ist konfi ei leia, kus avastatud superblockidega seadmed on nimetatud.

mkconf skripti väljund tuleb stdout-i, nii et pead ise selle õigesse faili suunama. Läbi sudo peab kasutama, muidu ei saa mdadm infot kätte.

Ma tavaliselt enne teen mdadm.conf-ist backupi, siis genereerin uue faili ja vaatan ta üle. Kuna mul on RAID massiivid tehtud ainult partitisioonidest, siis realt #DEVICE partitions eemaldan kommentaarimärgi. See peaks teoreetiliselt kiirendama bootimist, kui mujalt superblocke otsima ei pea automaatselt. Vaikimisi skännitakse ka konteiner-massiive (nagu ma aru saan, siis massiive, mille sees on teised massiivid, nagu vene matrjoška).
Sina võid sama teha, sest DEVICE partitions skännib ka füüsilisi kettaid

[avrn]

Väga põhjalik selgitus. Aitäh.
Tegelikult pakub mulle huvi tõesti ka OS-i enda peeglis ketastele paigaldamine. Seni ainult andmekettaid nii kasutanud. Tõsi, kunagi sai üks XP niimoodi käima pandud, küll riistvaralise Raid-kontrolleriga.
Kõneksoleva masina OS on juba vana (Ubuntu 18) ja peaks ehk uuemale liikuma.
Aga sellega kannatab, ootab 24-väljalaske ära, siis suve või sügise poole vaatab seda asja. Enne peab mõne vana masina peal katsetama.

[napoleon]

do-release-upgrade peaks upgrade suht valutult tegema. Kuigi nii vana puhul ei tea ka, võib kobiseda miskit.
OS kettad peeglisse saad installeriga isegi. ZFS puhul muidugi käsitöö, aga tavalise md softraid saad küll suht lihtsalt.

[Dogbert]

Ma mõtlesin, et OS on ka RAID peal. Kui ainult data, siis on lihtsam muidugi.

Aga ei ole väga keeruline töötavat Linuxit ka RAID mirrori peale kolida. Downtime põhimõtteliselt ainult rebootimise aeg.
Ma tegelikult olengi kõik RAID 1 pealt töötavad Debianid sedasi paigaldanud, et mdadm-i paigaldan alles siis kui OS on juba funktsionaalne. On kuidagi sedasi läinud lihtsalt...

Esimesel korral tegin puhtalt veebis oleva juhendi järgi, järgneval paaril korral oli ka juhend igaks juhuks kõrval, et mõnd etappi ei unustaks.

Võin homme juhendi üles otsida, seda enamasti uuendatakse iga uue Debiani releasi puhul või vähemalt üle ühe. Aga ega seal aastatega midagi muud muutunud ei olegi kui MBR-ilt ja BIOS-ilt GPT ja UEFI peale minek, nii et ainult partitsioneerimine ja GRUB paigaldus erinevad. Mdadm ja rsync on ikka samad ning need on selle protsessi juures peamised töövahendid.

Põhimõttelised etapid töötava süsteemi RAID 1-le migreerimisel on:

• teise füüsilise ketta lisamine ja süsteemiketta partitsioonitabeli kloonimine (või uue loomine uuele kettale), lisatud kettal kloonitud partitsioonide tüübi muutmine Linuxist RAID-iks
  
• mdadm paigaldus töötavasse süsteemi ja lisatud ketta partitsioonidest RAID 1 puuduva elemendiga massiivide moodustamine ning mdadm algse seadistuse salvestamine
  
• RAID 1 massiivide formaatimine ja mountimine ajutisse kataloogi samal viisil nagu nad on töötavas süsteemis, pm chroot ettevalmistuse etapp
  
• rsynciga töötava süsteemi kopeerimine lisatud RAID kettale, chroot kopeeritud süsteemi ja uuele kettale kopeeritud süsteemi /etc/fstab failis partitsioonide UUID-de muutmine RAID partitsioonide omaks
  
• chrootis GRUB paigaldus RAID kettale ja initrd värskendamine sealsamas
  
• poweroff ja süsteemiketta lahtiühendamine, bootimine RAID kettalt
  
• kui kõik sai tehtud õigesti, siis hakkab süsteem tööle
  
• uuelt RAID kettalt partitsioonitabeli kloonimine vanale kettale
  
• mdadm-is puuduva elemendiga RAID partitsioonidele puuduvate elementide lisamine vanal kettal asuvate partitsioonide näol. Mdadm sünkib need automaatselt.
  
• GRUB paigaldus/uuendamine ka vanale kettale
  
• mdadm uue konfi salvestamine ja GRUB ja initrd uuendamine
  
• reboot täieliku RAID 1 pealt süsteemi bootimise testimiseks
  
• poweroff ja uue ketta lahtiühendamine, ainult vanalt kettalt bootimise testimine
  
• uue ketta tagasiühendamine, RAID elementide tagasiühendamine/sünkimine mdadm-is
  

[Scott]

Ubuntus (konkreetselt juhtus Lubuntuga) tähtsaid faile välisele andmekandjale liigutades ei tohi kasutada cut and paste käsku, kui pole lisakoopiaid.

Liigutasin videofaile USB-adapteri abil välisele kettale, umbes poole peal korraks unmountis logiseva USB-mini ühenduse tõttu, jäi seisma ja aitas uuesti ühendamine. Aga seni liigutatud failid olid kustunud nii arvuti kettalt kui ka välisele kettale polnud salvestunud. Mis veel liigutamata, need olid arvutis alles.

Otsisin ja lugesin netist juhendeid, kuidas taastada, aga enam kusagil failidest jälge pole. Windowsis jäävad failid näha ja saab cut-käsu eemaldada ning failid ei kustu lähtekohast.

Mõned lingid:

https://askubuntu.com/questions/1263209/how-to-recover-files-lost-during-cut-and-paste
https://askubuntu.com/questions/132638/lost-some-files-after-i-cut-and-pasted-in-ubuntu-12-04
https://askubuntu.com/questions/25311/best-tool-to-recover-removed-files

https://www.itprotoday.com/software-development/how-undelete-files-ubuntu-3-tools-linux-data-recovery
https://medium.com/@prasanthmaverick/how-to-recover-deleted-files-in-ubuntu-254b0db19cb9
https://www.cgsecurity.org/wiki/TestDisk

[Dogbert]

Ei ole see move (ehk cut&paste) Windowsis ka eriti turvaline failide liigutamise meetod. NTFS-i pealt kustutatud faile taastada on natuke rohkem lootust küll, aga SSD peal asuvalt ehk mitte niiväga.

Ja välisele kettale mingi logiseva USB otsas move'iga faile liigutada on ise endale häda kaelatõmbamine täitsa sõltumata OS-ist.

[Scott]

Lahendasin nii, et panin SATA-juhtmega otse emaplaadi külge. Ja kui faili ülekanne katkeb või unmountib, tuleb dialoogiaknas Cancel vajutada ja igaks juhuks ka hiireklikk failidel. Siis lähevad hallid failiikoonid tumedaks tagasi ning failid säilivad algasukohas.


...


Üks teine mure ka. Lubuntuga ketas hakkab vigaseks minema ja peale kinnikiilumist on üks suur tekstifail katki . Just mõni minut enne lisasin sinna rea ja salvestasin ära. Proovisin igasuguseid taastevariante ja vaatasin hex-is, kuid sisu on jura täis ning üle 10000 reaga failist on alles 400+ rida, kuigi failisuurus on üle 100kB. Varasem koopia on olemas, kuid umbes poole aasta lisandused on läinud. Lugesin, et teoreetiliselt peaks kusagil olema eelmised versioonid laiendiga .old, kuid ei oska neid otsida.
On mingi lootus kasvõi nädalavanune koopia kätte saada või kas saab vigase faili taastada? Viimases kahtlen, sest hex-editoris pole algsest sisust jälgegi.

[kaabakas]

Häda sul on jamada nende vigaste ketastega. Play stupid games. Win stupid prizes.

[Scott]

kaabakas, päev kohe korda läinud, kui teise hädale on lajatatud Lootsin uut vastust nähes, et on ehk midagi abiks. Ja kust sa loed välja, et vigaste ketaste ladu mul siin on Üks ja ainus ning asjade migreerimine oli pooleli.

https://en.wikipedia.org/wiki/Foremost_(software) ei installeerunud. Extundelete tuleb teisele kettale panna ja siis uuritavat skannida.

Aga vist on lootusetu üritus. Muu on kõik alles, ainult see õnnetu tekstifail. Mitte miskit eluliselt tähtsat, vaid poole aasta jagu huvipakkuvate laulude nimesid ja mitu meetrit nalju ja häid ütlemisi kommentaariumitest ja foorumipostitustest.

[Supiplex]

[kaabakas]

Sul on kaks erinevat katkise ketta probleemi järjest, nii et kisub lao poole küll. Vaadates aastaid pealt, kuidas inimesed oma ketastest ja andmetest ei hooli, siis minu lähenemine kisub tõepoolest sinnapoole, et lajatada. Muu ei paista aitavat. Teisisõnu, abiks saab sulle olla sellega, et ehk tuleb õppetund ikkagi ära ja sa endale sama jama kolmandat korda ei korralda.
Kui failitabel katki on, siis on võimalus, et faili sisu on ketta peal ikkagi korras. Kui fail ise katki on, ja varukoopiaid pole, siis pole midagi teha. No põhimõtteliselt on ssd puhul lootus, et faili ei korrumpeerunud kettal seistes, vaid kirjutati prahiga üle ja sisu on alles puhtaks kirjutamata varusektorites. Kas ja kuidas nendest variantidest midagi õnnestuma saab on korraliku joppamise, nähtava vaeva, ja makstava raha küsimus.

[Scott]

Supiplex, kasutasin FeatherPad proget, see on lihtne proge põhiliste käskudega. Avasin ka LibreOfficega, kuid selle muudatuste halduse filtrilehel on vanemate versioonide valik hall ehk neid pole. Failiotsing kettalt andis vaid selle katkise faili (peidetud ja süsteemikaustad olid lubatud).

Kui faili vaatan, siis alguses on mitukümmend lehekülge trelle, kusjuures viies märk on mustas kestas valge küsimärk. Edasi hakkab segane tekst kooskorduva partitionkey sõnaga ja veebiaadressidega, mida olen külastanud, kuid mis ei sisaldunud algses failis (v.a. Youtube jms).
Viga sai alguse sellest, et hakkas Firefoxi lehitsedes jäätuma, kui mõni raskem leht avada ja mitmeid tabe korraga lahti oli. Resetiga tuli jälle üles, mõned korrad tegi Busybox failisüsteemi taastust. Ohu märk oli see, kui paar päeva tagasi brauseri detsembri seisu taastas. Eile õhtul jooksis samamoodi kinni. See tekstifail sai arvatavasti seepärast pihta, et olin sinna faili just lisanud ühe rea ja faili salvestanud, kuid mitte sulgenud.
Ketas on täis, kuid mitte pungil. Kahtlustan, et on vigaseid sektoreid ja brauser kirjutas failile peale.

kaabakas, ole hea, näita, kus see nö esimene ketta probleem mul on?

[Supiplex]

See FeatherPad mingit varukoopiat ei tee, seega pole failisüsteemist suurt mõtet otsida.

Sinu kirjeldusest järeldan ma, et see ketas on väga, väga perses. Kahjuks SSD puhul ei pääse tegelikult allolevale Flashile ligi, selle ees seisab SSD firmware mis otsustab ainuisikuliselt kuhu füüsilisse kiipi ja lehele andmeid kirjutatakse. Kui see enam oma tööga hakkama ei saa, pole suurt lootust et failisüsteemi recovery töötaks, sest ta peab samuti selle firmware käest asju küsimas käima.

Üldiselt tasub SSD-de puhul arvestada, et nad surevad üsna vähese etteteatamisega ja üsna lootusetu on sealt pärast midagi kätte saada. Mu eelmine Linuxi ketas, 480 GB Sandisk õnneks hoiatas ette - kernel leidis sealt mingeid I/O erroreid ja kupatas kogu failisüsteemi read-only režiimi. Veidi alla 10 aasta pidas kenasti vastu. Peale uue ketta ostmist panin ma igapäevase backupi käima

[napoleon]

Mida ext4(eeldan et kasutusel on see kuna Ubuntu puhul vist default) teeb kui mingi sektor loetamatuks muutub?
Üritab parandada ja keerab asja veel hullemini tuksi või teatab, et ei saa lugeda?

Muide tekstifaili puhul on päris suur lootus miskit üles leida kui mingeid sõnu/fraase mäletad ja nende järgi ketast skännima hakata

[Scott]

HDD on, mitte SDD.

Kettatuli jääb punaseks, veebilehed hanguvad. Oodata pole mõtet, teen reseti ja hakkab uuesti tööle. Mõned korrad on Busybox failisüsteemi taastanud ja kõik on alles jäänud. Aga nüüd on fail katki. Fail iseenesest pole ju kadunud, sisu on tuksis.

[XeStAiSy]

Linux on selline asi kui arvutil midagi viga siis linux ei toimeta windows on see mis peidab vead ära. HDD tänapäeval ei tasu osta kui juba SSD ilmus muutusid HDDd päris nigelaks. Eks see minemas HDD on. Või tõesti on mingi minemas USB mis kurja teeb.

[Scott]

USB antud juhtumis asjaosaline ei olnud, lihtsalt mõni siin loeb üle rea ja siis teeb "järeldusi".
HDD on vana ja kasutatud, süsteem sai tegelikult ajutiselt katsetamiseks pandud, aga nagu ikka, ajutisus kestis mitmeid aastaid. Ja nüüd, kui mõned videofailid kettale kirjutasin, leidis süsteem vigased kettasektorid üles ning kirjutas vajaliku faili katkisele kohale või pigem brauseri data tekstifaili peale.

[pppd]

ütleme nii, et tavakasutaja oskuste ja vahenditega on suht ebatõenäoline sealt midagi rohkem kätte saada, ketas ning failisüsteem on ilmselt mõlemad pihta saanud, imeväel (või mingi supersalajase käsu abil) neid ära enam ei paranda, ainuke mõistlik tee edasi oleks selle ketta edasisest piinamisest loobuda, ettevaatlikult üritada andmed maha kopeerida (soovitavalt vastava tehnikaga, hädapärast ddrescue, mõlemad nõuavad kogemusi) ja siis proovida klooni pealt võimalikult palju taastada. Kui andmetel on reaalne väärtus, siis pakutakse ka vastavat teenust, aga see on suht kallis ja mingit garantiid loomulikult ei anta. Kui aega palju ja viitsib nikerdada, siis loomulikult võib ka ise näpuvahel proovida.

[mina634]