Synology btrfs recovery

[devilkin]

Hoi,

Deze nacht vond m'n nas het nodig me wakker te maken met de melding "Volume1 has crashed".
Eerst dacht ik dat het aan de schijven zou liggen, maar die zijn allemaal nog in orde (smart test OK, geen reconnects, geen read errors)

Voor zover ik kan zien is het btrfs volume z'n pedalen kwijt geraakt. Ik kan hier en daar nog aan iets van data, maar de merendeel krijg ik fouten op.
De recovery tools op de NAS zelf gebruiken lukt niet gezien /volume1 mounted blijft, en er een of ander proces nog dat volume in gebruik heeft.

Iemand enige ervaring met recovery via een desktop pc van een btrfs volume - eer ik m'n desktop sloop op er de 4 schijven in te hangen?

[Ordon]

Images maken van de NAS disken en aan de slag met (kopieën) van deze images lijkt mij het veiligst.
Zelf heb ik geen Synology.
Wel met ReadyNAS OS gezien dat het allemaal niet zo "standaard" was. Oppassen dus!
Met images kan je uitvlooien hoe het precies zit, zonder onomkeerbare schade te veroorzaken.

PS Zelfs indien de S.M.A.R.T. gegevens OK zijn, kan er toch een probleem zijn met één of meerdere sectoren. Grondige en volledige disk surface analysis van de "gecrashte" HDD is meer dan aangewezen. Reparatie is vaak mogelijk ("grown defect list" in firmware).

[rapidgorgon]

Staat er in de SMART informatie ook niets bij 'reallocated sector count' of 'current pending sector'? Van wat ik begrijp uit de Synology documentatie, zou een array pas als "crashed" mogen aangeduid worden als data onleesbaar is. Met btrfs weet je zelfs bij RAID1 welk blok correct is, en welk slecht, als één van de schijven leesfouten geeft. Eén voorwaarde hiervoor, is dat het (sub)volume niet gemount is met de opties nodatacow of nodatasum, wat bij Synology omgekeerd geïmplementeerd wordt; als ik de documentatie correct interpreteer. Als die optie niet aanstaat, verlies je wel een van de beste features van btrfs, dus ik mag hopen dat deze standaard ingeschakeld is...

Zelf zou ik smartcl smartctl gebruiken voor de SMART info, en btrfs scrub om fouten te vinden en te herstellen. Geen idee of je hier toegang tot hebt (evt. via SSH) op een Synology NAS. Heb je eventueel een pc met Linux waarop je deze schijven (of images ervan) kan aansluiten? Desnoods kan je hiervoor ook een live image draaien (Arch, Fedora, Ubuntu, Debian...)

[devilkin]

Nope. Die metrics staan beide nog op 0 voor alle disks.
Reconnection count is ook 0 - wat meestal op disks issues duidt.

Momenteel is er nog een smart extended scan aan het lopen. Nadien ga ik eens zien of ik die scrub via cmdline kan in gang zetten. Via de web interface is het no go.

Ik zie wel massa's checksum errors in de logs :/

[Ordon]

MHDD gebruik ik nogal eens om "slechte plekken" op een SATA disk te vinden.
Typisch zitten deze sectoren boven 100ms en worden OK bevonden door S.M.A.R.T. ...
Dat is om problemen vragen natuurlijk.
Het zijn typisch sectoren die voor intermitterende problemen zorgen en moeilijk op te sporen met de reguliere tools.
Een tijdje hameren op deze sectoren en ze verdwijnen in de grown defects list in de firmware(!) van de HDD en zijn niet zichtbaar in de S.M.A.R.T. gegevens.
Dat laatste is destructief voor de gegevens maar de HDD gaat vaak nog erg lang mee (vele duizenden uren en meer).
Ter controle kunnen een cyclus of vier, vijf van badblocks de gemoedsrust ten goede komen.

PS Kan ook via bootable USB stick (DOS). Dat is makkelijker om de log bestanden op te slaan en config parameters aan te passen.

[devilkin]

Nu, bad sectors zou ik ook moeten zien in Linux dat er een retry gebeurd, en dat zie ik niet. Maar verdere dingen gaan sowieso pas kunnen als ik de schijven in m'n desktop hang.

Sent from my ONEPLUS A6003 using Tapatalk

[Ordon]

