Defecte opslag brengt servers van mijn.host urenlang offline

Hoster mijn.host heeft sinds vannacht te maken met een storing, waardoor enkele servers offline zijn. Het bedrijf meldt dat dit komt door defecte opslag binnen het platform. De getroffen diensten komen inmiddels weer deels online.

Mijn.host meldde vannacht rond half vijf dat enkele servers offline waren. Sindsdien herstelt het bedrijf de getroffen servers, meldt de hoster op zijn statuspagina. De problemen treffen de vps-servers en een aantal webservers. Alle andere servers en diensten zijn wel operationeel.

De vps-dienst is inmiddels voor 70 procent hersteld, zei mijn.host vanmiddag. Shared hosting is voor 40 procent hersteld. Wanneer alle servers weer naar behoren werken, is onduidelijk.

Bron: Mesh cube/iStock/Getty Images

Reacties (45)

[mijn.host]

Hoi allemaal, we geven graag wat meer context.

Vannacht rond half vier is een van onze storageclusters uitgevallen. Daardoor is een klein deel van onze vps’en en shared-hostingservers offline gegaan, in totaal ongeveer 5% van al onze servers.

We weten dat dit erg vervelend is, zeker als je website of applicatie al uren niet bereikbaar is. Onze excuses daarvoor.

Om alles weer online te krijgen, moeten we de back-ups van afgelopen nacht terugzetten. Dat kost tijd, en daardoor duurt het herstel langer dan we zouden willen. De actuele stand van zaken vind je op https://status.mijn.host.

Onze prioriteit is nu om alle diensten weer draaiend te krijgen. Daarna onderzoeken we verder waarom de redundantie binnen het cluster deze uitval niet heeft opgevangen. We willen niet dat dit nog een keer gebeurt, en zullen er alles aan doen wat nodig is om herhaling te voorkomen.

[eLScha]

"De backup van afgelopen nacht". Daarbij bedoelen jullie volgens mij dus de nacht ervoor. De storing was vannacht opgetreden en de backups zijn van zondagnacht. 24 uur data = verloren?

[Roberto4646]

Helemaal correct, als u een backup terug moet zetten van een nacht daarvoor dan bent u inderdaad 24 uur data kwijt. Dat is voor dit soort diensten niet heel erg afwijkend toch?

Staat overigens ook heel duidelijk in de voorwaarden, of had u die nog niet gelezen?

1. Retentie en Frequentie
Bewaartermijn: Back-ups worden tot 30 dagen bewaard.
Frequentie (Schema):
Huidige week: Er wordt elke dag automatisch een back-up gemaakt (7 dagelijkse herstelpunten).
Afgelopen maand: Na 7 dagen wordt er 1 volledige week-back-up bewaard. Dit herhaalt zich 4 keer, zodat je van de afgelopen maand elke week een full backup ter beschikking hebt.

[eLScha]

Mijn.host schrijft “afgelopen nacht”. Die uitspraak is onduidelijk. Ging het om een backup van eerder die nacht of om een nacht ervoor?

En wat hebben die voorwaarden er precies mee te maken? Een hoster die 24 uur data kwijt raakt heeft wat uit leggen, ongeacht de voorwaarden.

[Roberto4646]

Als u een dienst afneemt, tekent u voor de voorwaarden die u belangrijk vind voor uw dienst of klanten.

Achteraf klagen met "Een hoster die 24 uur data kwijt raakt heeft wat uit leggen" betekent dat u uw huiswerk en voorwerk gewoon niet correct heeft onderzocht t.o.v. de wensen die u of uw klanten hebben.

Als u dan ook nog roept dat voorwaarden er niets mee te maken hebben, lijkt het beeld inderdaad te kloppen.

U kiest bewust voor een dienst met een 24-uurs backup strategie. Een dienst met ​een Continuous Data Protection (CDP) is natuurlijk beduidend kostbaarder en dat moet weloverwogen worden.

[Phoenix_X]

Ik was inderdaad zo'n 36 uur aan data kwijt.

Dat kan gebeuren, dat weet ik. Mijn suggestie zou echter zijn om de VPSsen niet op te starten na de restore. Dat is bij mij wel gedaan, en voor ik het kon voorkomen werd er alweer flink gebruik gemaakt van de gehostte diensten. Het is nu heel veel werk om mijn eigen backups samen te voegen met de live omgeving waar een stuk mist.

