helpstoreBackup - Support: sr #108865, Dateivergleich: Vergleich von size...

 
 

sr #108865: Dateivergleich: Vergleich von size statt ctime möglich (und sinnvoll)? Idee ist, dass Backpus von ntfs schneller laufen

Submitter:  None
Submitted:  Thu 13 Aug 2015 04:12:59 PM UTC
 
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Tue 03 Nov 2015 05:35:40 AM UTC, comment #2: 

Hi,

ich kann bestätigen, dass StoreBackup unter cygwin unter Win7 (bei mir) auch nur das Relevante (geänderte/neue) einem md5-check unterzieht:

sum of target new = 20.13%
sum of md5ed files = 20.23%

Gruß lopiuh @ gmail.com

Anonymous
Sun 16 Aug 2015 05:45:38 PM UTC, comment #1: 

Hallo,

so ganz verstehe ich das Problem nicht. Ich sichere bei mir nur eine ntfs Partition, die von Windows geschrieben wird. Ich habe gerade von Linux aus (dualboot) mal ein Backup der Linux und der Windows-Partitionn gemacht:
19328 files processed
forks md5 = 241
Das sieht ja ganz vernünftig aus.

Wieso werden bei Dir die ctime-Werte geändert?

Mit den Bezeichnungen scheinst Du Recht zu haben - jedenfalls macht es so mehr Sinn.

>  Dabei kennt der Linux-Kernel aber doch eigentlich keine "creation time"? Laut http://lwn.net/Articles/397442/ habe Linus Torvalds nur mal drüber nachgedacht, die ctime als "creation time" umzudefinieren, weil das Windows-Attribut "date created" veränderbar sei, also eher eine "change time" wäre. Wobei Deine ctime vermutlich das ist, was Perl als ctime sieht und als cross-platform Sprache mag die Definition von der Linux-Defintion abweichen...und ich bin mir auch nicht sicher, was der Linux-ntfs-Treiber auf die ctime legt...


Mit dem, was ich mache, liege ich auf jeden Fall "auf der sicheren Seite" - es werden bei Änderung der Rechte nur ein paar md5 Summen zuviel gerechnet. Bisher hat das nie gestört.

Die Frage wäre, warum die sich bei Deinen ntfs Partitionen ändern?

Sieh mal in storeBackup.pl, Zeile 2142ff.
Mit der "versteckten Option" könntest Du die ctime ausknipsen:
storeBackup.pl ...... --ignoreTime ctime

Hilft das weiter?

Grüße, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Project Administrator
Thu 13 Aug 2015 04:12:59 PM UTC, original submission:  

Hallo Heinz-Josef,

Dein Programm und Deine Dokumentation ist fantastisch. Mit der Fähigkeit zur Dateikompression, verschobene bzw. umbenannte Dateien zu deduplizieren, die Datei-Integrität prüfen, große Dateien zu zerlegen, einen isolated-mode zu nutzen, ragt es weit über die Masse der Hardlink-Backup-Tools heraus.

sB berechnet die md5-Summe nur für Dateien, bei denen "Pfad + Dateiname, ctime, mtime" nicht identisch ist, http://www.nongnu.org/storebackup/en/node22.html . Hingegen wird - soweit ich das sehe - die Kombination "Pfad + Dateiname, mtime, size" von vielen anderen Backup-Programme benutzt, weil sie unter der Haube auf rsync und dessen default-Vergleichseinstellung zurückgreifen. So zB bei dem ct-rsync-Skript für Windows aus 2006, bei dirvish oder bei einem der unzähligen Timemachine-Clones von Github. Zwar bietet rsync auch einen genaueren Vergleich (-c), aber beim querlesen von einigen Artikeln zum Thema "rsync und backup" wird diese Option sehr selten genutzt. Damit scheint die Kombination "Pfad + Dateiname, mtime, size" von vielen als hinreichend und bewährt angesehen zu werden.

Kann man storeBackup dazu bringen, auch diese Kombination zu nutzen, also  beim Vergleich als 4. Merkmal neben Pfad, Dateiname, mtime auf die Größe statt die ctime zu setzen? Ich frage nur, weil die Größe jeder Datei ohnehin in .md5CheckSums.bz2 vermerkt ist.

