Linux scripting in een native app

[R.G]

Mijn vraag
...
Ik merk dat wanneer logrotate zijn werk doet, dat e2fsck blijft hangen / zijn file handle verliest over de fixoutput.txt en dan niet meer zijn append kan doen en dan vast blijft hangen?

Probleem is de external destination kan volraken, we praten hier over systemen welke > 6tb aan data bevatten.

Ik wil af van het script en wil het eigenlijk dedicated onder brengen in een linux native app.
Zoals je bijvoorbeeld in kan typen curl - params.

Zoiets als hddfix -device -options -logfile

Hoe kan ik dat voor elkaar krijgen?

Relevante software en hardware die ik gebruik:
qnap Linux variant kernel 5.10.60
e2fsck_64 programma

command:

• e2fsck_64 -y -b 32768 -C 0 /dev/mapper/ > /share/external/DEV3304_1/logs/fixoutput.txt 2>&1 &

code:

e2fsck_64 -y -b 32768 -C 0 /dev/mapper/ > /share/external/DEV3304_1/logs/fixoutput.txt 2>&1 &

code:

Logrotate file:

/share/external/DEV3304_1/logs/fixoutput.txt {
    su admin administrators
    hourly
    size 14M
    copytruncate
    rotate 4
    compress
    missingok
    notifempty
    create 0640 admin administrators
}

cron job -e

0 * * * * /usr/sbin/logrotate /opt/logrotate/hddfix , dit is de logrotate file

...

Wat ik al gevonden of geprobeerd heb
Verschillende setups met en zonder logrotate.

Probleem is, e2fsch spit veel uit maar soms ook niks, overwriten verlies ik de data.
Wat ik wil doen is als de file groter wordt dan 500mb, dan truncate en zippen en verder gaan met een nieuew file.

Maar het programma dat daarheen schrijft crasht dan / gaat freezen. het is een background process.

enig idee of richting voor mij?


...

[ Voor 4% gewijzigd door R.G op 24-01-2025 13:47 ]

[Room42]

Ik heb zoveel 'waarom'-vragen, maar goed.

Ik denk dat jouw probleem opgelost is door het naar `split` te pipen:

e2fsck_64 -y -b 32768 -C 0 /dev/mapper/ 2>&1 | split -b 500M - /share/external/DEV3304_1/logs/fixoutput_ &

code:

split --help
Usage: split [OPTION]... [FILE [PREFIX]]
Output pieces of FILE to PREFIXaa, PREFIXab, ...;
default size is 1000 lines, and default PREFIX is 'x'.

With no FILE, or when FILE is -, read standard input.

Mandatory arguments to long options are mandatory for short options too.
  -a, --suffix-length=N   generate suffixes of length N (default 2)
      --additional-suffix=SUFFIX  append an additional SUFFIX to file names
  -b, --bytes=SIZE        put SIZE bytes per output file
  -C, --line-bytes=SIZE   put at most SIZE bytes of records per output file
  -d                      use numeric suffixes starting at 0, not alphabetic
      --numeric-suffixes[=FROM]  same as -d, but allow setting the start value
  -x                      use hex suffixes starting at 0, not alphabetic
      --hex-suffixes[=FROM]  same as -x, but allow setting the start value
  -e, --elide-empty-files  do not generate empty output files with '-n'
      --filter=COMMAND    write to shell COMMAND; file name is $FILE
  -l, --lines=NUMBER      put NUMBER lines/records per output file
  -n, --number=CHUNKS     generate CHUNKS output files; see explanation below
  -t, --separator=SEP     use SEP instead of newline as the record separator;
                            '\0' (zero) specifies the NUL character
  -u, --unbuffered        immediately copy input to output with '-n r/...'
      --verbose           print a diagnostic just before each
                            output file is opened
      --help        display this help and exit
      --version     output version information and exit

The SIZE argument is an integer and optional unit (example: 10K is 10*1024).
Units are K,M,G,T,P,E,Z,Y,R,Q (powers of 1024) or KB,MB,... (powers of 1000).
Binary prefixes can be used, too: KiB=K, MiB=M, and so on.

CHUNKS may be:
  N       split into N files based on size of input
  K/N     output Kth of N to stdout
  l/N     split into N files without splitting lines/records
  l/K/N   output Kth of N to stdout without splitting lines/records
  r/N     like 'l' but use round robin distribution
  r/K/N   likewise but only output Kth of N to stdout

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/split>
or available locally via: info '(coreutils) split invocation'

[ Voor 84% gewijzigd door Room42 op 24-01-2025 14:01 ]

[R.G]

Room42 schreef op vrijdag 24 januari 2025 @ 13:58:
Ik heb zoveel 'waarom'-vragen, maar goed.

Ik denk dat jouw probleem opgelost is door het naar `split` te pipen:

e2fsck_64 -y -b 32768 -C 0 /dev/mapper/ 2>&1 | split -b 500M - /share/external/DEV3304_1/logs/fixoutput_ &

[...]

