Datenplatte spiegeln - "dd" oder "cp" Kopie?

[theSplit]

Jetzt mal ein "Fun" Fact, man sollte sich bei "dd" auch sicher sein, das die Festplatten gleiche Kapazitäten besitzen...

Mit "cp" oder "rsync" wäre mir spätestens dann, mit großes Sicherheit, aufgefallen, das ich ein 1,5 TB Medium auf ein 1 TB Medium spiegele... hab mich nur beim prüfen der Daten eben gewundert warum ich überhaupt keine Daten sehe... gab wohl einen Fehler dadurch, aber "dd" hat munter die Platte befüllt, jedenfalls das was ging. Ärgerlich.

Ich kopiere jetzt wahlweise mal die Daten mit "rsync" - werde dann auch mal sehen ob und was für eine Fehlermeldung kommt, wenn kein Platz mehr ist. Hätte ich mir bei "dd" in dem Fall aber auch gewünscht. Aber gut, muss man wohl vorher prüfen...
Allerdings ist das auch ziemlich doof, wenn man zum Beispiel bei "in der Theorie" baugleiche USB-Stick Abbilder macht, und diese auf andere Sticks ziehen will, die aber, aus was für Gründen auch immer, eine etwas geringere Kapazität besitzen.

Aber war wohl Lehrgeld, die Erfahrung zu machen....

--- [2017-07-23 17:10 CEST] Automatisch zusammengeführter Beitrag ---

You do not have permission to view link please Anmelden or Registrieren

Nur noch kurz, das stimmt wohl, ich hab das mit der Bulksize aber noch nicht 100% raus, kommt so wie es verstehe wohl aber darauf an wie viel "Puffer" / Cache die Datenträger haben und wie die Lese/Schreibgeschwindigkeiten sind. Utopisch hohe Werte würden die Datenübertragung ja meist dann auch nicht direkt verbessern, wenn das Schreiben das Bottleneck wäre. Oder?

 

[nik]

You do not have permission to view link please Anmelden or Registrieren

Richtig, da die Standard aber gerade mal 512b entspricht, ist es in jedem Fall besser, wenn du da einfach die Blockgröße des Datenträger nimmst.

 

[theSplit]

Rsync hat ein etwas komisches Verhalten beim kopieren, es könnte auch an den Festplatten liegen.
Aber der Kopiervorgang "pausiert" regelmäßig nach ein paar Kopiervorgängen für 15-20 Sekunden und geht dann normal weiter.

Kann man das irgendwie verhindern? Warum "blockt" da etwas? Ist rsync "zu schnell" für die Hardware?

Edit: Mit "cp" gab es auch diese periodischen Pausen, von daher hab ich es gar nicht weiter damit versucht gehabt.

 

[drfuture]

Versuch mal eine Platte hinten und eine vorne anzuschließen

 

[musv]

Ich möchte eine Festplatte, 1 TB, auf eine andere spiegeln … Es handelt sich allerdings um eine reine Datenplatte die nur eine Partition mit FAT32 bzw. NTFS … beinhaltet,

Nein, du möchtest die Platte nicht spiegeln, sondern den Inhalt der einen auf die andere kopieren.

Allerdings würde ich bei großen Datenplatten ein vernünftiges Dateisystem verwenden. Präferenz wäre xfs, danach käme ext4. Oder musst du an die Daten zwingend mit Randgruppenbetriebssystemen rankommen?

Was wäre der schlaueste Weg in diesem Fall?

rsync

cp hat halt den Nachteil, dass es im Abbruchsfall das Kopieren nicht an derselben Stelle wieder aufnehmen kann. Früher hat man noch cpio --passthrough verwendet. Aber das fand ich schon immer zu umständlich.

dd willst du dafür nicht nehmen, da du mehrere Unsicherheitsfaktoren hast. Fehler an den Quelldateien bekommst du gar nicht mit. Und wenn die Zielplatte auch nur etwas kleiner als die Quellplatte ist, dann hast du ein Problem, was du aber erst am Ende des Kopiervorganges präsentiert bekommst. dd nimmt man, wenn die Übernahme der Partitionierung im Vordergrund steht.

Kann man das irgendwie verhindern? Warum "blockt" da etwas? Ist rsync "zu schnell" für die Hardware?

Kann mehrere Faktoren haben. Zum einen ist sicherlich NTFS ein Problemfall, da die ntfs3g-Treiber über fuse arbeiten. Damit ist ntfs3g halt kein Kerneltreiber und entsprechend langsamer.

Überwachen kannst du das Ganze mit iotop.

 

[theSplit]

You do not have permission to view link please Anmelden or Registrieren

