Mehr Platz auf Festplatte belegt als auf der Sicherungskopie. Warum?
 

Hallo,

ich habe auf meinem Laptop
eine 250 GB SSD (C: ), auf der Windows und sämtliche Programminstallationen sind,
und eine 1.000 GB HDD (D: ), auf der nur selbst erstellte und runtergeladene Dateien sind. Keine Windowsdateien und keine sonstigen Installationen sind auf D. Es gibt keine weitere Partition auf dieser HDD.

Gemäß Rechtsklick auf das Laufwerk D im Windows-Explorer habe ich:
Belegter Speicher 998.902.792.192 930 GB
Freier Speicher 1.299.185.664 1,20 GB


Mit dem Robocopy-Befehl robocopy d: f:\kopie_von_d /e /purge /w:0 /r:0
kopiere ich zur Sicherung das komplette D: auf eine externe Festplatte F in das Verzeichnis Kopie_von_D.

Das Programm "Folder Size" sagt mir, dass "Kopie_von_D" 916.011.029 KB groß ist.
Ein Rechtsklick im Windows-Explorer auf F:\Kopie_von_D zeigt 873 GB (937.995.293.546 Bytes).

In jedem Fall scheint die Kopie_von_D auf F also weniger Platz zu belegen als am Ursprungsort D. Aber warum?

Da Robocopy auf dem Ziellaufwerk Dateien löscht, die beim Startlaufwerk nicht vorhanden sind, versuchte ich es anschließend umgekehrt mit robocopy f:\kopie_von_d d: /e /purge /w:0 /r:0.

Das brachte keine Änderung!

Warum ist D größer als Kopie_von_D?
Und wie kann ich den zusätzlich belegten Speicherplatz frei bekommen (ohne dass was fehlt)?

Oder mache ich einen Denkfehler?

Für Hilfe wäre ich dankbar.

Wieso nimmst du robocopy wenn du ein Abbild deiner gesamten 1TB-HDD machen willst? Dafür würde ich drivesnapshot nehmen da es ja um Windows geht.

Ansonsten vergleich einfach mal die Anzahl der Dateien auf der internen mit der externen Platte. Helfen kann dabei auch sowas wie Totalcommander. Mit dem kannst du übrigens auch Verzeichnisse spiegeln oder syncen, noch ein Grund weniger für robocopy.

Oder er holt sich als evtl. Alternative zu drivesnapshot - - -

Ich hatte robocopy genommen, weil ich auch die absichtlich auf D gelöschten Dateien in der Sicherung gelöscht haben wollte, um nicht einen ständig größer werdenden Datenfriedhof zu verursachen. Angesichts der Art der Dateien würde ich sofort bemerken, wenn eine fehlt und könnte die dann auch einzeln wieder zurückkopieren, so dass eine Komplett-Wiederherstellung gar nicht notwendig ist. Außerdem geht so ein Durchgang recht flott, da ja nur die geänderten Dateien angefasst werden.

Zurück zur Frage der abweichenden Dateimenge (oder betrachte ich da etwas falsch und die abgelesenen Zahlen aus meinem ersten Post führen mich in die Irre?):

Total Commander bestätigt mir (Markieren -> Verzeichnisse vergleichen), dass D: identisch wäre mit Kopie_von_D.

Ich hatte zunächst vermutet, dass irgendwie ein (nicht angezeigter) Papierkorb diese Menge aufweisen würde. Aber ich habe den Papierkorb von D sichtbar gemacht, er hatte nur die zuletzt gelöschte Datei von 1,2 GB drin (auch in der Sicherung).

Wo die Differenz von ca. 60 GB herrührt würde mich schon interessieren...

Vergleiche mit Treesize.

Mit Treesize beides verglichen.

Die Angaben "Größe" waren an beiden Orten exakt gleich. Auf D zählt er eine Datei und ein Verzeichnis mehr.

Die Angaben "Belegt" waren an beiden Orten leicht über der Angabe "Größe", jedoch deutlich mehr bei D (ca. 2 GB Differenz bei D; 0,1 GB Differenz bei Kopie von D).

Gleiches Dateisystem, gleiche Cluster-Größe? "fsutil fsinfo ntfsinfo" gibt Auskunft.

Weiß nicht, ob nach einem Monat das Problem noch akut ist :zunge:

Ich habe mit "fsutil fsinfo ntfsinfo D:" bzw "... F:" die Clustergröße auslesen können. Ergebnis:
D: 65536
F: 4096

Neulich war die Differenz ja ca. 60 GB. Ich habe aktuell mehr freie Kapazität und habe neu geprüft.
Windows-Explorer Rechtsklick nach aktuellem Durchlauf robocopy:
D: 904.095.137.792 (842 GB)
F:\Kopie von D: 901.595.562.347 (839 GB)

