Dyskusja Utrata danych

[Moyrez]

Ratujcie !!! Ostatnio to jakaś czarna seria dopadła mojego Qnap'a. Problem tym razem wydaje się poważny bo utraciłem wszystkie foldery współdzielone, gdzie miałem wszystkie swoje dane (Multimedia i wszystkie w nim podfoldery a także, Download, Public itp.) Dostaje komunikat w ostrzeżeniach, że domyślne foldery dzielone nie istnieją i należy je odtworzyć bądź sformatować dysk. Podziało się to po nieoczekiwanym restarcie, gdy miałem uruchomiony backup danych w TimeMachine oraz kopiowanie danych na dysk USB. Po tym restarcie włączył się samoczynnie proces synchronizacji wolumenu i po jego zakończeniu foldery zniknęły :'(

 

[Moyrez]

/proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,size=64M)
none on /proc/bus/usb type usbfs (rw)
/dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)
/dev/md1 on /share/MD1_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl)
/dev/md13 on /mnt/ext type ext3 (rw,data=ordered)
tmpfs on /.eaccelerator.tmp type tmpfs (rw,size=32M)

done i co dalej?

A możesz mi zdradzić tak na przyszłość (odpukać) co to się podziało z tym ustrojstwem ?

Wszystkie problemy jak sięgam pamięcią zaczęły się od czasu update do QTS 4.0.5

 

[Silas Mariusz]

Odłącz i zatrzymaj macierz md1

umount /dev/md1            # odmountuj urzadzenie
mdadm -S /dev/md1          # zatrzymaj wolumin macierzy RAID

Złóż macierz RAID na nowo na podstawie urządzeń z poprzedniej konfiguracji (md1 w /proc/mdstat)

mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3

Proces składania macierzy zajmie trochę czasu, a więc nie wykonuj żadnych innych operacji na serwerze oraz nie wyłączaj go. Przebieg procesu będziesz mógł nadzorować mdadm lub z patrząc na status w mdstat

mdadm --detail /dev/md0
cat /proc/mdstat

Przyłącz macierz

mount /dev/md0 /share/MD0_DATA

Jak status?

 

[Moyrez]

Robię backup jeszcze, ale szczerze to chyba czasowo wyjdzie na to samo jak zapuszczę format i skonfiguruję całość od nowa

 

[Silas Mariusz]

Nie! Tak się nie dowiemy co było przyczyną.

Logi znajdują się na woluminie MD1.
Dlatego po ponownym przyłączeniu macierzy, wgraj QNAP Diagnostic Tool i wygeneruj dumpy. Zresetuj serwer NAS i po ponownym uruchomieniu wygeneruj dumpy drugi raz. Oba zrzuty logów wrzuć w załącznik...Jak status? Pamiętaj, że jest jeszcze QNAP Live Support, który zdalnie może naprawić Twój problem - a właściwie z tego co się dowiedziałem zrobić właśnie to co Ci napisałem

 

[Moyrez]

Jeszcze jade z backupem...

 

[kaktus]

W między czasie zapoznaj się z tym. ;-D

 

[Silas Mariusz]

To w między czasie zapytam... Czy miałeś może kiedyś uruchomione np. dwa woluminy RAID w serwerze?

 

[Moyrez]

Nic mi o tym nie wiadomo. Do czasu az zrobilem update do 4.0.5 wszystko chodzilo cacy a potem sie zaczelo od tego poprzedniego problemu jak nie można było odłączyć dysku do przeskanowania a wczoraj te zaginione dane.

 

[Silas Mariusz]

Zgrywasz już trochę te dane
... a tu się okaże, że macierz złoży się sukcesywnie w 3min

 

[Moyrez]

To jest ponad 2T to troche to trwa. Należe do osób, które JUŻ robią backupy

 

[Silas Mariusz]

To się ceni!

 

[Moyrez]

Poleciał proces składania macierzy. Zapuściłem też te dwa polecenia do sprawdzania statusy z tym, że nie wiem, w którym miejscu pokazuje ile jeszcze zostało do końca.
Tu jest to co wypluł system:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Fri Sep 27 18:35:39 2013
    Raid Level : raid1
    Array Size : 2928697536 (2793.02 GiB 2998.99 GB)
  Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB)
  Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sat Nov 23 19:00:58 2013
          State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
  Spare Devices : 0

          Name : 1
          UUID : 68adc8c3:a5b9b074:0c96302c:a9754530
        Events : 26274

    Number  Major  Minor  RaidDevice State
      2      8        3        0      active sync  /dev/sda3
      1      8      19        1      active sync  /dev/sdb3

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid1 sda3[2] sdb3[1]
      2928697536 blocks super 1.0 [2/2] [UU]
     
md256 : active raid1 sdb2[1] sda2[0]
      530112 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md13 : active raid1 sda4[0] sdb4[1]
      458880 blocks [2/2] [UU]
      bitmap: 0/57 pages [0KB], 4KB chunk

md9 : active raid1 sda1[0] sdb1[1]
      530048 blocks [2/2] [UU]
      bitmap: 0/65 pages [0KB], 4KB chunk

unused devices: <none>

 

[Silas Mariusz]

Ten wynik wskazuje przyłączone urządzenia do macierzy. Nie pozostaje Ci nic innego jak zrobić mount md0 pod MD0_DATA

 

[Moyrez]

to mamy jakiegoś liptona...

# mount /dev/md0 /share/MD0_DATA
mount: wrong fs type, bad option, bad superblock on /dev/md0,
      missing codepage or other error
      In some cases useful info is found in syslog - try
      dmesg | tail  or so

Dodatkowo obawiam się, że wszystkie dane poszły... siną w dal bo pod sftp ani pod md0_data ani pod md1_data nic nie ma :'(

 

[Silas Mariusz]

Żaden lipton... Linux się odezwał i jego system plików, który nie można zamontować bez wcześniejszego sprawdzenia po awarii (chyba).

e2fsck /dev/md0

 

[Moyrez]

# e2fsck /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
Volume1: clean, 539827/91525120 files, 306206002/732174384 blocks

i?

 

[Silas Mariusz]

mount

 

[Moyrez]

..i po mount:

# mount /dev/md0 /share/MD0_DATA
mount: wrong fs type, bad option, bad superblock on /dev/md0,
      missing codepage or other error
      In some cases useful info is found in syslog - try
      dmesg | tail  or so

 

[Silas Mariusz]

K... sorry... Zapomniałem... Nie można urządzenia mapować w lokalizację bez określenia formatu.

mount -t ext3 /dev/md0 /share/MD0_DATA

... lub dla ext4

mount -t ext4 /dev/md0 /share/MD0_DATA

I jak?

 

[Moyrez]

Poszło !!! QTS pokazuje mi, że volumen jest nieaktywny i nie mogę zainstalować QDT.
Robić restart?