Wil je dat ik dit test?
Momenteel loopt er namelijk een process en is ook zonde om te killen nu of wel doen?


zie afbeelding:

[ Voor 74% gewijzigd door R.G op 24-01-2025 14:52 ]

[BCC]

R.G schreef op vrijdag 24 januari 2025 @ 13:45:
Mijn vraag
...
Ik merk dat wanneer logrotate zijn werk doet, dat e2fsck blijft hangen / zijn file handle verliest over de fixoutput.txt en dan niet meer zijn append kan doen en dan vast blijft hangen?

Nee het is andersom - e2fs houd zn oude file handle vast terwijl logeotate zn log file onderuit schoffelt . Waarom draait e2fsck zo lang ?

[R.G]

BCC schreef op vrijdag 24 januari 2025 @ 14:51:
[...]

Nee het is andersom - e2fs houd zn oude file handle vast terwijl logeotate zn log file onderuit schoffelt . Waarom draait e2fsck zo lang ?

21tb raid op lvm niveau.

denk iets van 18tb gevult.

edit:


Ook vaag dat e2fsck dus files maakt in 2012 omdat de e2fsck tool uit 2012 komt?

[ Voor 40% gewijzigd door R.G op 24-01-2025 14:55 ]

[R.G]

- onnodige vraag.

[ Voor 88% gewijzigd door R.G op 24-01-2025 14:57 ]

[R.G]

output tot nu toe log is 357mb +

code:

Inode 338231876 has INDEX_FL flag set on filesystem without htree support. (ignorable)
Inode 338231872 has INDEX_FL flag set but is not a directory.
Inode 338231933 has INDEX_FL flag set but is not a directory.
Inode 338232339 has INDEX_FL flag set but is not a directory.
Inode 338231961 has INDEX_FL flag set but is not a directory.
Inode 338231865 has INDEX_FL flag set but is not a directory.
Inode 338231863 has INDEX_FL flag set but is not a directory.
Inode 338231315 has INDEX_FL flag set but is not a directory.
Inode 338232365 has INDEX_FL flag set but is not a directory.
Inode 338232370 has INDEX_FL flag set but is not a directory.
Inode 338232054 has INDEX_FL flag set but is not a directory.
Inode 338232051 has INDEX_FL flag set but is not a directory.
Inode 338231767 has INDEX_FL flag set but is not a directory.
Inode 338231957 has INDEX_FL flag set but is not a directory.
Inode 338231955 has INDEX_FL flag set but is not a directory.
Inode 338232078 has INDEX_FL flag set but is not a directory.
Inode 338231703 has INDEX_FL flag set but is not a directory.
Inode 338231699 has INDEX_FL flag set but is not a directory.
Inode 338231672 has INDEX_FL flag set but is not a directory.
Inode 338231941 has INDEX_FL flag set but is not a directory.
Inode 338231963 has INDEX_FL flag set but is not a directory.
Inode 338231420 has INDEX_FL flag set but is not a directory.
Inode 338231989 has INDEX_FL flag set but is not a directory.
Inode 338231637 has INDEX_FL flag set but is not a directory.
Inode 338231641 has INDEX_FL flag set but is not a directory.
Inode 338231610 has INDEX_FL flag set but is not a directory.



Illegal block number passed to ext2fs_test_block_bitmap #70118196959030 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #243595041882516 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #90930634873451 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #145449641437594 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #240658740558040 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #190146579776917 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #183116833841771 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #265388839612305 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #222608100935535 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #77927509664168 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #134152933224475 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #214300146577804 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #258746717925909 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #11081020180706 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #278817195906784 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #138567278024874 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #226294651728859 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #227431591696962 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #235642903657311 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #162799075772626 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #197588149264264 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #119915881603653 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #200907313558982 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #40617464212833 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #40368341097379 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #200181432599302 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #257873799298927 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #65888115384852 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #230024302231336 for multiply claimed block map
Multiply-claimed block(s) in inode 157745958: 1383597143


Pass 1D: Reconciling multiply-claimed blocks
(There are 28745 inodes containing multiply-claimed blocks.)

