Platte scheinbar randvoll, doch nur ein Viertel wird gefunden

Hallo zusammen,
auf unserem UCS scheint eine fehlerhafte Datensicherungskonfig die Festplatten (RAID) komplett vollgemüllt zu haben.
Leider ist die IT-Firma, die den Server eingerichtet hat, mittlerweile pleite (wundert mich nicht :wink: ).
Ich habe nur sehr rudimentäre Linux-Kenntnisse und brauche deshalb nun von Euch Hilfe, wie ich solche versteckten Datenpakete in Linux finden kann.
Aktuell weiß ich nicht mal, welche(s) Sicherungsprogramm(e) verwendet wurde(n) :unamused:
Ich habe jetzt zunächst über einen neuen NAS alle Userdaten, Intranet etc. gesichert, das sind zusammen nicht mal ein Viertel der Festplattengröße.
Einzelne Dateien aus den Verzeichnissen habe ich schon mal versucht. mit vollen Rechten über eine Suche aus dem root-Verzeichnis heraus zu finden, z.B.:

-name index.php

leider vergeblich, die Sicherung scheint als eigenes Format gespeichert worden zu sein.
Auch eine Suche nach besonders großen Dateien z.B. mit

find -size +500M

hat kein Ergebnis gebracht.

Über jede Idee wäre ich sehr dankbar, von unseren 2 TB sind aktuell noch 9 GB frei…

Herzlichen Dank!
Chnutz

Moin!

du -hs /bin /boot /etc /home /lib /lib64 /lost-found /media /mnt /opt /tmp /root /sbin /srv /usr /var sollte die (top-) VErzeichnisse bringen, die am meisten Platz verbrauchen. Und von dort an kannst Du Dich mit du immer weiter vorarbeiten.

df -h wäre auch noch interessant…

BTW: Ich war mal so frei und habe "im Topic “Speicher” in “Platte” geändert. Speicher ist normalerweise der Hauptspeicher, nicht der Festplattenspeicher…

/KNEBB

Erstmal Danke für’s Umbenennen! :slightly_smiling_face:
Vorweg: Problem ist gelöst!

Der Lösungsweg:
Ich habe beide Befehle mal als root durchgeführt. Folgende Ergebnisse gab es dabei:

root@server01:~# du -hs /bin /boot /etc /home /lib /lib64 /lost-found /media /mnt
/opt /tmp /root
7,5M /bin
88M /boot
64M /etc
427G /home
396M /lib
4,0K /lib64
du: Zugriff auf „/lost-found“ nicht möglich: Datei oder Verzeichnis nicht
gefunden
1,1T /media
4,0K /mnt
144M /opt
56K /tmp
117M /root

df -h
Dateisystem Größe Benutzt Verf.
Verw% Eingehängt auf
rootfs 1,8T 1,7T 1,7G 100%
/
udev 10M 0 10M 0%
/dev
tmpfs 797M 22M 775M 3%
/run
/dev/disk/by-uuid/3097c26f-5e64-4597-8e2e-f38ab80fb4fd 1,8T 1,7T 1,7G 100%
/
tmpfs 5,0M 0 5,0M 0%
/run/lock
tmpfs 5,3G 0 5,3G 0%
/run/shm

Merkwürdig für mich war dabei die Größe von Media, 1,1T. Aufgrund der nach Durchsicht vollständigen Datensicherung haben wir mit sinnvollen Daten nur ca. 600 GB belegt, also Home und noch ein weniges mehr.

Als ich mir das Verzeichnis Media mit * ls -l --block-size=M* anzeigen ließ, wurden nur Kleinigkeiten gelistet:

lrwxrwxrwx 1 root root 1M Jul 9 2015 cdrom → cdrom0
drwxr-xr-x 2 root root 1M Jul 9 2015 cdrom0
drwxr-xr-x 2 root root 1M Nov 7 2017 Datensicherung
-rw-r–r-- 1 root root 1M Jul 13 2015
Datensicherungowncloud-sqlbkp_20150713103509.sql
-rw-r–r-- 1 root root 1M Jul 13 2015
Datensicherungowncloud-sqlbkp_20150713103545.sql
drwxr-xr-x 2 root root 1M Aug 1 2019 ext

Ich stand deshalb leider immer noch auf dem Schlauch :thinking:

Dann aber habe ich zufällig einen Artikel über den Unterschied zw. ls -h und du -h gefunden.
Dank Deines Tipps und dieses Hinweises habe ich dann zwei Monster-Zip-Dateien mit Datensicherungen in Media gefunden.

Voilá, Problem gelöst, vorher 1,4 GB frei, nun 715 GB!

Herzlichen Dank für die Hilfe!

Mastodon