Skip to content

Raid1 - Platte verschwunden!?

Verschoben Linux
  • Für die Raid-Experten unter Euch, das was ich hier aufgeschrieben habe ist absolutes Einsteigerwissen!

    An alle! Bitte nutzt das hier auf keinen Fall auf irgendeinem produktiven System. Holt Euch da lieber professionelle Hilfe!

    Hier mal was, was bei meiner ganzen Spielerei so alles passieren kann. Da ich ja über die Tage versucht habe, das NAS von mir auf ein Armbian zu bringen, ist mir dann irgendwann in meinem check_mk aufgefallen, das das RAID 1 nicht mehr gut aussieht 😞

    Ok, Ruhe bewahren. Ich hatte eben noch ein Backup mit Restic gemacht, also alles kein Problem. Dann schauen wir uns das mal an.

    Status

    So, habe ich das Raid 1 vorgefunden.

    rock64@rockpro64v_2_1:~$ sudo mdadm --detail /dev/md0 
    /dev/md0:
               Version : 1.2
         Creation Time : Sat Oct 20 09:05:51 2018
            Raid Level : raid1
            Array Size : 1953379392 (1862.89 GiB 2000.26 GB)
         Used Dev Size : 1953379392 (1862.89 GiB 2000.26 GB)
          Raid Devices : 2
         Total Devices : 1
           Persistence : Superblock is persistent
    
         Intent Bitmap : Internal
    
           Update Time : Wed Dec 26 13:59:23 2018
                 State : clean, degraded 
        Active Devices : 1
       Working Devices : 1
        Failed Devices : 0
         Spare Devices : 0
    
    Consistency Policy : bitmap
    
                  Name : rockpro64v_2_1:0  (local to host rockpro64v_2_1)
                  UUID : 33ac7964:473fe590:3682dd85:a979b336
                Events : 56050
    
        Number   Major   Minor   RaidDevice State
           0     252        0        0      active sync   /dev/dm-0
           -       0        0        1      removed
    

    Raid 1 besteht nur noch aus einer Platte. Irgendein Test hatte dann über einen fehlenden Superblock auf der ersten Platte gemeckert. Ok, schon mal ein Anhaltspunkt. Nach ein wenig Recherche, man ist ja kein Raidexperte 😉 , ging es dann an die Arbeit.

    Raid stoppen

    rock64@rockpro64v_2_1:~$ sudo mdadm --stop /dev/md0
    mdadm: stopped /dev/md0
    

    Superblock Nullen

    rock64@rockpro64v_2_1:~$ sudo mdadm --zero-superblock /dev/mapper/raid_pool0
    

    Raid 1 wieder starten

     rock64@rockpro64v_2_1:~$ sudo mdadm --assemble --scan
     mdadm: /dev/md/0 has been started with 1 drive (out of 2).
    

    Zustand

    rock64@rockpro64v_2_1:~$ cat /proc/mdstat 
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
    md0 : active (auto-read-only) raid1 dm-1[1]
          1953379392 blocks super 1.2 [2/1] [_U]
          bitmap: 5/15 pages [20KB], 65536KB chunk
    
    unused devices: <none>
    

    Laufwerk wieder hinzufügen

    rock64@rockpro64v_2_1:~$ sudo mdadm --add /dev/md0 /dev/mapper/raid_pool0
    mdadm: added /dev/mapper/raid_pool0
    

    Danach syncen die Laufwerke - das kann dauern!

    rock64@rockpro64v_2_1:~$ watch cat /proc/mdstat
    

    3c04ad4e-f663-4f2f-af31-b63c8e44d553-grafik.png

    Ob es klappt? Keine Ahnung - lassen wir uns überraschen!

    Ca. 10 Stunden später war der Sync angeschlossen. So konnte ich heute Morgen nachschauen, ob ich auch die richtige Platte erwischt hatte. So, mal vorsichtig nachschauen.

    root@rockpro64_NAS:~# cat /proc/mdstat 
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
    md0 : active raid1 dm-1[1] dm-0[2]
          1953379392 blocks super 1.2 [2/2] [UU]
          bitmap: 0/15 pages [0KB], 65536KB chunk
    
    unused devices: <none>
    root@rockpro64_NAS:~# mdadm --detail /dev/md0 
    /dev/md0:
            Version : 1.2
      Creation Time : Sat Oct 20 07:05:51 2018
         Raid Level : raid1
         Array Size : 1953379392 (1862.89 GiB 2000.26 GB)
      Used Dev Size : 1953379392 (1862.89 GiB 2000.26 GB)
       Raid Devices : 2
      Total Devices : 2
        Persistence : Superblock is persistent
    
      Intent Bitmap : Internal
    
        Update Time : Thu Dec 27 06:57:26 2018
              State : clean 
     Active Devices : 2
    Working Devices : 2
     Failed Devices : 0
      Spare Devices : 0
    
               Name : rockpro64v_2_1:0
               UUID : 33ac7964:473fe590:3682dd85:a979b336
             Events : 57882
    
        Number   Major   Minor   RaidDevice State
           2     253        0        0      active sync   /dev/dm-0
           1     253        1        1      active sync   /dev/dm-1
    root@rockpro64_NAS:~# 
    

    Sieht gut aus, der Zustand ist wieder clean. Nicht über den anderen Benutzer wundern, ich habe mittlerweile wieder auf Armbian gewechselt. Im Moment sieht alles wieder gut aus, ich werde da die nächsten Tage aber mal ein Auge drauf haben. Die Frage warum das passiert ist?

    Ich denke, das ich was falsch gemacht habe, wie ich das erste mal Armbian genutzt habe. Dort gibt es ja am Anfang kein Device md0.

    Ich hatte wohl ein

    mdadm --assemble md0 /dev/sda1 /dev/sdb1
    

    gemacht. Dabei hatte ich wohl eine falsche Platte erwischt. Durch die USB3-Platte ist da was durcheinander gekommen. ABER, das ist alles reine Spekulation, genau weiß ich das nicht mehr.

    Man muss das mit

     mdadm --assemble --scan 
    

    machen.

    Zum Schluss

    An einem Raid 1 rumzuspielen ist kein Vergnügen 🙂 Das dauert alles so lange und man weiß vorher nicht immer ob es auch klappt (also ich).

    Wer gravierende Fehler feststellt, bitte in die Kommentare damit ich das entsprechend ändern kann. DANKE!

    Die /dev/mapper/ Devices die ich benutze kommen davon, das die HDDs verschlüsselt sich. Bei einem unverschlüsselten System nutzt man dann halt die normalen Device Bezeichnungen!

  • Debian Bookworm 12.9 released

    Verschoben Linux
    1
    0 Stimmen
    1 Beiträge
    211 Aufrufe
    Niemand hat geantwortet
  • Rest-Server Version 0.12.1 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    105 Aufrufe
    Niemand hat geantwortet
  • 2,5G

    Linux
    2
    1
    0 Stimmen
    2 Beiträge
    163 Aufrufe
    FrankMF
    Gutes Video zum Zyxel Switch, was ich vorher gar nicht kannte. Hätte meine Entscheidung aber auch nicht verändert. https://www.youtube.com/watch?v=59I-RlliRms
  • ZFS - Wichtige Befehle

    Linux
    2
    0 Stimmen
    2 Beiträge
    743 Aufrufe
    FrankMF
    Unter dem Beitrag sammel ich mal ein paar Beispiele, für mich zum Nachlesen Den Anfang macht die ZFS-Replication Ich hatte Am Anfang ein wenig Verständnisprobleme, bis es klar war, das diese Replication von Pool zu Pool funktioniert. Also brauchen wir zwei vorhandene ZFS-Pools. root@pbs:/mnt/datastore/datapool/test# zfs list NAME USED AVAIL REFER MOUNTPOINT Backup_Home 222G 677G 222G /mnt/datastore/Backup_Home datapool 2.36G 1.75T 2.36G /mnt/datastore/datapool Wir erzeugen ein Dataset im datapool zfs create datapool/docs -o mountpoint=/docs Wir erzeugen eine Datei mit Inhalt echo "version 1" > /docs/data.txt Wir erzeugen einen Snapshot zfs snapshot datapool/docs@today Kontrolle root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 0B - 96K - Wir replizieren den vorhandenen Snapshot zum ZFS-Pool Backup_Home und speichern ihn da im Dataset test. zfs send datapool/docs@today | zfs receive Backup_Home/test Nun befinden sich die Daten in dem anderen ZFS-Pool root@pbs:/mnt/datastore/datapool/test# ls /mnt/datastore/Backup_Home/test/ data.txt Und was mich am meisten interessiert, ist wie man das zu einem anderen Server schickt zfs send datapool/docs@today | ssh otherserver zfs receive backuppool/backup Den Test reiche ich dann später nach. Quelle: https://www.howtoforge.com/tutorial/how-to-use-snapshots-clones-and-replication-in-zfs-on-linux/ ZFS inkrementelle Replication Als, nur die geänderten Daten senden! Wir erzeugen ein paar Dateien root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data1.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data2.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data3.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data4.txt Neuer Snapshot zfs snapshot datapool/docs@17:02 Liste der Snapshots root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 56K - 96K - datapool/docs@17:02 0B - 112K - Wir senden dieinkrementelle Replication zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K cannot receive incremental stream: destination Backup_Home/test has been modified since most recent snapshot Dazu schreibt die Anleitung, die ich unten verlinkt habe, das die Daten verändert wurden. Warum, verstehe ich aktuell noch nicht. Mit -F im send Befehl erzwingt man einen Rollback zum letzten Snapshot. zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive -F Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K Und Kontrolle ls /mnt/datastore/Backup_Home/test/ data1.txt data2.txt data3.txt data4.txt data.txt Quelle: https://klarasystems.com/articles/introduction-to-zfs-replication/
  • Kopia 0.7.0-rc1 Kurztest

    Kopia
    2
    2
    0 Stimmen
    2 Beiträge
    350 Aufrufe
    FrankMF
    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt. I guess you could run it in the cloud but latency will be progressively worse because it's a chatty protocol sensitive to latency Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden. Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.
  • Kopia 0.7.x released

    Kopia
    1
    0 Stimmen
    1 Beiträge
    233 Aufrufe
    Niemand hat geantwortet
  • NAS - Cups & Sane

    Linux
    1
    0 Stimmen
    1 Beiträge
    495 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Upgrade auf v1.9.0

    NodeBB
    2
    1
    0 Stimmen
    2 Beiträge
    867 Aufrufe
    FrankMF
    Da oben fehlt ein Schritt. cd nodebb (or path to where nodebb is installed) ./nodebb stop git fetch git checkout v1.12.x git merge origin/v1.12.x ./nodebb upgrade Beim nächsten Upgrade testen.