Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Back-up: One size doesn’t fit all

 

Computable Expert

Ruud Mulder
Advisory Systems Engineer, Dell EMC. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Loopbaan.

Back-up processen zorgen nog vaak voor een te hoge belasting van de it-infrastructuur. In veel gevallen wordt er gekozen voor one size fits all-oplossing en dat is niet altijd de meest effectieve oplossing qua prestaties en kosten. Hoe kun je teleurstellingen voorkomen en maak je de juiste keuzes?

Stap 1: Breng je datalandschap in kaart
Het is van groot belang om een goed beeld te hebben van je datalandschap. Hoeveel data is er aanwezig? Bij welke bedrijfsprocessen hoort deze data? Welke applicaties maken gebruik van deze data?  Wat is je groei? Vooral de groei is belangrijk om in kaart te brengen. Zo voorkom je bijvoorbeeld dat je te klein of te groot instapt. Vooral bij back-up naar disk kan dit voor verrassingen zorgen (een onmiskenbaar voordeel van tape is en blijft de schaalbaarheid in volume). De uitkomst van deze inventarisatie is de basis en essentieel voor alle volgende stappen.

Stap 2: Classificeer je data op basis van beschikbaarheid/herstelbaarheid
Het classificeren van de data is een van de meest tijdrovende klussen die er maar is. Als je namelijk aan de gebruikersorganisatie vraagt hoe belangrijk iets is, dan krijg je vaak te horen dat het allemaal belangrijk is en superkritisch. Maar als je vraagt hoeveel geld ze er voor over hebben, dan wordt het meestal al een heel ander verhaal. Dit is het eerste knelpunt in een ‘one size fits all’-aanpak. Het is daarom van groot belang dat je de dataclassificatie goed en gestructureerd oppakt, om te voorkomen dat de back-up een zorgenkindje wordt. Data classificeren naar het belang van de business wil zeggen dat je een aantal categorieën creëert op grond van eisen betreffende het herstel:

  • Kritisch: verlies van deze data kan het einde van de bedrijfsvoering tot gevolg hebben
  • Essentieel: verlies bedreigt de voortzetting van de bedrijfsvoering
  • Ondersteunend: verlies is vervelend, maar bedreigt voortzetting van de bedrijfsvoering niet
  • Archief: data die bewaard moet worden, maar weinig invloed heeft op de bedrijfsvoering

Een nog veel gemaakte fout is dat de back-up niet ontworpen wordt voor herstel. Per groep dienen dan ook recover point objective (rpo) en recover time objective (rto) bepaald te worden. Met name deze twee waarden bepalen uiteindelijk de technologiekeuze. De recovery point objective is bepalend voor het maximale verlies aan informatie.  Zo verliest bijvoorbeeld een organisatie met een rpo van twaalf uur dus één dag aan wijzigingen. De recovery time objective bepaalt hoe snel de data in geval van een escalatie weer beschikbaar moet zijn. Met name tape heeft hier een slechte reputatie: algemeen genomen duurt het teruglezen een factor twee tot drie langer dan het schrijven.

Pas na het vaststellen van bovenstaande zaken zou er gekeken moeten worden naar een passende technische oplossing om te voorkomen dat er een one size fits all-oplossing gekozen wordt die niet alleen inefficiënt is in kosten, maar ook ineffectief als het om dataprotectie gaat. Nu is classificatie één van de meest tijdrovende processen binnen een organisatie. Het is een discussie waar de ict-afdeling om de tafel moet met de gebruikers om duidelijkheid te scheppen.

Stap 3: Manier van veiligstellen

De uitkomsten van stap 1 en 2 dienen als basis gebruikt te worden voor de technologiekeuze. Tijdens het maken van een back-up is een organisatie kwetsbaar, zeker als dit proces langer dan acht tot twaalf uur duurt. Het is daarom belangrijk om voor de eerder vastgestelde groepen de juiste keuzen te maken op het gebied van technologie, waarbij er in hoofdlijnen twee werkwijzen zijn om de data veilig te stellen: volledig of incrementeel. Oftewel iedere keer een back-up maken van alle data of alleen van de wijzigingen ten opzichte van de vorige back-up. Met name hier komt het voordeel van disk versus tape sterk naar voren door de mogelijkheid om uit verschillende incrementele back-up’s een volledige back-up te maken.

