Wat moet worden opgenomen in een back-upstrategie voor applicaties?

Question

Accepted Answer

Uw FileMaker-systeem draait al jaren stilletjes uw orderproces, uw productieplanningen of uw klantgegevens — 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 hier van terug te herstellen. Niemand weet hoe lang een volledig herstel werkelijk zou duren. Dat is geen back-upstrategie, dat is hoop.

Dit artikel behandelt wat een echte back-upstrategie voor een bedrijfscriterium FileMaker-systeem zou moeten bevatten — van wat u moet back-uppen, tot hoe vaak, tot twee dingen die de meeste bedrijven nog steeds verkeerd doen: nooit het herstel testen en alle kopieën in hetzelfde gebouw als de server bewaren.

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

Omdat een back-upbestand dat nooit is teruggezet een onbewezen bewering is, geen veiligheidsneet. Een klassiek scenario: een serverhard drive van een bedrijf faalt op een dinsdag ochtend. 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 waren opgenomen. De database opent prima. Elk bijgevoegd document van de afgelopen drie jaar is weg.

Een echte strategie beantwoordt drie vragen voordat de ramp toeslaat, niet tijdens:

Wat wordt er precies back-upt?
Hoe vaak, en hoe ver terug kunnen we gaan?
Hoe snel kunnen we werkelijk weer aan het werk gaan — en heeft iemand dit bewezen?

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

Een FileMaker-systeem bestaat zelden uit slechts één .fmp12-bestand. Een complete back-upstrategie omvat:

De databasebestanden zelf — inclusief elk gekoppeld bestand in een multi-file-oplossing, niet alleen de "hoofdbestanden".
Containergegevens die extern zijn opgeslagen — als u externe of externe containeropslag gebruikt (gebruikelijk voor gescande documenten, foto's, pdf's, video), moet die mappenstructuur op hetzelfde schema als de database worden back-upt, anders lopen de twee uit elkaar.
De FileMaker Server-configuratie — planning, beveiligingsinstellingen, SSL-certificaten, plug-inconfiguraties. Een server zonder dit vanaf nul herbouwen is traag en foutgevoelig.
Alle verbonden integraties — API-connectorreferenties, webhookconfigureraties, geplande scripts die gegevens naar een ERP of boekhoudpakket zoals Exact Online pushen. Als deze niet zijn gedocumenteerd en back-upt, kan de database perfect worden teruggezet terwijl alles eromheen gebroken blijft.
Aangepaste scripts en server-side planning — geëxporteerd als tekst of apart gedocumenteerd, zodat een herbouw niet afhankelijk is van iemands geheugen van "hoe het werkte".

Hoe vaak moeten back-ups draaien en hoeveel moeten u bewaren?

Dit komt neer op twee getallen die elke bedrijfseigenaar zonder overleg met IT zou moeten kunnen noemen:

RPO (Recovery Point Objective): hoeveel gegevens kunt u zich veroorloven te verliezen? Als het "maximaal 15 minuten orderinvoering" is, is een nachtelijke back-up niet genoeg — u hebt progressieve back-ups nodig die elke 5-15 minuten draaien, wat FileMaker Server eigen ondersteunt.
RTO (Recovery Time Objective): hoe lang kan het bedrijf zonder het systeem? Als het antwoord "minder dan een uur" is, heeft uw strategie meer nodig dan een back-upbestand dat ergens staat — het heeft een plan nodig (en bij voorkeur infrastructuur) 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 (behouden voor een dag of twee)
Een volledige back-up elke nacht (behouden voor 1–2 weken)
Een weekelijkse back-up gearchiveerd voor een maand
Een maandelijkse back-up gearchiveerd voor een jaar of langer, voor compliance of historische herstelbehoeften

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

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

Een praktijkvoorbeeld: een productiebedrijf had back-ups perfect ingesteld op een NAS in de serverruimte. Een ransomware-infectie verspreidde zich 's nachts over het lokale netwerk en versleutelde de NAS samen met de productieserver. De back-ups bestonden — ze waren alleen nergens waar ransomware niet kon komen.

Een gezonde externe back-upbenadering omvat:

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

Wat voegt FileMaker Standby Server aan dit toe?

FileMaker Standby Server is een nieuwere mogelijkheid die verder gaat dan traditionele back-ups: in plaats van een back-upbestand na een storing terug te zetten, wacht een tweede, voortdurend gesynchroniseerde kopie van de database om over te nemen.

