Volume 2 von 95% auf 5% ohne erkennbaren Grund

[Seppareh82]

Hallo zusammen,

danke für Eure Mühen.

@Benares:
da ich "live" gesehen habe, wie im DSM bzw. im Widget des Speichermanager der "Füllstand" von Volume2 von 95% auf 5% gesprungen ist, kann ich den Zeitpunkt ziemlich genau eingrenzen, wobei ich nicht sofort auf die Uhr gesehen habe ... das war auf alle Fälle so um 17:30 Uhr am 28.08., d.h. ich gehe davon aus, dass da sämtliche logs noch in der rm.log drin sind und nichts verschoben wurde.

edit: Du meinst also, dass nicht alle Löschvorgänge enthalten sind im rm.log?

@AndiHeitzer:
Pluto ist der Name meiner DS, kein Account oder User. Die Meldungen erklären also nicht ein Löschen von sämtlichen Aufzeichnungen bis zum 27.08.? Komisch, ich verstehe das nicht... wenn im rm.log alle Meldungen stecken, was auf den Volumes Dateien löscht, dann ist es nicht enthalten. Die Meldung muss doch "volume2" enthalten? Und das sind die einzigen beiden Meldungen, welche "volume2" enthalten ... also spinnt ggf. nur die HDD?

 

[Benares]

Und von wann bis wann hat deine rm.log Einträge?
Aber, wie gesagt, ich bin mir nicht sicher, ob diese alle Löschungen enthält. Ich vermisse dort auch Löschungen, die ich selbst durchgeführt habe.
Deshalb auch der Hinweis aufs Protokoll-Center.
Aber vermutlich hast du nur innerhalb der SS (nutze/kenne ich nicht) etwas falsch eingestellt, und die löscht halt zu viel.

 

[Seppareh82]

die Einträge gehen zurück bis 10.08. und im Protokoll-Center (weder DSM, noch SS) war nichts auffälliges zu finden ...

Ich kann mir nicht vorstellen, dass ich in der SS was falsch eingestellt habe; ich hatte dieses Phänomen bisher noch nicht, dass auf einmal alle Aufnahmen (von 3 Kameras) gelöscht sind. Ich schaue da sehr oft rein und das wäre mir schon mal aufgefallen ... die drei Kameras sind so eingestellt, dass sie max. 1,6TB aufzeichnen (350GB + 750GB + 500GB) und die Platte ist eine 2TB Skyhawk von Seagate mit 1,7TB verfügbarer Kapazität. Und diese ist eigentlich immer bei 95% im Widget des Speichermanagers im DSM. Ich bin fast täglich im DSM, mind. alle 3 Tage und da wäre mir weniger Auslastung im Volume2 aufgefallen ...

Gibt es denn noch eine log-Datei, wo solche Dinge mitgeloggt werden, wenn rm.log scheinbar nicht alle Löschvorgänge mitloggt?

 

[Benares]

Welche Einstellungen gibt es denn in der SS bezüglich Löschung/Überschreibung? Ich kenne die SS kaum.
Geht das nur per Platz pro Kamera? Und wer überwacht dann, ob das Ziel-Volume bald voll ist, und was dann zu tun ist?

 

[Seppareh82]

Hallo Benares,

im SS kann man u.a. den max. Speicher pro Kamera begrenzen, d.h. die Aufnahme "rotiert" wenn diese Grenze erreicht ist. "Rotieren" bedeutet, dass die älteste Aufzeichnung überschrieben wird. So ist meine SS bzw. die Kameras in der SS eingestellt und es funktioniert auch seit längerem ohne Probleme ...

Edit: was immer noch nicht erklärt, warum die Aufnahmen einfach gelöscht sind bzw. weg sind ...

 

[Benares]

Deshalb ja auch meine 2. (bzw. 3. Frage) in #24, "Und wer überwacht dann, ob das Ziel-Volume bald voll ist, und was dann zu tun ist?", was ja bei dir der Fall war.

 

[Seppareh82]

das Überwachen des Ziel-Volumes macht die SS, denke ich, selbst, in dem man den max. zulässigen Speicherplatz pro Kamera definiert; wie gesagt bei mir in Summe 1,6TB (350GB + 750GB + 500GB) bei 1,7TB verfügbarer Kapazität. Ich habe mich eben auch nochmal durch die Einstellungen der SS gewühlt... es deutet keine Einstellung auf ein anderes Verhalten hin, also bei Erreichen der Limits pro Kamera die entsprechend ältesten Aufnahmen zu überschreiben ... klappt ja auch bisher problemlos bis eben zum vorgestrigen Tage ... die SS kann das Volume2 nicht mit mehr als 1,6TB Aufzeichnungen belegen, da die SS dann wieder anfängt, ältere Aufzeichnungen zu löschen. Oder reden wir aneinander vorbei und ich checks grad net, was Du mir sagen willst?

 

