2TB-Datei kopieren

[Sykehouse]

Erstelle einen Torrent und lad ihn dir auf einen (privaten) Tracker, dann ziehst du dir die Daten wieder und speicherst sie dabei auf dem neuen Laufwerk...

 

[puri]

Wenn Du sicher gehen willst nimm "Robocopy", ist bei Windows dabei. "Robo" steht für "Robust". Gibt auch eine GUI dafür.

 

[devVvon]

Ich hab auch schon mein 8TB Nas einfach mit dem Windows Explorer gesichert und danach wieder draufgeschoben, da ich das Volume neu machen musste, das war garkein Problem.

 

[masterw]

Wie kopiere ich das am besten, damit die Datei auch wirklich dem Original entspricht?

Hash der Originaldatei berechnen, nach dem Kopieren den Hash der Kopie checken, wenn identisch: alles OK.
Wird zB bei Linux-ISOs so gemacht. Dauert halt bei 2TB ein bissl. Aber wenn die beiden Dateien den gleichen SHA512-Hash haben, sind sie auch absolut identisch.

https://docs.microsoft.com/en-us/po...hell.utility/get-filehash?view=powershell-7.1

 

[madmax2010]

nimm zum vergleichen ruhig md5. Das geht deutlich flinker als SHA512

Du wirst aber schon merken, ob das Volume noch mountbar ist oder nicht

Mach dir mal nicht zu viele sorgen wegen des Kopierens . 2TB sind heutzutage nicht mehr sonderlich viel. Es gibt leute die beruflich täglich mehr Daten erzeugen & verarbeiten und auch die kochen alle nur mit wasser. Windows kommt mit so großen Dateien seit 20 Jahren klar

 

[Humptidumpti]

Was habt ihr alle mit Hashes. Das ist doch völlig überzogen. Ich habe als ich mein Raid 5 neu aufgebaut habe mein komplettes Backup von über 24TB mit dem Explorer kopiert. Alles OK.

Wenn der Rechner nicht sowieso schon instabil läuft muss man sich bei so popeligen Datenmengen keine erweiterten Gedanken machen.

 

[AGB-Leser]

Prüfsumme erstellen --> kopieren --> Prüfsumme der Kopie erstellen --> Prüfsumme vergleichen

 

[babykanzler]

hi

was ist mit teracopy siehe mal das hier an
teracopy

 

[lordlaschi]

Was habt ihr alle mit Hashes. Das ist doch völlig überzogen. Ich habe als ich mein Raid 5 neu aufgebaut habe mein komplettes Backup von über 24TB mit dem Explorer kopiert. Alles OK.

Wenn du etwas von einer Platte auf eine andere kopierst, durchlaufen die Daten zunächst den RAM. Wenn du keinen ECC RAM mit Fehlerkorrektur hast, dann kommt es immer mal wieder zu geflippten bits. Je länger der Vorgang dauert und je mehr RAM er verwendet, desto höher ist die Wahrscheinlichkeit, dass ein geflipptes bit (falsch) auf die Zielplatte geschrieben wird. Bei Audio oder Videodateien hat dann vielleicht mal ein Pixel irgendwo ne andere Farbe, oder die Datei kann nur bis zu einem bestimmten Punkt geöffnet/dekodiert werden, bei einer komprimierten oder verschlüsselten Datei könnte das aber schlimmere Folgen haben. Macht also schon Sinn bei sehr wichtigen Daten die Prüfsummen zu vergleichen!

 

[PHuV]

Was habt ihr alle mit Hashes. Das ist doch völlig überzogen.

