Synology volume crash

[vespino]

Ik heb een Synology 1817+ waarvan donderdag het volume is gecrashed. Ik ben hierover in contact met Synology, maar gezien het weekend gaat dit nog even duren en ik word een beetje onrustig. Mijn Synology host een aantal mappen (sommige versleuteld, enkele niet) en een vijftal VMMs. Toen het voorval zich voordeed, heb ik mijn Synology opnieuw opgestart in de hoop dat het euvel zich zou verhelpen, echter kan ik sindsdien niet meer bij de versleutelde bestanden. Inmiddels ben ik de gehele toegang (web en SSH) kwijt en ben ik alleen nog maar de niet versleutelde bestanden aan het overzetten via SCP naar een externe schijf. Het apparaat is readonly op het moment.

Iemand hier ervaring mee en tips wat te doen? Ik heb al contact opgenomen met een data recovery service, echter wil ik alle opties onderzoeken om z.s.m. weer online te zijn. Ik heb backups van enkele van de belangrijkste versleutelde mappen in STACK staan, echter zijn deze uiteraard versleuteld en alleen te benaderen via Hyper Backup, een programma dat ik nu dus niet kan benaderen.

Enkele ideeën die ik had:
- Niet versleutelde informatie via SCP overzetten > nu mee bezig, duurt nog "eventjes"
- Versleutelde informatie uploaden naar een externe server > niet gelukt omdat die server aangaf vol te zijn
- Een reset met behoud van data, hopende dat ik daarna nog bij de ruwe bestanden kan
- Professionele recovery, onderzoek 500€, herstel 750-3000€

Maar wilde toch nog even informeren of er hier iemand is die met die euvel te maken heeft gehad en tips heeft. Als mijn download van de niet versleutelde informatie compleet is, zal ik het apparaat nog een keer booten in de hoop er dan weer met SSH in te kunnen. Tot die tijd blijf ik overal van af.

[DukeBox]

Je hebt Synology Hyper Backup Explorer

"Een bureaubladtool voor bladeren, decoderen en uitpakken van verschillende back-upgegevensversies in Hyper Backup-opslagplaatsen."

zie: https://www.synology.com/...ownload/DS1817+#utilities

Met je decryptie keys kan je daarmee ook restoren.

[SambalBij]

Eventueel ergens snel een andere Synology vandaan halen, Hyperbackup daar weer op zetten, en daar alvast die folders vanuit die STACK naar terug restoren?

(Er tenminste vanuit gaande dat dat gewoon kan qua encryptie? Je offsite backup zal neem ik aan niet alleen maar afhankelijk zijn van de keys die op de bestaande Synology staan, omdat anders die backup alsnog zinloos zou zijn?)

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 11:26:
Je hebt Synology Hyper Backup Explorer

[...]

zie: https://www.synology.com/...ownload/DS1817+#utilities

Met je decryptie keys kan je daarmee ook restoren.

Thanks, daarmee kan ik hopelijk al wat belangrijke data herstellen. VMMs zijn echter nog belangrijker.

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 11:40:
VMMs zijn echter nog belangrijker.

Hoe had je ie opgeslagen/toegewezen ?

Je gaf aan dat je er met SCP bij kan, dan zou SSH dus ook moeten werken, met rsync kan je dan een stukje
sneller data overzetten.

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 11:46:
[...]

Hoe had je ie opgeslagen/toegewezen ?

Je gaf aan dat je er met SCP bij kan, dan zou SSH dus ook moeten werken, met rsync kan je dan een stukje
sneller data overzetten.

Hoe bedoel je "toegewezen"? Synology heeft een eigen Virtual Machine tool die ik al een tijd gebruik.

Ik heb gisteravond met WinSCP verbinding kunnen maken en een download gestart van alle niet versleutelde data. Ook had ik een SSH sessie open staan, maar op dit moment kan ik daarmee (en dus ook de web interface) geen verbinding meer maken.

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 12:11:
Hoe bedoel je "toegewezen"? Synology heeft een eigen Virtual Machine tool die ik al een tijd gebruik.

Is er een direct attached volume of heb je een virtual volume ?

Ook had ik een SSH sessie open staan, maar op dit moment kan ik daarmee (en dus ook de web interface) geen verbinding meer maken.

