Re: Linux Raid1: directories plotseling leeg
On Tue, 6 Sep 2022 20:00:03 + mailingli...@vanwingerde.net wrote: > > Dat zou ik ook met symlinks doen ja. Die --bind gebruik ik alleen > > wel eens als een chrooted dir een /dev en een /proc nodig heeft. > Symbolic linksd doern het niet via nfs. Zoals ik al zei, ik gebruik dat al jaren. > > > Als ik het mij goed herinner dan is er standaard een > > > bewakingsscript die dat doet. De `cat /proc/mdstat` is wel goed > > > startpunt om te onderzoeken wat er aan de hand. ( hint, hint, > > > hint ;-) > > > > Dat script draait iedere ochtend om 6:25 > > > > Subject: DegradedArray event on /dev/md/3:iomega1 > > > > En die stuurt je ook nog de output van /proc/mdstat mee. > Niks ontvangen. Misschien doet je mail het niet naar root of admin van die machine? Of het is ok en dan valt er niets te mailen uiteraard -- richard lucassen http://contact.xaq.nl/
Re: Linux Raid1: directories plotseling leeg
On Tue, 6 Sep 2022 19:57:47 + mailingli...@vanwingerde.net wrote: > > Die `mount -t none -o bind,verdere,opties /media/data/var/repository > > /var/repository` zou ik met een symbolic link doen, voor wat het > > waard is. > Symbolic links doen het niet via nfs. Dat is onhandig. Nou, bij mij werkt dat gewoon al jaren... -- richard lucassen http://contact.xaq.nl/
Re: Linux Raid1: directories plotseling leeg
Heren! Ik heb de server uit het netwerk gehaald en een en ander bekeken. mdadmin en fsck gaven geen problemen aan. Daarna tesdtdisk gedraaid. Die gaf het advies 'fsck.ext4 -p -b884736 -B 4096' te draaien. Ik voegde daar nog '-z fsck.txt'aan toe. Dit leverde een fsck.txt file van 57,9 MB op. In dit bestand staat niks bijzonders: heel veel 00 en ff en wat kleine flarden oninteressante logs. Ik trof dus geen resten van (mnetadata van) verdwenen bestanden aan. Nu 2,509 TB vrije plek aanwezig op de schijf. Eerst was dat 2,3 TB. Er is ongeveer 600 GB aan bestanden zoek. Ik had dus verwacht dat er nu 2,9 TB vrije plek aanwezig zou zijn. Op dit moment wordt de var-directory uit de laatste backup via usb > sata op een schijf gezet. Morgen zet ik een en ander terug. Daarna moet ik de var directory met 'cp -al' aan de laatste backup toevoegen om te voorkomen dat rsync 600 GB over de adsl-verbindingen gaat pompen. Ik heb dus geen duidelijke oorzaak van de crash van var gevonden. Er is 600 GB aan bestanden verdwenen, maar de beschreven schijf werd slechts 200 GB kleiner. Doeg, Jaap. Op 2022-09-02T12:41:48+ schreef mailingli...@vanwingerde.net in bericht , inzake: het volgende. > Heren (dames ook), > > Ik heb een servertje (met Debian 11) thuis met een aparte data > schijf: ext4. Deze software raid bestaat uit twee sata-schijven van 2x > 4 'TB'. Deze schijf is gemount naar /media/data/ en er is van 3,6 TB > nog 2,3 beschikbaar. > > Verder heb ik met bind een flink aantal directories naar het normale > bestandssysteem gemount. Dit gaat om bijvoorbeeld /home/jaap/data en > directories in /var, zoals /var/cache, var/repository, > /var/log, /var/lib/acme, /var/www-ssl en /var/music. Veel van deze > directories zijn ook met NFS vanaf de desktop computers in huis > bereibaar. > > Voorbeelden uit /etc/fstab: > /dev/md2 /media/data ext4 rw,relatime,lazytime,user_xattr,acl 02 > /media/data/var/repository /var/repository none > bind,relatime,lazytime,rw,suid,acl,user_xattr 0 0 > > Gisteren bleek dat alle directories in /media/data/var leeg waren. Dat > merkte ik omdat deze niet meer op mijn desktop computer verschenen. > Tot mijn stomme verbazing stonden de bestanden nog wel in de op de > server met bind gemounte directories, zoals /var/music. Volgen MDadm > was en is alles OK. DE smart status van de schijven is ook goed. > > Ik heb toen de server opnieuw opgestart en daarna waren zowel de met > bind gemounte directories als de directories op de data schijf leeg. > Daardoor deden apache, postfix, dovecot en openvpn het niet > meer. Gelukkig deed ssh het nog wel. Door het aanmaken van wat > directories in /var/log en het uit de backup halen van /var/lib/acme > en /var/www-ssl deed een en ander het weer. > > Het is opvallend dat er nog steeds 2,3 TB op de schijf beschikbaar is. > In de verdwenen directories staan naar schatting meer dan 600 GB > aan bestanden. > > Ik heb geen idee wat er aan de hand is. Ik kan een schijf tijdelijk > uit de raid halen en via usb onderzoeken, maar ik wil eerst meer > weten over mogelijke oorzaken. Mijn backup staat elders en het > overpiepen via een adsl up en down link gaat natuurlijk eeuwen duren. > Ik zal dan wel met een harde schijf over straat moeten. Naar dat wil > ik pas doen als de oorzaak bekend is. Google was hierbij mijn vriend > niet. > > Hebben jullie enig idee waar ik de oorzaak moet zoeken? > > Doeg, > Jaap van Wingerde >
Re: Linux Raid1: directories plotseling leeg
Op 2022-09-02T21:32:51+0200 schreef Richard Lucassen in bericht , inzake: het volgende. > On Fri, 2 Sep 2022 19:43:23 +0200 > Geert Stappers wrote: > > > Die `mount -t none -o > > bind,verdere,opties /media/data/var/repository /var/repository` zou > > ik met een symbolic link doen, voor wat het waard is. > > Dat zou ik ook met symlinks doen ja. Die --bind gebruik ik alleen wel > eens als een chrooted dir een /dev en een /proc nodig heeft. Symbolic linksd doern het niet via nfs. > > > Heb je gekeken met mdadm of alles ook nu nog steeds goed is? > > > cat /proc/mdstat > > > > Als ik het mij goed herinner dan is er standaard een bewakingsscript > > die dat doet. De `cat /proc/mdstat` is wel goed startpunt > > om te onderzoeken wat er aan de hand. ( hint, hint, hint ;-) > > Dat script draait iedere ochtend om 6:25 > > Subject: DegradedArray event on /dev/md/3:iomega1 > > En die stuurt je ook nog de output van /proc/mdstat mee. Niks ontvangen.
Re: Linux Raid1: directories plotseling leeg
Op 2022-09-02T19:43:23+0200 schreef Geert Stappers in bericht , inzake: het volgende. > On Fri, Sep 02, 2022 at 03:02:08PM +0200, Paul van der Vlis wrote: > > Op 02-09-2022 om 14:41 schreef mailingli...@vanwingerde.net: ... > > > Voorbeelden uit /etc/fstab: > > > /dev/md2 /media/data ext4 rw,relatime,lazytime,user_xattr,acl 02 > > > /media/data/var/repository /var/repository none > > > bind,relatime,lazytime,rw,suid,acl,user_xattr 0 0 > > > > Zou het kunnen dat je dingen dubbel gemount hebt? > > Die `mount -t none -o bind,verdere,opties /media/data/var/repository > /var/repository` zou ik met een symbolic link doen, voor wat het > waard is. Symbolic links doen het niet via nfs. Dat is onhandig. ... > > Als ik het mij goed herinner dan is er standaard een bewakingsscript > die dat doet. De `cat /proc/mdstat` is wel goed startpunt > om te onderzoeken wat er aan de hand. ( hint, hint, hint ;-) Ik ontving geen bericht van mdadm. > > > Hebben jullie enig idee waar ik de oorzaak moet zoeken? > > In het verleden. Logfiles kunnen vertellen wat er gebeurd is. > Vooropgesteld dat er logfiles zijn van het systeem in kwestie. De gebackupte logs zijn te oud. De logs van het probleem moment konden niet naar de data-schijf geschreven worden.
Re: Linux Raid1: directories plotseling leeg
Op 2022-09-02T15:02:08+0200 schreef Paul van der Vlis in bericht , inzake: het volgende. > Hallo Jaap en anderen, > > Op 02-09-2022 om 14:41 schreef mailingli...@vanwingerde.net: ... > > Voorbeelden uit /etc/fstab: > > /dev/md2 /media/data ext4 rw,relatime,lazytime,user_xattr,acl 02 > > /media/data/var/repository /var/repository none > > bind,relatime,lazytime,rw,suid,acl,user_xattr 0 0 > > Zou het kunnen dat je dingen dubbel gemount hebt? Nee, niks dubbel. > ... > Heb je gekeken met mdadm of alles ook nu nog steeds goed is? > cat /proc/mdstat Ja, mdadm zegt clean. > > > Het is opvallend dat er nog steeds 2,3 TB op de schijf beschikbaar > > is. In de verdwenen directories staan naar schatting meer dan 600 GB > > aan bestanden. > > Heb je gekeken met fsck of er iets te repareren valt aan het > filesysteem? > > umount /dev/md2 > fsck -f /dev/md2 Ja. fsck zegt 0 = OK. Die -f staat niet in de manpage: https://manpages.debian.org/bullseye/util-linux/fsck.8.en.html > > > Ik heb geen idee wat er aan de hand is. Ik kan een schijf tijdelijk > > uit de raid halen en via usb onderzoeken, > > Ik zou de boel zoveel mogelijk testen in de raid. Heb ik gedaan. > Eventueel met de debian installer in rescue mode. Deze kan ook > uitstekend omgaan met software raid, encryptie, LVM, etc. Je moet > alleen wat vaak op return drukken bij het opstarten ;-) > > USB is sowieso minder goed bij problemen dan echte SATA. > ... > > > > Hebben jullie enig idee waar ik de oorzaak moet zoeken? > > Misschien in het filesysteem. Misschien in de hardware. Ja.