Die "slechte" sectoren (feitelijk half slecht) zijn nog goed genoeg om "een" waarde van te lezen zonder foutmelding in het OS.
Maar niet noodzakelijk "de" waarde...
Dat is de merde van deze sectoren.
Btrfs zou dat in theorie moeten kunnen ondervangen. Maar als nodatasum al niet opstaat...

Een loopje om specifiek veelvuldig op deze specifieke sectoren te schrijven en ze verdwijnen (door firmware van de disk).
Want bij schrijven vallen ze écht door de mand.

[devilkin]

Reply van Synology:

Thank you for contacting our support,

Unfortunately it will not be possible to repair a volume that has crashed. the only solution will be to back up your data and then erase the crashed volume (as erasing a volume means all your data will be erased) and recreate a new healthy one, on which you will then be able to re-transfer all the backed up data.

So if you still have access to your data, we will suggest you to back them up as soon as possible, and then proceed to the recreation of a new volume.

Nog eens doorgevraagd naar een onderliggende reden. Synology / BTRFS is nu wel behoorlijk hard gedaald in m'n achting, als ik eerlijk ben. Ik ga perfect akkoord dat een NAS geen backups is (3rd party backups blijven nodig), maar een volume dat zichzelf gewoon even gaat corrupt maken... pf.

[deman]

Terwijl ik dit lees breekt het angstzweet mij uit.
Heb 7 schijven in Btrfs staan. Die lopen al 2 jaar zonder problemen.
Mocht daar ooit iets mee gebeuren

[rapidgorgon]

Ik draai zelf toch al enkele jaren btrfs RAID1 systemen waar ik nog geen enkel probleem mee heb gehad. Het heeft me zelfs erg geholpen met een falende WD red die soms wel, soms niet (zoals Ordon ook al zei) leesfouten geeft. N=1 natuurlijk, als ik enkel naar mezelf kijk, maar zeker RAID1(0) zou betrouwbaar moeten zijn met btrfs. Synology gebruikt wel een oude kernel (3.10.105) en een oudere versie van btrfs-progs (4.0). Ik weet wel niet hoeveel verbeteringen ze zelf backporten.

Het voordeel van btrfs scrub is dat het online kan/moet gebeuren. Je kan dus op je NAS btrfs scrub start /volume1 draaien en zien wat dat geeft. Als dit volume natuurlijk altijd gemount was met nodatacow/nodatasum, dan zal het vermoedelijk kwestie zijn van redden wat er te redden valt. Kijk eventueel ook eens naar btrfs rescue/check/restore.

Mocht het een RAID5/RAID6 btrfs array betreffen, gebruik je best een zo recent mogelijk kernel (en btrfs-progs). Maar aangezien dit nog nergens echt wordt aangeraden als je data je lief is, vermoed ik dat je array veel eerder RAID1 of RAID10 zal zijn.

[MrBlueSky]

In het verleden hadden we op het werk in een lab omgeving een Synology NAS draaien, eveneens met BTRFS. Elke dag, ergens in de ochtend, werden logfiles van verschillende devices weggeschreven naar die NAS. Dus er was geen constante hoge load. Enkel 's ochtends wat.

Vorig jaar was BTRFS ook op de fles gegaan, en een hele schijf was corrupt. Ook hier: hardwarematig alles in orde, maar data kon niet meer gered worden.

We hadden wel backups, en het is ook maar een lab omgeving, dus geen drama. Maar sinds die miserie met BTRFS gebruiken we dit filesysteem niet meer...

[devilkin]

Mocht het een RAID5/RAID6 btrfs array betreffen, gebruik je best een zo recent mogelijk kernel (en btrfs-progs). Maar aangezien dit nog nergens echt wordt aangeraden als je data je lief is, vermoed ik dat je array veel eerder RAID1 of RAID10 zal zijn.

Ik heb het met een RAID5 (SHR-1) array draaien. mdraid geeft geen fouten aan. Ik was verder nog eens aan't graven, en was nog wel dit tegengekomen in m'n logs

Code: Selecteer alles

