Nachdem ich das Angebotene Update auf Version 7.3.1-86003 Update 1 eingespielt hatte, das eine Sicherheitslücke beheben sollte, bootete unsere Synology DS220+ nicht mehr. Sie blieb einfach mit blau blinkender Power-LED hängen. Das war nicht das erste Mal, dass sie beim Booten Probleme machte, aber diesmal ließ sie sich nicht einfach durch einen weiteren Reboot wieder erwecken. Nachdem wir alle Diagnoseschritte aus dem entsprechenden KB-Artikel durchgeführt hatten blieb nur die Option “Mainboard defekt” übrig.
Der Synology Support verweigerte die Reparatur, weil sowohl die Unterstützung der Generation unserer NAS-Reihe als auch die Garantie unseres Gerätes abgelaufen waren. Die vorgeschlagenen Optionen waren:
- Netzteil austauschen
- Gerät austauschen und Festplatten migrieren
- Datenwiederherstellung mit einem Linux-PC
Ein anderes Netzteil hatten wir schon getestet. Eine neue Synology kaufen widerstrebte uns, da Synology erst vor kurzem die Unterstützung für Fremd-Festplatten eingestellt hatte. Diese Entscheidung haben sie zwar kurz danach wieder teilweise revidiert, aber auch in den aktuellen Nutzungsbedingungen steht:
“Für Laufwerke, die nicht auf der Kompatibilitätsliste stehen, kann Synology nur eingeschränkten Support für Systemhardware, Software und Konfiguration bieten.”
Mit anderen Worten, bei der Nutzung von Festplatten für die man nicht den Synology-Aufpreis bezahlt hat, bekommt man dann im Problemfall unter Umständen gesagt “Da müsst ihr jetzt selbst mit klar kommen”. Da habe ich keine Lust drauf. Also war recht schnell die Entscheidung getroffen wieder auf ein DIY-NAS umzusteigen.
Die Festplatten wollten wir weiterverwenden, die Weiternutzung war aber mit einer Neupartitionierung und -formatierung verbunden. Wir hatten die zwei Festplatten im NAS getrennt betrieben, auf einer lagen verschlüsselt alle unsere wichtigen Daten, die regelmäßig auf eine USB-Platte gesichert wurden die an einem sicheren Ort aufbewahrt wird. Auf der zweiten Festplatte lag eher unwichtiger Kram, im wesentlichen Downloads aus der Mediathek die wir irgendwann mal schauen wollten und ähnliches, da wäre ein Verlust zu verschmerzen gewesen.
Trotzdem wollte ich versuchen nochmal auf beide Festplatten zuzugreifen, zum Einen gab es da tatsächlich noch ein paar Fotos die bei der letzten Sicherung auf die USB-Platte noch nicht da waren und die bereits von der Kamera gelöscht waren, zum Anderen wollte ich mir die Arbeit sparen verschiedenste Serien die ich über einen längeren Zeitraum aus der Mediathek zusammengesammelt hatte wieder neu zusammensuchen zu müssen. An der Stelle kam mir ungewollt DHL entgegen, die das Paket mit dem wichtigsten Teil der Hardware für unsere neues NAS verbaselt hatten … das Mainboard und der RAM-Riegel.
Synology hat einen recht ausführlichen KB-Artikel zur Datenwiederherstellung mit einem Linux-PC, dem ich folgte.
Seit unserem vollständigen Wechsel auf Linux mangelt es hier ja nicht an Linux-Geräten, also schloss ich die erste Festplatte mit einem USB Adapter an meinen Laptop an, kam aber nicht weit.
root@ubuntu:~# fdisk -l /dev/vdb
Disk /dev/vdb: 1.7 TiB, 1801763774464 bytes, 3519069872 sectors
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: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/vdb1 1 4294967295 4294967295 2T ee GPTAus irgend einem Grund wurden sowohl die 6 TB als auch die 3 TB Platte als 1,7 TB Festplatte mit einer 2TB Partition darauf erkannt … was definitiv falsch war. Die Befehle die man ausführen sollte brachten auch nicht das erwartete Ergebnis
root@ubuntu:~# mdadm -AsfRv
mdadm: looking for devices for further assembly
mdadm: cannot open device /dev/sr0: No medium found
mdadm: no recogniseable superblock on /dev/dm-0
mdadm: Cannot assemble mbr metadata on /dev/vdb
mdadm: no recogniseable superblock on /dev/vda3
mdadm: no recogniseable superblock on /dev/vda2
mdadm: no recogniseable superblock on /dev/vda1
mdadm: Cannot assemble mbr metadata on /dev/vda
mdadm: No arrays found in config file or automatically
root@ubuntu:~# vgchange -ay
1 logical volume(s) in volume group "ubuntu-vg" now active
root@ubuntu:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@ubuntu:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi-ao---- <14.00g Kein mdraid, das einzige lvm-Volume das ich bekam war das meines Systems. Auf meinem Laptop läuft mit Tuxedo OS, das auf Ubuntu 24.04 basiert. In der Anleitung von Synology ist Ubuntu 18.04 genannt, aber ich dachte mir “neuer wird schon passen”. Dann fand ich aber an verschiedenen Stellen Hinweise darauf dass es tatsächlich ein Ubuntu 18.04 sein muss.
Newer Ubuntu versions like 20.04.6 LTS and 22.04.4 LTS […] install an mdadm version that won’t work with DSM’s superblock location.
Also installierte ich Ubuntu 18.04 in einer VM, erzielte dort aber das gleiche Ergebnis wie direkt im Hostsystem, egal ob ich das USB-Gerät durchreichte oder das vom USB-Adapter präsentierte Gerät als Block Device an die VM durchreichte. An einer weiteren Stelle fand ich noch die Behauptung auch Ubuntu 18.04 sei schon zu neu, man müsse 16.04 benutzen. Also probierte ich auch das in einer VM, mit demselben Ergebnis.
Um den USB-Adapter als potentielle Fehlerquelle auszuschließen organisierte ich mir leihweise einen PC bei dem ich die Festplatten direkt via SATA anschließen konnte.
Ich installierte dort Ubuntu 18.04, und siehe da, ich kam ohne Probleme zu dem Punkt an dem sowohl das mdraid als auch die lvm-Volumes gefunden wurden:
root@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 5.5T 0 disk
├─sda1 8:1 0 2.4G 0 part
├─sda2 8:2 0 2G 0 part
└─sda5 8:5 0 5.5T 0 part
└─md2 9:2 0 5.5T 0 raid1
├─vg1-syno_vg_reserved_area 253:2 0 12M 0 lvm
└─vg1-volume_1 253:3 0 5.5T 0 lvm
sdb 8:16 0 2.7T 0 disk
├─sdb1 8:17 0 2.4G 0 part
├─sdb2 8:18 0 2G 0 part
└─sdb5 8:21 0 2.7T 0 part
└─md3 9:3 0 2.7T 0 raid1
├─vg2-syno_vg_reserved_area 253:0 0 12M 0 lvm
└─vg2-volume_2 253:1 0 2.7T 0 lvm
nvme0n1 259:0 0 465.8G 0 disk
├─nvme0n1p1 259:1 0 1M 0 part
└─nvme0n1p2 259:2 0 465.8G 0 part /Was allerdings immer noch nicht funktionierte war das Mounten der Volumes, hier bekam ich Fehlermeldungen vom btrfs.
root@ubuntu:~$ mount /dev/vg2/volume_2 /mnt/volume2
mount: /mnt/volume2: wrong fs type, bad option, bad superblock on /dev/mapper/vg2-volume_2, missing codepage or helper program, or other error.
root@ubuntu:~$ dmesg |tail
[ 135.889644] BTRFS critical (device dm-1): corrupt leaf: root=1 block=203603968 slot=15, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 135.889866] BTRFS critical (device dm-1): corrupt leaf: root=1 block=203603968 slot=15, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 135.889916] BTRFS warning (device dm-1): failed to read tree root
[ 135.941608] BTRFS error (device dm-1): open_ctree failed
[ 138.661973] BTRFS info (device dm-1): using free space tree
[ 138.661977] BTRFS info (device dm-1): has skinny extents
[ 138.666073] BTRFS critical (device dm-1): corrupt leaf: root=1 block=203603968 slot=15, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 138.666536] BTRFS critical (device dm-1): corrupt leaf: root=1 block=203603968 slot=15, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 138.666764] BTRFS warning (device dm-1): failed to read tree root
[ 138.717560] BTRFS error (device dm-1): open_ctree failed
Den entscheidenden Hinweis bekam ich dann in diesem Reddit-Thread: Irgendwann wurde ein Kernelpatch aufgenommen der einen Mount von btrfs-Volumes unter bestimmten Umständen verhindert. Die letzte Version des Kernels ohne diesen Patch für Ubuntu 16.04 und 18.04 ist demnach 4.15.0-108. Also konfigurierte ich Grub so dass ich die Möglichkeit bekomme beim Start einen Kernel auszuwählen:
# /etc/default/grub
#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5Dann installierte ich den gewünschten Kernel:
sudo apt install linux-image-4.15.0-108-generic
sudo reboot
Nach dem Boot in den richtigen Kernel wiederholte ich die Befehle aus dem KB-Artikel und siehe da, die Volumes ließen sich problemlos mounten. Auch das Mounten der mit ecryptfs verschlüsselten Shares funktionierte hinterher entsprechend der Anleitung.