Ja, die Platten müssen überall laufen, auch unter Windows oder mal nen MediaPlayer der nur FAT32 unterstützt.

Das mit dem Spiegeln habe und das einfach abgebrochen wird, wenn das Zielmedium keinen Platz mehr hat, habe ich schon bei dd festgestellt.

Habe wie gesagt nun auch rsync genommen, ich habe lediglich noch nicht ganz raus, wie ich damit einen mit "Strg + C" abgebrochenen Kopiervorgang wieder aufnehmen kann. Habe zwar gesehen es gibt eine "Append" Funktion, aber die wird vermutlich die Daten nur "anhängen" an bereits existierende Dateien?
Also wie das mit dem "Resume" funktioniert, wäre nett wenn du das kurz anreißen könntest welchen Befehl man dafür verwendet.

Das NTFS geringfügig bzw. entsprechend langsamer ist, ist mir auch schon aufgefallen, jetzt kenne ich mal einen Grund

iotop muß ich mal testen.

You do not have permission to view link please Anmelden or Registrieren

Du meinst sicherlich weil es über den gleichen IO Controller geht? Deßhalb mal hinten und "vorne" testen?
Ich bin noch nicht dazu gekommen, da ich schon einiges kopiert hatte, aber das sollte ja relativ leicht machbar sein das mal auszuprobieren.

 

[Metal_Warrior]

@theSplit: rsync synchronisiert. Daher der Name. Es checkt am Anfang die Unterschiede und gleicht an. Daher gibt es auch sowas wie eine "setze abgebrochenen Kopiervorgang fort"-Funktion nicht wirklich, weil er quasi ständig damit rechnet, dass auf dem Ziel identische Dateien sind.

Beliebte Optionen sind -au (alle Rechte etc. beibehalten und update, d. h. überschreibe am Ziel nur, was auch älter als die Quelle ist).

 

[musv]

Habe wie gesagt nun auch rsync genommen, ich habe lediglich noch nicht ganz raus, wie ich damit einen mit "Strg + C" abgebrochenen Kopiervorgang wieder aufnehmen kann.

Wie Metal Warrior schon gesagt hat, es setzt das Kopieren einer abgebrochenen Datei nicht fort, sondern kopiert diese neu. rsync erkennt aber, welche Dateien schon korrekt kopiert wurden und kopiert dann nur noch den Rest. Auch die Option -u (skip files that are newer on the receiver) ist halt sinnvoll.

Das NTFS geringfügig bzw. entsprechend langsamer ist, ist mir auch schon aufgefallen, jetzt kenne ich mal einen Grund

Um mal in der Geschichte etwas weiter auszuholen:

Wie wir alle ja wissen, ist M$ böse. Also haben sie die Specs von NTFS nie rausgegeben. Bis 2005 gab's nur einen Unstable-Treiber, der auch noch im Linux-Kernel enthalten ist. Lesen war damit sicher. Beim Schreiben konnte man sich durchaus das Dateisystem zerschießen. Im Jahre 2005 setzte sich dann ein netter Tscheche hin und bastelte einen Wrapper, mit dem man den Windows-Treiber nutzen konnte. Das Ganze nannte sich

You do not have permission to view link please Anmelden or Registrieren

und funktionierte eigentlich ziemlich gut. Auch hier kam

You do not have permission to view link please Anmelden or Registrieren

zum Einsatz.

Ein paar Jahre später etablierte sich dann

You do not have permission to view link please Anmelden or Registrieren

, was auch heute noch (und auch bei Dir) zum Einsatz kommt. NTFS-3G wurde anfangs in extrem mühevoller Reverse-Engineering-Arbeiit entwickelt. Erst Jahre später gab sich M$ geschlagen und kooperierte.

You do not have permission to view link please Anmelden or Registrieren

ist ein Kerneltreiber, der eine Schnittstelle zum Userspace und die entsprechenden Libs zur Verfügung stellt, um beliebige Dateisystemtreiber zu implementieren. Bekanntestes Beispiel neben ntfs3g ist die Webdav-Geschichte.

iotop muß ich mal testen.

Es gibt noch mehr Monitoring-Tools, um die Gründe für das Stocken herauszufinden. Bei top gibt's z.B. den wa-Wert (oben techts). Ein hoher Wert lässt darauf schließen, dass die CPU auf die Festplatte warten musst. Das tritt u.a. auch auf, wenn der RAM ziemlich ausgelastet ist und das System anfängt zu swappen (

You do not have permission to view link please Anmelden or Registrieren

).

You do not have permission to view link please Anmelden or Registrieren

gibt Dir ebenfalls hübsche Informationen.

Aber wie gesagt, bei Dateisystemtreibern, die auf fuse basieren, kannst du keine Performance erwarten, die du bei nativen Kerneltreibern (xfs, ext, btrfs) erhältst.

 

