Speicherplatz belegt obwohl Datenvolumen nur 750GB

[Egenberger]

Hallo Gemeinde,

wir haben hier eine Synology DS414, dort liegt momentan, über die Filestation wird ein Datenvolumen von etwa 750GB, die Synology selbst meckert an das die 4TB Platten voll wären.

Papierkorb ist nicht aktiviert, wo kann die angebliche Datenmenge sein?

Gruß Egenberger

 

[dil88]

Falls Du die CloudStation intensiv nutzt, dann könnte hier eine Ursache liegen (Hintergrund). Eine kommende Version der CloudStation wird es ermöglichen, die Versionierung abzuschalten. Diese Version wird dann nur noch so viel Speicherplatz belegen wie die Daten, die man 'reinfüllt. Falls bei Dir akute Not besteht, sollte die Deinstallation der CloudStation für Linderung sorgen.

 

[Egenberger]

Hallo,

CloudStation ist nicht installiert.

Gruß Egenberger

 

[Puppetmaster]

Hier wäre dann weitere Infos und ggf. ein paar Screenshots hilfreich, ansonsten stochern wir hier auch im Nebel.

 

[Egenberger]

hier mal 2 Screenshots, was wird noch benötigt? ich liefere gerne jede Info!

 

[dil88]

Auf welche Art schreibst Du Backups auf die DS?

 

[Frogman]

Beispielsweise die übliche Ausgabe von

du -sh /volume1

auf der Konsole (analog für weitere Volumes).

 

[Puppetmaster]

Und was ist die andere Freigabe "ext.HDD"? Ist das tatsächlich eine externes Laufwerk?

 

[Egenberger]

Gesichert wird mit Acronis -> liegt ergo eine TIB Datei in der Backup Freigabe, dann liegt noch eine .vmdk inkl. Konfigdatei darin.

Die ext.HDD ist die USB Platte.

Gruß Martin

 

[Puppetmaster]

Tja, dann mal den Tipp von frogman versuchen. Damit solltest du auf jeden Fall sehen, wo der Speicher verbraten wird.

 

[Egenberger]

hier mal die Ausgabe von Putty, da fehlt doch was oder?

 

[Puppetmaster]

Du musst dich als "root" anmelden. Passwort ist das vom admin.

 

[Egenberger]

ok danke, nun steht aber nur noch 3.6TB /Volume1

weiter wird nichts aufgelistet!

Gruß Egenberger

 

[dil88]

Dann nimm bitte einmal

du -h /volume1

 

[Frogman]

dann mach mal ein

ls -al /volume1

 

[Egenberger]

so mit du -h habe ich doch schon mehr Informationen, diese bkp_repo Geschichte schluckt wohl einiges an Platz.


