local backup auf volume2, Grössenunterschiede bei Dateien

[duffy]

Hallo zusammen,
ich habe ein etwas merkwürdiges Verhalten beim local backup auf Volume 2 festgestellt.
Ich lasse mit der eingebauten Backup-Funktion jede Nacht eine Kopie der shared folders von Volume 1 auf Volume 2 erstellen (gelöschte Dateien bleiben im Backup erhalten). Dabei ist mir aufgefallen, dass nach einer Sicherung zwar die Timestamps der Dateien auf Volume 1 und Volume 2 gleich sind, jedoch die Dateigrösse einiger Dateien unterschiedlich ist. Bei den Fällen, die ich gefunden habe, war in jedem Fall die Datei im Original kleiner als die auf dem Backup. Ein binärvergleich war mir auf Grund des Grössenunterschieds bisher nicht möglich, der Inhalt des Backups schien aber auf den ersten Blick OK zu sein.
Ist das Verhalten hier schonmal jemandem aufgefallen? Kann das mit irgendwelchen Einstellungen zusammenhängen? oder ist es ein fall für den Support?
System: DS209 mit DSM 2.3-1141
Viele Grüße
Markus

 

[itari]

Geht das auch bei ganz kleinen Dateien? Also Dateien, die nur 10 oder 20 Zeichen groß sind? Kannst das damit mal irgendwie vorführen?

Itari

 

[thedude]

Von wieviel Byte/Kilobyte/Megabyte Grössenunterschied reden wir denn?

gruss
dude

 

[duffy]

das muss ich noch ausprobieren, ich hoffe ich komme heute abend dazu einen extra Test-share dafür einzurichten um das Verhalten definiert nachzustellen.

Markus

 

[duffy]

Von wieviel Byte/Kilobyte/Megabyte Grössenunterschied reden wir denn?

Je nach Datei im Byte/Kilobyte-Bereich. Ich habe den Eindruck, dass es bei Dateien auftritt, die durch Änderung kleiner geworden sind (Excel, Word) und dass die Grösse im Backup nicht verringert wird.
Ich dachte ich frage erstmal hier bevor ich versuche das definiert nachzustellen, den Reaktionen nach scheint das Verhalten aber eher unbekannt zu sein. Ich werd´s dann heute abend mal versuchen definiert nachzustellen.

Markus

 

[itari]

Ein Backup ist eine Kopie und eine Kopie sollte die gleiche Größe haben wie das Original, wenn denn nicht während des Kopierens das Original geändert wird.

