Anzeige
Anzeige

Am Puls von Microsoft

Anzeige

Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis

C

Com

kennt sich schon aus
Hallo liebe Community,

ich habe nur mal eine Frage aus Interesse, ich mache ab und zu ein Backup mit robocopy und mir ist aufgefallen, dass ich auf der Quell-Platte etwa 8GB mehr Speicher frei habe, als auf der Ziel-Platte.

Warum ist das so?

Die Kapazität beider Festplatten beträgt jeweils etwa 1,81TB (Bild 1) und der zu kopierende Ordner hat eine größe von 1,67TB (Bild 2), wenn ich die 1,67 von der 1,81 abziehe lande ich ja bei etwa 140GB freien Speicher, auf der Quell-Platte habe ich allerdings 148GB freien Speicher.

So führe ich robocopy aus:
Code: 
robocopy H:\A J:\B /mir /log+:RoboLog01.txt /v /fp /np /dcopy:t /x /ts /xd H:\A\500gb_bkup


Im Netz habe ich u.a. gelesen, dass es etwas mit Hardlinks und Symlinks zu tun haben könnte, z.B. hier:
https://www.computerbase.de/forum/threads/nach-kopieren-unterschiedliche-ordnergroesse-und-dateianzahl.1040517/

Ich habe auch mal mit Cygwin auf beiden Platten einmal nach Hardlinks:
Code: 
find . -links +1

und einmal nach Symlinks:

Code: 
find . -type l -ls

suchen lassen, die Ausgabe für beide Platten ist aber identisch.

Hat jemand eine Idee, wie das mit den 8GB zustande kommt?
 

Anhänge

  • Platten_Vergleich.PNG
    Platten_Vergleich.PNG
    107,9 KB · Aufrufe: 127
  • Ordner_A-B_Vergleich.PNG
    Ordner_A-B_Vergleich.PNG
    71,3 KB · Aufrufe: 131
Anzeige
Im 2. Bild steht die Antwort / Lösung. Auf beiden Datenträgern befindet sich die gleiche Datenmenge (1.844.821.763.184 Bytes), aber die Daten belegen unterschiedlich viel Platz. Das passiert deswegen weil die Platten wohl unterschiedliche Cluster-Größen verwenden. (Legt man beim Formatieren fest.)

Die Default-Größe bei NTFS ist 4096 Bytes. Ist eine Datei z.B. 40 Bytes groß, dann belegt sie trotzdem 4096 Bytes auf dem Datenträger. Gleiches gilt für größere Dateien. Mit 6000 Bytes belegt eine Datei 2 Cluster und damit 2 x 4096 Bytes = 8.192 Bytes.
Wenn deine HDDs unterschiedliche Cluster-Größen verwenden, dann ist am Ende unterschiedlich viel Platz belegt. Deswegen gibt es den Unterschied zwischen Datengröße und Größe auf dem Datenträger.

Infos zu den Cluster-Größen kannst du z.B. via "Powershell" unter Windows abfragen. Einfach die Powershell starten und eingeben:
Code: 
Get-Volume  | Format-List AllocationUnitSize, FileSystemLabel, DriveLetter

Der relevante Wert ist die Angabe zu "AllocationUnitSize"
 

Anhänge

  • Get-Volume_-_Command_not_found.PNG
    Get-Volume_-_Command_not_found.PNG
    46,7 KB · Aufrufe: 97
Wichtig ist "Größe" und "Inhalt". Aber robocopy ist alles andere als zeitgemäss und hat Limitierungen, spätestens bei der Anzahl Pfad-Ebenen und Länge des Pfade - nimm irgendwas, was UNC kann.
 
@HerrAbisZ:

So, gestern Abend ist die Defragmentierung von J:, also der Platte wo nur 140GB über sind, abgeschlossen worden (Bild4).
Hat ganz schön gedauert :D

Vielleicht sollte ich noch erwähnen, dass es sich bei den beiden Platten um externe Festplatten handelt.
Systemdateien, wie zum Beispiel Schattenkopien oder ähnliches sind dort nicht enthalten, den Papierkorb habe ich natürlich auch überprüft.


@.Bernd:

Welches Programm zum Spiegeln von Dateien könntest du mir denn als Robocopy-Alternative empfehlen?
Die Geschwindigkeit ist mir egal, es sollte aber zuverlässig sein.


---

Was ich halt nur seltsam finde ist, dass nicht auf J: 8GB zu wenig sind, sondern, dass auf H: 8GB zuviel sind. Denn wenn ich nochmal Bild1 anschaue und dort von den 1,81TB 1,67TB abziehe, lande ich bei 140GB und nicht bei 148GB.

Oder kann es sein, dass der Explorer spinnt und was falsches anzeigt?

Wird sich spätestens wohl dann zeigen, wenn ich über die 140GB Grenze komme...
 

