/home nicht mehr schreibbar, Start endet in Konsole

[linuxlooser]

Hallo zusammen,

gestern abend hab ich die Kiste noch genutzt, dann in STR über Nacht, heute morgen wollte ich weiterarbeiten und konnte die bearbeiteten Dateien nicht speichern.

Runtergefahren, neu gestartet, dann kamen auf dem Bildschirm solche Meldungen, die ich in boot.log wiederfinden konnte:

Code: Alles auswählen

[[0;1;31mFAILED[0m] Failed to start [0;1;39mFile System Check on /dev/disk/by-uuid/22e837d9-27f3-44cc-811d-048ccc081f0a[0m.
See 'systemctl status "systemd-fsck@dev-disk-by\\x2duuid-22e837d9\\x2d27f3\\x2d44cc\\x2d811d\\x2d048ccc081f0a.service"' for details.
[[0;1;33mDEPEND[0m] Dependency failed for [0;1;39m/home[0m.
[[0;1;33mDEPEND[0m] Dependency failed for [0;1;39mLocal File Systems[0m.
[[0;1;33mDEPEND[0m] Dependency failed for [0;1;39m/home/benutzer/NAS_Audio[0m.
[[0;1;33mDEPEND[0m] Dependency failed for [0;1;39mRemote File Systems[0m.
[[0;1;33mDEPEND[0m] Dependency failed for [0;1;39m/home/benutzer/NAS_Video[0m.

In syslog finde ich

Code: Alles auswählen

Oct 10 09:11:40 Rechner kernel: [1253524.924805] print_req_error: I/O error, dev sda, sector 3435913264
Oct 10 09:11:40 Rechner kernel: [1253524.924815] ata1: EH complete
Oct 10 09:11:40 Rechner kernel: [1253524.924832] Aborting journal on device sda4-8.
Oct 10 09:11:40 Rechner kernel: [1253525.730244] EXT4-fs error (device sda4): ext4_journal_check_start:61: Detected aborted journal
Oct 10 09:11:40 Rechner kernel: [1253525.730250] EXT4-fs (sda4): Remounting filesystem read-only

Der Boot-Vorgang endet in einer Konsole mit der Aufforderung, mich als root anzumelden und logs anzuschauen etc.

System: aktelles Debian Buster (noch nicht auf Bullseye aktualisiert) 64bit Cinnamon

Hab im Rechner noch eine zweite Platte mit einem alten Mint (auf beiden Platten ist je eine vollständige Umgebung mit efi, root, swap und home Partitionen, die unabhängig voneinander laufen). Von dort aus kann ich die /home-Partition auf der jetzt anderen Platte einbinden und drauf zugreifen, die Daten sind noch da. Auch eine Text-Datei läßt sich anlegen.

Wie krieg ich die o. g. Fehler raus und die Partition wieder schreibbar als /home eingebunden?

[kalle123]

ALS ALLERERSTES!

Da du ja Zugriff hast, Daten sichern. Dann kann man weiter sehen ...

cu KH

[MSfree]

dann in STR über Nacht

Ich weiß zwar nicht, was der Stuttgarter Flughafen mit dem Problem zu tun hat, aber:

Code: Alles auswählen

Oct 10 09:11:40 Rechner kernel: [1253524.924805] print_req_error: I/O error, dev sda, sector 3435913264

heißt, daß da der Plattensektor 3435913264 kaputt ist. Die Platte sollte also ausgetauscht werden, bevor noch mehr kaputt geht. Die Daten spielt man dann halt vom Backup wieder ein.

[linuxlooser]

Da du ja Zugriff hast, Daten sichern. Dann kann man weiter sehen ...

Daten sind eh mehrfach gespiegelt, da mache ich mir nur begrenzt Sorgen (Haupt-PC plus Reise-PC plus ext. Platte ...)

dann in STR über Nacht

Ich weiß zwar nicht, was der Stuttgarter Flughafen mit dem Problem zu tun hat, aber:

Suspend-to-RAM

Code: Alles auswählen

Oct 10 09:11:40 Rechner kernel: [1253524.924805] print_req_error: I/O error, dev sda, sector 3435913264

heißt, daß da der Plattensektor 3435913264 kaputt ist. Die Platte sollte also ausgetauscht werden, bevor noch mehr kaputt geht. Die Daten spielt man dann halt vom Backup wieder ein.

ok, klare Ansage.
Nachdem da eh zwei Platten im Rechner sind, werde ich halt das Mint plattmachen und alles auf die andere Platte umziehen. Die defekte Platte wird dann irgendwann ersetzt (irgendwie liebe ich meine Doppel-Festplatten-Konfiguration) ...

[linuxlooser]

hmm ...

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

https://nopaste.debianforum.de/41487

auch kein Verlaß drauf ...

[linuxlooser]

allerhand kaputt:

https://nopaste.debianforum.de/41488

Jedenfalls fährt die Kiste jetzt wieder hoch ... mal sehen, was ich als nächstes mache.

Frage: läßt sich irgendwie aus den betroffenen Sektoren oder Blöcken oder Inodes oder was da alles aufgezählt wird auf die betroffenen Dateien schließen? Die müßten ja dann irgendwie kaputt oder verkürzt oder was auch immer sein, wenn Teile nicht wieder korrekt zusammengeflickt werden können bei so einem Check ...

[wanne]

auch kein Verlaß drauf ...

Der Test lief vor 194 Betriebstagen. Also vermutlich so vor 1-2 Jahren. Eventuell war sie da noch in Ordnung.
Mittlerweile hat sie auf jeden Fall so viele Fehler geworfen, dass der Speicher dafür aus gegangen ist. Die erste noch gespeicherte war vor 45 Betriebstagen. Die hat also ordentlich gewarnt.

[wanne]

Frage: läßt sich irgendwie aus den betroffenen Sektoren oder Blöcken oder Inodes oder was da alles aufgezählt wird auf die betroffenen Dateien schließen?

Ja. Prinzipiell schon. Wenn das wirklich ne Datei und nicht irgend welche Dateisystem interne Daten sind. (Wo welche Datei mit welchem Namen liegt...) – Was recht wahrscheinlich ist, wenn er dir beim Dateisystemcheck auf die Fresse gefallen ist.

Aber guck erst mal genauer den Log an. Der verrät dir schon deutlich mehr, was die suche deutlich einfacher macht.
Aber das von Hand zu flicken wird ziemlich unmöglich. Da sind nochmal mindestens 2 weitere Blöcke kaputt. Und vermutlich Zig tausende mehr, wenn du jetzt mit systematischem kopieren anfängst. Spiel dein Backup ein und fertig.
Wenn du wissen willst, ob deine Dateien in Ordnung sind, schalte Checksumming im Dateisystem an.

[linuxlooser]

Der Test lief vor 194 Betriebstagen.

Wo sehe ich das?

Ich hatte mich bis dato immer daran orientiert:


"aktualisiert vor 'n paar Minuten" - was immer das heißen mag. Für Otto Normaluser klingt das so, als ob alles ok ist.

Wenn ich da allerdings jetzt händisch einen Selbsttest anstoße, dann kommt


smartctl meldet immer noch:

Code: Alles auswählen

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Interessant, was dazu im Wiki steht:

Hinweis: Dieser Indikator ist zunehmend nicht sehr aussagefähig. Es kann sein, dass trotz fehlschlagender Selbsttests und anderer schwerwiegender Fehler hier ein PASSED gemeldet wird. Die Gründe könnten darin liegen, dass der Hersteller bei frühzeitigem Auslösen zu hohe Rücklaufzahlen bewältigen müsste, was Image- und wirtschaftlich schädigend wäre.

Hab jetzt mal

Code: Alles auswählen

~# smartctl -t long  /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-18-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 260 minutes for test to complete.
Test will complete after Mon Oct 11 17:41:18 2021

laufen.

Warum das Ganze?
Weil ich sehen will, ob die zweite Platte i. O. ist. Und dazu muß ich erst wissen, wie ich die Fehler der ersten angezeigt bekomme in so einem Report ...

[linuxlooser]

Ich hab in der Zwischenzeit mal - gemäß Wiki - dieses auf meiner zweiten Platte gemacht:

Code: Alles auswählen

~# smartctl -l xselftest /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-18-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      9436         910032
# 2  Short offline       Completed: read failure       90%      9436         910032
# 3  Short offline       Completed: read failure       90%      9436         910032
# 4  Short offline       Completed: read failure       90%      9435         910032
# 5  Short offline       Completed: read failure       90%      9435         910032
# 6  Extended offline    Completed: read failure       90%      9435         910032
# 7  Short offline       Completed without error       00%      1783         -

Heißt das ... die ist auch Schrott?

Zumindest wohl alt ...

Code: Alles auswählen

~# smartctl -A /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-18-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       277
  3 Spin_Up_Time            0x0027   183   179   021    Pre-fail  Always       -       5850
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6760
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       2
  7 Seek_Error_Rate         0x002e   200   199   000    Old_age   Always       -       8
  9 Power_On_Hours          0x0032   083   083   000    Old_age   Always       -       12784
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   094   094   000    Old_age   Always       -       6740
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       65
193 Load_Cycle_Count        0x0032   123   123   000    Old_age   Always       -       231071
194 Temperature_Celsius     0x0022   112   098   000    Old_age   Always       -       38
196 Reallocated_Event_Count 0x0032   198   198   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       76

Im Vergleich dazu die hier diskutierte defekte /dev/sda:

Code: Alles auswählen

~# smartctl -A /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-18-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       709
  3 Spin_Up_Time            0x0027   181   178   021    Pre-fail  Always       -       5916
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6734
  5 Reallocated_Sector_Ct   0x0033   195   195   140    Pre-fail  Always       -       148
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       9861
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   094   094   000    Old_age   Always       -       6715
192 Power-Off_Retract_Count 0x0032   199   199   000    Old_age   Always       -       1495
193 Load_Cycle_Count        0x0032   154   154   000    Old_age   Always       -       139363
194 Temperature_Celsius     0x0022   112   101   000    Old_age   Always       -       38
196 Reallocated_Event_Count 0x0032   197   197   000    Old_age   Always       -       3
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       239
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       238
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   198   198   000    Old_age   Offline      -       677

dabei gefällt mir

Code: Alles auswählen

Reallocated_Sector_Ct   0x0033   195   195   140    Pre-fail  Always       -       148

erstmal gar nicht.

Und danach sind Zeile 196 bis 198 auch gar nicht gut ... ich glaube, so allmählich versteh ich das Ganze ...

[wanne]

Heißt das ... die ist auch Schrott?

Ganz gesund ist die auf jeden Fall nimmer. Aber einige wenige Read und Seek errors müssen nicht unbedingt ein Problem sein. Nur wenn das jetzt kontinuierlich weiter hoch geht. (Worauf ich aber fast tippen würde.)

Wo sehe ich das?

Das steht bei der wievielten Stunde der letzte lief (5181) und bei welcher man aktuell ist: 9850. Die Zahlen kann man voneinander abziehen...

[linuxlooser]

super, danke Dir. Bringt jedenfalls richtig Licht ins Dunkel.

Nun hab ich noch eine Frage:

Wenn du wissen willst, ob deine Dateien in Ordnung sind, schalte Checksumming im Dateisystem an.

Wie das?
Ich hab derzeit noch überall ext4 laufen ... Daten halt immer auf der Platte in der Partition 4 gelassen, in Partition 2 (und 1: EFI) die Betriebssysteme installiert/aktualisiert (3 ist Swap). Evolution halt ...

Wenn ich aber eh neue Platten kaufe, dann könnte ich neu aufsetzen. Datenintegrität ist mir wichtig - Checksummen kenne ich von meinem Bildarchiv (alles RAW-Dateien aus der Kamera), dort lasse ich ein Script über die Dateien rennen und verschiedene Checksummen (CRC32, SHA1 und MD5) in eine Datei schreiben und mit wieder einem Script regelmäßig prüfen.
Auf Dateisystemebene kannte ich das noch nicht - sollte ich das Dateisystem wechseln? Wohin?

[MSfree]

Checksummen kenne ich von meinem Bildarchiv (alles RAW-Dateien aus der Kamera), dort lasse ich ein Script über die Dateien rennen und verschiedene Checksummen (CRC32, SHA1 und MD5) in eine Datei schreiben und mit wieder einem Script regelmäßig prüfen.

CRC kannst du dir schenken, weil das nicht zuverlässig ist. Ein einzelnes umgekipptes Bit kannst du damit zwar finden, aber bereits zwei umgekippte Bits können sich schon wieder kompensieren, so daß die Datei letztlich intakt aussieht. MD5 ist schon ziemlich zuverlässig, besser wäre hier aber sha256 oder höher.

Auf Dateisystemebene kannte ich das noch nicht - sollte ich das Dateisystem wechseln? Wohin?

Prüfsummen im Dateisystem unterstützt ja auch nicht jedes Dateisystem. Die beiden Dateisysteme, die meines Wissens Checksumming unterstützen, sind btrfs und ZFS. Wobei beide nicht uneingeschränkt empfehlendswert sind.

btrfs ist meiner Meinung nach immer noch nicht so robust wie ext3/4. In Produktivumgebungen würde ich es jedenfalls nicht einsetzen wollen.

Bei ZFS gibt es die LIzenzinkompatibilität zwischen dem Linuxkernel und der Softwarelizenz von ZFS, weshalb ZFS nach wie vor nicht Bestandteil des Kernels ist. Für mich der Grund, der mich von ZFS fernhält.

[linuxlooser]

CRC kannst du dir schenken, weil das nicht zuverlässig ist. Ein einzelnes umgekipptes Bit kannst du damit zwar finden, aber bereits zwei umgekippte Bits können sich schon wieder kompensieren, so daß die Datei letztlich intakt aussieht. MD5 ist schon ziemlich zuverlässig, besser wäre hier aber sha256 oder höher.

muß ich mich vielleicht mal wieder drum kümmern, Script ist schon etwas älter ...

weshalb ZFS nach wie vor nicht Bestandteil des Kernels ist. Für mich der Grund, der mich von ZFS fernhält.

nachvollziehbar, danke.

[wanne]

CRC kannst du dir schenken, weil das nicht zuverlässig ist. Ein einzelnes umgekipptes Bit kannst du damit zwar finden, aber bereits zwei umgekippte Bits können sich schon wieder kompensieren, so daß die Datei letztlich intakt aussieht. MD5 ist schon ziemlich zuverlässig, besser wäre hier aber sha256 oder höher.

Bei SHA1 gibt es ein relativ berühmtes Beispiel mit einem einzelnen umgekippten Bit, die wieder die selbe Summe geben. Bei MD5 welche mit einem angehängten Byte.
Der Große Unterschied zwischen CRC und den letzteren ist, dass es für CRC einfach errechenbar ist, welche zwei/drei Bits du kippen musst (z.B. genau zwei im Abstand von exakt 32Bit ist der Abstand kleiner sind deutlich mehr Bits nötig.), während es für MD5 eine extrem aufwändige Suche ist und für SHA256 die sogar so aufwändig ist, dass es noch nie jemand geschafft hat.
Da ne Platte nicht bösartig ist und hoffentlich nicht gezielt ausrechnet welche Bits sie jetzt kippt ist das eher irrelevant.
Da zählen nur noch Wahrscheinlcihkeiten und da ist CRC32 mit der Chance 1:4 Mrd., dass ein Fehler von mehr als zwei Bit nicht erkannt wird nicht so schlecht. 6 Richtige + Superzahl im Lotto sind 40 mal wahrscheinlicher und CRC64 genug für jeden. Nur bei CRC16 muss man ein bisschen aufpassen.

Die beiden Dateisysteme, die meines Wissens Checksumming unterstützen, sind btrfs und ZFS.

ext4 hat das glaube ich auf der Agenda. Im Moment aber wohl nur für Metadaten. Ansonsten gibt es noch LUKS2, dass Checksumming kann du unter alles drunter legen kannst. Dann bekommst du aber auch wieder nur Blöcke. Aber wenigstens eine volle Liste. Wobei du das wohl auch trigern kannst indem du ein mal cat über die volle Partition laufen lässt und d

btrfs ist meiner Meinung nach immer noch nicht so robust wie ext3/4. In Produktivumgebungen würde ich es jedenfalls nicht einsetzen wollen.

Vor wie vielen Jahren hast du dir diese Meinung gebildet und wann hast du vor die anhand welcher Kriterien neu zu überdenken?

[schorsch_76]

@MSFree: Ich nutze btrfs seit vielen Jahren ohne Probleme auf dem Desktop, Pi4 oder BBB. Mit btrfsmaintenance hab ich auch keine Probleme und das Filesystem wird regelmässig "gewartet".

[linuxlooser]

noch kurz zur Ergänzung, weil ich die Daten gerade da habe: die beiden 2TB-Platten oben sind WD Blue aus Mitte 2017 - haben also im PC am heimischen Schreibtisch stehend für e-mails, Webseiten schreiben, Bilder editieren und das übliche Web-Surfen gerade 4 Jahre gehalten (die Hälfte davon passiv, weil die jeweils andere Platte im Einsatz war, s. o.) ...

[wanne]

Und noch kurz wie du die Datei zum Block bekommst.
Beispiel: Block: 4935609
Auf der Platte:

Code: Alles auswählen

 fdisk -l /dev/sda
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device        Start      End  Sectors  Size Type
/dev/sda1      2048   278527   276480  135M Linux filesystem
/dev/sda2    278528 68638719 68360192 32.6G Linux filesystem
/dev/sda3  68638720 83884031 15245312  7.3G Linux swap

Code: Alles auswählen

$ calc 4935609-278528
4657081

=> Der 4378553ste Block auf sda2
Nun muss man aufpassen Oben steht, dass die Festplatte in 512Byte Blöcken rechnet. ext4 rechnet aber immer in 4kiB-Blöcke. => Um auf die Blocknummer im Dateisystem zu kommen musst du durch 8 teilen:

Code: Alles auswählen

echo -e "open /dev/sda2\n icheck $((4657081/8))" | debugfs -f -
debugfs:  icheck 582135
Block   Inode number
582135  1707692

=> Inode nummer 1707692 gehört zu dem Block.

Code: Alles auswählen

find / -xdev -inum 1707692
/usr/bin/xxd

=> Block liegt in xxd:
Die beiden letzten Chckes können prinzipiell beide fehlschlagen: Der erste, nach dem inode wenn der Platz auf der Platte schlicht frei ist, der 2. nach der Datei auf dem inode Wenn an der Stelle keine Datei sondern Metadaten liegen.

Gegencheck:

Code: Alles auswählen

filefrag /usr/bin/xxd -v
File size of /usr/bin/xxd is 18552 (5 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       4:     582134..    582138:      5:             last,eof

Ich hoffe ich habe jetzt keinen off by one error gemacht...

[linuxlooser]

Nun muss man aufpassen Oben steht, dass die Festplatte in 512Byte Blöcken rechnet. ext4 rechnet aber immer in 4kiB-Blöcke. => Um auf die Blocknummer im Dateisystem zu kommen musst du durch 8 teilen:

Bei mir kommt dieses Mischmasch aus 512Byte und 4k:

Code: Alles auswählen

~# fdisk -l /dev/sda
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZRZ-00Z
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Device         Start        End    Sectors  Size Type
/dev/sda1       2048     411647     409600  200M EFI System
/dev/sda2     411648  136726527  136314880   65G Linux filesystem
/dev/sda3  136726528  187058175   50331648   24G Linux swap
/dev/sda4  187058176 3907028991 3719970816  1,7T Linux filesystem

War mir nicht sicher, ob ich dann auch durch 8 teilen muß, aber

Code: Alles auswählen

2000398934016 ÷ 3907029168 = 512

also wohl ja.

Und als Wert kann ich dann den aus dem Log nehmen?

Code: Alles auswählen

Oct 10 09:11:40 Rechner kernel: [1253524.924805] print_req_error: I/O error, dev sda, sector 3435913264

Code: Alles auswählen

3435913264 - 187058176 = 3248855088

Dann käme

Code: Alles auswählen

~# echo -e "open /dev/sda4\n icheck $((3248855088/8))" | debugfs -f -
debugfs 1.44.5 (15-Dec-2018)
debugfs: open /dev/sda4
debugfs:  icheck 406106886
Block	Inode number
406106886	<block not found>

Die beiden letzten Chckes können prinzipiell beide fehlschlagen: Der erste, nach dem inode wenn der Platz auf der Platte schlicht frei ist

was - wenn ich nicht grundsätzlich was falsch gemacht habe, beruhigend wäre ...

[wanne]

Bei mir kommt dieses Mischmasch aus 512Byte und 4k:

Ja. Grauenhaft. Der Grund ist, dass die Platte eigentlich 4k Blöcke hat. Aber nach außen zerteilt sie jeden in 8 Einzelteile tut so als hätte sie 512Byte, weil ältere Windows-Versionen (Alles vor Windows 10) nur damit umgehen können. Weil das so ist, gelten die 512.

was - wenn ich nicht grundsätzlich was falsch gemacht habe, beruhigend wäre ...

Nein. Ganz im Gegenteil. Wenn das dir die Zuordnung kaputt schießt welche Daten zu welcher Datei gehören, können halt prinzipiell alle Dateien Probleme haben...

[linuxlooser]

Kann ich eigentlich eine mittels `gdisk` gesicherte Partitionstabelle auf eine neue Platte zwar gleicher Größe, aber anderen Typs (WD black akutell vs. WD blue von vor 4 Jahren) übertragen?

Als Halblaie könnten mir evtl. ein paar Unwägbarkeiten einfallen

[GregorS]

Als Halblaie ...

Grundsätzlich: Wenn eine Platte Ärger macht, immer und zu allererst ein "rohes" Backup der vollständigen Platte anfertigen. Ich mache das alle paar Monate und vor tiefgreifenden Konfigurationsänderungen mit dd.

Gruß

Gregor

[linuxlooser]

alle paar Monate (...) mit dd.

Scheidet aus, wir sprechen hier von 2TB - hab nicht so viele redundante Platten rumliegen ...
Hab die vollständigen Daten parallel auf 2 PCs zzgl. einer ext. Platte, dort mit Versionierung.
Und vom Betriebssystem gibt's gelegentliche Timeshift-Snapshots.

Mir geht es aktuell (nachdem gestern die Ersatzplatte eingetroffen ist) darum, ob ich alles von Hand neu aufsetzen muß oder ob ich die Partitionstabelle aus dem gdisk-Backup der alten Platte verwenden kann und dann den letzten Timeshift-Stand einspielen ...
(mit dd könnte ich zum jetzigen Stand eh nur eine kaputte Platte kopieren)

[MSfree]

dd halte ich auch für ungeeinet als Backup in diesem Fall. dd kopiert ja auch die unbennutzen Plattensektoren, was einerseits völlig überflüssig ist und andererseits Platz benötigt.

Backups auf Dateibasis sind da deutlich sinnvoller.

Mir geht es aktuell (nachdem gestern die Ersatzplatte eingetroffen ist) darum, ob ich alles von Hand neu aufsetzen muß oder ob ich die Partitionstabelle aus dem gdisk-Backup der alten Platte verwenden kann und dann den letzten Timeshift-Stand einspielen ...

Das Anlegen eine neuen Partitionstabelle ist ja nun kein so schwieriges Unterfangen. Die alte Partitiontabelle würde ich nicht nutzen, denn das funktioniert nur dann reibungslos, wenn die neue Platte exakt genauso vielie Bytes hat wie die alte. Schon 4096 Bytes Unterschied kann problematisch werden. Ausserdem kann man sich beim Neuanlegen auch mal Gedanken machen, ob die alte Partitionierung sinnvoll war oder ob man lieber die Aufteilung etwas ändert.

Den letzten Timeshift-Stand kannst du auch auf eine frisch partitionierte Platte einspielen.

[linuxlooser]

Die alte Partitiontabelle würde ich nicht nutzen, denn das funktioniert nur dann reibungslos, wenn die neue Platte exakt genauso vielie Bytes hat wie die alte. Schon 4096 Bytes Unterschied kann problematisch werden.

Das war eine meiner Bedenken, danke!

Den letzten Timeshift-Stand kannst du auch auf eine frisch partitionierte Platte einspielen.

Werd ich probieren.