SSH en HTTP(S) zijn op zich niet gerelateerd aan elkaar, dit zijn 2 losse services.

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 12:21:
[...]

Is er een direct attached volume of heb je een virtual volume ?

[...]

SSH en HTTP(S) zijn op zich niet gerelateerd aan elkaar, dit zijn 2 losse services.

Het is één volume waarop Synology zijn gegevens (shares, apps, etc) opslaat.

Misschien is de firewall ingesprongen door teveel connecties of zo? Kan het apparaat nog wel pingen, en SCP kopie loopt nog steeds (al 18 uur+), maar SSH en HTTPS werken dus niet. Wel vreemd natuurlijk aangezien SCP ook over SSH loopt, maar misschien was dat een verbonden sessie en doet ie daar niet moeilijk over?

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 12:24:
Het is één volume waarop Synology zijn gegevens (shares, apps, etc) opslaat.

Dan zou je de VM's moeten kunnen vinden onder /volume1/@iSCSI/LUN/VDISK_BLUN/

SCP ook over SSH loopt, maar misschien was dat een verbonden sessie en doet ie daar niet moeilijk over?

Firewall zou kunnen, dus wees dan nu maar 'zuinig' op de werkende SSH sessie
Als je daar mee klaar bent kan je wel weer een stapje verder met proberen.

Uit hoeveel HDD's bestaat je array ? Als je een vaste pc hebt met genoeg aansluitingen kan je daar ook altijd je array aan hangen om te recoveren. Meermaals gedaan.

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 13:44:
[...]

Dan zou je de VM's moeten kunnen vinden onder /volume1/@iSCSI/LUN/VDISK_BLUN/

[...]

Firewall zou kunnen, dus wees dan nu maar 'zuinig' op de werkende SSH sessie
Als je daar mee klaar bent kan je wel weer een stapje verder met proberen.

Uit hoeveel HDD's bestaat je array ? Als je een vaste pc hebt met genoeg aansluitingen kan je daar ook altijd je array aan hangen om te recoveren. Meermaals gedaan.

Die directory had ik inderdaad al gevonden, maar daarin staan loeigrote bestanden, 512gb. Bovendien kreeg ik ze niet veiliggesteld. Maar stel het lukt, wat dan?

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 13:49:
Bovendien kreeg ik ze niet veiliggesteld. Maar stel het lukt, wat dan?

Waarom lukt dat niet ? Dat is de 'virtuele HDD' van je VM, hiermee kan je een weer restoren.

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 13:58:
[...]

Waarom lukt dat niet ? Dat is de 'virtuele HDD' van je VM, hiermee kan je een weer restoren.

Kon ze niet uploaden naar een andere server en een usb schijf werd niet herkend.

Is het een kwestie van ze in dezelfde map terugzetten en herkent VMM ze dan?

[ Voor 11% gewijzigd door vespino op 06-06-2020 14:07 ]

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 14:06:
Is het een kwestie van ze in dezelfde map terugzetten en herkent VMM ze dan?

Nee, je moet ze restoren/importeren. Andere optie is een nieuwe VM aanmaken met dezelfde specs (voornamelijk HDD grootte) en deze er dan overheen zetten.

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 14:09:
[...]

Nee, je moet ze restoren/importeren. Andere optie is een nieuwe VM aanmaken met dezelfde specs (voornamelijk HDD grootte) en deze er dan overheen zetten.

Importeren lijkt me alleen kunnen met een .ova bestand. Die heb ik, echter van uch geleden. Maar ja, dat zou een begin zijn. Overschrijven valt allicht te proberen, maar nogmaals moet ik dan wel eerst de image kunnen veilig stellen.

Vraag me af wat er gebeurt als ik de Synology reset zonder verlies van data: https://www.howtogeek.com...-reset-your-synology-nas/

[DukeBox]

vespino schreef op zaterdag 6 juni 2020 @ 14:27:
Importeren lijkt me alleen kunnen met een .ova bestand.

Je kan ook gewoon een disk image importeren.

Vraag me af wat er gebeurt als ik de Synology reset zonder verlies van data: https://www.howtogeek.com...-reset-your-synology-nas/

Waarom begin je niet eerst gewoon met een reboot nadat je de huidige data waar je wél kan veilig hebt.