2020-04-19T03:03:59+02:00 cube kernel: [949363.329504] BTRFS warning (device dm-0): csum failed ino 4159194 off 29360128 csum 3093891149 expected csum 0 
2020-04-19T03:03:59+02:00 cube kernel: [949363.355914] Result: hostbyte=0x00 driverbyte=0x08 
2020-04-19T03:03:59+02:00 cube kernel: [949363.365007] Sense Key : 0x2 [current] 
2020-04-19T03:03:59+02:00 cube kernel: [949363.373036] ASC=0x8 ASCQ=0x0 
2020-04-19T03:03:59+02:00 cube kernel: [949363.380470] cdb[0]=0x2a: 2a 00 00 10 00 48 00 00 10 00 
2020-04-19T03:03:59+02:00 cube kernel: [949363.386372] end_request: I/O error, dev isda, sector in range 1048576 + 0-2(12) 
2020-04-19T03:03:59+02:00 cube kernel: [949363.394679] Aborting journal on device isda-8.

welke waarschijnlijk de culprit is... Straks eens badblocks loslaten op die schijven, mhdd krijg ik niet deftig aan de waggel

Ondertussen hangen de schijven in m'n desktop, daar eens geprobeerd met een recente kernel/btrfstools:

Code: Selecteer alles

# btrfs check --b /dev/mapper/vg1000-lv 
Opening filesystem to check...
Checking filesystem on /dev/mapper/vg1000-lv
UUID: 35c3da8a-3efc-414e-a106-06a3fddd1fbe
[1/7] checking root items
parent transid verify failed on 9652607303680 wanted 3894840 found 3894821
parent transid verify failed on 9652607303680 wanted 3894840 found 3894821
parent transid verify failed on 9652607303680 wanted 3894840 found 3894821
Ignoring transid failure
parent transid verify failed on 9652607483904 wanted 3894840 found 3894788
parent transid verify failed on 9652607483904 wanted 3894840 found 3894788
parent transid verify failed on 9652607483904 wanted 3894840 found 3894788
Ignoring transid failure
parent transid verify failed on 9652607516672 wanted 3894840 found 3894821
parent transid verify failed on 9652607516672 wanted 3894840 found 3894821
parent transid verify failed on 9652607516672 wanted 3894840 found 3894821
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=49233920 item=107 parent level=1 child level=1
ERROR: failed to repair root items: Input/output error

Nog wat verder aan het graven in de logs kwam ik deze tegen, net voor de crash:

Code: Selecteer alles

