# Wat moet worden opgenomen in een back-upstrategie voor toepassingen? ## Regelmatige back-ups - Automatische back-ups op vaste intervallen (dagelijks, wekelijks, maandelijks) - Back-ups naar meerdere locaties - Instellingen voor retentie en archivering ## Gegevensbescherming - Versleuteling van back-ups tijdens opslag en transport - Toegangscontrole en authenticatie - Compliance met gegevensbeschermingsregels (GDPR, etc.) ## Redundantie en opslag - Off-site back-uplocaties - Geografisch verspreide back-upcentra - Verschillende opslagmedia (cloud, lokaal, tape) ## Testprocedures - Regelmatige herstelTests - Verificatie van gegevensintegriteit - Testen van disaster recovery-plannen ## Documentatie - Back-upschema's en procedures - Contactgegevens voor noodsituaties - Recovery procedures en RTO/RPO-doelstellingen (Recovery Time/Point Objective) ## Monitoring en alerting - Real-time status van back-ups - Automatische meldingen bij fouten - Logboeken van alle back-upactiviteiten ## Onderhoud - Regelmatige review en updates van de strategie - Aanpassingen aan groeiende gegevensvoluming - Beveiligingspatches voor back-upsystemen

Je FileMaker-systeem draait al jaren stilletjes je orderproces, productieplanning of klantengegevens — en de back-upstrategie erachter is nog steeds "een nachtelijke kopie naar een externe schijf die iemand in 2015 heeft ingesteld." Niemand heeft ooit geprobeerd dit terug te zetten. Niemand weet hoe lang een volledig herstel eigenlijk zou duren. Dat is geen back-upstrategie, dat is hoop.

Dit artikel helpt je door wat een echte back-upstrategie voor een zakelijk kritiek FileMaker-systeem moet bevatten — van wat je back-upt, hoe vaak, tot twee dingen die de meeste bedrijven nog steeds verkeerd doen: nooit testen of je de back-up kunt terugzetten, en alle kopieën in hetzelfde gebouw houden als de server.

Waarom is "we hebben back-ups" niet genoeg?

Omdat een back-upbestand dat nooit is teruggezet een onverifieerde bewering is, geen vangnet. Een klassiek scenario: de serverschijf van een bedrijf faalt op een dinsdagochtend. IT vindt de back-up van gisteravond, zet deze terug — en ontdekt dat de containerfields (de map met gescande facturen, foto's en pdf's) nooit in de back-uptaak zijn opgenomen. De database opent prima. Elk bijgevoegd document van de afgelopen drie jaar is weg.

Een echte strategie beantwoordt drie vragen nog voordat de ramp toeslaat, niet als het gebeurt:

1. Wat precies wordt gebackupt?
2. Hoe vaak, en hoe ver terug kunnen we gaan?
3. Hoe snel kunnen we eigenlijk weer aan het werk — en heeft iemand dit bewezen?

Wat moet eigenlijk in de back-up zitten, niet alleen het databasebestand?

Een FileMaker-systeem is zelden slechts één .fmp12-bestand. Een complete back-upstrategie dekt het volgende af:

• De databasebestand(en) zelf — inclusief elk gekoppeld bestand in een multi-file-oplossing, niet alleen het 'belangrijkste'.
• Containergegevens opgeslagen in externe opslag — als je externe of remote containeropslag gebruikt (gebruikelijk voor gescande documenten, foto's, pdf's, video), moet die mappenstructuur op hetzelfde schema als de database worden gebackupt, anders raken de twee uit sync.
• De FileMaker Server-configuratie — schema's, beveiligingsinstellingen, SSL-certificaten, plug-inconfiguraties. Een server zonder dit van nul af opnieuw opbouwen is traag en foutgevoelig.
• Alle gekoppelde integraties — API-connectorreferenties, webhookconfiguraties, geplande scripts die gegevens naar een ERP of boekhoudpakket zoals Exact Online pushen. Als deze niet worden gedocumenteerd en gebackupt, kan de database perfect worden hersteld terwijl alle integraties eromheen kapot blijven.
• Aangepaste scripts en serverzijdige schema's — geëxporteerd als tekst of apart gedocumenteerd, zodat een herbouw niet afhankelijk is van iemands geheugen van "hoe het vroeger werkte."