DiskStation> du -h /volume1
16.0K /volume1/lost+found
4.0K /volume1/@tmp/@img_recycle
8.0K /volume1/@tmp
4.0K /volume1/@spool/cache
4.0K /volume1/@spool/tmp
12.0K /volume1/@spool
444.0K /volume1/@database/pgsql/global
4.0K /volume1/@database/pgsql/pg_xlog/archive_status
16.0M /volume1/@database/pgsql/pg_xlog
12.0K /volume1/@database/pgsql/pg_clog
12.0K /volume1/@database/pgsql/pg_notify
4.0K /volume1/@database/pgsql/pg_serial
4.0K /volume1/@database/pgsql/pg_snapshots
12.0K /volume1/@database/pgsql/pg_subtrans
4.0K /volume1/@database/pgsql/pg_twophase
12.0K /volume1/@database/pgsql/pg_multixact/members
12.0K /volume1/@database/pgsql/pg_multixact/offsets
28.0K /volume1/@database/pgsql/pg_multixact
5.9M /volume1/@database/pgsql/base/1
5.9M /volume1/@database/pgsql/base/11814
6.0M /volume1/@database/pgsql/base/11819
6.4M /volume1/@database/pgsql/base/16384
24.1M /volume1/@database/pgsql/base
4.0K /volume1/@database/pgsql/pg_tblspc
4.0K /volume1/@database/pgsql/pg_stat
4.0K /volume1/@database/pgsql/pg_stat_tmp
40.7M /volume1/@database/pgsql
4.0K /volume1/@database/.pgsql.1395216776
40.7M /volume1/@database
133.8G /volume1/Backup/SERVER
133.8G /volume1/Backup/Backup_alte_Server/SERVER
70.6G /volume1/Backup/Backup_alte_Server/T-SERVER
256.4G /volume1/Backup/Backup_alte_Server
753.6G /volume1/Backup
4.0K /volume1/@autoupdate
4.0K /volume1/@img_bkp_repo/Pool/2/@eaDir
100.6G /volume1/@img_bkp_repo/Pool/2/0/0
100.5G /volume1/@img_bkp_repo/Pool/2/0/1
100.5G /volume1/@img_bkp_repo/Pool/2/0/2
100.5G /volume1/@img_bkp_repo/Pool/2/0/3
100.5G /volume1/@img_bkp_repo/Pool/2/0/4
100.4G /volume1/@img_bkp_repo/Pool/2/0/5
100.5G /volume1/@img_bkp_repo/Pool/2/0/6
100.5G /volume1/@img_bkp_repo/Pool/2/0/7
100.5G /volume1/@img_bkp_repo/Pool/2/0/8
100.5G /volume1/@img_bkp_repo/Pool/2/0/9
100.5G /volume1/@img_bkp_repo/Pool/2/0/10
100.5G /volume1/@img_bkp_repo/Pool/2/0/11
100.5G /volume1/@img_bkp_repo/Pool/2/0/12
100.5G /volume1/@img_bkp_repo/Pool/2/0/13
100.5G /volume1/@img_bkp_repo/Pool/2/0/14
100.5G /volume1/@img_bkp_repo/Pool/2/0/15
100.5G /volume1/@img_bkp_repo/Pool/2/0/16
100.6G /volume1/@img_bkp_repo/Pool/2/0/17
100.3G /volume1/@img_bkp_repo/Pool/2/0/18
100.5G /volume1/@img_bkp_repo/Pool/2/0/19
100.5G /volume1/@img_bkp_repo/Pool/2/0/20
100.5G /volume1/@img_bkp_repo/Pool/2/0/21
100.5G /volume1/@img_bkp_repo/Pool/2/0/22
100.5G /volume1/@img_bkp_repo/Pool/2/0/23
100.5G /volume1/@img_bkp_repo/Pool/2/0/24
100.5G /volume1/@img_bkp_repo/Pool/2/0/25
100.5G /volume1/@img_bkp_repo/Pool/2/0/26
100.5G /volume1/@img_bkp_repo/Pool/2/0/27
94.7G /volume1/@img_bkp_repo/Pool/2/0/28
2.8T /volume1/@img_bkp_repo/Pool/2/0
2.8T /volume1/@img_bkp_repo/Pool/2
2.8T /volume1/@img_bkp_repo/Pool
4.0K /volume1/@img_bkp_repo/Config/2/@eaDir
4.0K /volume1/@img_bkp_repo/Config/2/@cand_file/@eaDir
204.5M /volume1/@img_bkp_repo/Config/2/@cand_file
4.0K /volume1/@img_bkp_repo/Config/2/Backup/@eaDir
172.0K /volume1/@img_bkp_repo/Config/2/Backup
128.0K /volume1/@img_bkp_repo/Config/2/@AppConfig
318.8M /volume1/@img_bkp_repo/Config/2
318.8M /volume1/@img_bkp_repo/Config
2.8T /volume1/@img_bkp_repo
8.0K /volume1/@eaDir/Backup/BackupData/img_backup_local_db/ff0aedadf7a4d90f57e9b046569bfa03/1
28.0K /volume1/@eaDir/Backup/BackupData/img_backup_local_db/ff0aedadf7a4d90f57e9b046569bfa03/2
40.0K /volume1/@eaDir/Backup/BackupData/img_backup_local_db/ff0aedadf7a4d90f57e9b046569bfa03
44.0K /volume1/@eaDir/Backup/BackupData/img_backup_local_db
48.0K /volume1/@eaDir/Backup/BackupData
52.0K /volume1/@eaDir/Backup
56.0K /volume1/@eaDir
3.6T /volume1
DiskStation>


Gruß Egenberger

 

[dil88]

@img_bkp_repo ist die Ursache, der Du auf den Grund gehen musst.

 

[Egenberger]

weiß man woher das kommt bzw. warum das angelegt wird?

Gruß Egenberger

 

[Frogman]

Dann hast Du unter "Backup & Replication" einen Backupjob - der legt in diesem Verzeichnis ab.

 

[TodsDeath]

@img_bkp_repo deutet auf einen Job unter "Datensicherung & Replikation" hin