Developer92 schrieb:
Capatcha schrieb:
Wenn ich fsck über die Platte laufen lasse, dann zeigt er mir folgendes an:
| sudo fsck /dev/sdc4
fsck von util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdc4: sauber, 1341693/114622464 Dateien, 446688654/458465280 Blöcke
|
Was ist mit 1341693/114622464 Dateien jetzt gemeint? Kann ich da doch mehr Daten drauf machen und es hängt nur irgendwo was?
Ich könnte mir vorstellen, dass die Anzahl der Dateien von der aktuellen Anzahl an Dateien sowie der übrigen Anzahl an Inodes des Dateisystems abhängig ist. Bei dir sind allerdings auch knapp 97,4% der Blöcke in Verwendung. Aufgrund des reservierten Speichers für root könnte es also sein, dass das Dateisystem hier bereits als „voll“ gemeldet wird. Die Ausgabe von sudo tune2fs -l /dev/sdc4 würde weitere Erkenntnisse liefern.
Zu deinem Backup-Problem kann ich dir allerdings nicht helfen.
Ich habe gestern noch das Programm rdfind gefunden, dass doppelte Dateien finden und diese durch Hardlinks ersetzen kann. Ich habe es dann auch mal über die Festplatte laufen lassen und habe so um die 230GB frei bekommen.
Hier ist jetzt die Ausgabe vom Programm, ich weiß aber nicht, ob man damit noch was anfangen kann, nachdem ich rdfind benutzt habe.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45 | sudo tune2fs -l /dev/sdc4
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: /media/capatcha/eaefabc7-7924-4720-9313-e5d23d4cef63
Filesystem UUID: eaefabc7-7924-4720-9313-e5d23d4cef63
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 114622464
Block count: 458465280
Reserved block count: 22923264
Free blocks: 78995991
Free inodes: 113442597
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 914
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Oct 18 17:46:26 2014
Last mount time: Tue Feb 17 13:59:39 2015
Last write time: Tue Feb 17 14:01:13 2015
Mount count: 38
Maximum mount count: -1
Last checked: Sat Oct 18 17:46:26 2014
Check interval: 0 (<none>)
Lifetime writes: 4551 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 27951cb1-43fa-4716-b924-1bd0eced45ba
Journal backup: inode blocks
|
Hier finde ich die Zeile mit "Last checked: Sat Oct 18 17:46:26 2014" seltsam, da ich es doch gestern überprüft habe.
Benno-007 schrieb:
Zu deinem Backup-Problem kann ich dir allerdings nicht helfen.
Zeig mal deinen rsync-Befehl. Der enthält ja auch die Ordner, wo du was löschen kannst. Hardlinks brauchen allerdings kaum Speicher, aber die Differenzen und Inoden summieren sich auch auf.
Mach dir selber mal ein Bild:
ls -hal /media/$USER/*
Zeigt mir nur den Speicherbedarf der Dateien direkt im Ordner an aber nicht der Ordner, die sich in diesem befinden.
So sieht der Backupbefehl bei mir aus:
| rsync -avx --progress -link-dest="/media/Externe/letztes Backup" "Meine Daten" "/media/Externe/neues Backup"
|
Namen stimmen jetzt nicht überein, aber von der Struktur her schon.