Hoe vaak moeten back-ups draaien, en hoeveel moet je bewaren?

Dit komt neer op twee getallen die elke bedrijfseigenaar zonder IT om hulp te vragen zou moeten kunnen aangeven:

• RPO (Recovery Point Objective): hoeveel gegevens kun je je veroorloven te verliezen? Als het "hooguit 15 minuten orderingave" is, is een nachtelijke back-up niet genoeg — je hebt progressieve back-ups nodig die elke 5–15 minuten draaien, wat FileMaker Server ondersteunt.
• RTO (Recovery Time Objective): hoe lang kan het bedrijf zonder het systeem? Als het antwoord "minder dan een uur" is, heeft je strategie meer nodig dan een back-upbestand dat in de kast staat — het heeft een plan (en bij voorkeur infrastructuur) nodig die snel een werkende server online zet.

Een verstandig gelaagd schema voor de meeste FileMaker-systemen ziet er als volgt uit:

• Progressieve back-ups elke 5–15 minuten (bewaard voor een dag of twee)
• Een volledige back-up elke nacht (bewaard voor 1–2 weken)
• Een wekelijkse back-up gearchiveerd voor een maand
• Een maandelijkse back-up gearchiveerd voor een jaar of langer, voor nalevings- of historische hersteelbehoeften

Waarom is een off-site (remote) kopie zo belangrijk?

Omdat een back-up opgeslagen op dezelfde server, in hetzelfde gebouw of op hetzelfde lokale netwerk als het productiesysteem je beschermt tegen een beschadigd bestand — maar niet tegen een brand, overstroming, diefstal of een ransomware-aanval die alles codeert wat het kan bereiken, inclusief je back-upschijf.

Een echt voorbeeld: een fabrikant had back-ups perfect draaien naar een NAS in de serverruimte. Een ransomware-infectie verspreidde zich 's nachts over het lokale netwerk en codeert de NAS samen met de productieserver. De back-ups bestonden — ze waren alleen nergens waar de ransomware niet kon.

Een robuuste remote back-upbenadering omvat:

• Ten minste één back-upkopie opgeslagen off-site of op een aparte cloudlocatie, fysiek en logisch gescheiden van het productienetwerk.
• Onveranderbare of write-once-opslag voor ten minste één recente kopie, zodat een gecompromitteerd beheerdersaccount historische back-ups niet kan verwijderen of versleutelen.
• Geautomatiseerde overdracht, geen handmatig "iemand herinnert zich vrijdag om het naar de cloud te kopiëren"-proces.

Wat voegt FileMaker Standby Server eigenlijk toe aan dit alles?

FileMaker Standby Server is een nieuwer vermogen dat verder gaat dan traditionele back-ups: in plaats van een back-upbestand na een storing terug te zetten, zit een tweede, voortdurend gesynchroniseerde kopie van de database klaar om over te nemen.

In de praktijk betekent dat:

• Wijzigingen op de primaire server worden in bijna real time naar de standby-server gestreamd.
• Als de primaire server uitvalt — hardwarefout, OS-crash, een slechte update — kan de standby-server worden gepromoveerd om de nieuwe primaire te worden, met veel minder gegevensverlies en downtime dan herstellen uit een nachtelijke back-up.
• Het is ontworpen voor zakelijk kritieke oplossingen waarbij een RTO gemeten in minuten, niet uren, echt belangrijk is — een productiehalsysteem, een klantgerichte orderportal, een logistieke dispatchertool.

Standby Server is geen vervanging voor back-ups — het beschermt tegen een ander storingscenario. Een back-up beschermt je tegen gegevensbeschadiging, onopzettelijk verwijderen of een slecht scriptuitvoering. Een standby-server beschermt je ertegen dat de primaire machine eenvoudig verdwijnt. Een volwassen strategie gebruikt beide samen.