[Benares]

Ich frag mich halt, was passieren würde, wenn du da was falsch einstellen würdest.
Bsp: Du ordnest jeder deiner 3 Kameras 1TB zu, hast aber nur ein 2TB Volume als Ziel.
Gibt es da schon bei den Einstellungen der Kameras was auf die Finger oder gibt es da noch übergeordnete Einstellungen, die das verhindern?
Evtl. gehst du bei 1,6TB (350GB + 750GB + 500GB) auch zu nah an die 1,7TB verfügbar heran und irgendwas passiert dann. Ist das Volume nur für SS?

 

[Seppareh82]

es gibt noch eine globale Einstellung unter "Aufnahmen" in der SS; die kontrolliert den gesamten Belegungsstatus des zugewiesenen Volumes und lässt Aufnahmen unabhängig der jeweiligen Kameraeinstellung bei einem Erreichen eines einstellbaren Wertes auch rotieren. Bei mir sind es 100GB, d.h. sind weniger als 100GB auf dem Volume frei, zwingt diese Einstellung die Aufnahmen zu rotieren, auch wenn die jeweiligen Limits in den Kamerasettings noch nicht erreicht sind. Dein unter #28 beschriebener Fall ist also auch abgefangen, d.h. falls man den Kameras zu viel Festplattengröße freigibt und die Summe größer als die Kapazität des Volumes ist.

Edit: aber ich weiß nicht, ob uns das hier zu diesem Thema weiterbringt ... Fakt ist, ich habe immer noch nicht herausfinden können, warum am 28.08. "plötzlich" Aufnahmen verschwunden sind ...

 

[AndiHeitzer]

Moing, nur noch ein kurzes OT, weil mir das mit dem rm.log keine Ruhe gelassen hat ...

Erstmal vielen Dank an @Seppareh82 für die Rückmeldung, dass es der HOSTNAME ist und nicht der USER.
@Benares ... ich kann mir nicht vorstellen, dass nicht alles aufgezeichnet wird, was an Löschungen stattfindet.
Bei mir finde ich einiges, was an 'Aufräumarbeiten' des DSMs statt findet. Sehr viele Löschungen werden dargestellt, weil ich viele selbst erstellte Logausgaben nach 30 Tagen in die Tonne trete. Und auch, was ich eben grade noch herausgesucht habe, meine grade eben getätigten manuellen Löschungen. Aber ...
Die Angaben des 'arguments' können u.U. etwas sparsam ausfallen und so möglicherweise irreführend sein.
Hier mal schnell Beispiele:
2022-08-31T07:31:14+02:00 OBELIX rm[2970]: uid: 0, euid: 0, arguments:["-rf" "APPS/"]
2022-08-31T07:32:08+02:00 OBELIX rm[3353]: uid: 0, euid: 0, arguments:["/volume1/_WARTUNGS-LOGS_/status4web__collect-data__OBELIX.txt"]
2022-08-31T07:33:23+02:00 OBELIX rm[3824]: uid: 0, euid: 0, arguments:["-rf" "/volume1/_BACKUP_/APPS/"]

Erste Zeile: Dort habe ich in das entsprechende Verzeichnis hineingewechselt, um ein Unterverzeichnis (APPS) zu löschen.
Zweite Zeile: Das kommt von einem meiner Scripte, die automatisch aufräumen.
Dritte Zeile: Da habe ich den gleichen Inhalt (wie Zeile 1) gelöscht, nur dass ich das von '/' aus erledigt habe ...
Und was noch blöd ist, die PID müsste dann diejenige sein, die der rm-Prozess selber bekommen hat. Also kann da der Verursacher nicht herausgelesen werden

Ansonsten kann ich hier nix mehr beitragen, weil ich mit der SS leider nix am Hut habe.

 

[Seppareh82]

Hallo Andi,

