[00:00] <ryker> https://paste.debian.net/plain/1267984
[00:00] <itu>  smartctl -d sat -A -T permissive  /dev/sdc   | nc termbin.com 9999   #  next try  
[00:01] <ryker> https://termbin.com/a0qns
[00:02] <ryker> ich denke, permission ist denied, weil gerade ddrescue läuft
[00:04] <itu> dann mach es nachdem du abbrichst ...
[00:04] <ryker> soll ich dann jetzt abbrechen?
[00:04] <itu> oder erstmal sudo  vorendran .. bzw. als root
[00:04] <ryker> ok
[00:05] <itu> ob du abbrichst oder über nacht laufen lässt musst du selber wissen 
[00:07] <ryker> ah ok, lag tatsächlich an sudo
[00:07] <ryker> https://paste.debian.net/plain/1267985
[00:07] <itu> echo $? sagt was?
[00:08] <ryker> $
[00:08] <itu> ist der fehlerwert , müsstest du allerdings direkt im anschluss abfragen ...
[00:09] <ryker> wo ist da der bezug zu sdc?
[00:12] <ryker> ah, jetzt scheint er doch nochmal erfolgreich was gelesen zu haben, denn: time since last successful read:      5m  9s
[00:13] <ryker> ich denke, dann macht es wohl sinn, über nach weiterlaufen zu lassen
[00:13] <ryker> nachT
[00:15] <itu>  -A könnstest du mal weglassen als nächstes
[00:17] <itu> und -H soweiso
[00:17] <ryker> -A hab ich doch gar nicht benutzt
[00:18] <ryker> welchen befehl meinst du genau?
[00:19] <itu> immer noch smartctl
[00:20] <itu>  -A hatte ich dir angegeben jedenfalls , s.o.
[00:21] <ryker> welchen parameter soll ich nehmen?
[00:21] <ryker> -T?
[00:26] <itu> sudo  smartctl -d sat -A -T permissive  /dev/sdc   | nc termbin.com 9999
[00:27] <itu> dann evt ohne -A probieren
[00:27] <ryker> was genau macht 'permissive'?
[00:29] <ryker> https://termbin.com/dcp4n
[00:29] <itu> es erlaubt irgendwas mehr ... und hilft wohl oft wenn sonst nix geht ...
[00:30] <ryker> ok
[00:33] <itu> sudo  smartctl  -d sat  -T permissive    -a /dev/sdc   # mit befehl in paste .. dann seh ich auch was du eigegeben hast
[00:36] <ryker> https://termbin.com/ry4g
[00:36] <ryker> achso, moment
[00:37] <ryker> https://paste.debian.net/plain/1267991
[00:41] <itu> 197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       1074
[00:41] <itu> 198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       1074
[00:41] <itu>  das sind unlesbaren sectors 
[00:44] <ryker> ok
[00:46] <itu> *+die
[00:50] <ryker> was jetzt?
[00:50] <itu> hoffen und beten
[00:53] <itu> du kannst vom image evt zwischenzeitlich nochmal ne kopie machen und es dir schon mal anschaun
[00:54] <ryker> ok, das mach ich mal eben
[00:54] <itu> dann ggf fsck machen und verluste eruieren und ggf. um datenverluste trauern
[00:56] <itu> um die weiterwerwendung der fehlerhafte platte gehts dir hoffentlich nicht 
[00:56] <itu> +n
[00:57] <itu> W>v
[00:58] <ryker> ne, gar nicht
[00:58] <ryker> das ist ne alte platte aus nem alten mac
[00:59] <itu> jo
[01:01] <ryker> was genau macht fsck? reparieren?
[01:01] <itu> jo
[01:01] <itu> man fsck
[01:02] <ryker> ok, aber bevor ich fsck mache, mache ich erst mal noch ddrescue ohne -n
[01:03] <ryker> nachdem der erste ddrescue-durchlauf beendet wurde
[01:05] <itu> wenn ich jetzt wüsste was scraping heissen soll ...
[01:07] <ryker> -n, --no-scrape     Keine "Kratz"-Phase; bzw. früher: Kein Teilen von nicht-lesbaren Blöcken und keine wiederholten Versuche, diese zu lesen. Schont die auszulesenden Medien.
[01:08] <ryker> Ein guter Ansatz ist es, zunächst einmal zu versuchen alles zu sichern, was zum Zeitpunkt der Sicherung fehlerfrei ist, und keine Zeit auf fehlerhafte Blöcke zu verwenden: ddrescue -n QUELLE ZIEL ddrescue.log
[01:09] <ryker> Erst danach startet man einen weiteren Durchlauf, in dem versucht wird, möglichst viele von den im ersten Schritt als kaputt markierten Daten doch noch zu retten: ddrescue QUELLE ZIEL ddrescue.log
[01:09] <ryker> Dieses zweigeteilte Vorgehen ist zu bevorzugen, da durch die intensive Beanspruchung, noch Daten aus den defekten Blöcke zu bekommen, auch andere Teile der Medien zerstört werden können.
[01:12] <itu> "keine wiederholten Versuche, diese zu lesen. "  wäre nur als erste Option sinvvoll gewesen   .... schliesslich ist es der ganze sinn von ddrescue so lange zu zu probieren bis es ggf. erfolg hat ....
[01:13] <ryker> was meinst du mit erste option?
[01:14] <ryker> wenn du erster durchlauf meinst, das ist der erste durchlauf
[01:14] <itu> erster versuch
[01:14] <itu> jo
[01:14] <ryker> wieso denkst du, es wäre nicht der erste durchlauf?
[01:15] <itu> warum sollte ich?
[01:16] <itu>  -n hättest du beim ersten angeben müssen , jetzt ist es zu spät um sinn zu machen
[01:16] <ryker> na ja, du schriebst "wäre sinnvoll gewesen"
[01:16] <ryker> es IST der erste
[01:16] <itu> genau
[01:17] <itu> hmmmpff
[01:17] <itu> es ist der erste und du hast den parameter NICHT angeben der nur beim ersten mal sinn macht .............................................
[01:18] <ryker> hab ich wohl
[01:18] <ryker> godwin@godwin-Aspire-7750G:~$ sudo ddrescue -f -R -n /dev/sdc /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.log
[01:19] <itu> [02:02:25] <ryker> ok, aber bevor ich fsck mache, mache ich erst mal noch ddrescue ohne -n     <--- konnte man anders interpretieren 
[01:19] <itu> also dann ist deine option -n wegzulassen 
[01:20] <ryker> genau, im zweiten schritt lasse ich -n weg
[01:20] <itu> ob lange versuche mit -n sinn machen bezweifle ich aber
[01:21] <ryker> ich verstehe nicht, warum das jetzt alles so schleppend geht
[01:22] <ryker> er ist jetzt seit gefühlt stunden bei 99,78%
[01:22] <itu> hm, kann sein dass ich auf dem schlauch gestanden bin wegen dem -n
[01:23] <ryker> macht ja nix
[01:24] <ryker> was meinst du, wie lange wird das jetzt noch dauern?
[01:25] <itu> möglichweise endlos ... er hat ja schon 5mal alles gelesen vorhin 
[01:25] <itu> schau halt mal ins man , etc
[01:26] <ryker> endlos? trotz -n?
[01:28] <itu>  -n bezieht sich ja nur auf die nicht-lesbaren Blöcke
[01:29] <itu> wie sieht denn die ausgabe aus jetzt?
[01:30] <ryker> https://paste.debian.net/plain/1267995
[01:31] <itu> "Pass 5 " liest sich für mich wie der 5 durchlauf, das war vor ne weile ja auch schon ...
[01:32] <ryker> ja
[01:33] <ryker> ich denke, ich geh mal pennen und lasse durchlaufen
[01:35] <ryker> danke bis hierhin
[01:36] <ryker> itu gute nacht
[01:36] <itu> nacht
=== ircuser is now known as ryker
=== ircuser is now known as ryker
[11:24] <ryker> tomreyn hi. ich hab die aktion heute morgen gegen 4 uhr abgebrochen, weil ich schiss hatte, dass die platte im laufe der nacht viel zu heiß wird
[11:25] <ryker> und ich hatte sowieso den eindruck, dass das ganze kein ende mehr nehmen würde, denn es blieb stundenlang bei 99,78%
[11:25] <ryker> https://paste.debian.net/plain/1268017
[11:25] <ryker> soll ich das ganze trotzdem nochmal fortsetzen und, wenn ja, mit welcher eingabe?
[12:15] <itu> heisslaufen?  es scheint mir eher normal zu sein dass platten ständig laufen als dass sie automatisch spin-down machen
[12:16] <itu> temperatur müsste auch in smartctl auslesbar sein , oder in hdparm
[12:17] <tomreyn> ryker: das ist in ordnung (abzubrechen), du kannst es dank der map (.log)-datei jederzeit wieder aufnehmen, wenn du willst. aber es wurden ja eh schon 99.78% der daten ausgelesen. du kannst versuchen es nochmal ohne -n laufen zu lassen, dann können, mit viel glück, noch weitere daten ausgelesen werden. falls du dafür platz hast, mach dir vorher aber noch eine kopie der image-datei, dann kannst du dort schon an der datenwiederherstellu
[12:17] <tomreyn> ng arbeiten, während das scraping noch läuft.
[12:18] <itu> 194 Temperature_Celsius     0x0022   044   065   000    Old_age   Always       -       44    ,  offenbar recht cool
[12:26] <ryker> tomreyn danke. wie wäre denn der befehl für die wiederaufnahme und wie der für einen zweiten durchlauf ohne -n?
[12:27] <ryker> itu ich kenne mich halt nicht aus und da die platte schon sehr alt ist und sich vom anfassen halt schon sehr heiß anfühlte, war ich mir nicht sicher
[12:27] <ryker> ich kopiere jetzt schon mal die image-datei, wie sie momentan ist
[12:28] <tomreyn> ryker: der gleiche befehl wie letztes mal, nur ohne " -n".
[12:28] <ryker> ok, aber wird die image-datei dann nicht überschrieben?
[12:29] <tomreyn> oops, in der tat, -F musst du auch auslassen, sorry
[12:29] <ryker> (anders gefragt: woher weiß er, dass er die datei lediglich "ergänzen" soll?)
[12:29] <tomreyn> anhand der map-datei
[12:30] <ryker> .log ist die map-datei, ja?
[12:30] <tomreyn> ja
[12:30] <ryker> okay, kann ich das schon starten während die image-datei gerade dupliziert wird?
[12:31] <ryker> oder lieber warten?
[12:31] <tomreyn> warten
[12:32] <ryker> ok!
[12:33] <tomreyn> und wart mal eben noch ab mit dem ddrescue, ich lese nochmal über die optionen
[12:34] <ryker> ok, das duplizieren dauert nach aktuellem stand eh noch 1 std 15 min
[12:35] <tomreyn> über die GUI gemacht, wa?
[12:35] <ryker> ja
[12:35] <ryker> nicht sinnvoll?
[12:35] <tomreyn> cp ist fast immer schneller, ich weiß auch nicht wieso
[12:36] <itu> logfile=mapfile?  .. irgendwie blickt man da sowieso nicht wirklich durch ...
[12:36] <ryker> hmm
[12:37] <tomreyn> "NOTE:  In versions  of  ddrescue  prior to 1.20 the mapfile was called 'logfile'. The format is the same; only the name has changed."
[12:37] <itu> quarkig
[12:38] <tomreyn> logfile war halt eine irreführende bezeichnung, das umzubenennen war nur konsequent
[12:39] <itu> so konsequent wie panzerlieferungen  ... besser spät als nie
[12:42] <tomreyn> ryker: kopier sicherheitshalber auch die image_sdc.log, die dürfte ja so groß nicht sein, ne?
[12:42] <ryker> ja, 13,9 kb :)
[12:43] <tomreyn> 👍️
[12:44] <ryker> ich muss mich mal eben fertig machen, muss gegen 14 uhr für ein paar stunden weg. mache den zweiten ddrescue-durchlauf dann später
[12:50] <tomreyn> oder du startest ihn halt schon mal während du weg bist
[12:51] <tomreyn> stell nochmal sicher, dass das sdc noch das gleiche ist wie gestern, dann: sudo ddrescue /dev/sdc /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.log
[12:52] <tomreyn> oh und den mountpunkt solltest du auch nochmal prüfen 
[12:54] <tomreyn> alternativ: falls du so anti-feuchtigkeits-granulat hast, was in gelieferten paketen mitunter mit drin ist, oder ein tütchen backpulver, dann schnapp dir das, pack es mit der festplatte in eine plsstiktüte und pack die plastiktüte in den kühlschrank (aber nicht ins eisfach) während du weg bist.
[12:55] <itu> öh
[12:56] <ryker> ähhh :D  ok, krass
[12:57] <ryker> das schaff ich jetzt leider nicht mehr, aber ich hab ja zeit, was das angeht
[12:57] <itu> das wäre dann mal ein versuch .. würde aber erst mal normal probieren (ohne -n ..)
[12:57] <ryker> es fühlt sich für mich besser an, jetzt erst mal den kopierprozess zu beenden
[12:59] <ryker> gibt es vom chatraum hier eigentlich noch diesen log?
[12:59] <ryker> -diesen +einen
[12:59] <nichtryu> die meisten IRC clients loggen selber, kann also gut sein, dass du das log einfach auch lokal hast
[13:00] <tomreyn> https://irclogs.ubuntu.com/2023/01/21/%23ubuntu-de.html
[13:00] <le_bot> Title: /srv/irclogs.ubuntu.com/2023/01/21/#ubuntu-de.txt (at irclogs.ubuntu.com)
[13:00] <ryker> ne, ich bin über web.libera.chat drin
[13:00] <ryker> ah, genau das, danke
[13:00] <itu> oh mein gott, wir werden geloggt!
[13:02] <itu> hmmm
=== viktor is now known as Guest2673