[OMV] Datenkopie - mir fehlt 1,3TB

Beim MergerFS gibt es doch die zwei unterliegenden Filesysteme. Musste dann halt mal die Kopie direkt mit den beiden Filesystemen vergleichen, ob/was da fehlt.

Gibt's die Möglichkeit, das da irgendwelche Dateien im Merge nicht auftauchen oder evtl in den unterliegenden FS doppelt sind, so das nur eine Kopie davon im Merge auftaucht ?

Ansonsten: Gibts irgendwelche Datenbanken oder evtl. Docker - also sparse Files (bei DB erinnere ich das, bei Docker weiss ich nicht mehr) ? Wobei das eher dazu führt das die Kopie größer wird, wenn man das nicht macht. Beim rsync zumindestens muss man das immer explizit anschalten. Bei cp gibts im default eine Automatik.

SInd alle Filesysteme identisch formatiert (mit identischer Block-Größe und ggf. reserviertem Bereich für root)? (stat -f und tune2fs -l). Das kann Unterschiede ergeben, genauso wie halt auch Verbrauch an Metadaten in altem gewachsenem Filesystem anders (größer) sein kann.

Um Unterschiede aufzuspüren, du -sk für alle Ordner auf oberer Ebene. So kann man sich zu den Unterschieden hangeln.
Was mir einfällt für erschöpfenden sicheren (und recht langsamen) Vergleich mit Bordmitteln diff -qR Ordner_im_alten_FS Ordner_im_neuen_FS. Kannst da den obersten gemounteten Ordner nehmen für die kompletten Filesysteme, aber ich würde erst Mal eine Ebene tiefer anfangen, um zu sehen ob/wie das klappt und schnell Ergebnis zu sehen.