2020-04-19T03:01:47+02:00 cube kernel: [949231.381433] ata1: device unplugged sstatus 0x0
2020-04-19T03:01:47+02:00 cube kernel: [949231.386516] ata2: device unplugged sstatus 0x0
2020-04-19T03:01:47+02:00 cube kernel: [949231.391616] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozen
2020-04-19T03:01:47+02:00 cube kernel: [949231.391779] ata4: device unplugged sstatus 0x0
2020-04-19T03:01:47+02:00 cube kernel: [949231.391802] ata4.00: exception Emask 0x10 SAct 0x0 SErr 0x190002 action 0xe frozen
2020-04-19T03:01:47+02:00 cube kernel: [949231.391804] ata4.00: irq_stat 0x80400000, PHY RDY changed
2020-04-19T03:01:47+02:00 cube kernel: [949231.391806] ata4: SError: { RecovComm PHYRdyChg 10B8B Dispar }
2020-04-19T03:01:47+02:00 cube kernel: [949231.391809] ata4.00: failed command: FLUSH CACHE EXT
2020-04-19T03:01:47+02:00 cube kernel: [949231.391814] ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 27
2020-04-19T03:01:47+02:00 cube kernel: [949231.391814]          res 50/00:00:00:78:a3/00:00:61:01:00/e0 Emask 0x10 (ATA bus error)
2020-04-19T03:01:47+02:00 cube kernel: [949231.391815] ata4.00: status: { DRDY }
2020-04-19T03:01:47+02:00 cube kernel: [949231.391826] ata4: hard resetting link
2020-04-19T03:01:47+02:00 cube kernel: [949231.392025] ata3: device unplugged sstatus 0x0
2020-04-19T03:01:47+02:00 cube kernel: [949231.392051] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x190002 action 0xe frozen
2020-04-19T03:01:47+02:00 cube kernel: [949231.392052] ata3.00: irq_stat 0x80400000, PHY RDY changed
2020-04-19T03:01:47+02:00 cube kernel: [949231.392054] ata3: SError: { RecovComm PHYRdyChg 10B8B Dispar }
2020-04-19T03:01:47+02:00 cube kernel: [949231.392056] ata3.00: failed command: FLUSH CACHE EXT
2020-04-19T03:01:47+02:00 cube kernel: [949231.392061] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 30
2020-04-19T03:01:47+02:00 cube kernel: [949231.392061]          res 50/00:00:80:22:9e/00:00:61:01:00/e0 Emask 0x10 (ATA bus error)
2020-04-19T03:01:47+02:00 cube kernel: [949231.392062] ata3.00: status: { DRDY }
2020-04-19T03:01:47+02:00 cube kernel: [949231.392067] ata3: hard resetting link
2020-04-19T03:01:47+02:00 cube kernel: [949231.513708] ata2.00: irq_stat 0x00400040, connection status changed
2020-04-19T03:01:47+02:00 cube kernel: [949231.520817] ata2: SError: { PHYRdyChg 10B8B DevExch }
2020-04-19T03:01:47+02:00 cube kernel: [949231.526569] ata2.00: failed command: FLUSH CACHE EXT
2020-04-19T03:01:47+02:00 cube kernel: [949231.532225] ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 2
2020-04-19T03:01:47+02:00 cube kernel: [949231.532225]          res 50/00:00:80:44:db/00:00:32:00:00/e0 Emask 0x10 (ATA bus error)
2020-04-19T03:01:47+02:00 cube kernel: [949231.548262] ata2.00: status: { DRDY }
2020-04-19T03:01:47+02:00 cube kernel: [949231.552469] ata2: hard resetting link
2020-04-19T03:01:47+02:00 cube kernel: [949231.556733] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozen
2020-04-19T03:01:47+02:00 cube kernel: [949231.565436] ata1.00: irq_stat 0x00400040, connection status changed
2020-04-19T03:01:47+02:00 cube kernel: [949231.572551] ata1: SError: { PHYRdyChg 10B8B DevExch }
2020-04-19T03:01:47+02:00 cube kernel: [949231.578300] ata1.00: failed command: FLUSH CACHE EXT
2020-04-19T03:01:47+02:00 cube kernel: [949231.583958] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 21
2020-04-19T03:01:47+02:00 cube kernel: [949231.583958]          res 50/00:00:00:78:a3/00:00:61:01:00/e0 Emask 0x10 (ATA bus error)
2020-04-19T03:01:47+02:00 cube kernel: [949231.600110] ata1.00: status: { DRDY }
2020-04-19T03:01:47+02:00 cube kernel: [949231.604321] ata1: hard resetting link
2020-04-19T03:01:52+02:00 cube kernel: [949236.613438] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
2020-04-19T03:01:52+02:00 cube kernel: [949236.770796] ata2.00: retrying FLUSH 0xea Emask 0x10
2020-04-19T03:01:52+02:00 cube kernel: [949236.776460] ata2.00: Write Cache is enabled
2020-04-19T03:01:52+02:00 cube kernel: [949236.877426] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
2020-04-19T03:01:53+02:00 cube kernel: [949237.029855] ata1.00: retrying FLUSH 0xea Emask 0x10
2020-04-19T03:01:53+02:00 cube kernel: [949237.035533] ata1.00: device reported invalid CHS sector 0
2020-04-19T03:01:53+02:00 cube kernel: [949237.041725] ata1.00: Write Cache is enabled
2020-04-19T03:01:53+02:00 cube kernel: [949237.046431] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
2020-04-19T03:01:53+02:00 cube kernel: [949237.054164] ata3.00: retrying FLUSH 0xea Emask 0x10
2020-04-19T03:01:53+02:00 cube kernel: [949237.067398] ata3.00: Write Cache is enabled
2020-04-19T03:01:53+02:00 cube kernel: [949237.144425] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
2020-04-19T03:01:53+02:00 cube kernel: [949237.157638] ata4.00: retrying FLUSH 0xea Emask 0x10
2020-04-19T03:01:53+02:00 cube kernel: [949237.163315] ata4.00: device reported invalid CHS sector 0
2020-04-19T03:01:53+02:00 cube kernel: [949237.169483] ata4.00: Write Cache is enabled

Wat hier juist gaande was........ 4 schijven disconnecten op het zelfde moment?!

[rapidgorgon]

Als ik het zo zie, gebruikt Synology SHR geen btrfs RAID, maar btrfs bovenop LVM RAID.