Nun beherrscht der rsync nicht nur das Byte-Kopieren, sondern auch ein Block-Level-Kopieren (und kann daher eine Datei auch gleichzeitig mit 3 oder 4 Threads auf einmal kopieren (z.B. bei 4 Threads kopiert jeder Thread ca 25%). Der rsync ist auch so intelligent, dass er Blöcke identifizieren kann, welche sich nicht geändert haben und diese dann erst gar nicht kopiert. Das sind also auch noch Verfahrensweisen, welche eventuell verschiedenen Daten produzieren. Aber am Ende der Kopiererei sollte der rsync die Inode-Angaben (Datei-Header: Größe, Zugriffsrechte, Änderungsdatum usw.) wieder gleichziehen ... Wenn das nicht passiert, sollte es schon einen Grund dafür haben ... und den wollen wir uns gerne mal anschauen.

Itari

 

[duffy]

Ich habe das Ganze jetzt mal nachgestellt und ich kann das Verhalten eindeutig reproduzieren:
Ich habe auf volume 1 einen share "test-1" angelegt und auf volume 2 einen share "test-2".
Dann einen local backup-job angelegt mit Quelle test-1 und Ziel test-2.
Auf test-1 eine Datei test.txt angelegt, Grösse 5212 bytes.
Backup-Job ausgeführt, successful, Dateien auf /test-1 und /test-2/LocalBackup/test-1 sind identisch.
Nun habe ich aus der Textdatei auf test-1 am Ende einen ganzen Absatz rausgelöscht und einen kurzen Text hinten angefügt, neue Größe: 4888 bytes.
Backup-Job erneut ausgeführt, successful.
Ergebnis: Die Datei auf test-2 hat einen neuen timestamp passend zur Quelldatei aber immer noch 5212 bytes, der kurze Text, den ich an Stelle des Absatzes eingefügt habe, steht an der richtigen Stelle in der Datei, dahinter steht aber noch der Rest des gelöschten Absatzes.
Das Verhalten ist unabhängig von der incremental-Einstellung ("Do not delete any backed up files"). Auch bei einem Restore wird die Datei mit 5212 bytes restored.

Kann das vielleicht mal jemand von euch checken? Vielleicht hat ja nur meine DS209 eine Macke (kann ich mir aber nicht wirklich vorstellen). Ansonsten wohl ein Fall für den Support oder?

Markus

 

[itari]

Ich denke, dass das eine Konfigurationsgeschichte des rsyncs ist. Die Abweichungen sind möglicherweise durch die Sicherungstechnik des rsync zustande gekommen. Ich hatte ja schon oben Andeutungen gemacht. Schreib das mal dem Synology-Support und frag an, ob sie die Dateigröße korrigieren können, weil das sonst bei dir zu Irritationen führt, welche Dateigröße denn nun die richtige sei.

Vielleicht kannst du auch noch einmal schauen, ob sich auch im Windows-Explorer die Größe der Datei auf dem Datenträger verändert. Das wäre dann wirklich fatal.

Ich finde es toll, dass du solche Dinge hier herausgefunden hast.

Itari

 

[thedude]

Abgesehen von der Grösse ist doch das fatale hier, dass der Inhalt der Dateien nicht mehr übereinstimmt oder verstehe ich das falsch? Das ist doch ein No Go...

gruss
dude

 

[itari]

Nein, so schlimm ist das nicht. Weil MS ja immer eigene Header hat, die auf die Inhalte verweisen. Oft werden auch Sparse-Files verwendet, und da ist die Größenangabe eh Schall und Rauch. Oder anders gesagt; intern mag eine Kopie tatsächlich was total anderes sein; aber rein äußerlich sollte man soviel Wert drauf legen, dass die Dateinfos schon übereinstimmen, weil es sonst irritiert. Wir sind es halt nicht gewohnt, dass 4 25 Euro-Scheine soviel sind wie 8 12,5 Euroscheine, weil wir gedanklich immer dran kleben, dass es diese Scheine ja nicht gibt ...

Itari

 

[thedude]

Wir können jetzt auch anfangen Haare zu spalten. Header... bitte Dich. Wenn ich eine "plain" Textdatei sichere (und das beschreibt der OP) und die nachdem ich sie verändere nicht 1:1 im Backup auftaucht ist das in meinen Augen Gurke. Ein "normales" rsync kann damit auch prima umgehen. Ich habe so Jahre lang meinen Server gesichert und immer alles 1:1 im Backup gehabt. Aber vielleicht bin ich auch zu altmodisch was das angeht. Wer weiss.

gruss
dude

 

[itari]

Nun ich versuche, die Ungereimtheiten zu erklären und zu bewerten und benutze dabei ein Modell, welches halbwegs plausibel ist.

Fall1: Du hast einen Word-Datei abgespeichert. Jetzt änderst was darin und speicherst erneut. In den meisten Fällen wirst alten und neuen Inhalt in der Datei vorfinden und die Datei ist etwas größer geworden, obwohl die Änderungen den Word-Text nicht umfangreicher gemacht wurden. Wenn du die Datei nun 'sicherst', stellt sich die Frage, ob der 'alte' Inhalt auch mit gesichert werden muss ... je nach Intelligenz des Sicherungsprogramms könnte das unterschiedlich ausfallen (und ja, beim Sichern könnte man auch noch nach Viren schauen und komprimieren ... macht z. B. mein Windows-Home-Server so). Nach einer solchen Prozedur ist inhaltlich alles ok, dennoch ist die Datei eine andere geworden ... Dieser Fall ist zwar hier nicht relevant, soll aber etwas veranschaulichen.

Fall2: Ich habe eine Sparse-File. Das heißt, ich habe Löcher in der Datei. Oder anders gesagt, die Datei wird größer angezeigt als sie Platz auf der Platte belegt. Da alle Dateien in Dateiblöcken auf der Platte liegen, kann es durch unterschiedliche Blockgrößen sein, dass auch unterschiedlich viel Platz bei einer Kopie verbraucht wird, z.B. weil die Datei nun anders Fragmentiert wird. In anderen Worten: inhaltlich gleich, aber von der Block-Belegung total verschieden. Wenn jetzt ein Backup nicht auf der Byte-Ebene kopiert wird, sondern auf Block-Ebene (wie das der rsync gerne macht), dann muss der entweder so clever sein, die Fragmentierung aufzuarbeiten oder er kopiert sie blöd mit ...

So wie ich das verstanden habe, sind es ja keine normalen 'plain'-Dateien sondern Text-Dokumente ... deswegen hatte ich von Datei-Headern gesprochen. Kann ja sein, dass ich das missverstanden habe ...

Itari

 

[thedude]

Fall 1) und 2) sind klar verständlich und auch mögliche Scenarios. Hast völlig Recht. Ich hab den OP halt so verstanden das er Textdateien zum testen verwendet (.txt Suffix) und dort nicht nur die Grösse (die den von dir skizzierten Gegebenheite unterliegen kann) sondern auch den Inhalt kontrolliert. Wiederum mit einem Texteditor. Und wenn da das beschriebene Verhalten auftritt finde ich das aus der Ferne gesehen zumindest fragwürdig. Mehr sage ich ja gar nicht.