[ Voor 39% gewijzigd door DukeBox op 06-06-2020 14:29 ]

[vespino]

DukeBox schreef op zaterdag 6 juni 2020 @ 14:27:
[...]

Je kan ook gewoon een disk image importeren.

[...]

Waarom begin je niet eerst gewoon met een reboot nadat je de huidige data waar je wél kan veilig hebt.

Ben nu nog volop data aan het binnenhalen en heb inmiddels ook de download van stack gestart. Eerst dat maar eens afwachten, dan booten om te zien of ik dan weer kan ssh-en.

[vespino]

Tussentijdse update, ssh en http toegang zijn hersteld, Joost weet hoe, downloads lopen nog gewoon. Morgen dus even een servertje opgooien en kijken of ik de VMs daar naartoe kan uploaden. Fingers crossed.

[vespino]

Weer een update: niet versleutelde bestanden zijn inmiddels binnen, stack download loopt nog (ETA +/- 6 uur), VMs zijn op 1 na verplaatst van de NAS naar externe opslag en ik test straks met de laatste of ik deze op een andere NAS kan importeren.

Rest het overzetten van een versleutelde map met minder belangrijke informatie (komt in geen enkele backup voor) om later een keer te kijken of die nog te decrypten valt.

[vespino]

WITTE ROOK!

Ik heb mijn VMs via een verre omweg op een externe schijf kunnen zetten, vervolgens 1 van de VMs naar een NAS van een bekende gekopieerd, daar een import gedaan (VMM > Image > Schijfimage), de VM ingeschakeld en die werkend bevonden. Het viel me vervolgens op dat de VM de volle grootte in beslag nam, dus heb ik de geïmporteerde VM geëxporteerd en vervolgens weer geïmporteerd als .ova. Ook dat werkte prima en nu geeft de schijf gewoon aan wat zijn echte opslag is.

Nu nog even wachten tot mijn STACK download compleet is, dan kan ik kijken of ik daaruit mijn bestanden kan decrypten. Daarna ga ik mijn volume verwijderen en opnieuw opbouwen. Deze keer maar verschillende volumes maken?

Tips voor het decrypten van een versleutelde map buiten Hyper Backup om zijn overigens welkom.

Dank voor meedenken en de tips die ik heb mogen ontvangen!

[vespino]

STACK download eindelijk voltooid ( 348GB :-) ) en is nu aan het recoveren via Hyper Backup Explorer... dit gaat ook weer uuuuuuren duren. Ondertussen heb ik het kapotte volume verwijderd van de Synology (ook dat duuuuuuurt) en hoop ik straks toch wel een begin te kunnen maken met het inladen van de VMs aangezien mijn MX fallback een max. heeft van 72 uur welke verloopt over 3 uur.

[rookie no. 1]

Goed nieuws.

Voordat je weer een nieuw volume aanmaakt en al je data weer terug zet: zijn je HDD's nog in goede staat? Welk RAID indeling van je HDD's had je? En welk file system? (gewoon Btfrs neem ik aan).

Vertrouw je de fysieke NAS nog? Bv. het geheugen ervan?

[vespino]

rookie no. 1 schreef op zondag 7 juni 2020 @ 15:25:
Goed nieuws.

Voordat je weer een nieuw volume aanmaakt en al je data weer terug zet: zijn je HDD's nog in goede staat? Welk RAID indeling van je HDD's had je? En welk file system? (gewoon Btfrs neem ik aan).

Vertrouw je de fysieke NAS nog? Bv. het geheugen ervan?

Schijven zijn goed aldus de S.M.A.R.T. scan, draaien in SHR (BTRFS) met 1 schijf fouttolerantie. Synology zelf gaf aan dat het zou kunnen komen door het geheugen dat after market en niet van Synology zelf is. Of ik dit moet geloven of dat dit gewoon een truc is om geheugen dat 4x zo duur is te kopen...

[jeroen3]

Welke schijven zitten erin? Ik heb hier een paar oudere WD Red's met ~40k uren met weak sectors die niet zichtbaar zijn in smart maar wel je pool laten falen.

[vespino]

jeroen3 schreef op zondag 7 juni 2020 @ 15:34:
Welke schijven zitten erin? Ik heb hier een paar oudere WD Red's met >40k uren met weak sectors die niet zichtbaar zijn in smart maar wel je pool laten falen.

