Soweit verstanden

Zu 1: Alle Informationen, welche der Platten zuerst ausgefallen ist, sind durch die wechselweise Nichterkennung in den RAID-Metadaten zunichte. Präferenz gäbe es nur, wenn Du nach über einem Jahr noch in Erinnerung hättest, bei welcher der Platten "rebuild" in der Anzeige gestanden hat, bevor das RAID auf "Failed" gegangen ist.
Korrektur einer kleinen Unschärfe meiner Erklärung: Nicht nur die Daten, welche während des Ausfalls einer Platte und begonnenen Rebuilds auf der Partition verändert oder neu hinzugekommen sind, werden bei einem Fehlversuch beschädigt sein, sondern auch andere ältere, die sich positionsmäßig in der unmittelbaren Umgebung dieser befinden (auf den gleichen Stripesets) können beschädigt sein
Zu 2: Die methodische Vorgangsweise wäre:
- Aus dem Logfile die zuletzt ausgeführten Veränderungen im Filesystem ausfindig machen
- die MFT-Information dieser Dateien auslesen (in welchen Clustern die Daten abgespeichert sind)
- die entsprechenden RAID-Stripesets der Datencluster auslesen und auf Parity mismatch untersuchen, damit könnte vielleicht ein Anhaltspunkt der zuerst ausgefallenen Platte gefunden werden.
Eine weitere Methode wäre, alle Platten nach unlesbaren Sektoren zu durchsuchen, welche beim Abbruch der SATA-Verbindung (der zuerst ausgefallenen Platte beim Schreiben) zustande gekommen sein könnten.
Zu 3: Trial&Error
- Rekonstruktion des RAID ohne jeweils eine der 4 Platten (4 Versuche)
- je Versuch Analyse der Partition mit GetDataBack(kostenlose Trial-Version)
- je Versuch Auslesen der zuletzt veränderten Dateien und Überprüfung auf Fehlerfreiheit
(wenn fehlerfrei, dann ist die in diesem Versuch nicht eingebundene Platte die zuerst ausgefallene)
Ich würde zu 3) tendieren, weil dies zwar auch von der Durchführung zeitaufwändig ist, aber wenig manuellen Aufwand mit sich bringt.