Wéér spontaan van de server verdwenen bestanden

[Josefien]

Mijn vraag
...

En wéér zijn er spontaan bestanden verdwenen van de server thuis. Ik ontdekte net voor ik naar Amsterdam wilde vertrekken per toeval dat de volledige map "Afbeeldingen" in mijn home-directory is verdwenen. Zo 46GB aan foto's weg

De recentste backup is van 4 dagen geleden en daar was de map nog wel compleet.

Ik zie ook dat de backup ongeveer 55GB groter is dan de huidige situatie, dus mogelijk is er meer weg dan de foto's.

Eerder dit jaar is er ook al zoiets voorgekomen, maar toen betrof het alleen bestanden buiten de home-directory:

Willekeurige bestanden verdwenen van file-server

De oorzaak was nooit duidelijk geworden. Het heeft me toen dagen gekost om uit te zoeken wat weg was.

Wat kan hier aan de hand zijn geweest? Is er een cliënt aan het verwijderen geweest of zit de server stilletjes bestanden weg te gooien?


Ik begin nu toch wel wat in paniek te raken Simpelweg omdat ik niet weet wat er aan de hand is. En ik ook niet meer weet wat ik eraan kan doen (behalve telkens de boel terugzetten).


Relevante software en hardware die ik gebruik
...
De server draait nog steeds op Debian 8.0. En biedt via Samba en NFS data aan. Op Linux-werkstations wordt de server op /home gekoppeld. Windows gebruikt domein-logins i.c.m. roaming profiles. En op Android-telefoons wordt de SMB functie van "ES File Explorer" gebruikt om bestanden op te vragen.

De data op de server staat op een software RAID1 array. Ext4 bestandssysteem.


Wat ik al gevonden of geprobeerd heb
...
Ik heb gisteren sinds lange tijd een Windows 7 PC opgestart met een lokaal account en daarop even mijn home-directory via SMB als netwerk-share gekoppeld. Geen idee of daar iets fout is gegaan. Hoewel toen niet de Afbeeldingen-map is geopend. Wel toeval... is het enige "afwijkende" wat ik de afgelopen dagen heb gedaan.

De harde schijven in de server zijn nog in orde. De array is niet gedegradeerd en de SMART-data van de schijven is nog in orde.

[Nielson]

Zijn de bestanden op de server echt weg of zijn bijvoorbeeld de rechten veranderd waardoor je ze ze met je linux client niet meer ziet?

[Josefien]

Ze zijn echt weg. Er is ook daadwerkelijk 55GB minder schijfruimte in gebruik vergeleken met de backup als ik met "df" kijk.

[DoeEensGek]

Ik zou eerst een tijdvak gaan bepalen waarin dit is gebeurd. Wanneer heb je het geconstateerd, en wanneer waren de bestanden nog aanwezig.

Daarna zou ik in de logs gaan kijken in het tijdvak.
Eventueel kan je logs delen uit de periode dat het is gebeurd.

[Big Mama]

Inderdaad een vreemd probleem. Misschien een paar mogelijkheden:
- Wordt er vanaf een andere server een rsync met de '--delete' optie gedaan? Dat zou ervoor kunnen zorgen dat op de doelserver (de Debian8 doos) dingen worden weggegooid die niet op de bronserver staan.
- Zijn er ext4 errors zichtbaar in syslog?
- Welke cronjobs hebben gelopen tussen dat het nog goed was en dat het fout was?
- Is vanaf de Linux-shell die directory ook weg? Misschien is hij alleen hernoemd naar iets dat niet via Samba zichtbaar is.
- Zijn er rare dingen zichtbaar in de Samba-logging?
- Bekijk de shell history van alle gebruikers om te zien of daar aanknopingspunten zijn

[Josefien]

- In /var/log/samba/log.ws45 (ws45 is hostnaam v/d Win 7 cliënt) zijn alleen deze regels te vinden, heeft er niks mee te maken:

code:

[2018/08/03 15:08:31.117928,  0] ../lib/param/loadparm.c:1659(lpcfg_do_service_parameter)
  Ignoring unknown parameter "printer admin"

- In de shell-history van mijn gebruikersaccount zitten geen vreemde commando's.