4x WD RED 4TB

[rookie no. 1]

Als je HDD's verder in orde zijn, zou het nog niet eens zo vreemd zijn om je RAM te verdenken. Maar een memtest zegt meer, al moet je dan een machine hebben waar je het in kwijt kan voor zo'n test.

/edit: heb zelf overigens een corrupt ReFS volume gehad in een HPE Proliant Microserver gen8 omdat een SATA connector niet helemaal netjes contact maakte (Icydock conversion bay). Had ik de vage kuren gelijk onderzocht, had mijn 2de DC/DHCP/DNS VM nog geleeft.

[ Voor 40% gewijzigd door rookie no. 1 op 07-06-2020 16:29 ]

[vespino]

rookie no. 1 schreef op zondag 7 juni 2020 @ 16:25:
Als je HDD's verder in orde zijn, zou het nog niet eens zo vreemd zijn om je RAM te verdenken. Maar een memtest zegt meer, al moet je dan een machine hebben waar je het in kwijt kan voor zo'n test.

/edit: heb zelf overigens een corrupt ReFS volume gehad in een HPE Proliant Microserver gen8 omdat een SATA connector niet helemaal netjes contact maakte (Icydock conversion bay). Had ik de vage kuren gelijk onderzocht, had mijn 2de DC/DHCP/DNS VM nog geleeft.

Zo'n test kan niet worden gedaan in de Synology zelf? Of geeft dit dan een gekleurd beeld?

[DukeBox]

vespino schreef op zondag 7 juni 2020 @ 17:10:
Zo'n test kan niet worden gedaan in de Synology zelf?

Ja dat kan vanuit assistent.

[vespino]

DukeBox schreef op zondag 7 juni 2020 @ 17:24:
[...]

Ja dat kan vanuit assistent.

Dacht ik al eens gedaan te hebben op advies van Synology, maar kwam toen volgens mij niet verder als "er zit geen Synology geheugen in". Misschien dan toch maar 250€ er tegenaan klappen?

[DukeBox]

vespino schreef op zondag 7 juni 2020 @ 17:36:
Dacht ik al eens gedaan te hebben op advies van Synology, maar kwam toen volgens mij niet verder als "er zit geen Synology geheugen in". Misschien dan toch maar 250€ er tegenaan klappen?

Ik heb in geen van mijn synology's als ook die op mijn werk origineel geheugen. Die test kan je gewoon draaien.

[vespino]

DukeBox schreef op zondag 7 juni 2020 @ 18:23:
[...]

Ik heb in geen van mijn synology's als ook die op mijn werk origineel geheugen. Die test kan je gewoon draaien.

Dan ga ik dat doen als mijn VMs weer up zijn, ben net lekker aan het importeren.

[DukeBox]

vespino schreef op zondag 7 juni 2020 @ 18:24:
Dan ga ik dat doen als mijn VMs weer up zijn, ben net lekker aan het importeren.

Logischer is om dat voordat je gaat restoren gaat doen. Als het corrupt is kan je data ook corrupt op je storage komen te staan. Zeker aangezien er bij dit model geen ECC in zit.

[vespino]

Geheugentest loopt. Ga ook maar meteen even werken aan een script dat de VMs automatisch backupt, dit nooit meer.

[vespino]

Reactie geheugentest: Systeem heeft geen reactie. Verbinding time-out.

[Q]

vespino schreef op zondag 7 juni 2020 @ 21:02:
Reactie geheugentest: Systeem heeft geen reactie. Verbinding time-out.

Als het apparaat twee geheugenbankjes heeft zou je even een van de twee los kunnen trekken en de test opnieuw uitvoeren.

Als de test bij bankje 1 slaagt en bij 2 faalt (hij hangt weer) dan weet je mogelijk waar het probleem zit

Edit:

Ik wil niet teveel op de zaken vooruitlopen, maar als het geheugen niet lekker is, dan moet je ook rekening houden met mogelijke datacorruptie in de virtual machines. Dat hoeft niet, het is geen gegeven, maar hou het even in het achterhoofd.

[ Voor 22% gewijzigd door Q op 08-06-2020 10:47 ]

[vespino]