Als de vps beschikbaar was gesteld, maar niet gestart, had ik alleen even de backups hoeven terug zetten en klaar. Puur mijn tip voor de toekomst, want Murphy zegt dat het niet de laatste keer zal zijn 😉

[Xander2]

Nette melding.

Kan menig bedrijf wat van opsteken.

[marsian]

Nette melding, maar had hem graag op mijn (alternatieve) mail gehad. Ik moest er nu zelf achter komen dat mijn mail en site er dus al uren uit lagen.

[Oon]

Staat je mail niet ook bij mijn.host?
Ik heb (op wat Exchange accounts na) al mijn mail via mijn mijn.host reseller pakketje lopen, gelukkig lijkt die van mij niet geraakt te zijn maar anders is het wel lastig om nog mail te ontvangen

[marsian]

😊 vandaar het woordje “alternatief” in mijn bericht. Mijn mail staat bij mijn.host maar mijn gebruikers account bij hun gaat via Gmail. Zo slim was ik nog wel 😉

Overigens ben ik nu nog stress niet online met mijn mail en het laatste bericht van hun kant is al meer dann” 12 uur oud…

[fedaykin]

Zie ik mijn.host vaker doen op tweakers, heel tof, als ik niet alles net naar openprovider overgesnort had (van dat vreselijke vimexx af) zou ik deze gasten zeker een kans geven

[Faloude]

Beste mijn.host, wij hebben heel veel begrip en vergevendsgezindheid voor dit soort dingen - zo lang als jullie onafhankelijk blijven en de boel niet verkopen aan team.blue of menig andere wurginvesteerder. Ik ben zo moe van om de 2 jaar verhuizen naar de volgende hostingbedrijf.

[Jelleuuh]

alle begrip voor, kan helaas gebeuren. maar het duurt jammer genoeg inderdaad wel lang. al mijn klantenwebsites van mijn resellerhosting liggen er al uit sinds deze morgen. hopelijk krijgen jullie het snel gefixed zodat mijn klanten ook weer bediend zijn. in de 2 jaar klant gelukkig nooit een dergelijke storing meegemaakt.

[Triodes]

Ik kan me een post (vgm van TransIP en hun Stack platform) herinneren met ongeveer hetzelfde probleem. Ook daar zou redundantie een falende disk hebben moeten opvangen, maar ging daarna het hele array offline. De oorzaak bleek dat het hele array was opgebouwd uit disks van dezelfde fabrikant en zelfs dezelfde productiebatch. Deze schijven worden met zulke toleranties geproduceerd dat de mtbf akelig nauwkeurig is. Het falen van 1 disk en de daar op volgende array rebuild zorde voor een cascading failure. Ik wil uiteraard geen enkele uitspraken doen over wat bij de host.net storing de oorzaak is. Maar wellicht dat het de moeite waard is om even te checken dat het niet dit exacte probleem is.

Dus onthoudt: nooit je raid array opbouwen uit exact dezelfde disks met exact dezelfde leeftijd!

[itlee]

Vervelend allemaal. kan gebeuren. lekker oplossen en weer door met de dingen van de dag. jullie doen prima werk, platform werkt snel en overzichtelijk. iets kapot kan altijd.

[Techno-Basje]

Inmiddels is mijn webhosting meer dan 24 uur offline. En is de communicatie rond 18 uur gisteravond gestopt.

Een persoonlijk bericht zou inmiddels toch ook Wellink zijn geweest

[Technoid]

Iets zegt mij dat er geen (werkende) redundantie is geweest.

[Kees]

Volgens mij gebruiken ze Ceph. Dat is best goed redundant op te zetten, maar het probleem blijft dat het een enkel cluster is.