In dit geval kan btrfs gebruikt worden voor snapshots, copy-on-write gedrag, etc., maar is LVM dus verantwoordelijk voor de RAID. Dit betekent ook dat btrfs geen weet heeft van de verschillende redundante schijven en dus ook geen bestanden met slechte checksums kan herstellen met een scrub. Je bestanden beschermen tegen bit-rot en slechte sectoren is geheel de verantwoordelijkheid van LVM, dus dan moet je daar kijken of een scrub iets oplevert.

Met die vier schijven die tegelijk disconnecten, zou ik bijna durven denken dat het probleem niet zozeer bij (een van) de schijven zelf ligt, maar andere hardware van de NAS.

[devilkin]

Met die vier schijven die tegelijk disconnecten, zou ik bijna durven denken dat het probleem niet zozeer bij (een van) de schijven zelf ligt, maar andere hardware van de NAS.

Ik ben er vrij zeker van. Ik ga de badblocks nu wel laten lopen, maar m'n ticket naar syno is al aangevuld.

EDIT: reply van Synology, nas issue, wordt vervangen in garantie.

[bitbite]

Als ik het zo zie, gebruikt Synology SHR geen btrfs RAID, maar btrfs bovenop LVM RAID.

Dat maakt de zaak wel anders denk ik. Misschien dat de LVM raid altijd de disk met bitrot naar voor brengt?
Misschien dat je rechtstreeks de disken onder LVM (de PV's dus) kan lezen/imagen, en/of eens één voor één uit de array halen?

[rapidgorgon]

EDIT: reply van Synology, nas issue, wordt vervangen in garantie.

Nog goed dat je die logs gevonden hebt!

De schijven zijn er waarschijnlijk op een slecht moment uitgeknald, waardoor je nu met een corrupt FS zit
Hopelijk kan LVM het nog redden. Met onderstaand commando kan je (niet-destructief) controleren of de logical volume nog okee is:

Code: Selecteer alles

Volume check starten:
# lvchange --syncaction check vg1000/lv
Voortgang bekijken:
# lvs vg1000/lv

lvs geeft je in de kolom "Cpy%Sync" dan aan hoeveel er al gecontroleerd is. De resultaten van deze check komen ook in de kernel logs.

[devilkin]

Kan ik eens bekijken als de badblock scan afgelopen is. Alleszinds vrees ik er een beetje voor.

[Jelly]

Over welk model van Synology NAS gaat het?

Mvg

[devilkin]

Code: Selecteer alles

Volume check starten:
# lvchange --syncaction check vg1000/lv
Voortgang bekijken:
# lvs vg1000/lv

lvs geeft je in de kolom "Cpy%Sync" dan aan hoeveel er al gecontroleerd is. De resultaten van deze check komen ook in de kernel logs.

Code: Selecteer alles

# lvchange --syncaction check vg1000/lv
  Command on LV vg1000/lv does not accept LV type linear.
  Command not permitted on LV vg1000/lv.

Over welk model van Synology NAS gaat het?

DS916+

[mailracer]

kan ik begrijpen dat er een hardware probleem was, waardoor 4 schijven eruit zijn gegaan, je cache niet is weggeschreven, en hierdoor je volume corrupt is gegaan ?

[devilkin]

Yep.

Het feit van de disconnect van de vier schijven heb ik pas ontdekt na het doorspitten van een aantal MB aan logs, gezien dat .. een falende btrfs nogal spammy is

Ik had er bij de eerste check ook volledig overgekeken - het is nu niet iets dat ik verwacht dat gebeurd na 3j.

[rapidgorgon]

Code: Selecteer alles

# lvchange --syncaction check vg1000/lv
  Command on LV vg1000/lv does not accept LV type linear.
  Command not permitted on LV vg1000/lv.

Jammer genoeg heb ik nu ook niet zoveel ervaring met LVM (op Synology NASen) dat ik hier meteen een antwoord op heb. Je kan anders een proberen om wat meer details over je layout te weten te komen, om zo te zien waar die RAID5 juist zit.

Code: Selecteer alles

lvs -a -o+lv_layout,lv_role,stripes,devices
cat /proc/mdstat

Als ik even naar een van onze Synology's met SHR kijk, dan is dat ext4 op lvm op mdraid. Een scrub van een mdraid-array kan je als volgt doen:

Code: Selecteer alles

echo check > /sys/block/md0/md/sync_action