[theSplit]

Vielen Dank für die Infos und auch fürs "Historische", klingt spannend

Jetzt hätte ich allerdings noch eine Frage, Metal_Warrior schlägt "-au" als Switches vor. Das macht soweit auch Sinn, wobei ich so kopiert hatte, das Timestamps beibehalten werden, mit folgendem:
[src]rsync -r -X --noatime --progress QUELLE ZIELPLATTE[/src]

wenn ich das mit dem Überspringen von neueren Dateien dazunehme und auch das beibehalten von Rechten (was bei FAT32 oder NTFS ja nicht angewendet wird):
[srch]rsync -r -a -u -X --noatime --progress QUELLE ZIELPLATTE[/src]

Ich hatte beim kopieren dann noch "--preallocate" verwendet. (Kurze Zwischenfrage, würde das generell existierende Dateien überschreiben?)

Das Preallocate hatte ich genommen, weil ich vermutet habe das dies das "blocking" umschifft, tats aber nicht.
Komischerweise, wenn man mit "dd" "spiegelt" und eine anständige Bulksize hat, kommt dieser Schluckauf nicht.

Am RAM sollte es dann eigentlich aber nicht liegen, ich habe 16 GB verbaut.

Für 800 GB habe ich fast 10+ Stunden gebraucht mit rsnyc, mit dd für 1 TB knappe ~7-8 Stunden mit angezeigten, durchgängigen, 42,9 MB die Sekunde.
Also eigentlich besser, aber ich geb zu, das ist natürlich nicht direkt ideal gewesen damit zu kopieren, aber es wäre theoretisch um einiges schneller gegangen.


Ich vermute mal, das dies wirklich mit der Bulksize zu tun hat, Festplatten haben ja einen Cache, der voll läuft und dann irgendwann "geflushed" wird, also das die Daten die im Zwischenspeicher liegen, auch wirklich geschrieben werden.
Und wie es schien wartetet rsync (cp aber auch) auf die Quellfestplatte, nicht aber auf die Zielfestplatte, diese hat keine Aktivität angezeigt, nur das Quellmedium hat munter aufgeleuchtet, obwohl die beiden Festplatten sich bis auf die Kapazität nicht viel nehmen,

----

Zu guter Letzt noch einmal eine andere Frage zu rsync - woran erkennt rsync das die Datei, die sich auf dem Zielmedium befindet, bereits existiert und auch die Gleiche Größe besitzt bzw. korrekt kopiert wurde?

An der Dateigröße + Änderungszeit und einer internen Prüfsumme bei gleichem Dateinamen?


Update: @drfuture: Habe mal wie du vorgeschlagen hast, jetzt beim kopieren von Daten die Quellplatte "hinten" am Rechner angeschlossen, die andere klemmt "vorne". Und siehe da, der Kopiervorgang blockt wirklich nicht mehr!

 

[Metal_Warrior]

@theSplit: Es hätte -auX gereicht - a steht für archive (impliziert damit -rlptgoD). Und nein, das preallocate überschreibt nix, das reserviert nur schonmal Speicherplatz. Braucht man nie. (Nachtrag: Warum ich -au vorgeschlagen habe: Braucht man oft, daher verwende ich gern "meine' Standardparameter, auch wenn ich sie grad nicht brauche, so wie das u in deinem Fall, weil Kopie nach leerer Platte. BTW: Ich hoffe, du hast die Platte vorher partitioniert und formatiert, nach deiner Aktion mit dd, sonst hast du nämlich bald die nächsten Probleme.)

Zeit ist völlig irrelevant - du willst was kopieren, das länger dauert. Warte 3 Minuten, schau nach, wie viel er schon kopiert hat (df -h hilft), rechne die Durchschnittsgeschwindigkeit aus, die daraus resultierende Dauer und schlag 10% für etwaige Schwankungen drauf. Dann geh ins Bett, wenns länger als 2 Stunden dauert.

Edit: Erkennen gleicher Dateien - erstmal gleicher Pfad und Dateiname (ist ja klar), dann müsste Änderungsdatum, Dateigröße und zu guter Letzt Gesamthash der Datei geprüft werden. Jedenfalls wird zu Beginn nicht sehr viel Information ausgetauscht, um die Dateiliste zu erstellen.

 

[theSplit]

You do not have permission to view link please Anmelden or Registrieren

Also wegen Repartionierung der Festplatte, habe ich gemacht, vor allem weil ich, nach fehlgeschlagenem dd, nicht mehr darauf als Dateisystem zugreifen konnte. Hab daher mit gparted komplett neu partitioniert und formatiert.