Nope. Nicht ohne Grund findest Du das in vielen Downloadportalen, Linux-Distributionen usw. Prüfsummen hinterlegt. @lordlaschi hats bereits ausführlich erklärt. Und ich hatte das sehr wohl mal schon bei einigen Dateien. Ein Fall war mal, daß eine Installation einer Datei von ca. 9 GB permanent einen Tag lang immer fehlschlug (Kunde hatte Datei dann von mir mit seinen Virenscannern geprüft und dann in seinem Netzwerk kopiert). Ich wußte absolut nicht, was los war, weil ich genau diese Datei schon mehrfach in anderen Projekten verwendete. Tja, genau das ist passiert, Kopierfehler, Prüfsumme mit SHA256 stimmte nicht überein. Datei nochmal kopiert, Prüfsumme war dann korrekt, und schon klappte alles wie gewohnt.

Bei 2TB und verschlüsselt würde ich auf alle Fälle mit Prüfsummen ohne Wenn und Aber arbeiten.

 

[Uridium]

Bei 2TB würde ich aber eher auf encrypted 'Partition' statt 'Datei' gehen. Das könnte man in solch einem Fall nachholen.
Auch würde sich eher ein Kopieren im gemounteten Zustand anbieten, wenn der Inhalt des Containers deutlich unterhalb des Maximums (2TB) liegt, da man ja dann nur die belegten Daten kopieren muss.

 

[Humptidumpti]

@PHuV
Wir reden hier nicht von einem Download sondern von einer Kopie von Lokalem Datenträger auf lokalen Datenträger. Die Chance das dabei was schief geht ist astronomisch gering. Da gewinnt man eher im Lotto.

Zumal ist es eine Kopie. Im Schadensfall wäre das Original sogar noch vorhanden. Ergo völlig wurscht.

@lordlaschi
Das ist mir klar. Dennoch bei einer lokalen Kopie ist die Chance das hier was schief geht so gering dass man sich da keine erweiterten Gedanken machen muss.

 

[PHuV]

@PHuV
Wir reden hier nicht von einem Download sondern von einer Kopie von Lokalem Datenträger auf lokalen Datenträger.

Bei mir war das auch kein Download, sondern einfache Kopie von Stick zur Platte.

Die Chance das dabei was schief geht ist astronomisch gering. Da gewinnt man eher im Lotto.

Dann hätte ich schon ziemlich oft im Lotto gewonnen. 🤗 Mir ist das schon öfters passiert.

Zumal ist es eine Kopie. Im Schadensfall wäre das Original sogar noch vorhanden. Ergo völlig wurscht.

Blöd nur, wenn man das nicht geprüft hat, das Original gelöscht hat, und dann erst den Fehler feststellt. Prüfsumme kostet doch kaum was, und liefert eine gewaltige Sicherheit, ob die Kopie mit dem Original übereinstimmt. Bei einer 2TB Datei würde ich es definitiv machen, da bricht man sich doch keinen ab, oder?
Da das ja nicht dauernd vorkommt, kann man das ruhig mal machen.

 

[M-X]

Warum nicht den Container mounten und die Daten einzeln kopieren wenn du soviele Bedenken hast ? Prüfsummen kann man schon machen wenn man auf Nummer sicher gehen will.

 

[Snowi]

Was habt ihr alle mit Hashes. Das ist doch völlig überzogen. Ich habe als ich mein Raid 5 neu aufgebaut habe mein komplettes Backup von über 24TB mit dem Explorer kopiert. Alles OK.

Hashes halte ich bei großen Datenmengen durchaus für Sinnvoll, aber da tut's auch CRC32 oder sowas, es geht ja nicht um "kritische Daten", sondern nur um's vergleichen auf korrektheit.

Wenn du etwas von einer Platte auf eine andere kopierst, durchlaufen die Daten zunächst den RAM. Wenn du keinen ECC RAM mit Fehlerkorrektur hast, dann kommt es immer mal wieder zu geflippten bits. Je länger der Vorgang dauert und je mehr RAM er verwendet, desto höher ist die Wahrscheinlichkeit, dass ein geflipptes bit (falsch) auf die Zielplatte geschrieben wird.