Stap 4: Bepaal het medium

De rpo en rto bepalen samen de keuze voor het medium. Tape is zeker nog een valide optie, want als je iets jaren ongewijzigd moet bewaren dan heeft dit medium nog altijd een goede business case. Nu wordt opmerkelijk vaak de back-up nog als archief misbruikt. Een dubbele last, omdat hierdoor niet alleen de kosten beduidend hoger worden, maar ook de hersteltijden langer. Een opkomend back-up medium is de cloud, die een kostenefficiënt alternatief biedt voor back-up, maar meestal niet de snelheid die nodig is om te herstellen. Vrijwel geen enkele provider biedt een sla aangaande de rto.  Dat wil nog niet zeggen dat dit medium oninteressant is, want met name aan de kant van de gebruiker groeit het volume aan data hard.

Stap 5: Kennis en beheer
In de markt leeft nog wel eens de perceptie dat de technologie vaak de spelbreker is en zorgt voor onsuccesvolle back-ups. De waarheid die ik vaak tegen kom bij klanten is totaal anders. Lange doorlooptijden zijn niet altijd zichtbaar. Niet alles wordt even effectief gedaan omdat investeringen in modernisatie van de back-up vaak een lage prioriteit hebben. Vaak wordt er achter de feiten aangelopen en is het hoogst onzeker of alle data wel hersteld kan worden, laat staan binnen de gestelde eisen. Dit terwijl de back-up onderdeel uitmaakt van het informatiebeveiligingsplan en dus een onderdeel is van de disaster recovery. Hierbij moet trouwens niet alleen gedacht worden aan de data maar ook aan ip-adressen, dns-aanpassingen, netwerkrouteringen, naamgeving et cetera. 

Conclusie

Een back-up dien je in omgekeerde volgorde te ontwerpen, op basis van hoe belangrijk de data is voor de business. Vind de juiste technologie bij de wensen en eisen en niet andersom. Niet alles is even bedrijfskritisch en essentieel. Dus classificeer eer ge begint. Pas dan kun je de meest effectieve en passende oplossing(en) voor het veiligstellen van je data vinden. In mijn volgende artikel zal ik nog meer uitweiden over de verschillende technologieën die er op het gebied van back-up beschikbaar zijn.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5162344). © Jaarbeurs IT Media.

7,9


Lees meer over


 

Reacties

Da's weer een helder stappenplan. zo ben ik ze van je gewend, Ruud.
Wat je wel kort aan stipt maar niet verder uitwerkt is het belang van het onderkennen van het verschil tussen back-up en archief. Omdat de functie verschilt (doel bewaren versus doel repareren) is ook de oplossing en het beslissingstraject niet per definitie het zelfde.


Guido,

Dank voor je reactie.

Ik heb hier in het verleden al wel eens iets over geroepen. Maar het is zeker een valide punt wat je aan haalt.

Tijdens het classificeren van je data is het van groot belang om ook te kijken naar welke data mogelijk gearchiveerd kan worden. Door deze archiefdata uit je reguliere back-up te halen en alleen nog maar veilig te stellen als er echt iets veranderd, verlaag je de belasting op je back-up omgeving aanzienlijk.

En ja, de beslissingstrajecten wijken ietwat van elkaar af in mijn optiek. Maar beide hebben dezelfde raakvlakken omdat je rekening moet houden met beleid,SLA'en regelgeving. Dataclassificatie dient als basis voor beide.

Mijn ervaring met archiveren is wel dat het politiek vaak wat gevoeliger ligt. Als je tegen een gebruiker zegt dat het langer duurt voor dat hij historische data kan opvragen, dan wordt dit niet altijd gewaardeerd.

Ik kan uit ervaring vertellen dat ik ooit eens project gedaan heb, waar in de organisatie niet ingelicht werd. En men had de 1e dagen helemaal niets door. Tot dat het iemand op viel dat de icoontjes ietwat gewijzigd waren. Het desbetreffende archiefprogramma wijzigde dit ietwat van kleur en voegde een embleem toe. Qua performance was het niemand opgevallen. Zo zie je maar weer dat informeren niet altijd nodig is.

