Tobias: Backup bei NTFS langsamer als bei EXT4

Hallo,

unter Linux nutze ich zum Backup rsync. Hat sich seit dem letzten Backup nicht viel geändert, stellt rsync das sehr schnell fest und es werden nur die Änderungen kopiert bzw. gelöscht.

Gleiches versuche ich unter Windows mit robocopy. Auch hier gibt es die Möglichkeit nur Änderungen zu übertragen. Aber: Um die Änderungen festzustellen, werden zunächst alles Ordner durchsucht und verglichen. Das dauert bei entsprechend großen Datemvolumen ewig.

Warum ist der unterschied so groß? Liegts am Programm oder (was ich ja eher vermute) am Dateisystem (Windows: NTFS, Linux: EXT4)?

Tschau

Tobias

--
Speedswimming? Finswimming? Flossenschwimmen?
ie:{ fl:| br:> va:) ls:[ fo:| rl:( n4:° ss:| de:] ch:? mo:) zu:)
Die Erklärung zum Selfcode findest du hier: http://emmanuel.dammerer.at/selfcode.html
Einen Decoder für den Selfcode findest du hier: http://peter.in-berlin.de/projekte/selfcode
  1. Hi,

    Warum ist der unterschied so groß? Liegts am Programm oder (was ich ja eher vermute) am Dateisystem (Windows: NTFS, Linux: EXT4)?

    ich glaube schon, dass es zum Großteil am Dateisystem liegt bzw. daran, wie effizient der Treiber dazu implementiert ist. Unter Windows 2000 habe ich bereits eindrucksvoll erlebt, dass der systemeigene NTFS-Treiber alles andere als performant ist, denn vor allem das Schreiben großer Datenmengen auf eine NTFS-Partition dauerte teilweise um 50..100% länger als auf eine FAT32-Partition auf derselben Platte. Lesezugriff war bei beiden Filesystemen etwa gleich schnell.

    Auf meinem XP-Rechner, der hier immer noch ab und zu treue Dienste leistet, ist auch der Zugriff auf eine ext2/ext3-Partition via Ext2IFS-Treiber merklich schneller als auf eine andere Partition mit native NTFS; am schnellsten ist da aber nach wie vor FAT32.

    So long,
     Martin

    --
    Lehrer:  Wieviel ist die Hälfte von 8?
    Schüler: Kommt drauf an. Waagrecht 0 und senkrecht 3.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Moin!

      Warum ist der unterschied so groß? Liegts am Programm oder (was ich ja eher vermute) am Dateisystem (Windows: NTFS, Linux: EXT4)?

      ich glaube schon, dass es zum Großteil am Dateisystem liegt bzw. daran, wie effizient der Treiber dazu implementiert ist. Unter Windows 2000 habe ich bereits eindrucksvoll erlebt, dass der systemeigene NTFS-Treiber alles andere als performant ist, denn vor allem das Schreiben großer Datenmengen auf eine NTFS-Partition dauerte teilweise um 50..100% länger als auf eine FAT32-Partition auf derselben Platte. Lesezugriff war bei beiden Filesystemen etwa gleich schnell.

      Vergleiche nicht Äpfel mit Mülleimern.

      Was du außer acht lässt, sind die weiteren Features eines Dateisystems außer "nimmt die Daten schnellstmöglich entgegen", darunter so interessante Dinge wie "findet die Daten auch wieder" und "die wieder gelesenen Daten entsprechen den geschriebenen - und im Zweifel merkt das Dateisystem, dass sie nicht mehr identisch sind".

      - Sven Rautenberg

      1. Hallo,

        ich glaube schon, dass es zum Großteil am Dateisystem liegt bzw. daran, wie effizient der Treiber dazu implementiert ist. Unter Windows 2000 habe ich bereits eindrucksvoll erlebt, dass der systemeigene NTFS-Treiber alles andere als performant ist, denn vor allem das Schreiben großer Datenmengen auf eine NTFS-Partition dauerte teilweise um 50..100% länger als auf eine FAT32-Partition auf derselben Platte. Lesezugriff war bei beiden Filesystemen etwa gleich schnell.
        Vergleiche nicht Äpfel mit Mülleimern.

        nana, das klingt aber hart! Sooo übel ist NTFS auch wieder nicht.

        Was du außer acht lässt, sind die weiteren Features eines Dateisystems außer "nimmt die Daten schnellstmöglich entgegen", darunter so interessante Dinge wie "findet die Daten auch wieder" und "die wieder gelesenen Daten entsprechen den geschriebenen - und im Zweifel merkt das Dateisystem, dass sie nicht mehr identisch sind".

        Nein, das lasse ich keineswegs außer acht. Das sind Grundanforderungen, die immer erfüllt sein _müssen_, damit ein Filesystem überhaupt zu gebrauchen ist. Darüber hinaus ist aber die Performance schon ein wichtiger Faktor. Und genau darum ging es ja im OP, das mich an das subjektiv relativ schlechte Abschneiden von NTFS in dieser Disziplin erinnerte.

        Ciao,
         Martin

        --
        Drei Sachen vergesse ich immer wieder: Telefonnummern, Geburtstage und ... äääh ...
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  2. Hallo,

    Ist es denn dieselbe Speicher-Hardware? Sind es vergleichbare Daten?

    Wenn nein, liegt es höchstwahrscheinlich an der Leserate der unterschiedlichen Festplatten bzw. an der unterschiedlichen Zersplitterung der Daten (mehr Verzeichniss, mehr Dateien, viele kleine Dateien…).

    Wenn ja, würde ich die Hypothese aufstellen, dass es an der Software liegt. Also am Dateisystem oder an der Backup-Software, die geänderte Dateien sucht. Ich bin kein Experte für Dateisysteme, kann mir aber nicht vorstellen, dass bei NTFS und Ext4 das reine Traversieren des Baumes und Lesen von Dateien große Rechenpower erfordert (aktuelle Prozessoren vorausgesetzt). Da unterscheiden sich die Dateisysteme natürlich, aber nicht so stark, dass es einem bei kleineren Backups ohne statistisch korrekte Benchmarks auffällt. Die Abweichung dürfte da unter 5% liegen.

    Alle gängigen Dateisysteme unterstützen Änderungszeitstempel, daher lässt sich ein einfacher Vergleichsalgorithmus problemlos umsetzen. Ich würde ins Blaue hinein vermuten, dass das Jahrzehnte alte rsync hier besser optimiert ist als robocopy. Hast du einmal ein anderes inkrementelles Backup-Programm für Windows/NTFS verwendet? Vielleicht performt das schon viel besser. Steckt Microsoft überhaupt noch Entwicklungszeit in robocopy? Sicherung ist ja mittlerweile in Windows integriert; vielleicht arbeitet die bereits effizienter.

    Mathias