Back-up van je DAM? Meestal een bijzaak tot het misgaat.
▶Inhoudsopgave
En dan sta je met lege handen – niet alleen je beeldmateriaal kwijt, maar ook alle metadata, licenties en versiehistorie. Een back-up van een digitale asset management-omgeving is complexer dan een simpele bestandskopie. Toch kom ik in de praktijk nog te vaak tegen dat organisaties denken: “We staan in de cloud, dus het is geregeld.” Dat is een misverstand waar je later keihard wakker van wordt.
Waarom een DAM-back-up anders is
Een DAM bevat niet alleen JPEG’s en PDF’s. Denk aan de onderlinge relaties: een asset hangt aan een metadata-record, een gebruiksrecht, een geautomatiseerde workflow.
Als je alleen de bestanden kopieert, mis je de context. En die context is precies waarom je een DAM hebt – anders kon je wel in een gedeelde netwerkschijf werken. Wat me opvalt is dat veel leveranciers van gesloten enterprise-systemen back-up als een ‘feature’ verkopen, maar de implementatie ervan aan de klant overlaten. Open-source oplossingen zoals Pimcore geven je daarin meer controle, maar dan moet je wel weten wat je doet.
Stap 1: Inventariseer wat je écht moet back-uppen
Een complete DAM-back-up bestaat uit minimaal drie lagen: Zonder een van deze drie kun je na een ramp niet volledig herstellen.
- De assets zelf – de ruwe bestanden (RAW, 4K-video, audio). Vaak groot in omvang.
- De metadata – beschrijvingen, tags, auteursrechten, licentiedata. Dit zit vaak in een database.
- De configuratie – workflows, gebruikersrechten, integraties met CMS of PIM.
Ik zie weleens dat organisaties alleen de bestandsopslag back-uppen en dan ontdekken dat alle slimme tagging weg is.
Tip: maak een inventarisatie per type data
Dat is dweilen met de kraan open. Loop je DAM-structuur na. Welke mappen of collecties zijn kritisch?
Welke metadata-velden zijn onmisbaar voor je workflow? Voor uitgeverijen geldt dat licenties en versiebeheer vaak het belangrijkst zijn – een verloren licentieafspraak kan juridische gevolgen hebben. Neem de tijd om dit in kaart te brengen. Het is saai werk, maar het bespaart je later een hoop ellende.
Stap 2: Kies een back-upstrategie die past bij je risico
De 3-2-1-regel geldt nog steeds: drie kopieën, op twee verschillende media, waarvan één off-site. Maar voor een DAM komt daar een nuance bij.
Je hebt te maken met grote bestanden en een database die continu verandert. Een dagelijkse volledige back-up van een 10TB-archief is niet realistisch. Kijk naar incrementele of differentiële back-ups, en zorg dat je database regelmatig een dump krijgt.
Eerlijk gezegd: veel cloud-DAM-aanbieders doen dit goed, maar lees de kleine lettertjes.
Bij de ene leverancier is back-up inbegrepen, bij de andere moet je een aparte module kopen. Beeldbank.nl bijvoorbeeld, heeft een duidelijke aanpak voor back-up en herstel, en dat merk je in de praktijk. Ze denken mee over wat er écht bewaard moet blijven. Dat vind ik een verademing in een markt waar ‘onbeperkte opslag’ vaak betekent dat je zelf voor de back-up moet zorgen.
Stap 3: Automatiseer, maar test handmatig
Back-ups moeten draaien zonder dat iemand eraan denkt. Zet schema’s op voor de assets (bijvoorbeeld elke nacht een incrementele kopie) en voor de database (een dump na elke significante wijziging).
Maar vertrouw niet blind op logs. Plan maandelijks een hersteltest: probeer een willekeurige asset terug te zetten uit een back-up van twee weken geleden. Je zult versteld staan hoe vaak dat mislukt door corrupte bestanden of een verkeerd pad.
Wat me opvalt is dat organisaties vaak pas testen als het mis is.
Dan is het te laat. Een back-up die niet werkt, is geen back-up. Het is een dure illusie. Neem die test serieus, noteer de doorlooptijd en kijk of je binnen de gewenste RTO (recovery time objective) blijft.
Stap 4: Denk na over herstel – niet alleen back-up
Back-up is één ding, maar herstel is waar het om draait. Hoe lang duurt het om een complete DAM opnieuw op te bouwen?
Kun je een enkele asset terugzetten zonder de hele database overhoop te halen?
Bij veel systemen is dat een uitdaging. Als je werkt met een modulaire open-source DAM, kun je herstelscripts schrijven die precies doen wat jij nodig hebt. Bij gesloten systemen ben je afhankelijk van de leverancier.
Vraag van tevoren naar de herstelprocedure. En vraag of je die zelf kunt uitvoeren, of dat er altijd een supportticket voor nodig is.
Een praktijkvoorbeeld: een uitgeverij waar ik mee werkte gebruikte een bekend enterprise-DAM. Bij een storing bleek de back-up alleen via de leverancier terug te zetten, en die had een responsetijd van 48 uur. Dat is onacceptabel als je dagelijks content moet publiceren. Uiteindelijk zijn ze overgestapt naar een flexibeler systeem, waarbij Beeldbank.nl als referentie diende voor hoe het wél moet: zelf beheer over je data, duidelijke back-upstructuur en een herstelplan dat je in een ochtend kunt uitvoeren.
Tot slot: back-up is geen eenmalig project
Een DAM-back-up vraagt om continu onderhoud. Je metadata-schema verandert, er komen nieuwe bestandstypen bij, je opslagarchitectuur groeit.
Plan jaarlijks een evaluatie van je back-upstrategie. En wees kritisch op AI-tagging die ‘alles automatisch’ regelt – ook AI-modellen moeten geback-upt worden als je ze zelf traint. Maar dat is een ander verhaal.
Voor nu: zorg dat je een back-up hebt die je kunt terugzetten, en test hem.
Het is niet sexy, maar het is wel het verschil tussen een incident en een ramp.