Hallo liebe LUG,
Ich war bisher eher nur Leser aber nun hab ich doch mal einen Frage. Da eine meiner Festplatten immer wieder aussteigt und die Backupplatte vor 4 Tagen auch das zeitliche gesegnet hat benötige ich dringend Hilfe. Die defekte Platte beherbergt alle Fotos die ich habe. Solang ich jedes Foto einzeln über die Konsole auf eine andere Platte kopiere funktioniert es auch aber sobald sie viele Lesezugriffe nacheinander abarbeiten muss steigt sie aus (z.B. wenn ich einen ganzen Ordner kopieren will).
Da ich mich mit dem Programmieren von Scripten nicht auskenne hier meine Frage:
Wäre jemand so nett mir ein Script zu schreiben das folgendes macht:
- es soll die Bilder alle einzeln kopieren - jedes mal wenn ein Bild kopiert wurde soll eine Pause von 10 Sekunden erfolgen bis das nächste Bild kopiert wird
Wenn mir jemand so ein Script schreiben könnte wäre ich ihm unendlich dankbar. Denn ich habe keine Ahnung wie lang die Platte noch mit macht und bei 30 GB Fotos würde es Tage dauern wenn ich alles händisch machen müsste.
Ich danke schon mal allen freundlichen Helfern im voraus!
Empfehlung: Mit dd_rescue eine vollständige Kopie der defekten Platte, soweit noch möglich, machen. Dann die Fotos aus diesem image heraus sichern. Das Kopieren von Ordnern (in denen auch einige unvollständige Dateien zu erwarten sind!), sollte dann kein Problem mehr darstellen.
Uwe
Am 13.02.2011 um 13:55 schrieb Lunix: [...]
Da eine meiner Festplatten immer wieder aussteigt und die Backupplatte vor 4 Tagen auch das zeitliche gesegnet hat benötige ich dringend Hilfe. Die defekte Platte beherbergt alle Fotos die ich habe. Solang ich jedes Foto einzeln über die Konsole auf eine andere Platte kopiere funktioniert es auch aber sobald sie viele Lesezugriffe nacheinander abarbeiten muss steigt sie aus (z.B. wenn ich einen ganzen Ordner kopieren will).
[...]
Eine vollständige Kopie der Platte ist aber leider nicht möglich da sie bei zu vielen Lesezugriffen sofort aussteigt. Ich komme also nicht umher jede Datei einzeln zu sichern.
Empfehlung: Mit dd_rescue eine vollständige Kopie der defekten Platte, soweit noch möglich, machen. Dann die Fotos aus diesem image heraus sichern. Das Kopieren von Ordnern (in denen auch einige unvollständige Dateien zu erwarten sind!), sollte dann kein Problem mehr darstellen
Siehe man dd_rescue. Wenn das nicht mehr funktioniert dann wird auch die Einzelkopie, wie auch immer durchgeführt, zum Problem. Außerdem: 30GB Fotos ergeben n Dateien. n*10s + n*Kopierzeit = Erforderliche Zeit für Backup. Diesen tagelangen Streß wird wohl die defekte Platte endgültig übel nehmen und vollständig abrauchen.
Am 13.02.2011 um 14:16 schrieb Lunix:
Eine vollständige Kopie der Platte ist aber leider nicht möglich da sie bei zu vielen Lesezugriffen sofort aussteigt. Ich komme also nicht umher jede Datei einzeln zu sichern.
Empfehlung: Mit dd_rescue eine vollständige Kopie der defekten Platte, soweit noch möglich, machen. Dann die Fotos aus diesem image heraus sichern. Das Kopieren von Ordnern (in denen auch einige unvollständige Dateien zu erwarten sind!), sollte dann kein Problem mehr darstellen
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Uwe Beger uwe.beger@unixprojekt.de (Sun Feb 13 14:24:12 2011):
Siehe man dd_rescue. Wenn das nicht mehr funktioniert dann wird auch die Einzelkopie ..
Ah, ok. Danke. Wieder was gelernt.
Heiko Schlittermann hs@schlittermann.de (Sun Feb 13 14:35:31 2011):
Uwe Beger uwe.beger@unixprojekt.de (Sun Feb 13 14:24:12 2011):
Siehe man dd_rescue. Wenn das nicht mehr funktioniert dann wird auch die Einzelkopie ..
Ah, ok. Danke. Wieder was gelernt.
Wobei in der Manpage nichts relevantes steht, jedenfalls nicht in meiner. Man wird also eine aktuelle Version benötigen, dort steht dann zumindest auf der Webseite, daß die Datenrate verringert wird, wenn Lesefehler auftreten.
Am Sonntag, 13. Februar 2011 schrieb Heiko Schlittermann:
Wobei in der Manpage nichts relevantes steht, jedenfalls nicht in meiner.
Da ich das Programm nicht installiert habe, habe ich nach der Manpage gegooglet und einige Varianten gefunden, aber keine enthielt irgendwelche in diese Richtung relevanten Informationen.
Man wird also eine aktuelle Version benötigen, dort steht dann zumindest auf der Webseite, daß die Datenrate verringert wird, wenn Lesefehler auftreten.
Welche Webseite? Hier http://www.garloff.de/kurt/linux/ddrescue/ finde ich nur die Information, dass die Blockgröße im Fehlerfall reduziert wird -- nix von Wartezeit oder Reduktion der Übertragungsrate (die folgt natürlich aus der kleineren Blockgröße, bewirkt aber keine geringere Belastung der Platte.
Uwe
Uwe Koloska ml@koloro.de (Sun Feb 13 18:07:13 2011):
Am Sonntag, 13. Februar 2011 schrieb Heiko Schlittermann:
Wobei in der Manpage nichts relevantes steht, jedenfalls nicht in meiner.
Da ich das Programm nicht installiert habe, habe ich nach der Manpage gegooglet und einige Varianten gefunden, aber keine enthielt irgendwelche in diese Richtung relevanten Informationen.
Man wird also eine aktuelle Version benötigen, dort steht dann zumindest auf der Webseite, daß die Datenrate verringert wird, wenn Lesefehler auftreten.
Welche Webseite? Hier http://www.garloff.de/kurt/linux/ddrescue/
Hm, ich bin mir ziemlich sicher, etwas von Fehlern und slow down gelesen zu haben. Hier steht das, aber die Seite, an die ich mich erinnere, sah anders aus.
http://paulski.com/zpages.php?id=1913 http://ubuntu-rescue-remix.org/node/51
Ok, sieht so aus, als hast Du Recht. Der Quelltext von dd_rescue ist relativ übersichtlich, da sieht auch nichts aus wie sleep oder select (oder was könnte man sonst noch zum Warten verwenden?).
Dann kommt dieses "langsamer" vielleicht einfach daher, daß beim Lesen von kleineren Blöcken es halt langsamer ist.
Uwe Beger uwe.beger@unixprojekt.de (Sun Feb 13 14:09:22 2011):
Empfehlung: Mit dd_rescue eine vollständige Kopie der defekten Platte, soweit noch möglich, machen. Dann die Fotos aus diesem image heraus sichern. Das Kopieren von Ordnern (in denen auch einige unvollständige Dateien zu erwarten sind!), sollte dann kein Problem mehr darstellen.
dd_rescue wird vielleicht auch zu viele Lesezugriffe erzeugen.
Lunix Lunix@gmx.net (Sun Feb 13 13:55:30 2011):
Hallo liebe LUG,
Ich war bisher eher nur Leser aber nun hab ich doch mal einen Frage. Da eine meiner Festplatten immer wieder aussteigt und die Backupplatte vor 4 Tagen auch das zeitliche gesegnet hat benötige ich dringend Hilfe. Die defekte Platte beherbergt alle Fotos die ich habe. Solang ich jedes Foto einzeln über die Konsole auf eine andere Platte kopiere funktioniert es auch aber sobald sie viele Lesezugriffe nacheinander abarbeiten muss steigt sie aus (z.B. wenn ich einen ganzen Ordner kopieren will).
Da ich mich mit dem Programmieren von Scripten nicht auskenne hier meine Frage:
Wäre jemand so nett mir ein Script zu schreiben das folgendes macht:
- es soll die Bilder alle einzeln kopieren
- jedes mal wenn ein Bild kopiert wurde soll eine Pause von 10
Sekunden erfolgen bis das nächste Bild kopiert wird
Wenn mir jemand so ein Script schreiben könnte wäre ich ihm unendlich dankbar. Denn ich habe keine Ahnung wie lang die Platte noch mit macht und bei 30 GB Fotos würde es Tage dauern wenn ich alles händisch machen müsste.
Mit je 10s Pause kann es auch für die Platte eher Ende sein als für die Kopieraktion.
Ohne Script könntest Du versuchen, rsync zu nutzen und mit der --bwlimit Option was anstellen. Ich *glaube*, die gilt auch für lokale Aktionen, zumindest lt. Manpage ist die Rede von I/O rate, nicht von Network.
Alternativ sowas wie (in der Bash, bei anderen Shells ist vielleicht anderes Quoting notwendig):
find /my/fotos/ -type f \ ( -exec cp --parents --verbose {} /mnt/new/ ; -o -exec true ; ) \ -exec sleep 10 ;
Ist ja noch kein Script, sollte es aber tun. (Sieht etwas umständlich aus, aber ich wollte die Pause immer haben, auch wenn cp schief geht, und ich wollte keine Shell benutzen, da das zu Problemen bei wirren Dateinamen führen könnte, deshalb 3x -exec.)
Erstmal danke für die vielen Hilfestellungen.
Also rsync erzeugt eindeutig zu viele Lesezugriffe in kurzer Zeit. dd_rescue hab ich mir noch nicht angeschaut, wird aber wohl zum gleichen Ergebnis führen.
Am 13.02.2011 14:22, schrieb Heiko Schlittermann:
Alternativ sowas wie (in der Bash, bei anderen Shells ist vielleicht anderes Quoting notwendig):
find /my/fotos/ -type f \ \( -exec cp --parents --verbose {} /mnt/new/ \; -o -exec true \; \) \ -exec sleep 10 \;
Die Zeilen erzeugen folgenden Feher: find: Der Pfad muß vor dem Suchkriterium stehen: Aufruf: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [Pfad...] [Suchkriterium] ./copy: line 3: (: command not found ./copy: line 4: -exec: command not found
Leider kann ich jetzt auch nicht so viel damit anfangen da ich nun nicht der größte Linuxspezialist bin.
Am 13.02.2011 14:47, schrieb Ronny Seffner:
Und ohne Erklärung kann ich dir noch folgende Erfahrung für sterbende Platten mitgeben: ab in eine Verschließbare Tüte, dann ins Eisfach und nach einer Stunde so schnell und viel davon lesen wie irgend geht. Der Raum sollte normale/wenig Luftfeuchte haben, weil die an der kalten Platte kondensiert. Das hat unseren Kunden schon oft geholfen.
Also das mit dem einfrieren klingt doch sehr abstrakt und gewagt. Denn wenn das nicht geht dann ist die Platte endgültig hin. Ich finde auch keinen plausiblen Grund warum die Platte wenn sie "gefroren" ist besser funktionieren soll.
Vielleicht hat ja noch jemand eine Lösung? Freu mich über jede Hilfe. Ach so das System ist übrigens ein Ubuntu 9.04
Lunix Lunix@gmx.net (Sun Feb 13 21:54:25 2011):
Erstmal danke für die vielen Hilfestellungen.
Also rsync erzeugt eindeutig zu viele Lesezugriffe in kurzer Zeit. dd_rescue hab ich mir noch nicht angeschaut, wird aber wohl zum gleichen Ergebnis führen.
Am 13.02.2011 14:22, schrieb Heiko Schlittermann:
Alternativ sowas wie (in der Bash, bei anderen Shells ist vielleicht anderes Quoting notwendig):
find /my/fotos/ -type f \ \( -exec cp --parents --verbose {} /mnt/new/ \; -o -exec true \; \) \ -exec sleep 10 \;Die Zeilen erzeugen folgenden Feher: find: Der Pfad muß vor dem Suchkriterium stehen: Aufruf: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [Pfad...] [Suchkriterium] ./copy: line 3: (: command not found ./copy: line 4: -exec: command not found
Du hast sicher Cut and Paste verwendet. Das geht je nach Mailprogramm nicht gut. Nach dem \ am Zeilende darf *kein* weiteres Zeichen, außer dem Zeilenumbruch kommen, nicht mal Leerstellen sind erlaubt.
Du mußt das am besten so abschreiben, wie es da steht, nur /my/fotos durch das Quellverzeichnis ersetzen und /mnt/new durch das, wo Deine neue Platte dran ist.
Die Backslashes am Zeilenende kannst Du weglassen, wenn Du alles auf eine ganz lange Zeile schreibst. Alle anderen Backslashes müssen da so hin.
Hallo,
On Sun, Feb 13, 2011 at 14:22:34 +0100, Heiko Schlittermann wrote:
Alternativ sowas wie (in der Bash, bei anderen Shells ist vielleicht anderes Quoting notwendig):
find /my/fotos/ -type f \ ( -exec cp --parents --verbose {} /mnt/new/ ; -o -exec true ; ) \ -exec sleep 10 ;
Auch in einem Shellskript sind Dateinamen mit Leerzeichen und aehnlichem Quatsch kein Problem, wenn man sie mit while read ... von stdin liest:
#!/bin/bash find /my/fotos/ -type f | while read p do cp --parents --verbose "$p" /mnt/new/ sleep 1 done
Gruss, Chris
Christian Perle chris@linuxinfotag.de (Mon Feb 14 15:27:15 2011):
Hallo,
On Sun, Feb 13, 2011 at 14:22:34 +0100, Heiko Schlittermann wrote:
Alternativ sowas wie (in der Bash, bei anderen Shells ist vielleicht anderes Quoting notwendig):
find /my/fotos/ -type f \ ( -exec cp --parents --verbose {} /mnt/new/ ; -o -exec true ; ) \ -exec sleep 10 ;
Auch in einem Shellskript sind Dateinamen mit Leerzeichen und aehnlichem Quatsch kein Problem, wenn man sie mit while read ... von stdin liest:
#!/bin/bash find /my/fotos/ -type f | while read p do cp --parents --verbose "$p" /mnt/new/ sleep 1 done
Hehe, nicht so einfach…
$ mkdir test && cd test $ touch ' a' 'b ' 'c d' $ find . -type f | while read p; do echo "<$p>"; done $ find . -type f | while read; do echo "<$REPLY>"; done $ find . -type f -print0 | while read -d $'\x00'; do echo "<$REPLY>"; done
Hallo Heiko,
On Mon, Feb 14, 2011 at 16:01:19 +0100, Heiko Schlittermann wrote:
Hehe, nicht so einfach???
$ mkdir test && cd test $ touch ' a' 'b ' 'c d' $ find . -type f | while read p; do echo "<$p>"; done $ find . -type f | while read; do echo "<$REPLY>"; done $ find . -type f -print0 | while read -d $'\x00'; do echo "<$REPLY>"; done
In der Tat, mein Skript funktioniert mit fuehrenden oder anhaengenden Leerzeichen nicht, mit eingebetteten gehts. Was Zeilenumbrueche in Dateinamen angeht... wer sowas macht, der will Schmerzen.
Man kann jetzt natuerlich darueber diskutieren, ob man so einen kranken Scheiss aktiv unterstuetzen soll oder besser den Benutzer dazu erzieht, solche Dateinamen nicht zu verwenden. Denn auch in einem grafischen Dateimanager sind solche Namen mehr als aergerlich:
http://chris.silmor.de/dreimal.png
Gruss, Chris
Christian Perle chris@linuxinfotag.de (Mon Feb 14 16:49:24 2011):
Hallo Heiko,
On Mon, Feb 14, 2011 at 16:01:19 +0100, Heiko Schlittermann wrote:
Hehe, nicht so einfach???
$ mkdir test && cd test $ touch ' a' 'b ' 'c d' $ find . -type f | while read p; do echo "<$p>"; done $ find . -type f | while read; do echo "<$REPLY>"; done $ find . -type f -print0 | while read -d $'\x00'; do echo "<$REPLY>"; done
In der Tat, mein Skript funktioniert mit fuehrenden oder anhaengenden Leerzeichen nicht, mit eingebetteten gehts.
Das ist der kleine Unterschied zwischen "read" und "read VARIABLE".
Was Zeilenumbrueche in Dateinamen angeht... wer sowas macht, der will Schmerzen.
Das ist ja eine andere Frage ☺ Im vorliegenden Fall ist es bei der Fotosammlung auch eher unwahrscheinlich, da die ja sicher aus FAT-Systemen kommen.
Man kann jetzt natuerlich darueber diskutieren, ob man so einen kranken Scheiss aktiv unterstuetzen soll oder besser den Benutzer dazu erzieht, solche Dateinamen nicht zu verwenden.
Manchmal koennen wir uns das nicht aussuchen. Und ein technikferner Nutzer wird darin nichts Verwerfliches entdecken. Man kann hoffen, daß die verschiedenen Werkzeuge, mit denen so ein Nutzer umgeht, es ihm schwer machen, solche nicht-EDV-konformen Filenamen zu verwenden.
Denn auch in einem grafischen Dateimanager sind solche Namen mehr als aergerlich:
Schoen ☺
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Heiko Schlittermann -
Lunix -
Uwe Beger -
Uwe Koloska