Auf das Thema bin ich gekommen, weil ich von Deinem Programm so begeistert bin, dass ich angefangen habe, es für alle Backups im Haushalt einzusetzen, unter anderem von ntfs-Partitionen auf meine große ext4-Backupfestplatte. Dabei bin ich aber auf das Problem gestoßen, dass Folge-Backups mit storeBackup regelmäßig sehr lange dauern, auch wenn nur kaum etwas verändert wurde.

Ein Beispiel:
Ich habe vor kurzem ein neues Laufwerk mit gut 60.000 Dateien und 350GB erstmalig mit sB gesichert. Jetzt stand das erste Folgebackup an. Es hat sich nur wenig gegenüber der ersten Sicherung verändert. Dabei wollte ich die Geschwindigkeit von storeBackup mit einem anderen Hardlink-Backup-Tool vergleichen. Für bessere Vergleichbarkeit habe ich die Kompression in storeBackup deaktiviert (comprRule = 0). Die Folge-Sicherung dieses Laufwerks dauert mit
-storeBackup fast 2 Stunden. Laut log-Datei gab es nur "sum of target new = 6.57%" aber "sum of md5ed files = 75.12%.".
-rsync etwa 20 Minuten. Ich habe rsync mit mit der Option "--link-dest=/Pfad/zu/Backup/Serie-neuesLaufwerk/2015.08.01_00:00:00" [das ist das erste Vollbackup, erstellt mit sB] ausgeführt. "--link-dest=dir" bedeutet "unchanged files are hard linked from DIR to the destination directory.".

Ein ähliches Geschwindigkeitsproblem habe ich auch bei der Sicherung von einer anderen ntfs-Partition: Da gab es sogar mal "sum of target new = 11.47%" und "sum of md5ed files = 100.00%". Ich wüsste nicht, wie ich bewusst die ctime oder mtime von jeder Datei verändert haben sollte. An dieser einen Partition kann es also nicht liegen. storeBackup ist auch nicht immer so langsam. Wenn ich vergleichbare Mengen von einer anderen Festplatte mit ext4-Partition sichere, läuft storeBackup wohl unter 30 Minuten.

Auf der Suche nach dem Grund dieses Unterschieds bin ich auf die ctime gestoßen. Ich habe aus dem letzten Backup die .md5CheckSums.bz2 entpackt und die entsprechenden Einträge der Datei mit der Ausgabe von "stat -c %Z,%Y filename" von einigen eigentlich unveränderten Dateien auf meiner ntfs-Partition verglichen. Dabei war die mtime immer gleich, aber die ctime unterschied sich. Anscheinend versauen entweder irgendetwas in Windows oder der Linux-ntfs-Treiber die ctime. Das scheint mir Dein Programm deutlich auszubremsen? Weil Dein Programm aber einzigartige Features hat (siehe oben) möchte ich nur ungern auf ein anderes Hardlink-Backup-Programm wechseln. Vielleicht würden auch andere Leute profitieren, wenn man einstellen könnte, wann Dateien allein anhand der Metadaten als identisch beurteilt werden? Ich weiß, dass storeBackup eine "Backup Suite für GNU/Linux" ist, deshalb soll das nur eine höfliche Nachfrage/Anregung sein.

Man genieße meine Ausführungen und Diagnose mit Vorsicht. Ich bin Anfänger und mir z.B. nicht ganz sicher, was "ctime" eigentlich ist. ctime wird wohl zumeist als "change time" von Metadaten gedeutet, in Deiner Dokumentation hingegen als "Erzeugungszeit/creation time" bezeichnet. Dabei kennt der Linux-Kernel aber doch eigentlich keine "creation time"? Laut http://lwn.net/Articles/397442/ habe Linus Torvalds nur mal drüber nachgedacht, die ctime als "creation time" umzudefinieren, weil das Windows-Attribut "date created" veränderbar sei, also eher eine "change time" wäre. Wobei Deine ctime vermutlich das ist, was Perl als ctime sieht und als cross-platform Sprache mag die Definition von der Linux-Defintion abweichen...und ich bin mir auch nicht sicher, was der Linux-ntfs-Treiber auf die ctime legt...

Vielen Dank für Deine Zeit und viele Grüße,
Richard

P.S.: Ich habe storeBackup auch aus cygwin ausgeführt. Die Daten werden zuverlässig kopiert und dedupliziert. Aber auch da sind Folgebackups bei nur wenig veränderten Daten häufig sehr langsam. Das ist immer dann so, wenn extrem viele md5-Summen berechnet werden.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hjclaes (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9