De mening van de gebruikers is 1, de eisen van de regelgevers zijn 2.
Waar back-up vooral een antwoord geeft op de behoefte om een integer informatiesysteem te hebben en houden is het archief vooral bedoeld om historische data niet kwijt te raken (maar wel weg te zetten).
Een verschil is doel maakt dat er ook andere criteria gelden die weer voor andere keuzes zullen zorgen.

Guido,

Je hebt helemaal gelijk. Maar back-up is wel degelijk ook om aan regelgeving te voldoen. Het niet terug kunnen zetten van data is in sommige gevallen strafbaar.

Helemaal waar, Ruud. In je auto zijn een rem en een handrem nodig en verplicht, ze doen veel het zelfde maar toch ook weer niet alles en je moet ze vooral niet door de war halen bij het gebruik ;-)

Weer een goed artikel Ruud.
Dank voor deze bijdrage.

Ruud,

Goed en sterk artikel. Kan het alleen maar bevestigen tov mijn ervaringen. Goed om te delen, dank voor je bijdrage.

@ Peter,

Dank voor je reactie en compliment.

Ik ben blij dat het herkenbaar is. In mijn 2e deel zal ik wat meer de keuzes die je op het gebied van back-up technologie kan maken toelichten.

Maar zonder bovenstaande voorbereidingen kan je nooit de juiste keuzes maken qua technologie.

Als eerste ga ik een Rezaatje doen door te verwijzen naar een eerdere opinie die ik over dit onderwerp geschreven heb: 'Back-ups zijn als vliegende olifanten'

In reactie stelde ik al dat met name het archief een steeds groter probleem wordt, veel organisaties misbruiken de back-up hiervoor waardoor RPO/RTO op verschillende manieren onder druk komt te staan. Gelijk gaf ik naar aanleiding van vragen ook cijfers over het belang van een back-up. Cijfers over een succesvolle restore zijn nog schokkender, zeker als het een volledige rebuild van een systeem betreft.

Ik wil dan met name aandacht vragen voor de conclusie, wie bepaald nu precies wat wel en niet belangrijk is?

Zo vraag ik me af hoe erg het is als een factuur 5 dagen later verstuurd wordt versus hoe erg het is als een bepaalde bestelling 1 dag later verstuurd wordt. Ik haal met name deze vraag aan omdat ik nog weleens constateer dat IT manager beslissingen neemt aangaande de back-up in plaats van de business. En ik denk niet dat ik een geheim vertel dat de meeste IT managers geconditioneerd zijn om op de kosten te letten.

Bovenstaande komt uit praktijk voorbeeld waar eindeloos over relatief kleine investering getwijfeld werd door IT terwijl de schade van onderbreking van de service een factor 100 groter was. Wie op de kleintjes let verliest namelijk nog weleens het grotere geheel uit het oog.

Een beetje uit de lucht gegrepen cijfer is dat 9 van de 10 organisaties een risico lopen aangaande herstel. De onderbouwing van voorgaande stelling is dat IT vaak geen enkel idee heeft van wat ze nu eigenlijk allemaal veiligstellen terwijl de business weer geen idee heeft van de onderliggende techniek.

Benieuwd naar vervolg wat in gaat op de technologie omdat deze dus sneller voortschrijdt dan het proces.

In het land der blinden is eenoog koning en dus verbaas ik me ik me al niet eens meer over een praktijkcase die een concurrent hier publiceert waarbij de back-up als basis voor het zaakgericht werken gepresenteerd wordt maar ik had geloof ik al wat gezegd over back-up misbruiken als archief.

Vooral in de classificatie essentieel zie ik nog weleens een 'onderverzekering' doordat een in eerste instantie als ondersteunend geclassificeerd systeem stilletjes essentieel of zelfs kritisch is geworden. Daarmee wil ik benadrukken dat gehele classificatie zeker ook geen 'one-size-fits-all' proces is.

Ewout,

Dank voor je uitgebreide reactie. Je haalt een aantal zeer valide punten aan. Het classificeren van de data dient samen met de business gedaan te worden. IT heeft daar in een ondersteunende taak en moet de wensen en eisen vanuit de business vertalen naar de juiste techniek. Tenminste zo kijk ik er tegen aan.

