[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux Raid1: directories plotseling leeg



On Fri, Sep 02, 2022 at 03:02:08PM +0200, Paul van der Vlis wrote:
> Op 02-09-2022 om 14:41 schreef mailinglists@vanwingerde.net:
> > 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
> 
> 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.

 
> > 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.
> 
> 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 ;-)


 
> > 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
> 
> > 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.
> 
> 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.
> 
> > 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?

In het verleden.  Logfiles kunnen vertellen wat er gebeurd is.
Vooropgesteld dat er logfiles zijn van het systeem in kwestie.
 

Groeten
Geert Stappers
-- 
Silence is hard to parse


Reply to: