Nextcloud Installations Backup fehlgeschlagen SSD Voll Daten nicht sichtbar.

[Pyrukar]

Hallo zusammen,

ich habe ein Kurioses Problem ... Ich habe nachdem mir meine Nextcloud AIO beim Update einen Schuss vor den Bug gegeben hat, versucht ein Backup der Installation und Datenbank über das integrierte feature der AIO installation zu machen. Merke ich kann nicht lesen

Kurz zum Setup:

• Ich habe ein normales Debian bei dem auch alles up to date ist.
• Installation NC liegt auf der haupt SSD um die es auch gehen soll. Darüber hinaus war die ziemlich leer als Startzustand. (1TB 20GB belegt)
• Die ca 2,3TB Daten liegen auf einer HDD in einem Externen Festplattengehäuse.

So also ich habe jedenfalls diese Backup über das Webinterface gestartet und war der Meinung, dass es sich nur um ein Backup der Datenbank und Installationsbackup handelte wobei ich einen Ort auf der SSD angegeben habe die ja fast 1 TB verfügbar hatte in dem Glauben dass das Backup nur irgendwie 1-5GB groß werden würde. Aber tatsächlich wird bei dem Automatischen Backup immer die Daten Gleich mitgesichert und ich kann das anscheinend nicht umstellen.

Heute Morgen wache ich dann auf. Update gescheitert, 1 TB SSD Komplett voll (bis auf ca 30MB notbremse) und mit Fileslight wird mir die Datengröße auf der SSD mit immer noch ca. 20GB angegeben. Ich hab bleachbit versucht das System von dem Misslungenen backup Versuch zu reinigen, aber der findet die füllende Datei genau so wenig wie Fileslight. Auf der SSD sind jetzt laut Fileslight nur noch ca 13 GB was vermutlich Debian + NC Docker ist.

Wo liegt der ganze Datenmüll und wie kann ich ihn löschen? Das Backup war eine vorkonfigurierte version von BorgBackup. Den ca 30MB Ordner den ich als Ziel angegeben hatte habe ich bereits gelöscht aber natürlich meinen Speicherplatz nicht zurückbekommen.
Wie kann ich ein Backup nur von der Installation ohne Daten machen?

 

[netzwanze]

Moin moin,

mache erste einmal:

df -h

und dann schaue dir die vollen Bereiche einzeln an

du -hs (der Pfad)*

Gegebenenfalls mit sudo

 

[Pyrukar]

Ich habe mal noch 2 Screenshots mit dem Gnome Festplattenbelegungstool:

Das einzige was ich zwischen den beiden Bildern gemacht habe ist einmal auf den Pfeil der gedrückt um in die andere Ansicht zu kommen. das ist die selbe Platte aber massiv unterschiedliche Angaben zum Füllstand.

@netzwanze mach ich gleich mal

 

[johako]

Nach dem Löschen des Ordners den ganzen Rechner mal neu gestartet?

 

[Pyrukar]

okay, da tauchen die Datenmengen so wie es aussieht auf ... @netzwanze

jst@jst-hs:~$ sudo df -h
[sudo] Passwort für jst:
Dateisystem                  Größe Benutzt Verf. Verw% Eingehängt auf
udev                          6,7G       0  6,7G    0% /dev
tmpfs                         1,4G    2,6M  1,4G    1% /run
efivarfs                      128K     51K   73K   42% /sys/firmware/efi/efivars
/dev/mapper/jst--hs--vg-root  903G    818G   39G   96% /
tmpfs                         6,8G       0  6,8G    0% /dev/shm
tmpfs                         5,0M     12K  5,0M    1% /run/lock
tmpfs                         1,0M       0  1,0M    0% /run/credentials/systemd-journald.service
tmpfs                         6,8G    4,0K  6,8G    1% /tmp
/dev/nvme0n1p2                944M    178M  702M   21% /boot
/dev/mapper/vg1-volume_1      3,6T    2,1T  1,5T   59% /mnt/data
/dev/nvme0n1p1                975M    9,1M  966M    1% /boot/efi
tmpfs                         1,4G     92K  1,4G    1% /run/user/1000
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/22d7e6f6a22e95aa2a4db4d017f6043c44d6bc95257ed7c9b4a1381db6e8f635
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/8cc30d932af07505ddce7577fea2c0713894ff28e4ed9449ee10fd1cb9da723a
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/c89d268af2c3ca29a08a4401541003e7e0034809d4141132fc3415ddcc50fb4b
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/20cfdab5af324452ca6b5b28e63a90bda0cf4699ea8ef967a18187b2ebca3180
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/0318249175a45c4f4aaa6f7b8e27637a90f16e20a9450889dcface5408f834a5
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/d58d02e088248cb612694e5da0b894704ba0af9f206117c4bd1feb1d07726e6d
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/2279f223e6ee57cc68b9d87f2c4c1c99be77c6031ac1b7ac4017e9ccc69545c7
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/d06fbb3934f5bc45c7eeecc0b29e330d832fc212f01a84892fcf4498460f7d6d
overlay                       903G    818G   39G   96% /var/lib/docker/rootfs/overlayfs/b546532e0c140c9a5f67f2a425a68734432e8481433434bd4d76f9476b217d8