Ik ben inmiddels hersteld van een volume crash op mijn Synology, echter zit ik nog met één folder die niet in mijn backup stond en die ik alleen als encrypted hebt kunnen downloaden van het apparaat. Zijn er mogelijkheden deze bestanden alsnog te herstellen? Ik heb de sleutel gebruikt bij het encrypten.

[br00ky]

Even gemerged met je vorige topic.

[vespino]

Vanmiddag weer een crash van een van m’n volumes gehad. Deze ronde heb ik de Synology in meerdere volumes ingedeeld waardoor de schade deze keer werd beperkt tot het volume waarop de VMs staan en dus was ik snel weer up. Dit zette me (na het bestellen van officieel geheugen) wel aan het denken. Op het volume stond ook de SSD cache. Zou dat de boosdoener kunnen zijn? Rotte caching SSDs. Ik heb deze dan ook verwijderd (softwarematig, niet fysiek aangezien ik geen zin had het apparaat uit te schakelen en uit te bouwen) en ga nu eens een tijdje zonder de cache werken en dus ook het nieuwe geheugen maar even niet inbouwen.

Ik heb voor de caching overigens 2x Samsung 860 M.2 SSDs.

[ Voor 9% gewijzigd door vespino op 15-06-2020 17:21 ]

[vespino]

Na een helder moment is het me gelukt de bestanden te kunnen decrypten. Dat ging als volgt: maak een nieuwe share aan, versleutel deze met de originele passphrase en unmount deze na het aanmaken. Kopieer alle versleutelde bestanden vanuit de backup naar de nieuwe folder, in mijn geval was dat “/volumeX/@<naam-van-de-share>@“. Mount vervolgens de share weer met de passphrase en presto, alle bestanden (en mappen) zijn terug!

Hopelijk heeft iemand er in de toekomst iets aan.

[Q]

Wat was nu de oorzaak van de crash: de SSD caching? Of het geheugen?

[vespino]

Q schreef op dinsdag 30 juni 2020 @ 21:16:
Wat was nu de oorzaak van de crash: de SSD caching? Of het geheugen?

Vooralsnog ga ik uit van SSD caching aangezien ik zonder caching inmiddels ruim 2 weken zonder problemen draai en het daarvoor binnen een week met caching weer mis ging. Ik heb het geheugen dan ook ongebruikt retour gemeld.

[TweakerCarlo]

vespino schreef op zondag 7 juni 2020 @ 15:27:
[...]
Schijven zijn goed aldus de S.M.A.R.T. scan, draaien in SHR (BTRFS) met 1 schijf fouttolerantie. Synology zelf gaf aan dat het zou kunnen komen door het geheugen dat after market en niet van Synology zelf is. Of ik dit moet geloven of dat dit gewoon een truc is om geheugen dat 4x zo duur is te kopen...

Ik heb dat 4 maal duurdere geheugen draaien (32gb). En toch een soortgelijk probleem ondervonden.
Na het cpén van de vms naar een andere share en het verwijderen van de packages en de storage pool de disks opnieuw kunnen toevoegen.

Bij mij is het fout gegaan toen ik in win via dskmgmt een 512GB iscsi target verwijderde op het moment dat er een een filecopy vanaf een andere folder op dat volume plaats vond. Een van de disks crashte en het volume ging in Read only mode.

Op dit moment dus een raid 1 met die zelfde 2 disks draaien en alles is groen. Gebruik het nu alleen nog maar voor VM's. Time will tell.

Het draait weer. Dank voor je hulp.

[ Voor 24% gewijzigd door TweakerCarlo op 09-06-2022 23:18 ]

[vespino]

@TweakerCarlo bij mij bleek het toch het geheugen te zijn. Heb ik destijds dan ook vervangen door Synology geheugen, sindsdien geen vuiltje aan de lucht. Had met after market geheugen waarschijnlijk ook gewoon goed gegaan, maar ja om gedoe met Synology te voorkomen, ben ik toch maar voor het dure spul gegaan.

[TweakerCarlo]

Inmiddels is de smartcheck voltooid. Bij mij blijkt het een SSD te zijn die defect is. Binnen garantie. Dus word netjes opgelost. Ticket om die reden ook gesloten bij synology. Thanks voor dit topic.

[ Voor 21% gewijzigd door TweakerCarlo op 10-06-2022 08:53 ]