In de praktijk betekent dit:

Wijzigingen op de primaire server worden bijna in realtime naar de standbyserver gestreamd.
Als de primaire server uitvalt — hardwarestoring, besturingssysteemcrash, een slechte update — kan de standbyserver worden gepromoveerd om de nieuwe primaire server te worden, met veel minder gegevensverlies en uitvaltijd dan het terugzetten van een nachtelijke back-up.
Het is ontworpen voor bedrijfscriteriumoplossingen waar een RTO gemeten in minuten, niet uren, werkelijk uitmaakt — een productievloersysteem, een klantgericht orderportal, een logistieke dispatchtools.

Standby Server is geen vervanging voor back-ups — het beschermt tegen een ander foutpatroon. Een back-up beschermt u tegen gegevensbeschadiging, onopzettelijk verwijderen of het uitvoeren van een slecht script. Een standbyserver beschermt u tegen dat de primaire machine eenvoudig verdwijnt. Een volwassen strategie gebruikt beide tegelijk.

Hoe test u werkelijk of een back-up werkt?

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

Plan een echte herstellingstest — minimaal per kwartaal voor bedrijfscriteriumsystemen, maandelijks als het systeem vaak verandert.
Zet terug naar een afzonderlijke, geïsoleerde omgeving — test nooit een herstel tegen productie.
Open het bestand en verifieer gegevens, niet alleen dat het opent — controleer dat recente records aanwezig zijn, containerbestanden correct openen en scripts draaien.
Bepaal het gehele proces — van "besluit om terug te zetten" tot "systeem weer bruikbaar" — en vergelijk het met uw RTO. Als het langzamer is dan het bedrijf kan tolereren, moet de strategie veranderen, niet alleen de back-upschema.
Documenteer het resultaat — wie deed het, wat werd teruggezet, hoe lang het duurde, wat brak. Dit wordt bewijs voor management en een checklist voor het volgende echte incident.

Een snelle checklist voor een echte toepassingsback-upstrategie

Databasebestanden en alle gekoppelde bestanden opgenomen
Externe/externe containeropslag op hetzelfde schema back-upt
Serverconfiguratie, planning en certificaten gedocumenteerd en back-upt
Integratigereferenties en scripts apart gedocumenteerd
RPO en RTO gedefinieerd in plaine bedrijfstermen, overeengekomen met management
Progressieve + nachtelijke + weekelijkse + maandelijkse back-uptiers aanwezig
Ten minste één off-site of cloud-kopie, geïsoleerd van het productienetwerk
Onveranderbare/write-once-opslag voor recente back-ups (ransomware-bescherming)
Standbyserver aanwezig voor systemen waar minuten uitvaltijd belangrijk zijn
Herstel werkelijk getest op planning, met gedocumenteerde resultaten

Veelgestelde vragen: toepassingsback-upstrategie voor FileMaker-systemen

Hoe lang moeten we oude back-ups bewaren? Minimaal: genoeg dagelijkse kopieën om een week te dekken, weekelijkse kopieën voor een maand, en maandelijkse kopieën voor een jaar. Regelgeving of industrievereisten kunnen dit verder verlengen — controleer wat op uw gegevens van toepassing is.

Is cloudback-up alleen genoeg? Alleen als het werkelijk geïsoleerd is van uw productienetwerkreferenties — een cloudback-up bereikbaar door een aangetast beheersaccount biedt weinig extra bescherming tegen ransomware.

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

Wie moet verantwoordelijk zijn voor het testen van herstellen? Iemand buiten dagelijkse operaties, bij voorkeur met goedkeuring van management op de resultaten, zodat testen niet stilletjes wordt overgeslagen als het druk wordt.

Een back-upstrategie is nooit werkelijk "klaar" — deze moet zich ontwikkelen naarmate het systeem, de integraties en de tolerantie van het bedrijf voor uitvaltijd veranderen. Als u niet zeker weet of uw huidige instellingen werkelijk zouden standhouden in een werkelijk incident, is dat een goed startpunt voor een gesprek. Loggix kan helpen een back-up- en continueringstrategie rond een aangepaste FileMaker-oplossing controleren of bouwen — inclusief standbyserverinstellingen, externe back-upconfiguratie en herstellingstest — als onderdeel van een breder onderzoek naar hoe uw bedrijfscriterium software beveiligd en onderhouden wordt.