@johako JA neustart habe ich gemacht

 

[foofoobar]

Top Consumer auf dem Filesysten "/" anzeigen:

sudo du -xm / | sort -nr | head -n 20 # Choose your flavour
sudo du -xh / | sort -hr | head -n 20 # Choose your flavour

 

[Pyrukar]

@netzwanze noch der Detailbericht vom pfad und anschließend der von @foofoobar gewünschte befehl

jst@jst-hs:~$ sudo df -h /var/lib/docker/rootfs/overlayfs/
Dateisystem                  Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/jst--hs--vg-root  903G    818G   39G   96% /
jst@jst-hs:~$ sudo du -xm / | sort -nr | head -n 20
837369  /
819696  /home/jst
819696  /home
813490  /home/jst/.local/share
813490  /home/jst/.local
813483  /home/jst/.local/share/Trash/files/NC Backups/borg
813483  /home/jst/.local/share/Trash/files/NC Backups
813483  /home/jst/.local/share/Trash/files
813483  /home/jst/.local/share/Trash
813454  /home/jst/.local/share/Trash/files/NC Backups/borg/data
461048  /home/jst/.local/share/Trash/files/NC Backups/borg/data/0
352407  /home/jst/.local/share/Trash/files/NC Backups/borg/data/1
10459   /var
10132   /var/lib
8300    /var/lib/containerd
7194    /usr
6116    /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs
6114    /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots

ich habe ganz unten beim zweiten Befehl 2 zeilen die aufs Home verzeichnis gezeigt haben entfallen lassen.

Ergänzung (30. August 2026)

Kann man die Dateien unter /Trash einfach löschen? Laut Fileslight haben die auch nur die bereits beobachteten ca 30MiB

 

[netzwanze]

Lösche mal die alten ungenutzten Docker Images. Bitte aber über Docker und nicht auf dem Filesystem per rm.

 

[Helpmaster5000]

Wo liegt der ganze Datenmüll und wie kann ich ihn löschen? Das Backup war eine vorkonfigurierte version von BorgBackup.

Wird in der AIO nichts angezeigt?

Nextcloud sollte ein eigenes Volume für die Backups eingerichtet haben. Das solltest du einfach löschen können.

docker volume rm nextcloud_aio_backupdir
https://github.com/nextcloud/all-in-one#how-to-properly-reset-the-instance

 

[Pyrukar]

Wird in der AIO nichts angezeigt?

nur das das Backup fehlgeschlagen ist sonst nix relevantes?

Bitte aber über Docker und nicht auf dem Filesystem per rm.

kannst du das bitte ein bisschen ausführen ... ich bin kein Informatiker

docker volume rm nextcloud_aio_backupdir

ist das der korrekte Befehl den @Helpmaster5000 reingepostet hat. Muss ich den einfach in der Linux Konsole ausführen oder muss ich erst noch irgendwie in den Docker selbst rein?

 

[netzwanze]