eine Verständnisfrage zur ersten Zeile:
Warum nennt der log hier nicht das Volume, d.h. woher sieht man auf den ersten Blick, auf welchem Volume das Verzeichnis "Apps" liegt? Wenn ich das dann richtig verstehe, also dass nicht immer das Volume genannt wird, auf welchem gelöscht wurde, dann muss ich mir die logs nochmal ansehen, weil ich explizit nach "volume2" gesucht habe ... aber das, was mein Volume2 gelöscht hat, kann dann auch ohne Nennung von "volume2" enthalten sein ... wobei dann immer noch nicht klar sein wird, was den Vorgang ausgelöst hat, wenn ich das mit den PID auch richtig verstanden habe ... hmmmm ....

Edit: und was bedeutet "... von '/' aus ..."?

 

[AndiHeitzer]

In der ersten Zeile bin ich hergegangen und habe in das Verzeichnis hineingewechselt ... cd /volume1/_BACKUP_
Dort habe ich dann den rm -rf APPS durchgeführt.
In der dritten Zeile habe ich zuerst in das Wurzelverzeichnis gewechselt ... cd /
Dort habe ich dann den Befehl rm -rf /volume1/_BACKUP_/APPS durchgeführt.

Mich hat das interessiert, was das in der LOG-Ausgabe macht.
Ich erwähnte schon in #12, dass man als root solche Operationen mit bedacht durchführen sollte. Wenn im Befehl rm -rf /volume1/_BACKUP_/APPS auch nur ein einziges Zeichen der Verzeichnisangabe nicht passt, dann kannst Du Dich gleich seelisch drauf vorbereiten, das System neu aufzusetzen.
Ich spreche da als gebranntes Kind ...
Wenn ein Verzeichnis nicht gefunden wird, beginnt rm nämlich bei '/' ... was unter Windows einem FORMAT C: gleich kommt. Und wie ich schon sagte, LINUX fragt nicht nach, sondern macht gnadenlos das, was eingegeben wurde

 

[Benares]

Noch mal zur Klarstellung meiner Aussage oben.
Wenn man über ein Script mit "rm" eine Datei löscht, wird dies sicherlich in rm.log registriert, im Protokoll-Center steht dazu dann nichts. Umgekehrt ist es, wenn man z.B. eine Datei über den Explorer (SAMBA) löscht. Noch anders wird es sein, wenn z.B. ein C-Programms mit "remove()" eine Datei löscht. Allen Wegen gemeinsam dürfte sein, dass sie wohl nicht selbst löschen, sondern Kernel-Funktionen dafür aufrufen. Wollte man also wirklich alle Lösch-Operationen irgendwie loggen, müsste man wesentlich tiefer, zentraler ansetzen. Mag sein, dass es sowas gibt, aber ich weiß es nicht.
Fazit: Es wird wohl kein Log geben, was wirklich alle Löschvorgänge erfasst.

 

[AndiHeitzer]

Oha, das mit löschen per SAMBA hate ich nicht auf dem Schirm.
Danke für die Ausführung ...

 

[Seppareh82]

Hallo Andi und Benares,

jetzt hab ich schon einiges von Euch gelernt und das macht mich neugierig; daher (mal wieder) ein paar Verständnisfragen:

Wenn SS oder der DSM selbst durch einen Prozess o.ä. Dateien löschen, dann analog einer manuellen Konsoleneingabe mit dem "rm"-Befehl?
-> somit zu finden im rm.log?

Ich vermute mit Samba und Explorer meint Ihr, dass der Benutzer selbst Dateien löscht über das Fenster "File Station"?
-> das wäre dann in den Protokollen zu sehen?

Wie kann ich über Konsoleneingabe die Datei rm.log auf ein anderes Verzeichnis kopieren, um diese in File Station zu sehen, ohne Gefahr zu laufen, mein System zu formatieren?

@Andi:
Danke für die Erklärungen / Warnungen in #32 ... hatte ich in der Tat so nicht auf dem Schirm, dass schon ein Schreibfehler einem "Format C:" gleichkommt ... da muss ich wohl immer mind. 2 Kaffee morgens trinken, bevor ich auch nur ansatzweise das Tippen anfange ... hab mich schon gewundert, warum mich Synology direkt in der Konsole warnt, als würde ich an einer Bombe arbeiten

 

[Benares]

Es gibt halt leider viele Methoden, Dateien zu löschen. Eine davon ist der Befehl "rm", der oft in Scripten verwendet wird. Die Frage war ja, ob es ein zentrales Log gibt, dass alle Löschvorgänge, unabhängig von der Methode, aufzeichnet, aber das gibt es scheinbar nicht.
Warum "irgendwas" dir plötzlich alle Aufnahmen gelöscht hat, kann ich dir auch nicht sagen.

 