- Er is geen sprake van een andere server, dus een eventuele rsync die de boel verwijderd is niet mogelijk.

- De map is echt weg, ook via de command-line op de server niet te vinden.

- Syslog is praktisch onmogelijk om door te bladeren. Omdat de server ook DNS, DCHP en LDAP doet komt elke foutmelding daarvan ook erin en zit hij dus vol met webadressen die de DNS-server niet heeft kunnen vinden.

- Op 31 juli was de recentste back-up gemaakt en toen was de map er nog. In de ochtend van 4 augustus ontdekte ik dat 'ie weg was. In de tussengelegen dagen kan ik me niet meer herinneren wanneer ik er voor het laatst in was geweest.

- In cron zitten alleen de standaard bij Debian meegeleverde taken:

Dagelijks:
/etc/cron.daily/exim4-base
/etc/cron.daily/dpkg
/etc/cron.daily/logrotate
/etc/cron.daily/mdadm
/etc/cron.daily/apt-show-versions
/etc/cron.daily/samba
/etc/cron.daily/bsdmainutils
/etc/cron.daily/apt
/etc/cron.daily/passwd
/etc/cron.daily/aptitude
/etc/cron.daily/apache2
/etc/cron.daily/mlocate
/etc/cron.daily/man-db
/usr/sbin/ntpdate nl.pool.ntp.org

Wekelijks:
/etc/cron.weekly/man-db