Juist bij de classificatie gaat het nog te vaak fout. IT doet dat vaak op basis van aannames. En hier door kan het voorkomen dat data verkeerd geclassificeerd wordt. Ook heeft de business vaak geen benul wat de impact van het back-up proces is en wordt daarom te vaak gekozen voor een one size fits all oplossing. Die is nu eenmaal gemakkelijk te beheren.

Het kan ook nlg veel erger. IT gaat vaak nooit deze dataclassificatie discussie aan, omdat deze als lastig en tijdrovend wordt gezien.Uit deze discussie kan namelijk komen dat de door IT gebouwde en geadviseerde huidige omgeving alles behalve voldoet. Het classificeren van data zorgt er ook voor dat je toch in zekere mate een prestatie verplichting aan gaat. En ook dat geeft nog wel eens koudwatervrees.

Dataclassificatie is mijn optiek dus veelal een politiek proces wat uiteindelijk vertaald wordt in de juiste technische oplossingen.

3.b
Veiligstellen door de backup te verifiëren.
Wat Ewout ook al aanhaalde. En regelmatige backup zonder een regelmatig geteste restore is vragen om moeilijkheden.
De technologie is dan niet de bottleneck maar het menselijk inzicht en toepassing van een onderbouwde risicospreiding.
Dit hoort bij elke ICT organisatie/afdeling gemeengoed te zijn. Als dat niet het geval is dan heeft u of een goede reden of loopt u onnodig risico.

Johan,

Dank voor je toevoeging.

Helemaal mee eens. Veilig stellen van data is leuk. Maar daar ben je er nog niet mee. De data die je veilig gesteld hebt, moet consistent zijn en terug te zetten zijn.

Dat laatste is natuurlijk iets wat geregeld getest moet worden. Dit is veelal een organisatorisch proces wat in gegereld dient te worden. De technologie is hier veelal ondersteunend aan. Al moet ik wel onderkennen dat er steeds meer technologie beschikbaar komt die het 1 en ander kan simuleren en automatiseren.

Echter ben ik nog steeds van de oude stempel en van het zien is pas geloven. Het echt goed testen of je back-up consistent en goed is, is en blijft een tijdrovende aangelegenheid.

@Ewout,
Fijn te zien dat je ook iets van andere mensen aanneemt/overneemt. Dat zie ik meer als een compliment. Maar het verbaast me dat je dit pas nu aan mij relateert terwijl je dit al eerder in je reacties gedaan hebt! Maar nogmaals bedankt voor je compliment eb houd het vast :-)

Ruud,
Leuk artikel. Ik zie het meer als een samenvatting van een aantal zaken die je als reactie eerder op deze site achtergelaten hebt. Dus niks nieuws voor mij maar misschien interessant voor mensen die je niet eerder gevolgd hebben. Ik probeer even hierop te reageren anders oogt dit artikel als een Unisys feestje ;-)

Ik ben het eens met de zaken die je in stap 1 en 2 benoemd hebt. Maar……

1- Als het goed is heb je al je datalandschap, groei, dataclassificatie etc etc tijdens het ontwerp van je storage in kaart gebracht. Dus dat nog een keer doen lijkt me overbodig.

2- Heb je dat niet eerder gedaan in punt 1 hierboven? Geen punt, classificatie en indeling kom je nog een keer tegen als je je DR-draaiboek gaat maken. In dat proces kom je beschikbarstellen van je services en hieraan gerelateerde zaken zoals data(bronnen/soorten/ volgorde/RPO-RTO en nog meer) tegen. Daarom vind ik stap 1 en 2 niet echt nodig als je al je BC/DR plan opgesteld en getest hebt. Voordeel van deze aanpak is dat je je BC/DR ook tets!

3- De uitvoering volgens je aanpak in stap 1 en 2 zie ik persoonlijk, in de termen gesproken van je collega Ewout Dekkinga hoogleraar taal en wollige communicatie, als “de gebruikelijke zeemeeuwen consultancy”. Want we weten heel goed dat de inrichting en indeling van je storage en dus je datalandschap circa 1 jaar na de implementatie totaal anders gaat worden dan in het begin. Ik denk dat je veel zaken hieromtrent eerder, voordeliger en slimmer kunt oplossen als je begint met het opstellen van een BC/DR draaiboek.

Ik sla punt 3,4,5 over. Daar hebben we eerder in andere artikelen over gesproken.