De ceph omgeving die ik beheer heeft de laatste tijd ook last van wat kleine bugjes, waardoor 1 klein onderdeel (bijvoorbeeld 1 van de 60 osd's) die niet goed werkt langzaam het hele cluster onderuit trekt. Dan kun je nog alles 3-dubbel uitvoeren qua hardware, maar omdat het 1 cluster is, blijft het een single point of failure.

Je kan dan twee clusters gebruiken die naar elkaar synchroniseren. Maar je servers kunnen maar 1 van de twee omgevingen gebruiken. Als je dan merkt dat 1 van je omgevingen stuk is, dan moet je al je VM's overzetten naar het andere cluster, wat niet zomaar gedaan is.

Ik weet niet hoe het bij hen zit, maar gedeelde storage blijft gewoon enorm lastig.

[c-nan]

Ik ben wel benieuwd wat je bedoelt met 'waardoor 1 klein onderdeel (bijvoorbeeld 1 van de 60 osd's) die niet goed werkt langzaam het hele cluster onderuit trekt.`. Heb je daar een voorbeeld van? Hoe trekt 1 osd het hele cluster onderuit? Wat werkt er niet goed? Performance? Iets anders?

[Z80]

1 disk die aan het stukgaan is, maar nog niet zover stuk dat deze uitvalt of smart meldingen gaat geven kan een complete raidset zeer langzaam maken. Aangezien de raidcontroller denkt dat de disk nog goed is en blijft wachten tot deze meld dat de schrijfactie klaar is.

[Kees]

Twee weken geleden had ik een korte netsplit. Hierna hing 1 osd. Elke request die van die osd wilde lezen hing vervolgens. En omdat we best veel PG's hebben waren er een behoorlijk aantal pg's opgeslagen op die ene osd.

De osd zelf vond namelijk alles prima en reageerde positief op healthchecks, maar vond wel dat alle leesacties even moesten wachten tot hij klaar was met peeren. Dus eerst hingen er een paar VM's. Daarna een aantal processen die via cephfs van die ene osd gebruik maakten. Dat stapelde zich langzaam op. En ook al hebben we size=3, omdat die ene osd niet wilde dat er gelezen werd, namen de andere twee osd's het niet over.

Een simpele osd restart later en alles werkte weer.

[locke960]

Dat is de speciale wet van Murphy. Murphy vind altijd een conditie waar je redundantie niet op voorbereid is.

[Piemol]

Is het zo dat je na bijv. 3 of 4 jaar preventief schijven gaat vervangen in zo'n omgeving?
Om te voorkomen dat je schijven moet gaan vervangen als de eersten kuren beginnen te krijgen, terwijl ze allemaal precies even oud zijn?

[BugBoy]

Ik werk voor een bedrijf waar we software verkopen voor grote clusters. Over het algemeen worden er geen schijven preventief vervangen. Wel zorgen de meeste klanten er voor dat er reserve schijven klaar liggen, zodat bij het uitvallen van een schijf deze meteen vervangen kan worden. Meestal worden storage clusters na een (flink) aantal jaar vervangen door een nieuwe generatie. Snellere schijven (veelal NVMe tegenwoordig), meer RAM (caching) en ook snellere networking.

De eisen m.b.t. storage worden steeds hoger. Niet enkel de capaciteit wordt hoger, maar ook de snelheden moeten (vooral bij AI loads) flink omhoog. We hebben zelfs tegenwoordig klanten die draaien met 800gbit networking. Dat stelt overigens hele hoge eisen aan alle componenten, maar dan kan je wel een retesnel object storage krijgen.

Helaas zien we klanten die oude systemen (bijv. grote database clusters) opnieuw inzetten als storage cluster. Aangezien (over het algemeen) minder zware CPU eisen hebben klinkt dit aantrekkelijk, maar vaak zijn die schijven al wel aan het einde van hun latijn. Vaak is vervanging van oude schijven door hetzelfde type vaak lastig omdat die niet meer te krijgen zijn. Als vervanging te lang duurt en er teveel schijven kapot gaan, dan kan je alsnog data verliezen.

[Piemol]

Preventief vervangen voorkomt juist dat er teveel schijven tegelijk kapot gaan. Soms gaan ze juist kapot door de hoge load van syncen van data terwijl ze juist zelf ook al op leeftijd zijn. Maar goed, dit is wat ik geleerd heb. En ik heb nog niet te maken gehad met clusters van tientallen schijven, dus dan is wat leeftijdsdifferentatie niet zo'n grote kostenpost

[c-nan]

Ik heb enkele Ceph clusters in beheer gehad en preventief schijven vervangen hebben we nog nooit gedaan. Is ook erg zonde van je resources. Daarbij bestaat je cluster nooit uit 1 batch, dus als het goed is horen ze niet allemaal tegelijk uit te vallen.

[Kees]

Ik vervang ze niet preventief, maar elke 5 jaar hang ik er wel een nieuwe batch in. Dan is de garantie ook verlopen. Maar ik zet gewoon de oude disks over en gebruik ze tot ze stuk gaan.

Van de eerste 48 ssd's in ons eerste cluster zijn er nog 45 werkend

[Dylan_R]

Ik doe zelf ook veel met ceph and punt 1 die je daar noemt is echt de GROOTSTE irritatie die ik heb met ceph. Als 1 schijf bijvoorbeeld niet mee gaat met de IOPS trekt die het hele systeem onderuit. Verder is het wel een robuust systeem.

[wooha]

Wij hadden in beide datacentra een Ceph cluster. Data was verdeeld over primary en secondary databaseservers verdeeld over de datacentra. De primary repliceerde naar de secondary en applicaties gebruikten uiteraard hun primary.

Overige data (documenten) gingen eerst de database in en werden vandaar uit in elk datacentrum in een filesystem geplaatst.

Het uitschakelen van een problematische primary en vervolgens promoten van secondary naar primary was nog wel handwerk. Net als het herstellen van de oude primary als nieuwe secondary na het verhelpen van de problemen.

De applicaties konden meervoudig in beide datacentra draaien maar elke applicatie was wel afhankelijk van één (zijn primary) databaseserver.

We hadden het voordeel dat we netwerk, hardware en applicaties in eigen beheer hadden en kennis konden delen.

Dat laatste bleek bijvoorbeeld handig toen de performance om onduidelijke redenen in kon storten. Dat bleek vanwege een 1:N ORM query probleem en VLANs die beide datacentra overspanden, waarbij al het verkeer door de ene Cisco router ging die als primary was aangemerkt voor het VLAN. Elke query kon dan 0, 1 of 2 hops tussen datacentra vereisen. Het verschil tussen geen of twee dure hops werd dan duidelijk merkbaar.

[Bierkameel]

Zelfs als dat er is kan er nog van alles fout gaan.

Ik heb jaren Netapps beheerd met 100 HDD's, op het eind gingen er meerdere HDD's defect maar door de rebuild load klapten er steeds meer schijven uit, uiteindelijk heb ik bijna 20 HDD's in 1 week vervangen en is het een paar net langs dataverlies heengelopen maar het scheelde niks.
En ja er waren natuurlijk backups maar een vervangend systeem haal je niet de volgende dag bij de Mediamarkt op.

Dus dubbele controllers, dubbele stroom, dubbel gescheiden netwerk en redundancy op disk niveau en toch kan Murphy langskomen.

[Reactie gewijzigd door Bierkameel op 12 oktober 2026 14:30]

[Roberto4646]

Dat is geheel correct, staat inderdaad in hun eigen verhaal. De redundantie heeft niet gewerkt.

[CUGEL2000]

Mijn website en e-mail werken al meer dan 24 uur niet. Onacceptabel. Ik ben nog niet zo lang klant, maar ik heb nog nooit zoiets meegemaakt bij een andere provider. Het is nu 6:20 volgende dag. Er worden ook geen upates meer gegeven over hoe ver ze zijn met het herstel.

[Reactie gewijzigd door CUGEL2000 op 13 oktober 2026 06:50]

[Lost-Viking]

Inderdaad, onze resellerbak met wel zeker 75 klanten is al sinds 4 uur gisternacht offline. Dat is op dit moment van schrijven 27 uur..... Onbegrijpbaar dat er sinds gisteravond half 7 geen enkele update meer is.

[Ballantines]

Mee eens. Hier hetzelfde. Niks geen bericht. Dit is niet uit te leggen.

[jinks26]

Ze passen best hun headline op hun website aan '.Altijd betrouwbare hosting'

[CUGEL2000]

Ik heb inmiddels mijn mail geregeld via een andere dienst, dit nooit meer. Les geleerd.

[3raser]

Klinkt alsof ze backups aan het herstellen zijn.
Je kunt de status van het herstel op twee manieren lezen.
A: 70% van de VPS-dienst werkt alweer.
B: Het herstel van de VPS-dienst zit op 70% en werkt pas als deze op 100% zit.

[anpat]

Ik wacht liever op de uitleg van hun zelf en ga niet speculeren, Inieder geval is onze dienst niet onderbroken geweest. Dus wat er aan de hand is/was heb ik het raden na. Dit wens je geen enkel bedrijf/klant toe inieder geval!

En zie reactie Mijn.host bovenaan. Nog even de oplossing afwachten en misschien de echte reden, nog maar is een bewijs dat ze hun bedrijf 'zeer' serieus nemen

[Reactie gewijzigd door anpat op 12 oktober 2026 14:47]

[Rataplan_]

Aha, vandaar dat er zo traag / niet op mijn ticket wordt gereageerd? Dat was een ticket van afgelopen donderdag. We zien dat bv backups van backup04.mijn.host naar een nieuwe backup host zijn sinds achterin september ergens. We hadden een oude backup nodig en die backup04 is niet te bereiken. Heeft dit alles met elkaar te maken? (overigens hebben we ons issue anderszins opgelost).

Succes met oplossen, de rest komt later!

[Reactie gewijzigd door Rataplan_ op 12 oktober 2026 16:17]

[GertBuskruit]

Heb daar één VPS'je draaien, die is ook na uren downtime weer online. Alleen IPv6 functioneert (nog) niet naar behoren. (Hij lijkt IPv6-verkeer zowel inkomend als uitgaand niet te accepteren.) Uiteraard ook gemeld via een ticket. Maar mocht je zelf nu een VPS bij mijn.host met gekke issues hebben, dan is dit mogelijk iets om te checken.

[njitter]

Op 23 augustus: 'De Nederlandse hostingprovider mijn.host stopt na minder dan twee jaar al met zijn zogenaamde publicclouddienst CloudStack. De provider raadt gebruikers aan over te stappen naar zijn vps-dienst. Mijn.host zegt dat het de dienst niet stabiel genoeg kan aanbieden.'

En ook op VPS moet je dus maar hopen dat je opslag het doet 🤦‍♂️

[bartjuhhdidam]

Beetje vergezochte reactie niet waar...?

[njitter]

zo ver hoefde ik niet te zoeken hoor 😎

[webdesigner]

Ook ik ben het slachtoffer van die downtime @njitter , ik volg je redenering "waar rook is, is vuur ..." . Dit is the canary in the coalmine.

Tot op vandaag nog steeds vele sites die niet werken, en waarvan de data weg is. Mijn.host is scherp qua prijs, maar door de jaren heen heb ik voor de shared reseller hosting heel af en toe instabiliteit gemerkt in snelheid en kleine downtimes.
Ik kan echt niet begrijpen dat door een defect aan hun opslag, veel sites en mailboxen bijna 2 dagen offline zijn.
Zou het kunnen dat er iets meer aan de hand geweest is dan een gewoon defect ?
Een andere hostingfirma kan binnen enkele minuten een parallelle back-up storage switchen bij defect, en alles werkt terug. Het is niet normaal dat ze hier bijna site per site moeten restoren, en dan nog met bijna 48u dataverlies bij mails en websites bij veel klanten.
Volgens mij hebben ze bepaalde dure back-up systemen die grote spelers zoals Combell wel hebben, bewust niet aangekocht, om geld te besparen, want anno 2026 kan dit echt niet zo lang duren. Benieuwd wanneer alles weer zal werken, op hun statuspagina zijn ze veel positiever dan het echte nieuws: nog steeds zeer veel probelemen.

Ik ben voor de rest wel heel tevreden van mijn.host, maar het zijn stressvolle tijden gezien een groot deel van mijn klanten hun website, data & mails kwijt zijn tot nu toe. Ik wil hier niet op de man spelen, maar ik lijd hier economische schade onder, en heb hierdoor klanten kwijtgeraakt, dit kost me een hoop geld.

Ik blijf positief en hoopvol, en ben zeker dat mijn.host hier positieve lessen uit gaat trekken

[Reactie gewijzigd door webdesigner op 13 oktober 2026 12:46]

[webdesigner]

Hier het officiële antwoord van mijn.host over dit incident:

Onderwerp E-mail: Beveiligingsincident 12 oktober

Beste,

In de nacht van zondag 11 op maandag 12 oktober heeft er een incident opgetreden waardoor jouw webhosting of VPS enige tijd niet beschikbaar was. Tijdens de uitval hebben we gemeld op onze statuspagina dat de opslag van een aantal servers was uitgevallen. Inmiddels kunnen we je meer vertellen over de oorzaak van deze uitval: de uitval was het gevolg van een beveiligingsincident. Het ging om een beperkt aantal servers. Ongeveer 5% van onze klanten is hierdoor geraakt, en omdat jouw dienst(en) daarbij hoorde, ontvang je dit bericht.

Dit betreft de volgende dienst(en):

Product: Hostingpakket & VPS
Naam: xxx

Wat is er gebeurd?

Toen de storing ontstond, zagen we in eerste instantie dat de opslag van een beperkt aantal servers was uitgevallen. Onze eerste prioriteit was om alle diensten zo snel mogelijk te herstellen, wat veel tijd kostte. Tegelijkertijd hebben we onderzocht hoe de uitval kon ontstaan.

Na intensief onderzoek bleek dat via de beheerinterface (iDRAC) van de serverhardware een wisopdracht was gegeven voor de opslag van deze servers, zonder onze toestemming. Daardoor viel de opslag uit en ontstond de storing die je mogelijk hebt gemerkt. Vervolgens hebben we de logbestanden grondig nagelopen om zeker te weten wat er wel en niet is gebeurd, zodat we je volledig en juist konden informeren. We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke.

Zijn er gegevens ingezien of gekopieerd?

Nee, daarvoor hebben wij geen aanwijzingen. De beheerinterface legt vast welke acties er worden uitgevoerd. Daaruit blijkt dat er alleen een wisopdracht is gegeven. Bij een wisopdracht wordt de opslag gewist zonder dat de inhoud wordt uitgelezen.

Wat waren de gevolgen?

Het gevolg was dat je dienst tijdelijk niet beschikbaar was. Onze opslag is redundant uitgevoerd, maar die redundantie beschermt tegen hardwarestoringen en niet tegen een wisopdracht: die wist alle kopieën tegelijk. Daarom maken we daarnaast back-ups op gescheiden opslag.

Op maandagochtend 12 oktober zijn we begonnen met het terugzetten van alle gegevens vanuit die back-ups. Omdat dit herstel geleidelijk verliep, was je dienst afhankelijk van de server tussen de 6 en 30 uur offline. In uitzonderlijke gevallen was dit iets langer.

De teruggezette gegevens komen uit onze laatst beschikbare back-up. In de meeste gevallen was dat een back-up van dezelfde nacht, in andere gevallen van de nacht ervoor, en in enkele uitzonderlijke gevallen ouder. Gegevens die ná dat back-upmoment en vóór de storing zijn aangemaakt of gewijzigd, hebben wij mogelijk niet kunnen herstellen. Twijfel je of bepaalde recente gegevens compleet zijn, neem dan gerust contact met ons op.

Wat hebben we gedaan?

• Direct na de ontdekking hebben we de betreffende toegang tot de beheerinterface ingetrokken.
• We hebben alle beheertoegang tot onze systemen gecontroleerd en de toegangsgegevens vervangen.
• We hebben passende vervolgstappen ondernomen richting de verantwoordelijke.
• We scherpen onze procedures voor toegangsbeheer verder aan.
• We zijn bezig ons herstelproces te evalueren, zodat we bij een eventueel ander incident sneller weer volledig online zijn.

Waarom ontvang je dit bericht?

Gezien de impact van de storing willen we je volledig en eerlijk informeren over wat er is gebeurd. Daarom informeren we je over dit beveiligingsincident, zoals afgesproken in artikel 7 van onze verwerkersovereenkomst.

Wat betekent dit voor jou?

Gelet op onze bevindingen bestaat er voor jouw organisatie mogelijk een meldplicht bij de Autoriteit Persoonsgegevens en mogelijk aan personen, op grond van artikel 33 en 34 van de Algemene Verordening Gegevensbescherming (AVG). Meer informatie over deze meldplichten is te vinden op de volgende pagina's van de Autoriteit Persoonsgegevens:

• Informatie over stappen bij een datalek
• Melding bij de Autoriteit Persoonsgegevens
• Melding aan natuurlijke personen

We begrijpen dat dit bericht vlak voor het weekend komt. Daarom zijn we ook dit weekend bereikbaar voor vragen over dit incident.

Wij willen benadrukken dat wij deze situatie betreuren. Mocht je aan de hand van dit bericht vragen aan ons hebben, neem dan contact met ons op door te reageren op dit bericht.

Met vriendelijke groet,
mijn.host