Anhänge

  • J-Defragmentiert.PNG
    J-Defragmentiert.PNG
    88,9 KB · Aufrufe: 99
Also es sind beide 2TB externe Festplatten.

Beide sind NTFS formatiert.

Beide haben eine Speicherkapazität von 1,81TB

Beide sind mit etwa 1,67TB belegt, da ich immer die Daten von H: auf J: spiegele.

Laut Bild3 haben beide eine Block-Größe von 4096.
(Block-Größe ist das selbe wie Cluster-Größe?)


Theoretisch müssten beide nur 140GB Speicher übrig haben, da ja 1,81TB - 1,67TB = 0,14TB also 140GB sind.
Aber die Platte von der ich immer rüberspiegele, die Quell-Platte, hat seltsamerweise 148GB Speicher übrig.


Das ist kein Problem, was eine hohe Priorität besitzt, mich würde nur interessieren, wie die 8GB mehr zustande kommen.
Habe weiter oben ja geschrieben, dass ich im Netz etwas über Soft- und Hardlinks in dem Zusammenhang gefunden habe. Ich kenne mich aber diesbezüglich in dem Bereich zu wenig aus.
 
Man bräuchte ein dritte 2TB HDD - die anderen vollständig formatieren und dann die Daten wieder drauf geben

Vielleicht irgendwelche alte gelöschte / versteckte Daten ?

Mal euch ein Recuva drüber laufen lassen ?
 
die Robocop Alternative schlechthin wäre für mich GoodSync, kostet aber


Block-Größe ist das selbe wie Cluster-Größe?
Zum Vergrößern anklicken....

Sektoren: Größe wird von der Festplatte festgelegt und dient zur Adressierung der Daten (Blöcke) auf der Platte.

Cluster: liegt am Dateisystem, es werden mehrere Blöcke/Sektoren zu einem logischen Block zusammengefaßt, traditionell bei NTFS 8 Stück a 512 Byte=4KByte.
 
Wollte mir nochmal die Sektorgröße ausgeben lassen, diesmal mit:

Code: 
fsutil fsinfo ntfsinfo

Hier das Ergebnis:

für H:

Code: 
NTFS-Volumeseriennummer :           0x968e1d048e1cde95
Version :                           3.1
Anzahl der Sektoren :               0x00000000e8e080ae
Gesamtzahl Cluster :                0x000000001d1c1015
Freie Cluster :                     0x000000000250c4d2
Insgesamt reserviert :              0x0000000000000660
Bytes pro Sektor :                  512
Bytes pro physischen Sektor :       4096
Bytes pro Cluster :                 4096
Bytes pro Dateidatensatzsegment :   1024
Cluster pro Dateidatensatzsegment : 0
MFT-g�ltige Datenl„nge :            0x0000000028940000
MFT-Start-LCN :                     0x00000000000c0000
MFT2-Start-LCN :                    0x0000000000000002
MFT-Zonenstart :                    0x00000000185f5e80
MFT-Zonenende :                     0x00000000185f7e60
RM-Bezeichner:        BBFA32B5-9086-11E3-9217-B8CA3AA009F1

für J:

Code: 
NTFS-Volumeseriennummer :           0x3804e35f04e31f1e
Version :                           3.1
Anzahl der Sektoren :               0x00000000e8e077ff
Gesamtzahl Cluster :                0x000000001d1c0eff
Freie Cluster :                     0x0000000002379b3e
Insgesamt reserviert :              0x000000000005f990
Bytes pro Sektor :                  512
Bytes pro physischen Sektor :       <Nicht unterst�tzt>
Bytes pro Cluster :                 4096
Bytes pro Dateidatensatzsegment :   1024
Cluster pro Dateidatensatzsegment : 0
MFT-g�ltige Datenl„nge :            0x0000000029bc0000
MFT-Start-LCN :                     0x00000000000c0000
MFT2-Start-LCN :                    0x0000000000000002
MFT-Zonenstart :                    0x000000001b6fd460
MFT-Zonenende :                     0x000000001b709c80
RM-Bezeichner:        F061B8CB-31AA-11E3-B2E8-DF15230BB621

laut einem Kommentar hier unter der akzeptierten Antwort:
https://stackoverflow.com/questions/9465451/how-can-i-determine-the-sector-size-in-windows

soll, wenn die Eigenschaft Bytes pro physischen Sektor nicht unterstützt wird, die Größe 512 sein.
Es wird aber keine Quelle genannt.

Das würde dann aber wohl den Unterschied erklären...



@Mark O.:

Danke für die Erklärung
 
@KnSN:

Danke für den Link.
Also nach der Erklärung dort ist H: wohl 512 emulated.

Nun zu J:
Wo steht dort aber, dass wenn Bytes pro physischen Sektor nicht unterstützt wird, dies 512 Bytes pro Sektor sind?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Anzeige
Oben