Wat ik wel interessant vind is een duidelijke vergelijking tussen back-up naar cloud vs traditionele back-up!
Reno van de Looij heeft vorige week op een andere site hierover een artikel geplaatst. Je gaf in het kort een aanvullende reactie op mijn reactie op dat artikel. Het lijkt me zeer interessant als je als expert in je volgende artikel op Computable op een aantal punten die ik daar benoemd heb verder in te gaan.

Ik kijk uit naar je volgende artikel!

Reza,

Dank voor je reactie. En ja Unisys is erg actief in de discussies op Computable. En aangezien je ons hier actief volgt kan je ook zien dat we het niet altijd met elkaar eens zijn. Jouw collega's zijn natuurlijk hier ook meer dan welkom om zich in alle discussies te mengen. Hoe meer zielen, hoe meer vreugd. En van elkaars inzichten leer je natuurlijk alleen maar.


Even terug komen op je punten:

1. Uitgaan van "als het goed is" doe ik nooit. Aannames zijn in ons vak dodelijk. Je zal verbaasd zijn hoeveel organisatie geen enkel idee hier van hebben of na een paar jaar het inzicht totaal verliezen. Vaak is alleen de totale capaciteit duidelijk. En ook die cijfers zijn vaak niet accuraat.

Er wordt nog te vaak door onduidelijkheid en gebrek aan inzicht gekozen voor een one size fits all oplossing. Die natuurlijk alles behalve toereikend en kosteneffectief is.

Je geeft zelf ook al aan dat je datalandschap onderhevig is aan veel verandering. Dus in mijn optiek is deze stap een continu proces die zeer hevig is aan verandering. Dit doe je niet alleen maar bij het ontwerpen van je storage omgeving.

Als je dat eenmalig doet loop je in mijn optiek achter de feiten aan en loopt je continuïteit als organisatie zijnde mogelijk gevaar.De eisen en regelgeving op het gebied van het beschikbaar hebben van je data zijn onderhevig aan veranderingen. Wat vandaag belangrijk is en perse bewaard dient te worden kan over een x aantal weken,maanden, jaren totaal veranderd zijn.

Echter zie ik wel vaak dat de classificatiegroepen niet dagelijks veranderen. Alleen is het wel zaak om deze groepen zo nu en dan tegen het licht te houden. Is de RPO/RTO nog toereikend? Zit de data wel in de juiste groepen? Voldoe ik aan alle regelgeving? etc. etc.

2. Je brengt eerst je data in kaart. Dan verdeel je het in groepen en dan pas stel je per groep een RPO/RTO op. Dit combineren in 1 stap maakt het er niet duidelijk op. En kost vaak te veel tijd. Verschillende seperate iteraties vergroot de kwaliteit en dus ook het succes. En zoals ik hier boven al schreef dit blijft een dynamisch proces wat je geregeld even tegen het licht moet houden.

3. Dat je storage omgeving dynamisch is, is mij natuurlijk wel duidelijk. Gelukkig wel, anders zou mijn vakgebied wel heel erg saai worden. Je moet deze oefening natuurlijk geregeld doen en up to date houden. Zie dit als periodiek onderhoud. Data verandert namelijk dagelijks qua omvang en performance. Ik zie daarom het vergelijk met " Zeeleeuwen consultancy" totaal niet.

En ja er zit wel wat herhaling in van artikelen die ik eerder geschreven heb. Maar de kracht van herhaling kan nooit geen kwaad. Over cloud vs traditioneel heb ik in het verleden al wat geschreven:

http://www.computable.nl/artikel/opinie/storage/4635530/1277017/wijze-van-opslaan-bepalend-bij-veiligstellen-data.html

Mijn volgende stuk zal wat meer op de technologie keuzes in gaan. Dit is ook het logische vervolg aangezien dit artikel op de voorbereiding gaat.