File bracket.jpg (inode #79954433, mod time Wed Dec 25 16:43:44 2013) 
  has 3 multiply-claimed block(s), shared with 1 file(s):
    ... (inode #327419232, mod time Mon Jun 30 13:27:57 2053)
Multiply-claimed blocks already reassigned or cloned.

File /filepath/das/a/a.txt (inode #79954434, mod time Wed Dec 25 16:43:44 2013) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    ... (inode #327419232, mod time Mon Jun 30 13:27:57 2053)
Multiply-claimed blocks already reassigned or cloned.

Dit is nu, hou rekening mee dit zijn wat stukjes uit de log om te late zien wat het doet.

[CH4OS]

Is het met zoveel data en gewenste redundancy niet wellicht beter om over te stappen op bijvoorbeeld ZFS of BTRFS? Dan ben je ook gelijk van het inode gebeuren af, vroeg of laat zal je denk ik wel daar tegenaan gaan lopen?

[R.G]

CH4OS schreef op vrijdag 24 januari 2025 @ 15:03:
Is het met zoveel data en gewenste redundancy niet wellicht beter om over te stappen op bijvoorbeeld ZFS of BTRFS? Dan ben je ook gelijk van het inode gebeuren af, vroeg of laat zal je denk ik wel daar tegenaan gaan lopen?

10000% agree,

maar restricted tot OS en hardware. Ik zit vast met exfat,ntfs,ext3,ext4.

dan mdamd software dat raid software heeft..

Dit is een gecrashed nas, waarbij stroom van hd af kapte en er is iets fout gegaan met het installeren van docker images waardoor de schijven corrupt zijn geraakt.

De data is nogal cruciaal.. ik probeer het met mijn software en devops skills op te lossen ben er al 2 jaar mee bezig

amper: tijd en komt veel tussen, nu even tijd en pogign wagen.

[ Voor 4% gewijzigd door R.G op 24-01-2025 15:07 ]

[R.G]

momenteel log analyzed en daarin zie ik dit van phases:

code:

Pass 1: Checking inodes, blocks, and sizes haalde 70%
Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Error reading block 86376448 (Input/output error).  Ignore error? yes


Pass 1D: Reconciling multiply-claimed blocks
(There are 28745 inodes containing multiply-claimed blocks.)

Dit is volgens de specificaties wat e2fsck doet:

Dus het is nog lang niet klaar? ik zit nog te klooien met de superblocks?

Kill ik hiermee mijn disks? Stel dat ik de data niet belangrijk vind is dan beter om te wipen en overnieuw te beginnen? En wat als stroom weer uitvalt?

code:

Lijst van e2fsck Checks en Passes:
Pass 1 - Check for superblock errors:

Doel: Controleert of de superblock (de metadata van het bestandssysteem) correct is. Het bepaalt belangrijke gegevens zoals de grootte van de inodes, blokken en andere parameters van het bestandssysteem.
Actie: Als er een probleem wordt gevonden, kan e2fsck proberen de superblock te herstellen vanaf een reservekopie.
Pass 2 - Check for inode errors:

Doel: Controleert de inodes, die de metadata van bestanden en directories bevatten.
Actie: Controleert of de inodes correct zijn en geen corrupte bestands- of directory-informatie bevatten. Het kan inodes herstellen door ze opnieuw te toewijzen aan de juiste bestanden.
Pass 3 - Check for directory errors:

Doel: Verifieert de directorystructuur van het bestandssysteem.
Actie: Controleert of de directories goed zijn gekoppeld aan hun respectieve inodes en of er geen dubbele of beschadigde directory-invoer is.
Pass 4 - Check for file data errors:

Doel: Controleert de bestandsgegevens en of de datablokken goed gekoppeld zijn aan de juiste inodes.
Actie: Als er blokken zijn die naar niet-bestaande inodes verwijzen of als ze niet correct zijn toegewezen, worden ze opnieuw toegewezen.
Pass 5 - Check for block allocation errors:

Doel: Verifieert de bloktoewijzing op het bestandssysteem.
Actie: Controleert of de blokken correct zijn toegewezen en of er geen "zwevende" blokken zijn (blokken die niet correct zijn gekoppeld aan bestanden of inodes). Verkeerde toewijzing wordt gecorrigeerd.
Pass 6 - Check for free block errors:

Doel: Verifieert de vrije blokken op het bestandssysteem.
Actie: Als er blokken in de vrije lijst staan die daadwerkelijk in gebruik zijn, of als er blokken in gebruik zijn die in de vrije lijst staan, wordt dit gecorrigeerd.
Pass 7 - Check for free inode errors:

Doel: Verifieert de vrije inodes.
Actie: Als er inodes zijn die als "vrij" gemarkeerd zijn maar die daadwerkelijk in gebruik zijn, of als inodes verkeerd worden gemarkeerd, worden ze gecorrigeerd.
Pass 8 - Check for orphaned inodes:

Doel: Controleert op wees-inodes (inodes die niet gekoppeld zijn aan een bestand of directory).
Actie: Als er inodes worden gevonden die niet naar een bestaand bestand of directory wijzen, worden ze vrijgegeven of opnieuw toegewezen.
Pass 9 - Check for duplicate blocks or blocks in use:

Doel: Verifieert of er duplicaatblokken zijn of blokken die onterecht worden gebruikt door verschillende bestanden.
Actie: Corrigeert de toewijzing door duplicaten te verwijderen of te herschrijven.
Pass 10 - Check for file system consistency and rebuild:

Doel: Voert een eindcontrole uit om te zorgen dat het bestandssysteem consistent is en dat alle gegevens correct zijn hersteld.

subpasses pass1:

code:

Pass 1: Checking Inodes, Blocks, and Sizes
Pass 1 controleert de superblock, inodes, en de blokken die aan deze inodes gekoppeld zijn. Binnen deze pass zijn de volgende sub-stappen aanwezig:

Pass 1a: Inode Consistency Check
Doel: Controleert de basale consistentie van inodes.
Acties:
Controleer de grootte van bestanden en of deze overeenkomt met de toewijzing in blokken.
Controleer op ongeldige inode-nummers.
Herstel inodes die inconsistent zijn.
Pass 1b: Checking Duplicate Blocks
Doel: Controleer of er blokken zijn die door meerdere inodes worden gebruikt.
Acties:
Zoek naar duplicaatbloktoewijzingen (bijvoorbeeld een bestand dat hetzelfde fysieke blok deelt met een ander bestand).
Corrigeer duplicaten door blokken opnieuw toe te wijzen of een bestand te herstellen naar een veilige staat.
Pass 1c: Invalid Block Numbers
Doel: Zoek naar blokken die buiten het bereik van de bestandssysteemgrenzen liggen.
Acties:
Verwijder of markeer blokken die buiten de partitiegrenzen vallen.
Controleer verwijzingen naar ontbrekende blokken of metadata.
Pass 1d: Unreferenced Inodes
Doel: Controleer op inodes die niet worden gebruikt of worden verwezen door het bestandssysteem.
Acties:
Identificeer inodes die geen koppelingen hebben met bestanden of directories.
Verplaats "wees-inodes" naar de lost+found directory.
Pass 1e: Block Allocation Consistency
Doel: Controleer of alle blokken die door inodes worden gebruikt correct zijn gemarkeerd in de blok-bitmap.
Acties:
Valideer blokken die als "gebruikt" zijn gemarkeerd.
Markeer blokken die ten onrechte als "vrij" worden beschouwd, maar worden gebruikt door inodes.

[ Voor 21% gewijzigd door R.G op 24-01-2025 15:16 ]

[lordgandalf]

Als ik het verhaal zo hoor dan klinkt dit bijna als een dingetje wat gewoon een gebed zonder einde gaat worden. Snap dat je zeg dat de data cruciaal is maar is het twee jaar tijd waard om die data terug te krijgen ?
En hoop dat je kopieën hebt gemaakt en dit nu niet doet op de actuele drives want dan kan het zijn dat je gewoon je schijven aan het destroyen bent. Voelt meer aan als iets wat een gespecialiseerd bedrijf moet gaan bekijken.

[R.G]

Geen idee is wel leuke uitdaging ook..

Wat vreemd is de mdadm raid is clean als state.

Ik kan de raid ook mounten maar zie dan amper data.

[CAPSLOCK2000]

Mijn advies is om per direct twee grote HD's te kopen en de data op laag niveau over te kopieren (bv met dd of ddrescue). Iedere actie die je doet heeft veel risico om de boel verder kapot te maken. Je zou alleen moeten werken met de kopie.

Als je er al twee jaar aan werkt lijkt de prijs van een HD (of liever 2) de moeite waard.

Als fsck foutmeldingen geeft als "Input/output error" dan gaat het waarschijnlijk niet meer goed komen omdat je fysieke schade hebt.

[RobIII]

Softwareontwikkeling -> Linux en overige clients

[R.G]

CAPSLOCK2000 schreef op vrijdag 24 januari 2025 @ 16:27:
Mijn advies is om per direct twee grote HD's te kopen en de data op laag niveau over te kopieren (bv met dd of ddrescue). Iedere actie die je doet heeft veel risico om de boel verder kapot te maken. Je zou alleen moeten werken met de kopie.

Als je er al twee jaar aan werkt lijkt de prijs van een HD (of liever 2) de moeite waard.

Als fsck foutmeldingen geeft als "Input/output error" dan gaat het waarschijnlijk niet meer goed komen omdat je fysieke schade hebt.

Ja, volgens mij is dat een software error.
Want gisteren deed ik harddisk testen en smart en was goed. voor alle drives. Dus de error is vaag.

[R.G]

CAPSLOCK2000 schreef op vrijdag 24 januari 2025 @ 16:27:
Mijn advies is om per direct twee grote HD's te kopen en de data op laag niveau over te kopieren (bv met dd of ddrescue). Iedere actie die je doet heeft veel risico om de boel verder kapot te maken. Je zou alleen moeten werken met de kopie.

Als je er al twee jaar aan werkt lijkt de prijs van een HD (of liever 2) de moeite waard.

Als fsck foutmeldingen geeft als "Input/output error" dan gaat het waarschijnlijk niet meer goed komen omdat je fysieke schade hebt.

Kan dat zomaar met dd?

Want het is een raid met multiple disks?

moet ik dan /dev/md1 dd naar een grote hardisk of kan dat in split mode?
Alleen hoe kan je dan repareren en scannen op 2 aparte HDS het gaat niet zomaar passen we praten hier over > 12tb

[CAPSLOCK2000]

R.G schreef op vrijdag 24 januari 2025 @ 16:47:
Ja, volgens mij is dat een software error.

Ik zou daar maar niet van uitgaan. Het is niet uitgesloten dat het een software-probleem is maar bij "Input/Ouptut error" moet je uitgaan van hardware.

R.G schreef op vrijdag 24 januari 2025 @ 16:48:
Kan dat zomaar met dd?

Want het is een raid met multiple disks?

moet ik dan /dev/md1 dd naar een grote hardisk of kan dat in split mode?

Het kan gesplitst maar ik zou het niet doen. Een enkele HD kan tegenwoordig meer dan 20T bevatten.
Eventueel kan je ook meerdere nieuwe schijven nemen en daar een nieuw RAID mee bouwen om je data daar op te zetten. In het kader van betrouwbaarheid is dat nog beter.

Dat kan met dd maar voor gevallen als deze is ddrescue waarschijnlijk de beter keuze. Dat is een zeer volhardende variant van dd die niet stopt bij fouten maar het stug doorgaat om zoveel mogelijk data te kopieren. Dat is met name handig als je fouten hebt die soms optreden en soms niet, zoals hier het geval ljijkt.

Alleen hoe kan je dan repareren en scannen op 2 aparte HDS het gaat niet zomaar passen we praten hier over > 12tb

Mijn advies om twee grote schijven te kopen is zodat je direct twee reservekopieen kan maken en je de oorspronkelijke schijven niet meer hoeft te gebruiken. Als je tijdens je herstelacties een fout maakt met de ene reservekopie kun je een nieuwe kopie maken van de tweede schijf in plaats van terug te moeten gaan naar de oorspronkelijke schijven.

Ik kan niet inschatten hoeveel dit project je waard is en of de kosten opwegen tegen de risico's, maar als die data belangrijk is moet je onmiddelijk stoppen die schijven te gebruiken en er zeker niet meer naar toe schrijven, ook niet met fsck.

[R.G]

CAPSLOCK2000 schreef op vrijdag 24 januari 2025 @ 17:06:
[...]

Ik zou daar maar niet van uitgaan. Het is niet uitgesloten dat het een software-probleem is maar bij "Input/Ouptut error" moet je uitgaan van hardware.


[...]

Het kan gesplitst maar ik zou het niet doen. Een enkele HD kan tegenwoordig meer dan 20T bevatten.
Eventueel kan je ook meerdere nieuwe schijven nemen en daar een nieuw RAID mee bouwen om je data daar op te zetten. In het kader van betrouwbaarheid is dat nog beter.

Dat kan met dd maar voor gevallen als deze is ddrescue waarschijnlijk de beter keuze. Dat is een zeer volhardende variant van dd die niet stopt bij fouten maar het stug doorgaat om zoveel mogelijk data te kopieren. Dat is met name handig als je fouten hebt die soms optreden en soms niet, zoals hier het geval ljijkt.


[...]


Mijn advies om twee grote schijven te kopen is zodat je direct twee reservekopieen kan maken en je de oorspronkelijke schijven niet meer hoeft te gebruiken. Als je tijdens je herstelacties een fout maakt met de ene reservekopie kun je een nieuwe kopie maken van de tweede schijf in plaats van terug te moeten gaan naar de oorspronkelijke schijven.

Ik kan niet inschatten hoeveel dit project je waard is en of de kosten opwegen tegen de risico's, maar als die data belangrijk is moet je onmiddelijk stoppen die schijven te gebruiken en er zeker niet meer naar toe schrijven, ook niet met fsck.

Hmm, ik denk dat dit echt lastig gaat worden.

Hoelang duur het kopieren wel niet en hoe ga ik dat koppelen het systeem heeft volgens mij usb2.0 dat gaat gigantisch lang duren?

Daarnaast, e2fsck zal toch moeten herstellen? Ik zie in de logging files voorkomen welke gezien worden?

Ik zie e2f2sck zoiets als op windows met disk error check en repair.

Daarnaast hoe kan ik 100% testen of de disks echt goed zijn?

Stel ik formateer de hele boel en maak een nieuwe raid , hoe kan ik dan testen of ik niet weer input / output errors krijg?

Kan dit voorkomen, als af en toe stroom naar de drives verloren gaat?

[CAPSLOCK2000]

R.G schreef op vrijdag 24 januari 2025 @ 18:05:
Hmm, ik denk dat dit echt lastig gaat worden.

Hoelang duur het kopieren wel niet en hoe ga ik dat koppelen het systeem heeft volgens mij usb2.0 dat gaat gigantisch lang duren?

USB-2 zou inderaad niet ideeal zijn. Maar de data kopieren en dan fsck draaien zou wel een sneller kunnen zijn dan proberen een defecte schijf te fsck'en.

Zelf zou ik de schijven uit de NAS halen en ze via een ander syteem kopieren maar dat moet maar net kunnen.

Daarnaast, e2fsck zal toch moeten herstellen? Ik zie in de logging files voorkomen welke gezien worden?

Ja, maar niet op schijven/hardware die stuk is, zoals ik vermoed.

Ik zie e2f2sck zoiets als op windows met disk error check en repair.

Dat klopt, dat moet je niet doen op defecte disks.
Data herstellen heeft uiteraard grenzen, er moet wel nog iets zijn om te herstellen. Als data eenmaal onleesbaar is zal herstellen niet lukken.

Daarnaast hoe kan ik 100% testen of de disks echt goed zijn?

100% bestaat niet.

Stel ik formateer de hele boel en maak een nieuwe raid , hoe kan ik dan testen of ik niet weer input / output errors krijg?

De boel een keer helemaal volschrijven met een disk-tester geeft wel een goede indruk.

Kan dit voorkomen, als af en toe stroom naar de drives verloren gaat?

Ja, het is niet heel waarschijnlijk maar ook niet onmogelijk.

Alles slijt en gaat ooit stuk. Harde schijven hebben de neiging om dat te laten zien op het moment dat ze opstarten, zelfs als de schade eerder is opgetreden. Als de stroom uitvalt en een apparaat opnieuw opstart is vaak het moment dat problemen zichtbaar worden, bv een motor die niet meer lekker opstart maar het wel nog goed doet als ie eenmaal op vaart is.


Als de waarde echt hoog is advieseer ik om een expert in te huren en de NAS uit te zetten tot die expert er is.
Niet echt het Tweakers-antwoord maar ik ben een beetje voorzichtig met mijn antwoorden omdat ik de situatie en de waarde van de data niet ken. De emotionele waarde van babyfoto's is nu eenmaal anders dan de financiele waarde van een zakelijke klantendatabase of zo iets. Ik wil je niet onnodig adviseren om enorme kosten te maken. Van de andere kant wil ik je ook geen onnodige risico's laten nemen als data meer waard is dan geld kan betalen.
Misschien is er geen andere realistische optie dan het maar proberen en hopen dat het goed komt.


Aangezien het al twee jaar duurt lijkt het met de directe financiele waarde wel mee te vallen maar dat kan en wil ik niet beoordelen.

[R.G]

Room42 schreef op vrijdag 24 januari 2025 @ 13:58:
Ik heb zoveel 'waarom'-vragen, maar goed.

Ik denk dat jouw probleem opgelost is door het naar `split` te pipen:

e2fsck_64 -y -b 32768 -C 0 /dev/mapper/ 2>&1 | split -b 500M - /share/external/DEV3304_1/logs/fixoutput_ &

[...]

Slim heb even nagecheckt:

code:

hoe weet e2fsck dat is hij dan niet zijn file handle kwijt ofzo ik merkte dit met logrotate dat e2fsck dan stopt
Je hebt gelijk dat het gebruik van logrotate kan leiden tot problemen met programma's die continu naar een logbestand schrijven. Wanneer logrotate een logbestand roteert, wordt het oude bestand hernoemd en een nieuw bestand aangemaakt. Als het programma dat naar het logbestand schrijft (zoals e2fsck) geen signaal krijgt om het nieuwe bestand te openen, blijft het naar het oude bestand schrijven, wat kan leiden tot problemen.

In jouw geval, omdat e2fsck zijn uitvoer naar split stuurt, wordt de uitvoer direct naar de gesplitste bestanden geschreven. split zorgt ervoor dat de uitvoer in stukken van 500 MB wordt opgesplitst en naar de juiste bestanden wordt geschreven. e2fsck zelf is zich niet bewust van de splitsing en blijft gewoon zijn uitvoer naar de standaarduitvoer (stdout) sturen, die door split wordt afgehandeld.

Als je problemen ondervindt met logrotate en e2fsck, kun je overwegen om e2fsck uit te voeren zonder logrotate actief, of om een andere methode te gebruiken om de uitvoer van e2fsck te beheren.

[Room42]

R.G schreef op zaterdag 25 januari 2025 @ 14:03:
[...]


Slim, heb even gecontroleerd:

hoe weet e2fsck dat is hij dan niet zijn file handle kwijt ofzo ik merkte dit met logrotate dat e2fsck dan stopt
Je hebt gelijk dat het gebruik van logrotate kan leiden tot problemen met programma's die continu naar een logbestand schrijven. Wanneer logrotate een logbestand roteert, wordt het oude bestand hernoemd en een nieuw bestand aangemaakt. Als het programma dat naar het logbestand schrijft (zoals e2fsck) geen signaal krijgt om het nieuwe bestand te openen, blijft het naar het oude bestand schrijven, wat kan leiden tot problemen.

In jouw geval, omdat e2fsck zijn uitvoer naar split stuurt, wordt de uitvoer direct naar de gesplitste bestanden geschreven. split zorgt ervoor dat de uitvoer in stukken van 500 MB wordt opgesplitst en naar de juiste bestanden wordt geschreven. e2fsck zelf is zich niet bewust van de splitsing en blijft gewoon zijn uitvoer naar de standaarduitvoer (stdout) sturen, die door split wordt afgehandeld.

Als je problemen ondervindt met logrotate en e2fsck, kun je overwegen om e2fsck uit te voeren zonder logrotate actief, of om een andere methode te gebruiken om de uitvoer van e2fsck te beheren.

Maar even in een quote, want zo met code tags is niet te lezen.

Maar goed, dat is duidelijk het antwoord ChatGPT. Wat wil jij er nou mee zeggen?

[lordgandalf]

je had twee jaar geleden al met dd een kopie moeten maken. dd of ddrescue doen dit ok. maken een bitwise kopie. De errors die je nu ziet lijken de schijven zelf te zijn en smart checked alleen de basis info zegt niks over het file system.

[R.G]

lordgandalf schreef op maandag 27 januari 2025 @ 08:56:
je had twee jaar geleden al met dd een kopie moeten maken. dd of ddrescue doen dit ok. maken een bitwise kopie. De errors die je nu ziet lijken de schijven zelf te zijn en smart checked alleen de basis info zegt niks over het file system.

Oke, ja maar bedoel je dat dan het file system kapot is of de schijven zelf?

Het is momenteel nog aan het ef2scken..

Als dit faalt, ik laat het gewoon uitdraaien dan heb ik er ook van geleerd denk ik?

Dan wis ik de boel of ik regel een extern linux systeem met mdamd en ga doen wat jullie zeggen ik moet even overwegen hoeveel dat kost en wat het opbrengt.

Probleem is, ik moet dan

4 schijven attachen om de gehele raid te koppelen en dan moet ik een dd backup maken van de 4 schijven naar image kunnen opslaan en nog een keer voor recovery plek van de data?

dus 6x4 = 24TB, x 3 + 2 TB speling ?

72TB + 2 TB = 74TB nodig m dit te gaan doen?

Dat is wel extreem..

[R.G]

zit nog hier:
Pass 1D: Reconciling multiply-claimed blocks
(There are 28745 inodes containing multiply-claimed blocks.)

[R.G]

has 1 multiply-claimed block(s), shared with 1 file(s):
... (inode #192158607, mod time Thu Feb 25 18:14:04 2066)
Multiply-claimed blocks already reassigned or cloned.

betekenis:
Dit betekent dat er één of meer blokken op de schijf zijn die ervoor zorgen dat meerdere bestanden worden geclaimd. In normale omstandigheden zou elk blok op de schijf alleen door één bestand gebruikt moeten worden. Als meerdere bestanden hetzelfde blok claimen, kan dit leiden tot problemen met data-integriteit en potentieel gevaar voor het verlies van gegevens.

[R.G]

code:

Het e2fsck-commando is een veelgebruikte tool voor het controleren en herstellen van ext2/3/4-bestandssystemen op Linux. Bij het uitvoeren van e2fsck doorloopt de tool verschillende "passes" (of stappen) als onderdeel van het herstelproces. Hieronder een overzicht van de veelvoorkomende passes en hun functies:

Pass 1: Check inode en superblock
Wat het doet: Verifieert de integriteit van de superblock en inodes. Het controleert ook de structuur van de bestandsstructuur en of de inodes geldig zijn.
Duur: Het kan enkele minuten duren, afhankelijk van de grootte van het bestandssysteem, maar in het algemeen is het relatief snel.

Pass 1A: Check indirect blocks
Wat het doet: Controleert op indirecte blokken en zorgt ervoor dat deze correct worden toegewezen aan de inodes.
Duur: Dit onderdeel is meestal ook snel, maar kan iets meer tijd kosten afhankelijk van het aantal inodes.

Pass 1B: Check directory-inhoud
Wat het doet: Controleert de inhoud van directories op ongeldig gebruik en zorgt ervoor dat alle directories voldoen aan de vereiste structuur.
Duur: Dit kan langer duren afhankelijk van de complexiteit van de directory-structuur.

Pass 1C: Controleren op dubbele verwijzingen
Wat het doet: Detecteert en rapporteert dubbele verwijzingen naar gegevensblokken die door meerdere inodes zijn geclaimd.
Duur: Dit kan aanzienlijk tijd kosten, vooral met veel gegevens en zeker met 18 TB aan data.

Pass 1D: Reconciliatie van multiply-geclaimde blokken
Wat het doet: Probeert de vermenigvuldigd geclaimde blokken te reconciliëren. Dit is waar het echt kan vastlopen als er veel conflicten zijn.
Duur: Dit kan lang duren, vooral met een groot aantal conflicterende inodes (zoals jouw 28.745).

Pass 2: Check en herstel Blocks
Wat het doet: Verifieert dat elk inode een logisch aantal gegevensblokken heeft en dat deze correct zijn toegewezen. Blokken die niet langer worden gebruikt, worden gemarkeerd als vrij.
Duur: Afhankelijk van de omvang van de gegevens kan dit enkele uren duren.

Pass 3: Check en herstel inodes
Wat het doet: Gaat door elke inode en controleert of deze correct is; defecte inodes kunnen worden hersteld of verwijderd.
Duur: Dit kan ook aanzienlijke tijd in beslag nemen, vooral bij grote bestanden.

Pass 4: Controleren en herstellen van de directory-strucuur
Wat het doet: Het controleert de integriteit van directories en zorgt ervoor dat ze goed zijn opgebouwd.
Duur: Dit kan variëren afhankelijk van het aantal directory-inhoud en interacties, maar kan ook enige tijd duren.

Pass 5: Controleren op inhoud van de gegevensblokken
Wat het doet: Verifieert of de gegevensblokken correct zijn en niet zijn verloren.
Duur: Dit is een tijdsintensievere stap, vooral met een uitgebreide dataset.
Totale tijdsduur
De totale tijd die e2fsck nodig heeft voor het (her)controleren en repareren van een bestandssysteem van 18 TB kan variëren van enkele uren tot dagen, afhankelijk van de conditie van het bestandssysteem, de snelheid van de schijven en de hardwarecapaciteiten. Het is niet ongebruikelijk dat dergelijke processen lang duren, vooral bij grote hoeveelheden data en als er veel schade is.

Conclusie
Als het proces enkele dagen aanhoudt, kan het de moeite waard zijn om te controleren of het systeem nog steeds aan het werk is (door bijvoorbeeld naar de schijfactiviteit of logs te kijken), of om ondersteuning van een deskundige te vragen. In sommige gevallen kan herstarten van het systeem of het proces nodig zijn, afhankelijk van mogelijke vastlopers.

[lordgandalf]

Het grootste probleem is dat fsck meer stuk kan maken dan je lief is. En meestal als je schijven hebt die gezeik opleveren dan maak ik een bitwise kopie om te voorkomen dat ik de schijf met de data kapot maak. Beter dat je de clone ruineerd dan de echte schijf. Maar goed vrees dat het daarvoor nu te laat is. En ja je kan ook raid arrays clonen maar je hebt net zoveel ruimte nodig als de disks groot zijn dus tja.

[RiDo78]

Ik denk dat je het antwoord van @CAPSLOCK2000 ter harte moet nemen. Voor ons is het niet mogelijk om een risico-inschatting te maken. Maar als je iets doet, doe het dan op een kopie van de disken. Ook weet ik niet om hoeveel disken het gaat en welke nas je hebt.

Ook zijn tip om de disken in een ander (krachtiger) systeem om te hangen is goud waard. Dus ALS je besluit om zelf aan de slag te gaan zou ik je daarom het volgende willen aanraden:
- Neem een normale PC waar het moederbord minimaal 1 harddisk-aansluitingen meer heeft als je NAS en plaats daar een schijf in waar je Linux op zet. (De distributie maakt niet heel veel uit, RedHat/CentOS Stream/Fedora of Debian/Ubuntu; ze kunnen allen met EXT4 overweg. Gebruik voor nu GEEN LVM of software-Raid (MDADM) op je systeemdisk.
- Zorg dat MDADM en eventueel LVM niet gestart kan worden, zodat er geen raid-markers / timestamps worden weggeschreven op disken. Doorgaans gebeurt dat alleen bij een succesvolle constructie van een raid-set, maar ik heb ook wel gezien dat het mis ging.
- Plaats een 1 oude en een 1 nieuwe disk uit je NAS in die machine en kopieer door middel van dd / ddrescue de data van de oude disk over naar de nieuwe. De nieuwe disk hoeft niet exact even groot te zijn, als hij maar even groot of groter zijn dan de oude. Verwijder de disken na het kopiëren en plaats weer een setje van een oude en een nieuwe disk. Net zolang tot alle disken gekopieerd zijn.
- Plaats de oude disken in een kluis (m.a.w. bewaar ze zorgvuldig) en plaats de nieuwe disken in de PC.
- Nu kun je MDADM en LVM wel inschakelen en zal MDADM als het goed is de raid-configuratie herkennen en de raidset kunnen bouwen.
- Als de raidset leeft dan kun je die herstellen met fsck. Je zult zien dat het sneller gaat dan met de oude disken; alle fysieke problemen die er waren met lezen zijn er al door DD uitgehaald. Wat rest zijn de filesystem-fouten.

Let wel, als e2fsck klaar is, dan is het filesystem in orde. Maar dat betekent NIET dat de bestanden zelf in orde zijn. Dus bijvoorbeeld een foto kan beschadigd zijn waardoor je alleen de bovenkant van de foto ziet en verder een grijs vlak. Dat is iets wat e2fsck niet kan zien. Verder kan het ook zijn dat bepaalde bestanden gewoon verdwenen zijn. Controleer daarom ook de lost+found folder in de root van het volume. Daar vind je bestanden in die e2fsck heeft gevonden maar waarvan het niet de meta-gegevens kon herstellen. Als een bestand daar niet in staat dan ben je het gewoon kwijt. Mogelijk kun je met tooltjes als PhotoRec nog proberen om dat van de originele disken af te schrapen, maar dat is een echte monnikenklus.

Eens je klaar bent met de recovery zou ik persoonlijk de data overzetten naar een beter filesystem, eentje die geschikt is voor grote volumes. En daar desnoods een PC of NAS bijzoeken die daarmee overweg kan.

En tot slot, heel cliché... maak backups!