Hallo, ich kopiere gerade eine Imagedatei von einer Festplatte auf die andere. Sind so ca. 7,5TB und zusätzlich sind beide Festplatten verschlüsselt. Da die Festplatten nicht die schnellsten sind und der Server auch schon älter ist, dauert das natürlich seine Zeit. Kennt jemand ein Programm, wo man die Datei in Teilen kopieren kann? Das dauert natürlich genau so lange, aber ich kann es auf mehrere Tage verteilen. Natürlich kenne ich 'split', aber man benötigt zusätzlich auf beiden Seiten den doppelten Platz, welchen ich nicht unbedingt habe. Ich möchte gern ohne zusätzlichen Platzbedarf auskommen. Es müßte eigentlich so funktioneren: Ich fange an zu kopieren -> dann breche ich ab. Am nächsten Tag kopiere ich weiter, wobei erkannt wird, was schon kopiert wurde und an der vorherigen Abbruchstelle macht er weiter und hängt den nächsten Teil an, bis ich wieder abbreche und so weiter ... Hat jemand eine Idee? BS:Debian Jogibär
Beitrag #6831152 wurde vom Autor gelöscht.
Was meinst Du mit 'zusaetzlichem Platzbedarf'? Kann mir nicht vorstellen, dass Du darum herum kommst, die Kopie auf der QuellHD zu behalten, waehrend die Zielkopie angelegt wird. Und rsync uebertraegt doch auch an der Stelle weiter, wo ein verheriger Vorgang abgebrochen wurde.
Keine Ahnung, wie Du kopierst (SSH, NFS?), aber Ziel ist es, das in einer Pipe zu erledigen. Beispiel: Jeder Brocken 100GB:
1 | dd if=meine-Datei bs=1G count=100 skip=0 | $up > meine-Datei |
2 | dd if=meine-Datei bs=1G count=100 skip=100 | $up >> meine-Datei |
3 | dd if=meine-Datei bs=1G count=100 skip=200 | $up >> meine-Datei |
4 | ... |
wobei $up Dein Übertragungsprogramm ist. Das ganze kann man als Schleife in einem Shell-Script leicht realisieren.
:
Bearbeitet durch Moderator
Du könntest dd verwenden und mit entsprechenden Längen und Offsets arbeiten. Beispielsweise du kopierst ab Stelle 0 ( Offset 0) 500 bytes. Und beim nächsten mal startest du beim Offset 500 und kopierst die nächsten 500 Bytes
Johannes U. schrieb: > Was meinst Du mit 'zusaetzlichem Platzbedarf'? > > Kann mir nicht vorstellen, dass Du darum herum kommst, die Kopie auf der > QuellHD zu behalten, waehrend die Zielkopie angelegt wird. > > Und rsync uebertraegt doch auch an der Stelle weiter, wo ein verheriger > Vorgang abgebrochen wurde. Hallo, ich meine damit, wenn ich die Datei in Teile aufsplitte habe ich die Datei und die Teile auf der Platte liegen. Das gleiche beim zusammenkopieren mit cat Teil1 Teil2 usw -> Datei. Jogibär
Frank M. schrieb: > Keine Ahnung, wie Du kopierst (SSH, NFS?), aber Ziel ist es, das in > einer Pipe zu erledigen. > > Beispiel: Jeder Brocken 100GB: >
1 | > dd if=meine-Datei bs=1G count=100 skip=0 | $up > meine-Datei |
2 | > dd if=meine-Datei bs=1G count=100 skip=100 | $up >> meine-Datei |
3 | > dd if=meine-Datei bs=1G count=100 skip=200 | $up >> meine-Datei |
4 | > ... |
5 | > |
> wobei $up Dein Übertragungsprogramm ist. > > Das ganze kann man als Schleife in einem Shell-Script leicht > realisieren. Ah, mit skip kann ich den Anfang überspringen. Hatte sowas ähnliches gesucht. Danke für den Tipp. Das könnte funktionieren, werde ich beim nächsten mal testen. Jogibär
Warum ist es nicht möglich die Datei am Stück zu kopieren? Server heißt für mich eigentlich das die Kiste dauerhaft läuft. Wenn es um die Login shell geht die geschlossen wird, wäre tmux zu verwenden.
MeinName schrieb: > Warum ist es nicht möglich die Datei am Stück zu kopieren? Server heißt > für mich eigentlich das die Kiste dauerhaft läuft. > Wenn es um die Login shell geht die geschlossen wird, wäre tmux zu > verwenden. Hallo, weil mein Server normalerweise aus ist, wenn ich nicht zu Hause bin. Ansonsten wäre screen auch eine Möglichkeit. Jogibär
:
Bearbeitet durch User
Michael J. schrieb: > weil mein Server normalerweise aus ist, wenn ich nicht zu Hause bin. Das ist natürlich ein ernsthaftes Hindernis. Da kann man natürlich nichts machen. Oliver
Beitrag #6831202 wurde vom Autor gelöscht.
Oliver S. schrieb: > Michael J. schrieb: >> weil mein Server normalerweise aus ist, wenn ich nicht zu Hause bin. > > Das ist natürlich ein ernsthaftes Hindernis. Da kann man natürlich > nichts machen. > > Oliver Oh je, hätte ich bloß nichts gesagt. Jetzt werde ich auseinandergenommen... 1. er verbraucht unnütz Strom. 2. ab und zu kann so ein Ding durchaus abbrennen 3. ich bekomme nicht mit, das es ein Problem gibt (So wie letztens eine 8TB Platte abgeraucht ist mit ganz schon Krawall, Konnte die Änderungen des letzten Tages noch sichern, so daß ich überhaupt keine Daten verloren habe, ansonsten wären ein paar wenige Daten verloren gewesen, Habe aus diversen Gründen kein RAID) Das ist einfach Geschmackssache. Bevor ich gehe, schaue ich immer nach ob alles zu und aus ist. Ist ne alte Gewohnheit, werde ich nicht los und hat mir schon oft Ärger erspart. Jogibär
Nimm einfach dd_rescue anstatt dem normalen dd. Das erstellt zusätzlich ein Map-File, in dem es sich merkt welche Teilbereiche es schon kopiert hat. Du kannst dann jederzeit auf beliebige Art abbrechen und später mit identischem Befehl weitermachen.
Michael J. schrieb: > Kennt jemand ein Programm, wo man die Datei in Teilen kopieren kann? Ich würde ddrescue zweckentfremden (Vorsicht: nicht mit dd_rescue verwechseln, das ist was anderes!). Primäres Ziel des Tools ist zwar eigentlich ein ganz anderes, aber deinen Anwendungsfall erledigt es ganz elegant mit, ohne jegliche Klimmzüge. Braucht nur drei Parameter Quelle, Ziel und der Name eines Logfiles. Das Logfile ist der eigentliche Trick. Darin merkt sich das Tool nämlich, was es bereits erledigt hat. Und macht beim nächsten Start mit denselben Parametern an exakt der Stelle weiter, wo du den vorigen Lauf abgebrochen hast.
Michael J. schrieb: > weil mein Server normalerweise aus ist, wenn ich nicht zu Hause bin. > Ansonsten wäre screen auch eine Möglichkeit. Also gerade bei so stumpfen Arbeiten wie 7,5TB kopieren will ich doch nciht daneben stehen... Wir starten bei mir auf Arbeit absichtlich bevor wir ins Wochenende gehen die großen Kopier/Image-Jobs und freuen uns dann dass die vor Montag fertig sind und keiner gelangweilt drauf warten musste...
Michael J. schrieb: > weil mein Server normalerweise aus ist, wenn ich nicht zu Hause bin. > Ansonsten wäre screen auch eine Möglichkeit. Gut das kopieren dieser Daten ist ja nicht der Anwendungsfall normalerweise. Dann lass es doch ausnahmsweise durchlaufen und du hast weniger ärger. Aber du entscheidest natürlich selbst was fur dich vertretbar ist. Natürlich wissen wir auch nichts über den Server außer das er langsam und brandgefährdet ist ;-)
MeinName schrieb: > Michael J. schrieb: >Natürlich wissen wir auch nichts über den Server außer > das er langsam und brandgefährdet ist ;-) Schon klar, der Spott läßt nicht lange auf sich warten. Ist halt so. Ich bin halt vorsichtig und habe, jedenfalls bilde ich mir das ein, gute Gründe. Hey, ich bin schon bei 76%, was wollt Ihr noch ;-) Trotzdem, Danke für die Tipps. Eure Vorschläge werde ich testen und ggf. nutzen. Danke nochmals. Jogibär
Michael J. schrieb: > Eure Vorschläge werde ich testen und ggf. nutzen. Wenn Dein System nebenbei noch arbeitet, verändern sich Daten laufend. Zieh ein komplettes Image z.B. mit Clonezilla. Das dauert auch ewige Tage, hätte aber den kleinen Vorteil, dass es schneller ist, als Datei-weise 7,5TB einzeln zu schaufeln. Außerdem werden alle Eigenschaften mit Datum und originaler Uhrzeit im Image gespeichert. Man achte jedoch auf das richtige Dateisystem. Bei verschlüsselten Containern ist natürlich Deine Dateilänge etwas länger? Da finde ich UNterbrechungen risikoreich.
oszi40 schrieb: > Wenn Dein System nebenbei noch arbeitet, verändern sich Daten laufend. > > Zieh ein komplettes Image z.B. mit Clonezilla. Das dauert auch ewige > Tage, hätte aber den kleinen Vorteil, dass es schneller ist, als > Datei-weise 7,5TB einzeln zu schaufeln. Außerdem werden alle > Eigenschaften mit Datum und originaler Uhrzeit im Image gespeichert. Man > achte jedoch auf das richtige Dateisystem. Bei verschlüsselten > Containern ist natürlich Deine Dateilänge etwas länger? Da finde ich > UNterbrechungen risikoreich. Wenn Querdenker über Covid aufklären, fühlt es sich für den studierten Virologen genau SO an.
Jan schrieb: > oszi40 schrieb: >> Wenn Dein System nebenbei noch arbeitet, verändern sich Daten laufend. >> >> Zieh ein komplettes Image z.B. mit Clonezilla. Das dauert auch ewige >> Tage, hätte aber den kleinen Vorteil, dass es schneller ist, als >> Datei-weise 7,5TB einzeln zu schaufeln. Außerdem werden alle >> Eigenschaften mit Datum und originaler Uhrzeit im Image gespeichert. Man >> achte jedoch auf das richtige Dateisystem. Bei verschlüsselten >> Containern ist natürlich Deine Dateilänge etwas länger? Da finde ich >> UNterbrechungen risikoreich. > > Wenn Querdenker über Covid aufklären, fühlt es sich für den studierten > Virologen genau SO an. Klingt so, als wüsstest du, wie man es richtig macht. Kläre doch den Jogibaer und alle anderen unwissenden bitte auf.
Trennen beim Kopieren kann man mit split statt cp, zusammensetzen wieder mit cat. https://man7.org/linux/man-pages/man1/split.1.html Mit dd kann man natürlich auch teilen, aber das ist umständlicher aufzurufen.
:
Bearbeitet durch User
Klaus W. schrieb: > Trennen beim Kopieren kann man mit split statt cp Du hast das Problem nicht verstanden: Der TO wollte split explizit nicht benutzen, weil dadurch Zwischendateien entstehen, für die er keinen Platz hat. Lies nochmal den Ausgangsbeitrag. > Mit dd kann man natürlich auch teilen, aber das ist umständlicher > aufzurufen. Mit dd kann man aber in einer Pipe arbeiten, so dass man die Zwischendateien vermeidet.
Ich glaube du könntest einfach rsync nehmen.
1 | rsync -av --partial --inplace --append --progress file_1 file_2 |
Zum unterbrechen Ctrl+C, zum fortsetzen, einfach das selbe Kommando nochmal ausführen.
Frank M. schrieb: > Klaus W. schrieb: >> Trennen beim Kopieren kann man mit split statt cp > > Du hast das Problem nicht verstanden: > > Der TO wollte split explizit nicht benutzen, weil dadurch > Zwischendateien entstehen, für die er keinen Platz hat. Lies nochmal den > Ausgangsbeitrag. Er will doch von einer Datei auf einer Platte in Teile auf einer anderen kopieren? Zumindest hat er das geschrieben: Michael J. schrieb: > ich kopiere gerade eine Imagedatei von einer Festplatte auf die andere. Und genau das geht mit split. Da kann er von der ersten lesen und in Teilen auf einer anderen Platte ablegen. Wenn er will, kann er auch dabei entschlüsseln: Von der Quelle in einer pipe zum Entschlüsseln, dessen Ausgabe in split pipen und das legt dann die Teile auf der Zielplatte ab. Wo entstehen dabei Zwischendateien (vorausgesetzt er kann in einer Pipe entschlüsseln)?
:
Bearbeitet durch User
Klaus W. schrieb: > und das legt dann die Teile auf der Zielplatte ab. Um diese Teile auf der Zielplatte wieder zusammenzufügen, braucht er denselben Platz nochmal auf der Zielplatte. Den hat er aber nicht. Und nein, auf der Quellplatte hat er den auch nicht ;-)
:
Bearbeitet durch Moderator
Klaus W. schrieb: > Und genau das geht mit split. > Da kann er von der ersten lesen und in Teilen auf einer anderen Platte > ablegen. Was ist der Vorteil gegenüber dem Einzeiler von Daniel A.? Der kann jederzeit abgebrochen und wieder aufgenommen werden. Also das, was der TO (jogibaer) möchte.
Wollt Ihr Räder an einem fahrenden Zug wechseln? Wenn er jeden Tag nur ein Stück eines lebenden Systems kopiert ist die Hälfte schon wieder geändert.
oszi40 schrieb: > Wenn Dein System nebenbei noch arbeitet, verändern sich Daten laufend. oszi40 schrieb: > Wollt Ihr Räder an einem fahrenden Zug wechseln? Wenn er jeden Tag > nur > ein Stück eines lebenden Systems kopiert ist die Hälfte schon wieder > geändert. Du hast den Eingangspost gelesen? Michael J. schrieb: > ich kopiere gerade eine Imagedatei...
:
Bearbeitet durch User
nachdenker schrieb: > Also gerade bei so stumpfen Arbeiten wie 7,5TB kopieren will ich doch > nciht daneben stehen... Hast Du einen Schrödinger-Quanten-Computer? Normale Computer machen das nämlich auch, wenn Du nicht daneben stehenbleibst und zuguckst.
Le X. schrieb: > Du hast den Eingangspost gelesen? > Michael J. schrieb: >> ich kopiere gerade eine Imagedatei... Sorry, dass TO Jogibär eine fertige 7,5TBImagedatei stückweise ohne split kopieren möchte, habe ich überlesen. Es ist nicht verboten, die Platten in einem schnelleren Rechner zu spiegeln. Frage ist immer, ob die riesige, halb fertige Terra-Datei nach Abbruch nochmals neu geschrieben wird? Auf jeden Fall würde ich hinterher mal mit MD5 prüfen, ob 7,5TB-Kopie gesund ist. Das dauert auch. Mit zu langen Dateien hatte ich schon mehrfach Ärger. Bei wenig RAM wird das System ausgebremst. Grundübel ist, dass Jogi seine Platten bis zum Rand vollschreibt und dann keinen Platz für Split-Manöver hat.
oszi40 schrieb: > Grundübel ist, dass Jogi seine Platten bis zum Rand vollschreibt und > dann keinen Platz für Split-Manöver hat. Sehe ich nicht so. Zum Vollschreiben sind Platten ja da. Oder nutzt du die Platten immer nur maximal zur Hälfte, um immer gewappnet zu sein falls der Fall eintritt die größte Datei doppelt vorhalten zu müssen? Aber mittlerweile gibt es ja genug (gute) Antworten wie man Dateien häppchenweise überträgt ohne die Häppchen extra vorhalten zu müssen. Der Punkt mit der MD5-Summe ist aber gut, würde ich definitiv auch empfehlen.
Le X. schrieb: > Sehe ich nicht so. Zum Vollschreiben sind Platten ja da. Als Admin sollte man bei 2/3 Füllstand fleißig werden. 1.Oft werden volle Platten langsamer. 2.Ein System sollte nie durch Platzmangel ersticken.
oszi40 schrieb: > Als Admin sollte man bei 2/3 Füllstand fleißig werden. Wenn ich eine Platte von 2TB habe, wöchentlich etwa 1GB dazukommt, dann muss ich mich bei welchem Füllstand ernsthaft um was größeres kümmern, wenn die Summe aus Beschaffungszeit und Zeit zum Clonen eine Woche ist und ich einen möglichen Admin-Urlaub von maximal drei Wochen ausgerechnet zum kritischen Zeitpunkt einkalkuliere? Simple Rechenaufgabe für Unter-Hilfs-Realschüler, deren Lösung aber den grenzenlosen Schwachsinn deiner pauschalisierten Aussage überaus drastisch aufzeigt. > 1.Oft werden volle Platten langsamer. Quatsch. Welcher physikalische Effekt sollte dafür deiner Meinung nach verantwortlich sein. Bits wiegen nix. Und selbst wenn sie es täten, könnte die Physik nicht unterscheiden, ob das Bit benutzt ist oder nicht. Vorhanden ist es nämlich immer... > 2.Ein System sollte nie durch Platzmangel ersticken. Das ist richtig. Und deshalb sollte man rechtzeitig für genug Platz sorgen. Das ist so klar wie nur irgendwas, darüber braucht man nicht zu diskutieren. Die Frage ist nur, wie sich daraus mathematisch die von dir postulierte allgemeingültige 2/3-Regel ableiten lassen sollte...
c-hater schrieb: > grenzenlosen Schwachsinn deiner pauschalisierten Aussage Hilfsschul-Berechnung setzt voraus, dass ALLES so bleibt, wie es immer läuft. Leider hatte manches Logfile plötzlich eine andere Meinung als Du. c-hater schrieb: > Bits wiegen nix. Das Wort Fragmentierung und der Aufbau einer Platte sind bekannt? Teste selbst mit hd2testw volle und leere Platte. https://www.heise.de/download/product/h2testw-50539
oszi40 schrieb: > Das Wort Fragmentierung und der Aufbau einer Platte sind bekannt? Ja, vor allem der von SSDs...
Beitrag #6834508 wurde von einem Moderator gelöscht.
c-hater schrieb: > oszi40 schrieb: > >> Das Wort Fragmentierung und der Aufbau einer Platte sind bekannt? > > Ja, vor allem der von SSDs... Erstens fragmentieren auch SSDs, was zwar keine zusätzliche mechanische Zugriffszeit bedeutet, wohl aber Performanceeinbußen durch höheren Filesystem-Overhead. Zweitens verhindert z.B. ext4 die Fragmentierung automatisch, aber nur, wenn die SSD nicht zu mehr als etwa 80% gefüllt ist. Drittens geht bei einer SSD ein dauerhaft sehr hoher Füllstand auf Kosten der Lebensdauer, weil nicht genug freie Blöcke mehr fürs wear levelling übrig sind. Die angegebene Lebensdauer in TBW bezieht sich schließlich auf full disk writes. Viertens war im OP die Rede von "Festplatten", nicht von SSDs.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.