mache mal ein sudo
sudo du -hs /var/lib/docker/rootfs/overlayfs/*

 

[Pyrukar]

@netzwanze

jst@jst-hs:~$ sudo du -hs /var/lib/docker/rootfs/overlayfs/
5,9G    /var/lib/docker/rootfs/overlayfs/
jst@jst-hs:~$

mit *kommt die Meldung Datei oder Verzeichnis nicht gefunden

 

[netzwanze]

mache mal bitte ein lsblk -f

 

[Donnerkind]

In Kommentar #7 steht doch das Problem, oder irre ich mich? Du hast 813 GB im Papierkorb liegen unter /home/jst/.local/share/Trash.

 

[Pyrukar]

@Donnerkind na ja nur papierkorb leeren geht halt nicht


@netzwanze

jst@jst-hs:~$  lsblk -f
NAME                            FSTYPE            FSVER    LABEL        UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                                          
├─sda1                          linux_raid_member 0.90.0                668e46fd-937a-c9d4-3017-a5a8c86610be                
├─sda2                          linux_raid_member 0.90.0                c1d57411-ed48-97b1-3017-a5a8c86610be                
└─sda5                          linux_raid_member 1.2      JST_NAS:2    4ded4634-f6eb-55ea-9ca5-fd7b0ce0d784                
  └─md2                         LVM2_member       LVM2 001              0z6BMs-SODY-NjB0-0gxv-7MD7-gBot-arRs9G              
    ├─vg1-syno_vg_reserved_area                                                                                              
    └─vg1-volume_1              ext4              1.0      1.44.1-64570 ebc2a0de-5e32-4f56-b569-b20904c88498      1,5T    58% /var/lib/docker/volumes/nextcloud_aio_nextcloud_datadir/_data
                                                                                                                              /mnt/data
nvme0n1                                                                                                                      
├─nvme0n1p1                     vfat              FAT32                 4543-66D1                                 965M     1% /boot/efi
├─nvme0n1p2                     ext4              1.0                   3e644818-a21b-4b5c-bc51-96137508f75f    701,1M    19% /boot
└─nvme0n1p3                     LVM2_member       LVM2 001              Hw7gBQ-Nl9C-z5mZ-5rOD-FnIY-SnUy-8h5jSK              
  ├─jst--hs--vg-root            ext4              1.0                   adf46fc8-4d3c-402b-95fc-15ddeb5ef2f0     38,4G    91% /
  └─jst--hs--vg-swap_1          swap              1                     578fe4ee-3dfd-4366-82fd-e44ed3a46451                  [SWAP]

Das eine müsste die Interne SSD sein das andere die HDD im externen Gehäuse

 

[Donnerkind]

@Donnerkind na ja nur papierkorb leeren geht halt nicht

Schau dir mal die Berechtigungen dieser Verzeichnisse an (Dolphin→Eigenschaften oder ls -l). Ich habe zwar keine Ahnung, wie das in den Papierkorb gekommen ist, aber wenn das von Nextcloud (was als Dienst läuft) erzeugt wurde und nach dem Backup-Fehlschlag in den Papierkorb verschoben wurde, gehören die Dateien vielleicht nicht deinem Benutzer. Und deshalb kann er das dann nicht löschen.

Die Holzhammermethode wäre sudo rm -r /home/jst/.local/share/Trash/*. Mir ist noch nicht ganz klar, wie das mit den Docker-Volumes zusammenspielt. Ist deine grafische Umgebung auch virtualsiert? Denn letztlich liegt dieser Papierkorb ja in einem dieser Volumes.

 

[Helpmaster5000]

ist das der korrekte Befehl den @Helpmaster5000 reingepostet hat. Muss ich den einfach in der Linux Konsole ausführen oder muss ich erst noch irgendwie in den Docker selbst rein?

Ja der Befehl kommt aus dem offiziellen GitHub Wiki von Nextcloud daher auch der Link. Den Befehl musst du mit sudo im Terminal eingeben.

 

[Pyrukar]

soo ich hab mich mal jetzt online mit jemandem Zusammengesetzt der etwas mehr Anung von Linux Konsolen befehlen hat wie ich und wir konnten das Problem lösen.

Kurzfassung wie hier schon vermutet wurde lagen die Daten im Papierkorb und haben nicht meinem Nutzer gehört, weshalb die meisten Tools sie nicht dargestellt haben aber die Festplatte dennoch voll war.
Lösung war also mit chown die Daten an meinen Benutzer zu überschreiben und dann einfach den Papierkorb zu leeren.

Dennoch danke an alle die hier tatkräftig vorschläge und Lösungsansätze gepostet haben, das Ganze wäre vermutlich nicht so schnell gegangen, wenn ich nicht mit eurer Hilfe schon vorarbeit geleistet hätte

 

[zelect0r]

Im besten Fall sollten die Daten "www-data" gehören.
Das habe ich auch so übernommen als ich mit der nativen Installation zu podman gewechselt bin.