Nun würde ich mich Mal durchhangeln und einen Unterschied genau finden. Also z.B. df -sk Privat/* auf den beiden Kopien und diff -qR /pfad/zu/Privatalt /Pfad/zu/Privatneu. Habe jetzt Privat genommen, weil das das kleinste schien in deiner Liste. Wenn man mal einen Unterschied verstanden hat sieht man weiter.

Beim du -s halt so weit gehen, bis man ein Verzeichnis hat ohne Unterverzeichnisse oder nur mit Unterverzeichnissen die keine Unterschiede zeigen. Dann mit ls -al ein Verzeichnislisting vergleichen. Wenn es nicht so tief verschachtelt ist, kann man natürlich auch direkt du ohne -s leicht vergleichen.

Nutzt du symbolische Links? Wenn ich github Beschreibung von mergerfs kurz überfliege sehe ich viele trickreiche Punkte, die einen Unterschied ergeben können in df Ausgabe. So oder so muss man bei Links aufpassen, die Hinweise unter statfs dort, ...

EDIT: Zu reservierten Blöcken, hier ein Beispiel von mir, in der ein Filesystem bewusst Blöcke reserviert hat:

root@hpms:~# tune2fs -l /dev/sdh1   | grep -i reserv
Reserved block count:     2811276
Reserved GDT blocks:      1010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
root@hpms:~# tune2fs -l /dev/sda1   | grep -i reserv
Reserved block count:     0
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Sowas kann auf einen Schlag einen größeren Unterschied ergeben (ich sag mal in manche Filesystem-Staistiken).

Vergleich halt erst mal die dateigroessen, nicht den Inhalt.

sowas hier z.b. Das ist schneller.

find <mergerfs-dir> -type f -size +100k -exec du -s -k {} \; | sort -k +2 > /tmp/orig
find <copy-dir> -type f -size +100k -exec du -s -k {} \; | sort -k +2 > /tmp/copy
diff /tmp/orig /tmp/copy

Natuerlich vorher den diff suspenden, damit nicht beide gleichzeitig die platte durchroedeln.

Ja, mit find ist eleganter. Würde allerdings statt -exec du ... einfach -printf '%h/%f\t%s\n' nehmen. Falls es Unterschiede gibt, eignet sich der Output auch, ihn leicht in Tabellenkalkulation zu laden (.tsv Format), da bekommt man leichter Überblick mit Filtern etc... Bei dem sort kenne ich mich nicht so gut aus, da müsste man vielleicht Kommando von te36 modifizieren (und ist vielleicht gar nicht einfach das schön hinzukriegen, wenn es Dateinamen mit Leerzeichen/Tab gibt). -size +100k kann man auch weglassen, wenn es damit keine Unterschiede gibt. So oder so sollte man aber schnell Unterschiede finden (wenn es welche gibt) und dafür tut es auch sort ohne Parameter. Sollte sehr schnell sein (da kein vielfacher Prozessstart). Ob man suspend eines laufenden diff Jobs benötigt? VIelleicht nicht mal.

Selbst habe ich mir für so Zeugs eigenes Tool geschrieben, das .csv ausgeben kann mit all den Eigenschaften pro Datei/Verzeichnis die man sich wünscht (auch subtilere Dinge, wie Datei ist grade in der Cloud und scheint nur hier zu sein, ist sparse/link/rehash point/..., Größe und Größe auf Disk, directory tree Größen), nach Wunsch Checksumme und Lesetiming (daran erkennt man, wenn Platte kaputt geht, wenn z.B. große Datei bei Checksummenberechnung langsam ist). Zuletzt hatte ich aber leider nur die Windows-Version gepflegt (die durchaus auf SMB SHares funktioniert). Ist super schnell im Vergleich zu find oder vielen anderen Tools, leider nicht ganz veröffentlichungs-bereit im Moment. Falls es knifflig wird, kann ich es aber privat weitergeben mit Kommandozeilen-Empfehlung für Problemstellung. Bei zweistelligen Terabyte Backup war mir früher nicht 100% wohl, und habe das immer mit Checksummen verglichen und auch die Vollständigkeit (muss Backup Stückeln auf verschiedene externe Platten - da könnte man schon mal was falsch machen). War aber praktisch immer gut. Bis darauf, dass ich kaputt gehende Platten über Performanz oder Lesefehler früh erkannt habe. Wird dann ganz schnell schlechter.

Huch. Was fuer ein Linux hast Du denn da ?

Bei all meinen Linux varianten zeigt du in der ersten Spalte die Groesse und in der zweiten den Dateinamen. Das sort war mit k +2 daraus ausgelegt, das es nach dateinamen sortiert, dann ist der diff besser vergleichbar. Muss also bei diesem merkwuerdigen du +1 sein. Die idee ist halt im Diff dann dieselben Dateien zu sehen wenn sie unterschiedliche Groessen haben, waehrend das mit der Sortierung jetzt halt die gleichen groessen mit unterschiedlichen dateinamen sind.

Du habe ich empfohlen statt einem printf, weil das halt wirklich die bloecke on disk zaehlt, also sparse files erkennt. Aber der printf output ist wie output von ls also die groesse ohne bedenken von sparse bloecken. Mit sort -n -k +2 ware das printf argument am besten "%s\t%%p" - also groesse, tab, pfadname.

wenn man nur mit den grossen dateien nicht weiterkommt, dann halt das -size weglassen, so das alle dateien ausgelistet werden.

ein anderer kleiner trick ist auch:

awk -e '{ sum += $1 } END { print sum }' < <orig-filename>

das ist wenn in der ersten spalte die groesse steht, ansonsten mit der jetzigen datei ist es $2. Summiert die zahlen einfach auf, so das du da eine idee hast, obs mit der erwarteten gesamtgroesse uebereinstimm. Macht natuerlich nur bei den > 100k files nicht soviel Sinn.Und man sollte halt keine hardlinks haben.

Das mit dem unterschiedlichen Start der Verzeichnisnamen war mein Versehen.

Ich würde den Prozess wiederholen ohne das -size +100k. Es könnte auch noch passieren, wenn beispielsweise dein Copy/Sync leere Verzeichnisse auslässt, das würde man mit dem find so wie im Thread nicht sehen. (Ich habe jetzt nicht die Optionen geprüft, aber es gibt schon bei Copy-Aktionen dieses Phänomen). Aber Terabytes kommen da nicht raus. Die sind ja auch nicht zu erkennen bei du auf oberster Ebene, das sind ja nur kleine Unterschiede. Entscheidend für meine Beurteilung wäre am Ende das Ergebnis des kompletten diff der gesamten Filesysteme. (Auch Kopieren von Links könnte komisch sein - auf den ersten Blick scheint da aber cp -a schon korrekt zu sein.)

Kam da nix raus bei diff der Privat-Verzeichnisse, wo ja du einen Unterschied zeigt. Auch Verzeichnis ISOs hört sich bisschen danach an, als könnte man das recht schnell mit ls -alR in zwei Fenster nebeneinander vergleichen (wenn da wenige große ISOs drin sind).

An dem df würde ich mich nicht so sehr orientieren, sondern an du (wegen schlechter Reproduzierbarkeit der Metadaten, reservierten Blöcke, ...) Aber um das genauer zu verstehen muss man tief abtauchen. Sowas vergisst man, wenn man es nicht braucht. Vielleicht willst du dir auch mal genauer die mergerfs Doku ansehen. Paar Stichworte hatte ich genannt. Unabhängig davon braucht nach meinem Verständnis mergerfs aus 2 FS mehr Platz als der identische Inhalt auf einem FS.

rsync machst du aber hoffentlich nicht parallel zu noch laufenden diffs. Wenn du jetzt weiter aufsynchronisierst, ohne zuvor die Ursache des Unterschieds verstanden zu haben, bleibt es vielleicht für immer ungeklärt. Wenn die Unterschiede dann weg sind, kanns dir vielleicht egal sein.

und wenn man dann am ende glaubt alles ist richtig kopiert weils gleich gross ist, dann nochmal "rsync -c" machen. Dabei wird dann der Inhalt verglichen, also auch von der kopie gelesen.

Rule of thumb: beim kopieren kann man nie auf zuviel nummer sicher gehen.

Da fällt mir noch auf, dass cp [...]/* gefährlich ist und .versteckte_objekte auf oberster Ebene nicht mitnimmt. Das könnte erklären, dass df einen Riesen-Unterschied zeigt, du der Verzeichnisse nur einen minimalen. Kannst das ja schnell prüfen. Meine Erfahrung zeigt halt, dass df schwierig ist zu vergleichen aus verschiedenen Gründen (von denen einige nach deiner Antwort nicht zutreffen, andere vielleicht schon). Soft-Links könnten auch tricky sein.

Ansonsten müsste das Vorgehen mit find schon sehr schnell fehlende Dateien/Verzeichnisse finden oder verschiedene Größe wenn man -size weglässt und evt. sogar -type (von mir direkt jetzt ungetestet, also mit potentieller Fehlermarge)

Wenn du die /tmp/Dateien vom find output gespeichert hast, findest du ja *eine* ts oder mkv die du im rsync siehst sehr schnell um zu erkennen, was an der Methode schief ging.

Dotfiles in Unterverzeichnissen sind ja unkritisch, aber /pfad/zum/mountpoint/.hilfsverzeichnis_vielleicht_von_besonderem_tool_zum_schneiden/datei.ext sind halt beliebte Falle bei cp -r /pfad/zum/mountpoint/* ziel. Glaub dir natürlich schon, dass das bei dir kein Problem ist - Hinweis auch für alle Leser hier, die vielleicht deinen cp Befehl oben sehen. Besser man gewöhnt sich an, eine Ebene höher anzufangen ohne Wildcard (kommt natürlich drauf an, was man will). Grade für Windows/Unix Parallel-Nutzer/Umsteiger kann das ja sehr überraschend sein.

Hatte ich exakt so vermutet. Der Output in deiner #5 zu du -sk hat keine Luft für viele vergessene .mkv oder .ts. Dort sind ja nur kleine Unterschiede zwischen Original und Backup. Wie gesagt, nach meinem Verständnis braucht mergerfs praktisch immer mehr Platz (weil beispielsweise manche Verzeichnis-Einträge jetzt halt in 2 Dateisystemen vorhanden sind). Aber da habe ich keine spezifische Erfahrung und kann das quantitativ nicht abschätzen.