[AndiHeitzer]

somit zu finden im rm.log

Ja

Ich vermute mit Samba und Explorer meint Ihr, dass der Benutzer selbst Dateien löscht über das Fenster "File Station"

Nein, damit ist gemeint, dass ich am PC ein Netzlaufwerk der DS nutze und dort per WIN-Explorer lösche oder, um auch die MAC-Welt nicht auszulassen, im Finder Dateien auf der DS lösche.
Da hatte ich ein Defizit, das aber durch @Benares geklärt wurde.
Da bringst mich auf die Idee, dass ich das noch checken müsste, ob im rm.log was auftaucht, würde ich in der Filestation Dateien löschen.

Wie kann ich über Konsoleneingabe die Datei rm.log auf ein anderes Verzeichnis kopieren

Das geht auf der Konsole mit dem Befehl cp ...
Konkret würdest Du ein cp /var/log/rm.log /volume1/SHAREDFOLDER/rm.log benötigen.
Abweichend vom /volume1/SHAREDFOLDER/rm.log müsstest Du für Deinen Bedarf das Volume und ggfs. das Share anpassen.
Automatisiert bzw. ohne Konsole kannst Du das nur machen, indem Du den cp-Befehl in den Aufgabenplaner einbaust.

Ich habe ja weiter oben schon beschrieben, dass ich /var/log komplett für mich bereitstelle. Bei mir macht das folgender Befehl:
/bin/rsync -rau --delete-before --ignore-errors /var/log/ /volume1/_SYSTEMPROTOKOLLE_/_root/var/log
Anstelle von cp verwende ich rsync, weil ich somit Dateien, die in der Quelle nicht mehr existieren, auch im Kopierziel entfernt werden.

hatte ich in der Tat so nicht auf dem Schirm, dass schon ein Schreibfehler einem "Format C:" gleichkommt

Ja, da war ich dann auch etwas ... ähhmm ... ach lassen wir das
Das trifft auch für die Groß-/Kleinschreibung zu ...

 

[AndiHeitzer]

Da bringst mich auf die Idee, dass ich das noch checken müsste, ob im rm.log was auftaucht, würde ich in der Filestation Dateien löschen.

Ich antworte mir mal selber ...
Wenn ich mittels Filestation etwas lösche, dann landet dies auch im rm.log

 

[Benares]

Mmh, bei mir nicht

Edit: Hängt wohl davon ab, ob es Dateien oder Ordner sind
Edit2: Komisch. Erstelle ich einen Ordner über die FS und lösche ihn dann wieder, taucht nichts auf. Kopiere ich aber zusätzlich eine Datei rein und lösche den Ordner dann, taucht wenigstens die Ordner-Löschung in rm.log auf, nicht aber die Datei-Löschung. Da scheint die FS wohl je nach Fall direkt zu löschen oder Scripte abzusetzen.

 

[AndiHeitzer]

Ich hatte ein Verzeichnis 'ADMINTOOLS' mit zwei Unterverzeichnissen als admin in ein Share 'FREUNDE' kopiert.
Danach habe ich als User 'andi' den Ordner 'ADMINTOOLS' mittels Filestation gelöscht.

Das stand da im rm.log:
2022-08-31T17:06:53+02:00 MAJESTIX rm[26604]: uid: 0, euid: 1041, arguments:["-rf" "/volume3/FREUNDE/ADMINTOOLS/PURETEXT"]
2022-08-31T17:06:54+02:00 MAJESTIX rm[26606]: uid: 0, euid: 1041, arguments:["-rf" "/volume3/FREUNDE/ADMINTOOLS/SYSINTERNALS"]
2022-08-31T17:06:54+02:00 MAJESTIX rm[26607]: uid: 0, euid: 1041, arguments:["-rf" "/volume3/FREUNDE/ADMINTOOLS"]

Du hast recht, einzelne Dateien sind da nicht im Log zu finden.

Mir fällt auf, dass die euid eine 1041 aufzeigt ... normal steht da eine '0' drin
Die 1041 entspricht meiner UID des Users 'andi', mit der ich die Lösch-Aktion durchgeführt habe.

Demnach deute ich das so, dass der 'root' (uid: 0) wohl die Löschung durchführt, aber die Anforderung vom 'andi' (euid: 1041) kommt?