Hoe test je eigenlijk of een back-up werkt?

Dit is de stap die bijna elk bedrijf overslaat, en het is de stap die het meest uitmaakt. Een back-up die je niet hebt hersteld is een back-up die je eigenlijk niet hebt.

1. Plan een echte herstellingstest — minimaal per kwartaal voor zakelijk kritieke systemen, maandelijks als het systeem regelmatig verandert.
2. Zet terug in een aparte, geïsoleerde omgeving — test nooit een herstel tegen productie.
3. Open het bestand en controleer gegevens, niet alleen of het opent — controleer of recente records aanwezig zijn, containerbestanden correct openen en scripts draaien.
4. Bepaal de timing van het hele proces — van "besluit tot herstellen" tot "systeem weer gebruikbaar" — en vergelijk dit met je RTO. Als het langzamer is dan het bedrijf kan tolereren, moet de strategie veranderen, niet alleen het back-upschema.
5. Documenteer het resultaat — wie deed het, wat werd hersteld, hoe lang het duurde, wat brak. Dit wordt bewijsmateriaal voor het management en een checklist voor de volgende echte incident.

Een snelle checklist voor een echte back-upstrategie voor toepassingen

• Databasebestanden en alle gekoppelde bestanden inbegrepen
• Externe/remote containeropslag gebackupt op hetzelfde schema
• Serverconfiguratie, schema's en certificaten gedocumenteerd en gebackupt
• Integratiereferenties en scripts apart gedocumenteerd
• RPO en RTO gedefinieerd in duidelijke zakelijke termen, overeengekomen met management
• Progressieve + nachtelijke + wekelijkse + maandelijkse back-uptiers ingesteld
• Ten minste één off-site of cloudkopie, geïsoleerd van het productienetwerk
• Onveranderbare/write-once-opslag voor recente back-ups (bescherming tegen ransomware)
• Standby-server ingesteld voor systemen waarbij minuten downtime belangrijk is
• Herstel daadwerkelijk getest volgens een schema, met gedocumenteerde resultaten

Veelgestelde vragen: back-upstrategie voor toepassingen voor FileMaker-systemen

Hoe lang moeten we oude back-ups bewaren? Minimaal: genoeg dagelijkse kopieën om een week af te dekken, wekelijkse kopieën voor een maand en maandelijkse kopieën voor een jaar. Regelgevings- of branchevereisten kunnen dit verder oprekken — controleer wat op je gegevens van toepassing is.

Is cloudback-up alleen genoeg? Alleen als het echt geïsoleerd is van je productienetwerk — een cloudback-up bereikbaar door een gecompromitteerd beheerdersaccount biedt weinig extra bescherming tegen ransomware.

Hebben we Standby Server nodig als we al goede back-ups hebben? Alleen als downtime zelf kostbaar is. Als het verliezen van een uur systeemtoegang echt bedrijfsimpact heeft — verloren orders, stilgestelde productie — sluit Standby Server een gat dat back-ups alleen niet kunnen dichten.

Wie moet verantwoordelijk zijn voor testen van herstellingen? Iemand buiten dagelijkse operaties, bij voorkeur met managementgoedkeuring voor de resultaten, zodat testen niet stilletjes wordt overgeslagen wanneer het druk wordt.

Een back-upstrategie is nooit echt 'klaar' — deze moet zich ontwikkelen naarmate het systeem, de integraties en de tolerantie van het bedrijf voor downtime veranderen. Als je niet zeker bent of je huidige instelling werkelijk zou standhouden in een echt incident, is dat een goed startpunt voor een gesprek. Loggix kan helpen bij het beoordelen of opbouwen van een back-up- en continuïteitsstrategie rond een aangepaste FileMaker-oplossing — inclusief Standby Server-instellingen, remote back-upconfiguratie en herstellingstests — als onderdeel van een breder onderzoek naar hoe je zakelijk kritieke software is beveiligd en onderhouden.