Ik vind het een weer sterk stukje, goed gedaan Guido. In het verleden heb ik verschillende premigrationele trajecten opgetuigd en daar was het echt wel one size fits all.
1. Resize data
Geef te kennen dat data gaat worden gereduceerd en dat data van langer dan moment (X) zal worden gebackupt doch niet langer bereikbaar. De bedoelde data werd slechts onzichtbaar gemaakt voor gebruikers voor een gelimiteerde periode en wanneer er geen reactie kwam, -> Archive. We hebben het hier over gemiddeld 80% van data die niet meer werd aangesproken. (Eyeopener???)
2. Dismiss data
U kent dat wel, onzinnige data die iedereen wel eens verzameld. JPG/GIF/BMP etc die men 'wel eens gebruikte' Overigens, surveys leerde ook dat menig niet te vies is van het neerzetten van MP3/4 of complete films op corporate shares. Ook een echte eyeopener.
3. Mailfiles
Niet veel mensen denken er aan maar mailfiles doen een enorme aanslag op je ruimte en performance doch weinig zie je daar echt oog op hebben. (Natuurlijk, u als lezende professional niet, I know...)
4 Duidelijk protocol
Lijkt een overbodige luxe maar 75% van de organisaties hebben werkelijk geen eenduidige richtlijn van de 'do's en dont's' van data. Begin er eens over want ook dat scheelt je enorm veel.
De stap voor die backup zou volgens mij gewoon datasupervision kunnen zijn.... als er natuurlijk iets 'as such' bestaat.

Goeie Guido. Dank.

NumoQuest,

Dank voor je compliment. Alleen was het niet Guido maar ik die het artikel geschreven heb ;-)

Je haalt zeer herkenbare punten aan. Waar voor dank!

1. Herkenbaar. Niet alles is even kritisch en wordt echt gemist. Dit is een leuk trucje om zo nu en dan te doen. Archivering op welke manier dan ook is een erg mooie oplossing om de back-up te ontzien.

2. Non business data zou in mijn optiek zou in mijn optiek preventief geruimd /tegen gehouden moeten worden. Maar ik deel je mening dat dit niet altijd even secuur gebeurt.

3. De logge en grote PST files nemen vaak te veel capaciteit en performance in beslag.

4. And last but not least. Alles begint in het leven met een goede opvoeding/educatie. Dus dat geldt hier ook zeker.

Ruud,

Helder verhaal zoals vaker. Veel is gelegen in het feit dat organisaties te weinig resources vrij maken om classificatie vorm te geven. Ergens is data altijd belangrijk zeker als de eigenaar onbekend is. Ervaringscijfers leren dat 60% van de data nooit meer wordt aangeraakt welke ooit opgeslagen is. Als ik niet struikel over de schoenen van de kinderen als ik de deur binnenkom dan ruim ik ook niet op. Misschien is de pijn toch niet zo groot en geven we graag extra geld uit aan opslag en back-up.

Frank,

Op zich zeer herkenbaar wat je schrijft. Waar voor dank.

Alleen is binnen iedere organisatie de back-up omgeving vaak een groot verbruiker op het gebied van resources en capaciteit. Echter is dat niet bij iedere organisatie altijd even helder en inzichtelijk. Ik heb wel eens assessments gedaan waar in men schrok van het feit dat er tig jobs langer dan 36 uur duurde. En dan waren dat niet alleen de periodieke fulls.

Juist het preventief opruimen en classificeren van je data zorgt er voor dat je RTO aanzienlijk verlaagd kan worden. Of te wel hoe minder je moet terug zetten na aanleiding van een incident/escalatie, des te sneller je weer in de lucht bent. Het is erg belangrijk om bijvoorbeeld bij het verliezen van een locatie vooraf duidelijk te hebben wat essentieel/kritisch is om ergens anders weer de lucht in te gaan. Alles terug zetten kost namelijk veel tijd.

Door het goed managen van je data ( lees archiveren/ opschoning ) creeer je ook vaak extra capaciteit. En die capaciteit kan mooi ingezet worden voor groei of voor het verbeteren van je RPO.

Of te wel om een lang verhaal kort te maken. Opruimen en bijhouden van je data en back-up omgeving levert een hoop voordelen op.

Sterk artikel. Kan het alleen maar bevestigen, ik heb dezelfde ervaringen.

Dank NumoQuest, ik vond ook dat het artikel bijna mijn niveau had ;-)

Ruud....

:O((((

Heel akelig minpuntje voor mij. Ben er al vaker op gewezen soms even te snel te gaan.

Guido,

Helaas, als jij het was geweest had het gepast.

RUUD! KLASSE!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×