Jetzt sind es nur noch 3 GB Differenz. Die Dateien, die zwischenzeitlich gelöscht wurden, haben jeweils zwischen 0,1 und 2 GB. Daher denke ich, dass hier die Clustergröße weniger relevant ist (wenngleich es mich stört).

Die 3 GB kann ich tolerieren, die 60 GB wollte ich nicht hinnehmen. Seltsam nur, dass das jetzt anders ist. Gibt es irgendwelche "automatischen" Mechanismen, also welche, die man nicht bewusst einsetzt, die Löschungen erst zeitverzögert umsetzen? Es können keine Temp-Dateien und keine Windows- oder andere Systemdateien sein, weil die alle nicht auf D zugreifen...

Die Frage stelle ich bewusst, weil ich damals auch den Eindruck hatte, dass Löschungen auf D überhaupt nicht den Effekt von zusätzlichem freien Speicher mit sich brachte. Und ich war der Meinung, auf D ca. 50 GB gelöscht zu haben...

Nur deshalb habe ich die Größe der Laufwerke überhaupt verglichen und bin auf diese Abweichung gestoßen.

Papierkorb auch geleert?

Hast du auch per Sync bei Totalcommander wieder verglichen?
Und beachte auch, dass es auf verschiedenen Laufwerken zu unterschiedlichen Belegungen des versteckten Systemordners SYSTEM VOLUME INFORMATION kommen kann. Windows legt da seine Schattenkopien und Restore Points rein.

Ach und nochwas:

Das sind das unvollständige Angaben. Der Filemanager gibt zwei Größen an, die Nettogröße also die tatsächliche Größe in Bytes aller Dateien und die Bruttogröße.
Der Bruttowert ist natürlich größer. Und je mehr kleine Dateien man hat, desto größer ist dieser Wert. Da kannst du auch noch so sehr sagen, dass du es nicht hinnehmen willst, wenn du als Clustergröße 64 kiB genommen hast, dann belegen auch winzige Dateien eben immer min. 64 kiB.

Welche Dateisysteme sind da drauf? Und warum ist für Laufwerk D Keine Standardclustergröße von 4 kiB genommen worden? Das muss man schon selbst aktiv beim Erstellen des Dateisystems verändern!

Auf D sind keine Programminstallationen, lediglich selbst erstellte und runtergeladene Dateien, wie Word, Excel, pdf, Outlook.pst, aber auch Mediendateien wie Bilder, Videos und Musik. Eine erforderliche Dateigröße von unter 64 kB kann natürlich bei Word und Excel vorkommen, das sind aber nicht viele.

Aktuell sind es allein 743 GB Filme aus den öffentlich-rechtlichen Mediatheken im mp4-Format. Hier ist auch die jeweils größte Veränderung, da ein 90-Minuten-Film in mittlerer Auflösung ca. 1,2 GB belegt und selbst eine 7-Minuten-Episode "Shaun das Schaf" über 100 MB hat.

Dazu kommen knapp 100 GB Bilder und 40 GB Musik, 25 GB Radio über radio.fx runtergeladen und 25 GB runtergeladene Installationsdateien (in der Regel .exe), wobei die Installation immer auf C: erfolgte.




Ich hatte das Laptop 2011 bei einer Filiale von Arlt.com mit einer 500GB HDD gekauft. Die hatte ich in C: und D: (gleiche inhaltliche Aufteilung wie heute) und E: für die Recovery partitioniert.

In 2018 habe ich dort die HDD durch eine 250 GB SDD ersetzen lassen und C: dorthin clonen lassen. An der Stelle des optischen Laufwerks habe ich mir zusätzlich die 1.000 HDD einsetzen lassen, wo die alten Dateien aus D: landeten. Beide Festplatten habe ich in diesem Zug dort neu gekauft. Scheinbar wurde dort die Clustergröße so festgelegt.

Da ich die Sicherung ja extern habe, kann ich D: natürlich mit der kleineren Clustergröße neu formatieren, ohne dass mir was verloren ginge.



Der Papierkorb kann es nicht sein, weil der von robocopy einfach mitkopiert wird, wie ich sehen kann. Es ärgert mich dann, weil es unnötig Zeit kostet, dass ich den nicht vorher geleert habe.


Sie "System Volume Information" habe ich mir noch nicht angesehen. Würde Windows auf einer abweichenden Platte größere Informationen reinschreiben? Ich habe ja keine Windows-Systemdateien auf D:

Welche Dateisysteme D und F haben sowie warum D eine Nichtstandardclustergröße hat, willst du nicht verraten?

Ah, ich glaube, ich hatte dich da nicht richtig verstanden. Beide sind NTFS.

Die Clustergröße von D habe ich nicht gesetzt. Das muss eben bei der Arbeit von Arlt.com dort - warum auch immer - so gesetzt worden sein. Da war ich nur Kunde, ohne dass über Dinge wie Clustergröße gesprochen wurde.