Prinzipiell hast du recht, und ich halte das prüfen auch für richtig/wichtig, aber: Es ist mit nichten so, dass da "ständig" mal ein Bit flippen würde.
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
Da ist ein Paper zu dem Thema. Das Problem existiert natürlich, aber bei weitem nicht so oft wie es gerne mal propagiert wird. Als "Normaluser" flippt dir vermutlich im Jahr ein einzelnes Bit im RAM, und ein mal 2TB im Jahr kopieren zähle ich durchaus zu Normaluser dazu.
Vergleich dazu: Ich hab hier insgesamt >100TB Storage belegt, wo ich regelmäßig alten Content lösche, neuen hinzufüge, und untereinander synchronisiere (Backups). In den letzten 2 Jahren hatte ich genau 2 Fehler die durch Checksummen aufgefallen sind, bei vermutlich mehreren hundert TB die ich insgesamt hin- und her geschoben habe.


Und zum Thema generell: Einfach mit Windows-Explorer kopieren. Hab auch auch schon mit 16TB Platten so gemacht.

 

[puri]

Gerade bei einer verschlüsselten Datei würde ich mir überhaupt keine Gedanken machen. Wenn sich beim Kopieren auch nur ein Bit dreht, kannst Du das Ding doch gar nicht mehr entschlüsseln, bzw. der Inhalt ist nur Müll.. D.H. ein kurzer Test nach dem Kopieren zeigt das ganz schnell. Und dass sich die Ursprungsplatte beim lesenden Kopiervorgang verabschiedet ist ungefähr genauso wahrscheinlich, wie dass sie sich in der Schublade liegend verabschiedet..Sicherlich kann man als Double Check auch die Prüfsummengeschichte machen, schadet ja nicht..

 

[Purche]

Gerade bei einer verschlüsselten Datei würde ich mir überhaupt keine Gedanken machen. Wenn sich beim Kopieren auch nur ein Bit dreht, kannst Du das Ding doch gar nicht mehr entschlüsseln, bzw. der Inhalt ist nur Müll..

Aber nicht bei verschlüsselten Festplattenimages. Da sind alle Sektoren unabhängig voneinander verschlüsselt. Macht auch anders gar keinen Sinn, sonst würde jeder Zugriff ewig dauern.

Je nach verwendetem AES Betriebsmodus ist eine Fehlerfortpflanzung sogar technologiebedingt auf z.B. ein oder zwei AES Blöcke (je 16 Byte) begrenzt.

Wenn in nem verschlüsselten Image irgendwo ein Bit kippt, dann dürfte maximal ein einzelner Sektor nach dem Entschlüsseln teils Grütze enthalten. Und die Wahrscheinlichkeit ist groß, dass der entweder innerhalb ungenutzter Bereiche oder in großen Dateien (meist Videos etc.) liegt, wo man kaum was davon mitbekommt.
Das Risiko, dass ausgerechnet Verwaltungsstrukturen des Dateisystems kaputt gehen und dadurch viele Dateien auf einmal nicht mehr ohne weiteres sichtbar/nutzbar sind, ist verschwindend gering...

 

[WH95]

Eine Sache ist mir noch eingefallen:

Der Windows-Explorer änder beim Kopieren (mindestens) das angezeigte Datum der Ordner. Ist das bei euch auch so und kann man das ändern?

 

[cartridge_case]

Welche Ordner? Ich denke du kopierst eine einzige Datei?!

 

[Snowi]

Macht aus meiner Sicht keinen Unterschied
Möglicherweise ändert Windows das Datum des Ordners, die Dateien darin sollten aber das alte Datum behalten.
Umgehen lässt sich das glaube ich nicht, sollte aber Programme geben mit denen sich das Datum ändern lässt. Unter Linux wüsste ich wie, unter Windows musst du leider selbst suchen, oder jemand anderes schreibt es evtl.
Gehen tut es aber auf jeden Fall.