Maandelijks RAID-array checken (zondag):
if [ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Elk halfuur:
[ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean

[boyette]

Ik denk dat het met de windows 7 pc te maken heeft. Start die nog eens op
Gebeurt het dan weer.. dan weet je waar je het moet zoeken

[johnkeates]

Ze je FS anders op read-only en kijk wat er errors geeft.

[Wim-Bart]

Zet je toch gewoon auditing aan op "delete" actie voor "everyone" op de betrokken folder. Overigens heeft EFS Explorer wel rare eigenschappen om opeens dingen weg te gooien als je een foute touch doet. Heb nog nooit een filesysteem iets weg zien gooien zonder een foute user actie of een foute job. Maar zonder auditing kan je niks.

[Josefien]

boyette schreef op zondag 5 augustus 2018 @ 02:52:
Ik denk dat het met de windows 7 pc te maken heeft. Start die nog eens op
Gebeurt het dan weer.. dan weet je waar je het moet zoeken

Probleem is dat ik niet weet wat er weg is. Je komt er pas achter als je het wil gaan gebruiken.

johnkeates schreef op zondag 5 augustus 2018 @ 03:27:
Ze je FS anders op read-only en kijk wat er errors geeft.

Home-directories op read-only, dan komen de Linux-clients niet voorbij het aanmelden

Wim-Bart schreef op zondag 5 augustus 2018 @ 03:52:
Zet je toch gewoon auditing aan op "delete" actie voor "everyone" op de betrokken folder. Overigens heeft EFS Explorer wel rare eigenschappen om opeens dingen weg te gooien als je een foute touch doet. Heb nog nooit een filesysteem iets weg zien gooien zonder een foute user actie of een foute job. Maar zonder auditing kan je niks.

Hoe zou ik dat moeten doen?

[jetspiking]

Probeer anders een HDD test uit te voeren, misschien is je HDD gewoon aan het einde van z'n levensduur (alhoewel je dan zou zeggen dat het OS op den duur ook opstartproblemen krijgt).

[Josefien]

Het OS van de server staat op een aparte oude 40GB HDD. Data op een RAID1 array.

Een defecte schijf zou dit niet moeten kunnen veroorzaken.

Ik zie m.b.v. een dry-run van rsync trouwens dat de verdwenen foto's slechts het topje v/d ijsberg zijn. Uit willekeurige mappen zoals de muziek-map zijn willekeurige nummers verwijderd. Net als uit de documenten-map.

Buiten de home-directory zijn er in /home/sw_dist o.a. willekeurige drivers en software-setups verdwenen.

En zo nog veel meer willekeurigs. Echt heel willekeurig. Zo heb ik in mijn home-directory een filmpje staan die is gesplitst in 4 delen. Daarvan is alleen deel 2 en 4 verwijderd.


Ik zit nu echt met m'n handen in het haar. Ik vrees dat ik hier niet de tijd en expertise meer voor heb om het op te lossen. Ik heb de neiging om de server maar permanent uit te zetten en weer stand-alone te gaan werken.


Alleen, waar moet ik dan mijn data opslaan? Blijkbaar is beschrijfbare opslag niet veilig. Getuige dat er zomaar tientallen gigabytes kan verdwijnen. Maar de data is te groot voor DVD's.

Back-ups werken ook maar tot een beperkte hoogte. Als je namelijk te laat ontdekt dat er dingen zijn verdwenen worden ze bij een volgende backup ook daar verwijderd en is terugzetten onmogelijk.

[ Voor 6% gewijzigd door Josefien op 05-08-2018 10:17 ]

[CurlyMo]

Er zijn al verschillende tips gegeven zoals door @Wim-Bart met auditing regels.

Je zou ook een cron kunnen draaien die je schijfruimte in de gaten houdt. Verkleint die met bijv. meer dan 1GB direct een mail met allerhande logs en alles op readonly. Je kan dan alleen zelf even niks meer verwijderen van meer dan 1GB. Als je eenmaal de mail ontvangt, dan heb je de logs en de schade beperkt gehouden. Je data staat dan tenminste nog in je backup.

Zet je Samba logs op de maximale verbosity zodat ook elke actie gelogd wordt.

Heb je ook al je clients al een schone installatie gegeven?

Er zijn genoeg mogelijkheden om dit verder te onderzoeken.

Als het jouw niet lukt om via debugging het antwoord te vinden, dan is het misschien een beter idee om naar een kant en klare NAS te gaan zoals Synology? Gaat het dan nog fout, dan is zeker weten een van je clients die besmet is.

Josefien schreef op zondag 5 augustus 2018 @ 10:13:
Back-ups werken ook maar tot een beperkte hoogte. Als je namelijk te laat ontdekt dat er dingen zijn verdwenen worden ze bij een volgende backup ook daar verwijderd en is terugzetten onmogelijk.

Zoals dit. Dit moet je door hebben. Backups != RAID. Dat geldt dus ook de andere kant op. Regel een backup strategie met versioning of snapshots. Behoud snapshot tot bijv. max een jaar. Of hoeveel tijd je nodig hebt om deze fouten te ontdekken.

Ik mail mezelf elke dag met een lijst van mijn backups historie en de datums. Voeg daar de backup grote aan toe en je ziet het ook gelijk.

[ Voor 29% gewijzigd door CurlyMo op 05-08-2018 11:03 ]

[Josefien]

Ik heb inmiddels gezien dat van sommige directories alleen de inhoud is verwijderd. De wijzigingsdatum van die directories zijn alleen van 2 augustus tussen 21:04u en 21:10u.

De Windows 7 PC kan dan uitgesloten worden, dit ging pas 3 augustus voor het eerst aan sinds een maand.

Rond die tijd was ik dit aan het doen:
TWRP kan data niet ontsleutelen

Via ES File Explorer een aantal bestanden via SMB kopieeren naar de server, naar een map in m'n home-directory.

Terwijl de telefoon aan het kopiëren was kan ik me herinneren dat ik m'n Linux-client aan het aanmelden was en dat bleef hangen terwijl de server extreme schijfactiviteit vertoonde. Na een reboot v/d cliënt werkte het weer.

Rest nu nog, waarom zouden er willekeurige bestanden verwijderd zijn uit allerlei mappen (vanuit Samba gezien zelfs van verschillende shares) als ik met ES File Explorer enkele bestanden kopieer naar de server (wat ik heel vaak doe zonder problemen)? Of is er iets fout gegaan door tegelijkertijd aanmelden van een Linux-client?

Of heeft het allemaal niets met elkaar te maken en is het toeval?

[ Voor 4% gewijzigd door Josefien op 05-08-2018 11:46 ]

[CurlyMo]

Zoals anderen en ik al aangegeven hebben, je zult bewijs moeten zoeken in je logs. En je moet zorgen voor een alert systeem dat je hier direct van op de hoogte brengt als het weer gebeurd. Zodat je niet meer tegen verlopen back-ups aanloopt.

En dit is allemaal onderdeel van je zelfbouw sysadmin rol. Bij zelfbouw zul je enige zelfredzaamheid moeten hebben, ook bij problemen.

[burne]

CurlyMo schreef op zondag 5 augustus 2018 @ 12:08:
Zoals anderen en ik al aangegeven hebben, je zult bewijs moeten zoeken in je logs. En je moet zorgen voor een alert systeem dat je hier direct van op de hoogte brengt als het weer gebeurd. Zodat je niet meer tegen verlopen back-ups aanloopt.

Auditd is je vriendje voor dat soort taken, maar ook dat vergt weer enige actie vooraf. Een korte howto. De kans is groot dat het al geinstalleerd is, maar niet aan staat.

[Josefien]

Ik zit langzaamaan toch wel aan een kant-en-klaar systeem te denken. Ik heb onderhand niet meer de kennis ervoor. Op de een of andere manier wordt opslag van alleen maar data steeds ingewikkelder. Een jaar of 10 terug was voor thuis een Linux-bak met Samba en wat schijven voldoende. En was een backup niet meer dan een extene HDD waar je eens in de zoveel tijd de boel naar synchroniseert.

Nu heeft iedereen het over versioning of schaduwkopieën, backups naar de cloud e.d. Dat was destijds n.v.t. voor thuisgebruik.


Maar met een kant-en-klare Synology NAS krijg je volgens mij ook geen waarschuwing als er ineens grote hoeveelheden data wordt verwijderd. En oude back-ups blijven bewaren kan ook maar beperkt daar schijfruimte niet onbeperkt is (voor thuisgebruik zit er eenmaal een beperkt budget aan). En als zo'n kant-en-klaar systeem fysiek stuk is gaat, kan je dan nog bij je data door de schijven in een reguliere PC te hangen? Is zo'n kant-en-klaar systeem daadwerkelijk een oplossing voor deze problemen?

[FreakNL]

Nee

Dit zit namelijk in je client. Of PEBCAK

Een filesystem gooit niet willekeurig dingen weg.

[ Voor 94% gewijzigd door FreakNL op 05-08-2018 12:30 ]

[CurlyMo]

Ik zou toch graag willen weten wat de oorzaak is. Daar heb je nu genoeg tips voor gekregen. Begin daar eens mee.

[burne]

Een snapshot is een punt in tijd waarop je je filesysteem bevriest en de staat ervan vastlegt. Alles wat erna gebeurt bewaar je wijziging op de bevroren staat, en niet als wijzigingen van de actuele bestanden.

Je kunt dan de huidige staat vergelijken met die van je snapshot en zien welke bestanden er verdwenen zijn, wat er bijgekomen is, en wat er veranderd is. En je kunt wijzingen dus weer ongedaan maken.

[jvanhambelgium]

Josefien schreef op zondag 5 augustus 2018 @ 12:23:
Maar met een kant-en-klare Synology NAS krijg je volgens mij ook geen waarschuwing als er ineens grote hoeveelheden data wordt verwijderd. En oude back-ups blijven bewaren kan ook maar beperkt daar schijfruimte niet onbeperkt is (voor thuisgebruik zit er eenmaal een beperkt budget aan). En als zo'n kant-en-klaar systeem fysiek stuk is gaat, kan je dan nog bij je data door de schijven in een reguliere PC te hangen? Is zo'n kant-en-klaar systeem daadwerkelijk een oplossing voor deze problemen?

Boah, precies redelijk wel hoor.
Je kan vb de logging opzetten rond "File Access" (en dus ook "file deletion")
Vervolgens gaat je dus netjes in de Log Manager alle bestanden zien die vb gewist werden (en door wie)
Vervolgens kan je enkele "Notifcation Rules" zetten ;

> aantal log-entries / sec meer als X
> keywords included
> severity-level

Effe een testje gedaan met keyword "delete" erin gezet, en ja, nadat ik erna enkele bestanden wegdeed kreeg ik direct de nodige mailtjes met info over welk bestand, vanaf welk IP werd gewist etc.

[Terrestrial]

Kijk is naar de status van je RAID 1 want ik heb in het verleden wel eens meegemaakt dat er 1 schijf stuk ging en die het kapotte filesystem ging repliceren naar schijf 2 waardoor ik nog niks aan die RAID1 opzet had.

Sowieso moet je voor een opslagoplossing kiezen waar je goed mee bekend bent zodat je kunt troubleshooten, auditing is altijd verstandig om in te stellen en niet iedereen zomaar alle rechten geven, alleen het noodzakelijke.

En anders neem een synology NAS ofzo, die werken ook op Linux maar alles is lekker simpel via een webinterface in te stellen. Heb je verder geen omkijken naar.

[HKLM_]

Josefien schreef op zondag 5 augustus 2018 @ 12:23:
Ik zit langzaamaan toch wel aan een kant-en-klaar systeem te denken. Ik heb onderhand niet meer de kennis ervoor. Op de een of andere manier wordt opslag van alleen maar data steeds ingewikkelder. Een jaar of 10 terug was voor thuis een Linux-bak met Samba en wat schijven voldoende. En was een backup niet meer dan een extene HDD waar je eens in de zoveel tijd de boel naar synchroniseert.

Nu heeft iedereen het over versioning of schaduwkopieën, backups naar de cloud e.d. Dat was destijds n.v.t. voor thuisgebruik.


Maar met een kant-en-klare Synology NAS krijg je volgens mij ook geen waarschuwing als er ineens grote hoeveelheden data wordt verwijderd. En oude back-ups blijven bewaren kan ook maar beperkt daar schijfruimte niet onbeperkt is (voor thuisgebruik zit er eenmaal een beperkt budget aan). En als zo'n kant-en-klaar systeem fysiek stuk is gaat, kan je dan nog bij je data door de schijven in een reguliere PC te hangen? Is zo'n kant-en-klaar systeem daadwerkelijk een oplossing voor deze problemen?

Dat is nog voldoende het zijn je wensen die het ingewikkeld maken, als ik lees wat je hebt opgezet dat denk ik waarom? Je hebt het schijnbaar zo ingewikkeld gemaakt voor je zelf dat je nu door de bomen het bos niet meer ziet.

_ Stap terug naar je Linux bak met samba en wat schijven
_ Koop een NAS en laat die het werk doen.

Al het gehobby is leuk maar bij issues moet je wel weten wat je wilt en wat je kunde is anders heb je er nog niks aan.

Je probleem zit vast bij 1 van de clients ik heb namelijk nog nooit meegemaakt met zowel Linux als windows dat er spontaan bestanden verwijderd zijn (Meestal zit het probleem tussen het bureau en de rugleuning van de stoel )

[ Voor 6% gewijzigd door HKLM_ op 05-08-2018 13:25 ]

[psy]

Josefien schreef op zondag 5 augustus 2018 @ 10:13:
Het OS van de server staat op een aparte oude 40GB HDD. Data op een RAID1 array.

Een defecte schijf zou dit niet moeten kunnen veroorzaken.

Ik zie m.b.v. een dry-run van rsync trouwens dat de verdwenen foto's slechts het topje v/d ijsberg zijn. Uit willekeurige mappen zoals de muziek-map zijn willekeurige nummers verwijderd. Net als uit de documenten-map.

Buiten de home-directory zijn er in /home/sw_dist o.a. willekeurige drivers en software-setups verdwenen.

En zo nog veel meer willekeurigs. Echt heel willekeurig. Zo heb ik in mijn home-directory een filmpje staan die is gesplitst in 4 delen. Daarvan is alleen deel 2 en 4 verwijderd.


Ik zit nu echt met m'n handen in het haar. Ik vrees dat ik hier niet de tijd en expertise meer voor heb om het op te lossen. Ik heb de neiging om de server maar permanent uit te zetten en weer stand-alone te gaan werken.


Alleen, waar moet ik dan mijn data opslaan? Blijkbaar is beschrijfbare opslag niet veilig. Getuige dat er zomaar tientallen gigabytes kan verdwijnen. Maar de data is te groot voor DVD's.

Back-ups werken ook maar tot een beperkte hoogte. Als je namelijk te laat ontdekt dat er dingen zijn verdwenen worden ze bij een volgende backup ook daar verwijderd en is terugzetten onmogelijk.

Daarom backup ik mijn belangrijke data voor de zekerheid dus 1x per zoveel maanden naar BluRay schijf (standaard 25GB per schijfje). Zoveel mensen die dan zeggen schijfjes zijn niet te vertrouwen, kan je toch beter naar een andere HD zetten of in de cloud en nog meer van die blah blah blah. Feit blijft dat die data gewoon vast op de schijf staat en er niet meer vanaf gaat. Mijn oudste Verbatim dvd's zijn nog gewoon 100% dus ik geloof het allemaal wel.
Het is duidelijk mijn last_resort_backup. Maar ik vind het zeer fijn om achter de hand te hebben.

[TommyboyNL]

Ik zie hier meerdere zaken fout gaan:
- Geen logging
- Geen monitoring
- Antieke zooi:

Josefien schreef op zondag 5 augustus 2018 @ 10:13:
Het OS van de server staat op een aparte oude 40GB HDD. Data op een RAID1 array.

écht, WTF!? Toen de laatste 40GB schijf van de productieband afrolde waren we zo ongeveer de Flevopolder leeg aan het pompen.

Tuig een nieuwe server op gemaakt van hardware die niet al in gebruik was ten tijde van de maanlandingen, knal hier een dedicated NAS OS (Zelf draai ik FreeNAS) op in plaats van een random OS dat toevallig ook SMB spreekt, zorg dat je monitoring op orde is (LibreNMS, Zabbix, PRTG (braak)), en zorg dat je logging op orde is.

[Mijzelf]

TommyboyNL schreef op zondag 5 augustus 2018 @ 14:57:
- Antieke zooi:

[...]

écht, WTF!? Toen de laatste 40GB schijf van de productieband afrolde waren we zo ongeveer de Flevopolder leeg aan het pompen.

Wat een onzin. Een 40GB schijf die nog leeft heeft meer kans de volgende 6 maanden te overleven dan een fonkelnieuw exemplaar. Check je statistieken.

Verder is de OS schijf totaal niet interessant als het om data veiligheid gaat. Ja, op een dag zal die crashen. Nou en? Dat heeft geen invloed op de data.

[johnkeates]

TommyboyNL schreef op zondag 5 augustus 2018 @ 14:57:
Ik zie hier meerdere zaken fout gaan:
- Geen logging
- Geen monitoring
- Antieke zooi:

[...]

écht, WTF!? Toen de laatste 40GB schijf van de productieband afrolde waren we zo ongeveer de Flevopolder leeg aan het pompen.

Tuig een nieuwe server op gemaakt van hardware die niet al in gebruik was ten tijde van de maanlandingen, knal hier een dedicated NAS OS (Zelf draai ik FreeNAS) op in plaats van een random OS dat toevallig ook SMB spreekt, zorg dat je monitoring op orde is (LibreNMS, Zabbix, PRTG (braak)), en zorg dat je logging op orde is.

Dit is geen bedrijfsnetwerk he, maar een thuis-hobby-dingetje zonder budget.

[T-Forever]

In het verleden hebben andere toegang tot mijn nas weten te krijgen, waarschijnlijk scripten met known security issues. Ik kreeg dus een extra administrator user erbij, die het een en ander uithaalde, hier al naar gekeken?

[TommyboyNL]

Mijzelf schreef op zondag 5 augustus 2018 @ 15:02:
[...]

Wat een onzin. Een 40GB schijf die nog leeft heeft meer kans de volgende 6 maanden te overleven dan een fonkelnieuw exemplaar. Check je statistieken.

Die 40GB schijf zal inmiddels behoorlijk ver naar rechts verhuisd zijn in de badkuipcurve, ik zou /dev/null er niet eens meer aan toevertrouwen.

[_Dune_]

Heren kunnen wij het een beetje netjes houden en als je commentaar ergens op geeft, doe dat dan fatsoenlijke onderbouwd en anders liever niet. Dank u.

[Mathijs]

Google eens op "incremental backup".
Dat kost je niet veel meer data dan de onveilige 1x backup die je nu hebt die overschreven wordt, maar laat je wel een hele tijd terug gaan. Ieder bestand wordt maar 1x ge-back-upped, het is alleen maar groter door verwijderde bestanden binnen de tijd dat de retentie is ingesteld, maar dus niet een veelvoud van al je data.

Verder de logging configureren zodat je wat meer kunt zien en in afzonderlijke bestanden. Dat is online ook prima te vinden, google maar eens op "advanced logging debian".

Verder nooit ergens 100% op vertrouwen en af en toe een backup maken naar een usb schijf die je in de kast legt.

[Aragnut]

Om in het verleden te kijken van wat er mis kan zijn gegaan zul je echt in de logs moeten graven (mogelijk even apart zetten en met grep de dns updates e.d. er uit halen, kijken of je wat kan filteren). Om in de toekomst te kunnen vangen zou ik dan aanraden om je log instellingen goed door te nemen (mogelijk aparte logging op filesystem access) cq. met een periodiek script metadata verzamelen van het filesysteem (hoeveel bestanden, hoeveel storage gebruik, wie hebben er momenteel open filehandles etc.)

Gezien de vorige keer bijna een half jaar geleden is, is het niet echt haalbaar om elke dag handmatig te checken: dit zul je dus moeten scripten met een trigger om je te waarschuwen wanneer je moet checken.

Mogelijk kun je met samba ook meer logging aanzetten (wie wanneer wat doet) zodat je mogelijk kan zien of een client wat raars aan het doen is.

Vanuit de overige leden gezien zal het zonder logs puur giswerk zijn wat er allemaal mis is gegaan (van filesystem rot/hardware failure tot malware of aggresief opruim script).

[Josefien]

Dit is zojuist weer gebeurt, waar ik bij ben. Deze keer gebeurde het toevallig nadat ik gisterenavond een back-up had gemaakt + vrijwel direct ontdekt, dus herstellen was een kwestie van tijd.

(Één van de) oorzaken is de Ubuntu 16.04 cliënt (aanmelden via LDAP en /home op NFS-share) waarbij door omstandigheden een niet-gebruikelijke situatie ontstaat dat een reeds aangemelde gebruiker opnieuw aanmeld op een andere tty.

De situatie was als volgt: gebruiker "josefien" was aangemeld (grafische omgeving, op tty7, standaard). Omdat ik het toetsenbord en muis wilde schoonmaken had ik het scherm vergrendeld. Door het indrukken van allerlei willekeurige toetsen is de cliënt alsnog naar het inlogscherm gekeerd. Dus ik meld me opnieuw aan. Zonder dat ik wist dat mijn bestaande sessie nog op tty7 actief was en op de e.o.a. manier via het toetsenbord/muis tijdens schoonmaken een nieuwe sessie met inlogscherm op tty8 is gestart.

Vervolgens bleef 'ie hangen bij een leeg bureaublad en hoorde ik de schijven v/d server flink ratelen. Hij was achteraf gebleken op de achtergrond dus o.a. de hele mappen Afbeeldingen en Muziek van mijn home-directory aan het verwijderen Met Ctrl+Alt+F7 ontdekte ik dat mijn vorige sessie nog ingelogd was op tty7. Toen heb ik de cliënt heel snel afgesloten en stopte het ratelen v/d schijven in de server.

Ik vreesde dat mijn bestanden weer weg waren en na herstarten en opnieuw aanmelden waren inderdaad alle foto's en muziek weg. Ik denk dat als ik niet de cliënt snel had afgesloten er nog meer weg ging tot de hele home-dir leeg was...


Het lijkt dus een vreemde gebeurtenis te zijn: als een gebruiker grafisch is ingelogd op een Ubuntu 16.04 PC en zich nogmaals opnieuw grafisch aanmeld op dezelfde PC op een andere tty, dan worden bestanden uit de home-directory verwijderd


Als ik eens diep nadenk is deze situatie al eens eerder voorgekomen. Het zal best wel eens de oorzaak van de vorige keer kunnen zijn. Alleen toen had ik het pas later ontdekt toen ik m'n foto's wilde kijken.


Sinds de vorige keer heb ik nooit meer een Windows 7 cliënt via SMB laten koppelen en ook geen ES File Explorer meer via enig Android-apparaat gebruikt om via SMB bij de server te komen. Foto's/muziek gewoon ouderwets via een kabeltje.

En nog steeds handmatige back-ups met rsync, maar altijd eerst een "dry-run" met -n parameter en dan het lijstje doorkijken of er niet massief wordt verwijderd voordat de back-up echt wordt gemaakt.