tschö
dude

 

[itari]

Nur damit kein Missverständnis aufkommt: Ich finde es auch nicht gut, dass die Dateien unterschiedliche Größenangaben haben und ich denke, dass man das auch aufklären muss bzw. wenn es ein Fehler ist, den auch beseitigen.

Meine Erläuterungen waren dafür gedacht, dass es durchaus sein kann, dass die rsync-Backup-Dateien trotzdem einen korrekten Inhalt haben können und damit die Backup-Funktionalität nicht in Frage gestellt werden muss. Denn das wäre ja auch fatal, wenn du dich auf ein rsync-Backup nicht mehr verlassen kannst.

Itari

 

[Trolli]

Na ja - laut Problembeschreibung in Beitrag #7 haben sie aber eben nicht den gleichen Inhalt...

 

[itari]

Na ja - laut Problembeschreibung in Beitrag #7 haben sie aber eben nicht den gleichen Inhalt...

Dort wird gesagt, dass nach dem veränderten Inhalt auch der 'gelöschte' Inhalt steht. Typisch für eine Word-Datei. Schaust es dir mit Word an, haben sie möglicherweise den gleichen Inhalt, schaust es dir mit dem vi an, sind sie vielleicht unterschiedlich. Bei Container-Formaten ist das halt immer so eine Sache ...

Itari

 

[thedude]

Es war aber nie von einem Word Dokument die Rede beim Testaufbau in Beitrag #7. Beitrag #7 sagt "test.txt". Daher gehe ich von einem plain text file aus.

gruss
dude

 

[itari]

Ihr hab ja so recht ... ich hatte das einfach überlesen. Dann ist es halt ein richtig schlimmer Fehler ... also vertraut keinem rsync-Backup mehr

Itari

 

[duffy]

Um die Verwirrungen zu bereinigen hier noch ein paar Ergänzungen:

zum Test habe ich eine Plain-Text-Datei benutzt, kein Word-Dokument. In der Text-Datei ist leichter nachvollziehbar, was sich wirklich tut.
Die Dateigrösse habe ich mir über den Windows-Explorer auf einem gemounteten Share angeschaut.

Bei Office-Dokumenten ist das Verhalten (wie itari schrieb) nicht so problematisch da eine interne Verwaltungsstruktur existiert, die die überflüssigen Daten ignoriert.
Bei Text-Dateien (ich denke zum Beispiel an Quellcodes) ist das Verhalten katastrophal, da kennt sich ja hinterher kein Mensch mehr aus wenn man wirklich auf das Backup zurückgreifen muss.

Ich werde nochmal prüfen, ob sich das Verhalten auch bei grösseren Unterschieden bemerkbar macht (z.B. komprimierte Access-Datenbank oder ein Word-Dokument, aus dem eine Grafik rausgelöscht wird) und das Ganze dann mal dem Support nahe bringen.
Bis dahin halte ich das local backup nur für sehr eingeschränkt tauglich :-(

Markus

 

[duffy]

hier die Antwort vom Support:

After some testing, I think this is our bug. Sorry about that.
We will fix it asap. Thanks for your feedback.
​

Dann warten wir mal auf den Fix.
Markus