Ergebnis 1 bis 14 von 14
Danke Übersicht9Danke
  • 2 Post By _Sabine_
  • 1 Post By Com
  • 1 Post By Com
  • 1 Post By KnSN
  • 2 Post By Com
  • 2 Post By KnSN
Thema: Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis Hallo liebe Community, ich habe nur mal eine Frage aus Interesse, ich mache ab und zu ein Backup mit robocopy ...
  1. #1
    Com
    kennt sich schon aus

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

    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/th...nzahl.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?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis-platten_vergleich.png   Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis-ordner_a-b_vergleich.png  

  2. #2
    _Sabine_
    gehört zum Inventar

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

    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"
    PeteM92 und skorpion68 bedanken sich.

  3. #3
    Com
    kennt sich schon aus

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

    Danke für den Tipp.

    Allerdings wird mir gesagt, dass die Powershell den Befehl "Get-Volume" (Bild3) nicht kennt.

    Habs dann mal dank dieser Seite:
    https://stackoverflow.com/questions/...-to-get-volume

    mit

    Code:
    Get-WMIObject -Class Win32_Volume | Select DriveLetter,BlockSize,Label
    probiert.


    Das sagt dann aber, dass beide eine Blockgröße von 4096 haben, also kann es daran ja nicht liegen, oder?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis-get-volume_-_command_not_found.png  

  4. #4
    .Bernd
    gehört zum Inventar Avatar von .Bernd

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

    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.

  5. #5
    HerrAbisZ
    unbequemer Zeitgenosse Avatar von HerrAbisZ

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

    Kann eine Defragmentierung helfen ?

  6. #6
    Com
    kennt sich schon aus

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

    @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

    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...
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Nach Backup mehr Speicher im Ziel-Verzeichnis verbraucht als im Quell-Verzeichnis-j-defragmentiert.png  

  7. #7
    HerrAbisZ
    unbequemer Zeitgenosse Avatar von HerrAbisZ

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

    Also H: ist kleiner - wie ist bei beiden die Clustergröße ? 4K ?

  8. #8
    Com
    kennt sich schon aus

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

    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.
    HerrAbisZ bedankt sich.

  9. #9
    HerrAbisZ
    unbequemer Zeitgenosse Avatar von HerrAbisZ

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

    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 ?

  10. #10
    Mark O.
    gehört zum Inventar Avatar von Mark O.

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

    die Robocop Alternative schlechthin wäre für mich GoodSync, kostet aber


    Block-Größe ist das selbe wie Cluster-Größe?
    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.

  11. #11
    Com
    kennt sich schon aus

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

    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/...ize-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
    HerrAbisZ bedankt sich.

  12. #12
    KnSN
    Side Channel Attacker Avatar von KnSN

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

    HerrAbisZ bedankt sich.

  13. #13
    Com
    kennt sich schon aus

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

    @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?
    KnSN und HerrAbisZ bedanken sich.

  14. #14
    KnSN
    Side Channel Attacker Avatar von KnSN

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

    Microsoft verweist auf ein Abfrage-Problem mit dem Device Input and Output Control (IOCTL) und nennt spezifisch die Ausgangsgröße der Bits (die Pufferlänge) als Ursache:
    https://docs.microsoft.com/de-de/win...ectedfrom=MSDN

    Die Vorredner haben recht - sie sind von Anfang an auf der richtigen Fährte, was diese Sache anbelangt.
    HerrAbisZ und Com bedanken sich.

Lesezeichen


  • An Google übertragen Google
  • -->

    Berechtigungen

    • Neue Themen erstellen: Nein
    • Themen beantworten: Nein
    • Anhänge hochladen: Nein
    • Beiträge bearbeiten: Nein
    •  

    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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163