Volledige naslag

Dezelfde tekst als de Help in het portaal, op één pagina. De documentatie met schermafbeeldingen is de kortere, geïllustreerde versie, ook in het Engels en Frans.

Deze handleiding beschrijft het portaal zoals het nu werkt en wordt samen met de software bijgewerkt. Vragen of opmerkingen: support@zekura.eu.

Zelf beginnen

Registreren. Op app.zekura.eu/register maakt u een account aan met bedrijfsnaam, e-mailadres en wachtwoord (minstens 12 tekens). Na de bevestigingsmail maakt Zekura uw organisatie aan: eigen opslag met eigen sleutels, een standaardbeleid en een bewijsketen. U komt terecht op Aan de slag, dat u in zes stappen naar de eerste geverifieerde backup brengt. Een van die stappen is de herstelsleutel: u krijgt de sleutel van uw backups in vijf delen, waarvan u er drie nodig hebt om ook zonder Zekura te kunnen terugzetten. Bewaar die delen op verschillende plaatsen en bevestig dat in het portaal. Daarna wist Zekura de delen. Wie de sleutel volledig zelf wil beheren (sovereign) kan dat kiezen bij het toevoegen van eigen opslag.

Voorwaarden. Bij de registratie aanvaardt u de algemene voorwaarden en de verwerkersovereenkomst; tijdstip, versie en IP-adres komen als record in uw bewijsketen. Is uw organisatie door Zekura of door uw IT-partner aangemaakt, of is er een nieuwe versie, dan vraagt het portaal een eigenaar om ze te aanvaarden (Instellingen → Voorwaarden).

Wachtwoord vergeten stuurt een link (2 uur geldig). Tweefactorauthenticatie (TOTP, elke authenticator-app) zet u aan onder Account; daarna vraagt het aanmelden een code. Aanbevolen voor elke beheerder, verplicht voor IT-partners.

Status. app.zekura.eu/status toont zonder aanmelding of het portaal, de planner, de verifiers, de workers en de publicatie van de ankerpunten werken, plus lopende incidenten (ook als JSON op /api/status). Deze documentatie staat ook openbaar op zekura.eu/docs, uit dezelfde bron als deze Help.

Agent-updates. De agent controleert bij elke heartbeat of er een nieuwere release is op het uitrolkanaal van uw organisatie (stable, beta of geen). Hij haalt de binary op, controleert sha256 én de Ed25519-handtekening van het platform, vervangt zichzelf atomisch en herstart via systemd, alleen tussen twee opdrachten door, nooit tijdens een backup. Een binary zonder geldige handtekening wordt geweigerd, wat er ook in de download zit.

Wat Zekura doet

Zekura maakt geen backup en zegt dan "gelukt". Het maakt een backup, zet hem op een aparte machine echt terug, controleert of alles er staat, en legt dat vast in een register dat alleen kan groeien en dat u zelf kan narekenen. Elke stap heeft drie begrippen die in dit portaal terugkomen:

De Restore Assurance Score op het overzicht is één getal per organisatie: hoeveel is beschermd (dekking), hoe oud is de laatste geslaagde run (versheid), en hoe recent is bewezen dat hij terugkomt (bewijs).

Waar staat wat

Het portaal heeft vijf plekken, elk met één vraag.

Bovenaan: zoeken over systemen, opdrachten en runs (Ctrl K), de bel met meldingen, en uw account met de keuze tussen lichte en donkere weergave.

Een systeem toevoegen

1. Ga naar Systemen → Nieuw systeem. U krijgt één commando met een eenmalig token (7 dagen geldig).
2. Voer dat commando uit op de server, als root:

   curl -fsSL {{BASE}}/install.sh | sudo bash -s -- --token <token>
   

3. Binnen een minuut staat de host in de lijst met status "ok".

Wat het commando doet, in die volgorde: zekura-agent (één statische binary, 2,7 MB) en kopia (de opslag-engine) downloaden van dit portaal naar /usr/local, een systemd-service zekura-agent aanmaken, de host registreren met het token, en de service starten. De agent genereert bij registratie een eigen sleutelpaar; met de privésleutel ondertekent hij elk rapport dat hij hierheen stuurt. Die sleutel verlaat de server nooit.

Vereisten: Linux x86-64 met systemd, uitgaand HTTPS naar {{BASE}} en naar de opslag. Voor Postgres in Docker moet docker op de host staan; voor lokale Postgres moet sudo -u postgres psql werken.

Een verifier toevoegen gaat op dezelfde manier via Systemen → Nieuw systeem → verifier. Een verifier maakt geen backups; hij voert de verificaties uit. Zet hem op een andere machine dan de hosts die hij controleert: dat is de hele bedoeling.

Handmatig, zonder het script: download {{BASE}}/downloads/zekura-agent en {{BASE}}/downloads/kopia, en draai zekura-agent enroll --server {{BASE}} --token <token>. De systemd-unit staat in de repository onder agent/zekura-agent.service.

Windows-servers

Dezelfde agent bestaat als zekura-agent.exe voor Windows Server 2019 en nieuwer en voor Windows 10/11 Pro (x64). Onder Systemen, Nieuw systeem staat naast het Linux-commando een PowerShell-commando: dat haalt de agent en Kopia op, registreert de host met hetzelfde eenmalige token en installeert de Windows-service ZekuraAgent (automatisch starten, herstart na een self-update). Het commando start het script met -ExecutionPolicy Bypass, omdat Windows gedownloade scripts standaard weigert ("running scripts is disabled on this system"); dat geldt alleen voor die ene uitvoering, het scriptbeleid van het systeem verandert niet. De statusmap is C:\ProgramData\Zekura\agent, alleen leesbaar voor SYSTEM en Administrators; het logboek staat daar als agent.log.

Wat er op Windows werkt: bestanden en mappen (met Volume Shadow Copy, dus ook open bestanden), de cloud-bronnen (Microsoft 365, Google Workspace, met de exe als connector), en SQL Server op de server zelf: laat de container leeg en vul de instantienaam in; zonder gebruiker gebruikt de agent Windows-authenticatie met het account van de dienst (LocalSystem, geef dat account de rol sysadmin of db_backupoperator). De inventaris meldt diensten, SQL Server-instanties met hun databanken, Hyper-V-VM's en serverrollen; het tabblad Onderdelen van het systeem toont databanken zonder opdracht zoals op Linux.

Nog niet op Windows: Hyper-V-backups en Active Directory (sprint 17), een ondertekende MSI-installer (SmartScreen waarschuwt bij het downloaden van de exe) en de verifier-rol met proefrestores van SQL Server-ketens (die draaien op een Linux-verifier in een container).

Eigen opslag gebruiken

Standaard gaan uw versleutelde blokken naar de opslag van Zekura in de EU (één of twee locaties, naargelang uw keuze). U mag ook uw eigen S3-bucket gebruiken, bij eender welke S3-compatibele partij: AWS, Hetzner, Scaleway, Impossible Cloud, een eigen MinIO. Dan hebben wij zelfs de opslag niet in handen; wij zien alleen versleutelde blokken die u zelf bewaart.

Instellingen → Opslag → Bestemming toevoegen. Vul endpoint, bucket, prefix en sleutels in. Zekura test de bucket meteen en toont het resultaat:

Een bestemming die de test niet doorstaat, is wel te gebruiken (bijvoorbeeld tijdens het inrichten), maar het portaal toont hem rood en de Restore Assurance Score rekent hem als zwak. Gebruik Test opnieuw nadat u de bucket hebt aangepast.

Huawei OBS (Cubixion). Deze partij eist een Content-MD5 op enkele beheeroproepen en aanvaardt de tijdstempels waarmee Kopia de object lock verlengt niet. Zekura vangt dat op: de lifecycle-regel wordt met MD5 gezet en de object lock wordt elke drie dagen door Zekura zelf verlengd (hele seconden). U ziet dat onder Onderhoud op de pagina van de bestemming; elke verlenging komt in de bewijsketen.

Twee sleutels. De agent-sleutel staat op uw servers en mag alleen toevoegen. De worker-sleutel mag verwijderen en wordt alleen gebruikt door onderhoud en verificatie op onze aparte compute, nooit op uw server. Geeft u alleen een agent-sleutel, dan gebruiken de verifiers die ook; dat werkt, maar onderhoud (opruimen van oude snapshots) kan dan niet.

Wat u moet weten: onder object lock blijft alles wat geschreven wordt: ook het kleine probe-object van de test, de volledige bewaartermijn staan. En de garantie "wij kunnen niet wissen" hangt bij eigen opslag af van úw IAM-instellingen; de test controleert wat hij kan, niet wat hij niet kan zien.

Uw herstelsleutel: managed of sovereign

Elke bestemming heeft een klantsleutel (32 bytes). Daaruit wordt het wachtwoord van de versleutelde repository afgeleid (HKDF), nooit andersom. Bij het aanmaken van een bestemming kiest u wie die sleutel heeft:

De shares. Het zijn stukken van de sleutel volgens Shamir: met drie willekeurige shares is hij volledig te reconstrueren, met twee weet u letterlijk niets. Bewaar ze op vijf plaatsen (twee mensen, een kluis, een wachtwoordmanager, papier). Het portaal toont ze precies één keer en vraagt u te bevestigen dat ze bewaard zijn; die bevestiging staat in de keten (escrow_confirmed). Zonder bevestiging krijgt u na een week een waarschuwing.

Escrow-test. Eens per jaar (of wanneer u wil: Instellingen → Opslag → escrow-test) geeft u drie shares op. Zekura bouwt de sleutel in het geheugen, vergelijkt de vingerafdruk en gooit hem weg. Geslaagd of niet, het staat in de keten (escrow_test_passed / escrow_test_failed). Na een jaar zonder test krijgt u escrow_test_due. Een sleutel die u niet getest hebt, hebt u niet.

Herstellen zonder Zekura. Installeer de agent op een schone machine, zet de sleutel (zekura-agent key --shares …; de vingerafdruk moet kloppen), en de agent kan met de bucket-credentials verbinden en terugzetten. Wij hoeven daarvoor niet te bestaan.

Rotatie van de platformsleutel. De handtekeningen ónder de keten komen van Zekura's eigen Ed25519-sleutel. Die wordt geroteerd; elk record draagt het keyId van de sleutel die het tekende en de export bevat alle publieke sleutels (publicKeys[]). zekura-verify kiest per record de juiste sleutel; oude records blijven voor altijd verifieerbaar (ADR-0008).

Een opdracht aanmaken

Wat is er nog niet beschermd? Open een systeem onder Systemen, tabblad Onderdelen: daar staat, per Docker-project, alles wat de agent heeft ontdekt (databank-containers, losse databanken binnen een server, named volumes en de systeemconfiguratie) naast wat een opdracht beschermt. Onbeschermde onderdelen staan bovenaan, met een knop die het opdrachtformulier vooraf invult. Ook een opdracht die uit staat of alleen handmatig draait, wordt daar als "zonder planning" gemarkeerd. Duikt er iets nieuws op dat nergens in zit, dan krijgt u een melding (Meldingen, en via uw kanalen): één per host, met de lijst erin. Een nieuwe databank in een bestaande PostgreSQL of MySQL verschijnt binnen enkele minuten; een opdracht met een lege databanklijst dekt die automatisch, een opdracht met een vaste lijst niet.

Sjablonen. Onder Sjablonen bundelt u soort, standaardinstellingen, planning en bewaarbeleid. Kies bij een nieuwe opdracht het sjabloon en het formulier staat vooraf ingevuld; u kiest alleen nog host en onderdeel. Handig om nieuwe systemen snel en uniform te beschermen.

Backups → Nieuwe opdracht. Kies de host, en dan de soort:

Bestanden en mappen

Geef één of meer paden op (één per regel), en eventueel uitsluitpatronen (*.tmp, cache/). De agent leest de paden als root; permissies, symlinks en attributen gaan mee. Goede eerste kandidaten: /etc, configuratiemappen van uw diensten, uploadmappen.

PostgreSQL: point-in-time recovery

Kies PostgreSQL, point-in-time recovery. Twee dingen gebeuren dan:

1. Base backup volgens de planning (wekelijks is genoeg; het is een pg_basebackup van de hele cluster, gecomprimeerd en gededupliceerd in de opslag). Kan ook op de knop Base backup nu.
2. WAL-shipping, continu: de agent start pg_receivewal op een replication slot (zekura) in de Postgres-omgeving en zet elke N minuten (uw WAL-interval, standaard 5) de nieuwe write-ahead-log in de opslag. Bij elk transport legt hij vast: de LSN en de rijenaantallen van de vijf grootste tabellen per databank, in één consistent meetpunt. Dat is wat de L3-verificatie nateelt.

Het WAL-interval ís uw RPO: bij 5 minuten verliest u bij een ramp hooguit vijf minuten. Op de opdrachtpagina staat de RPO van dit moment, en u krijgt een melding rpo_breach als de shipping drie intervallen achterloopt.

Terugzetten naar een tijdstip: opdracht → Terugzetten naar een tijdstip. Kies host, tijdstip (leeg = zo recent mogelijk) en een werkmap. De agent zet base backup en WAL uit, start een wegwerp-Postgres van dezelfde hoofdversie op een vrije poort op die host, speelt af tot het tijdstip en meldt de verbindingsgegevens op de run-pagina en in de keten (restore_completed). De container blijft staan tot u hem weghaalt, zodat u erin kan kijken, een dump kan nemen, of hem als nieuwe productie-instantie kan gebruiken.

L3-verificatie, wekelijks en automatisch: de verifier doet exact dezelfde restore tot de LSN van het laatste meetpunt, telt de tabellen na, vergelijkt met wat de agent op dat moment mat, en schrijft het verdict in de keten. Container weg. Dat is het "wij zetten uw databank echt terug en tellen na" van de voorpagina.

Wat u moet weten:

• De replication slot houdt WAL vast zolang de agent niet streamt. Is de agent lang weg, dan groeit pg_wal op de bron. Zet daarom max_slot_wal_keep_size (Postgres ≥ 13) op een veilige waarde; Zekura meldt rpo_breach lang vóór dat een probleem wordt. Opdracht uitschakelen = slot droppen.
• Base backup en WAL staan tijdelijk op de host in /var/lib/zekura-agent/work/; reken op de grootte van de databank aan vrije ruimte.
• docker (bij Docker-modus) en pg_basebackup/pg_receivewal in de Postgres-omgeving zijn vereist, die zitten in elk officieel Postgres-image.

PostgreSQL: dump per databank

Eenvoudiger alternatief: een consistente logische dump per databank (pg_dump, custom formaat, gecomprimeerd), plus rollen, plus dezelfde tabelmetriek. Een momentopname: wat ertussen gebeurt, is weg. Goed voor kleine databanken waar een nachtelijke dump volstaat.

Beide varianten bereiken Postgres zonder wachtwoord: Docker-container (docker ps-naam; alles draait ín de container als de postgres-gebruiker) of lokaal via socket (sudo -u postgres). Laat "databanken" leeg voor alles behalve de templates en postgres. De databankrol wordt automatisch bepaald (Docker: POSTGRES_USER, anders postgres).

Inventaris. Op de systeempagina ziet u per systeem wat de agent gevonden heeft: volumes, containers (en welke daarvan Postgres, MySQL of Gitea zijn), vrije schijfruimte. Het opdrachtformulier gebruikt dat om u te laten kiezen in plaats van te laten typen.

Docker-volumes

Kies de host; het formulier toont de named volumes uit de inventaris die de agent elke vijf minuten meestuurt (anonieme volumes met een 64-tekens-naam blijven weg). Vink aan wat mee moet. De agent leest het volume op de host zelf (/var/lib/docker/volumes/<naam>/_data). Met containers pauzeren worden de containers die het volume gebruiken tijdens de snapshot kort bevroren (docker pause): consistent, maar merkbaar, voor databanken gebruikt u beter de Postgres- of MySQL-workload.

MySQL / MariaDB

Consistente dump per databank (mysqldump --single-transaction, met routines, triggers en events) via de container; het wachtwoord komt uit de omgevingsvariabele van de container (standaard MYSQL_ROOT_PASSWORD), er wordt niets in Zekura bewaard. Leeg = alle databanken behalve de systeemdatabanken. Tabelmetriek (geschatte rijen) gaat mee.

SQL Server

Geen dumps maar de native backupketen van SQL Server, via sqlcmd in de container (of lokaal op een Linux-host met SQL Server): een full backup als er geen verse is (standaard om de 24 uur), een differential als die vervallen is (standaard om de 6 uur, 0 = uit) en bij elke run een logbackup van databanken in herstelmodel FULL of BULK_LOGGED. De planning van de opdracht is dus uw RPO: elke 15 minuten geeft hoogstens 15 minuten verlies. Databanken in herstelmodel SIMPLE krijgen alleen full en differential. Alles gaat met CHECKSUM en, buiten de Express-editie, met compressie. Bij TDE gaat het certificaat met de private sleutel mee in de keten (versleuteld, met een eigen wachtwoord dat in de keten zelf bewaard wordt, dus alleen leesbaar met uw herstelsleutel).

De keten staat in de werkmap van de agent en gaat elke run als geheel in de snapshot; Kopia dedupliceert de ongewijzigde full, dus een logbackup kost alleen de logbytes. Het wachtwoord komt uit de omgevingsvariabele van de container (MSSQL_SA_PASSWORD), Zekura bewaart het niet. Zekura beheert de logketen: laat geen ander programma tegelijk logbackups van dezelfde databank nemen, die breken de keten.

Terugzetten naar een tijdstip: op de opdrachtpagina kiest u een tijdstip en een werkmap; de agent zet de keten uit, start een wegwerp-SQL Server (zelfde hoofdversie, Developer-editie) op een vrije poort, past full, differential en logs toe met STOPAT en meldt poort en wachtwoord in het restore-rapport. L3 doet elke week hetzelfde op de verifier en telt de grootste tabellen na. De verifier heeft daarvoor 2 GB vrij geheugen nodig.

Gitea

Eén consistente set: eerst de wachtrijen leegmaken (gitea manager flush-queues), dan de Postgres-databank dumpen, dan de data-map (repositories, LFS, app.ini, avatars) en de extra paden (compose-bestand, Actions-runner). Herbouwen op een lege machine: data-map terugzetten, pg_restore van de dump, compose starten, zie lab/gitea-rebuild-test.sh in de repository voor de geteste procedure.

Mailcow

Eén consistente set van alles wat een mailserver nodig heeft om weer mail te zijn: de MariaDB-databank (domeinen, mailboxen, aliassen, wachtwoorden), de maildirs (vmail), de crypt-sleutels (zonder die zijn de mails onleesbaar), Postfix-wachtrij, Redis (quota, rspamd-instellingen) en mailcow.conf + data/conf. Niets wordt gepauzeerd: maildirs zijn per bestand atomisch en de dump is --single-transaction. Geef alleen de compose-map op; het wachtwoord komt uit mailcow.conf en gaat via de omgeving, nooit via de commandoregel.

L3 (wekelijks): de dump wordt in een wegwerp-MariaDB geladen, de actieve mailboxen worden geteld en voor elke mailbox wordt gecontroleerd dat haar maildir in de teruggezette vmail staat. Een mailserver herbouwen: mailcow.conf + data/conf terugzetten, docker compose up, volumes vullen vanuit de terugzetting, dump laden, de volgorde uit de Mailcow-documentatie.

Nextcloud

Maintenance-modus aan (gebruikers zien even "onderhoud"), Postgres-dump, dan html (met config/config.php en apps) en de data-map, en maintenance-modus weer uit, altijd, ook als de dump mislukt. Grote data-mappen gaan incrementeel (alleen nieuwe blokken vertrekken), maar het onderhoudsvenster duurt zolang de scan duurt; kies daarom een frequentie die past (bv. om de 4 uur, met een extra databank-dump per uur ertussen). Met "maintenance": false wordt er niets afgesloten, ten koste van een mogelijk inconsistente set.

L3 (wekelijks): wegwerp-Postgres + wegwerp-Nextcloud op de teruggezette mappen; occ status moet installed zijn en occ files:scan --all foutloos. Dat is de acceptatie uit het sprintplan, elke week opnieuw.

Proxmox-VM's

vzdump in snapshot-modus (of suspend/stop) naar de werkmap van de agent op de Proxmox-node, daarna gesnapshot naar de repository. Getest op een Proxmox VE 9.2-node in het lab (september 2026): de agent op de node maakt de vzdump in snapshot-modus terwijl de VM draait en zet hem in de repository.

Kubernetes

Resources per namespace als YAML (deployments, statefulsets, services, configmaps, secrets, ingresses, PVC's, RBAC, cronjobs, …) plus de inhoud van elke PVC via een datamover, naar het model van Velero: is er een CSI-VolumeSnapshotClass, dan eerst een snapshot en een tijdelijke PVC daaruit (consistent moment); anders wordt de levende PVC read-only gemount (consistent per bestand). Een helper-pod streamt de inhoud als tar naar de agent, die hem als snapshot wegschrijft. De agent heeft kubectl en een kubeconfig op de host nodig; hij draait niet ín het cluster.

Restore: naar een map (tar + YAML), of rechtstreeks in een PVC, geef als doel pvc:namespace/naam; bestaat de PVC niet, dan wordt hij aangemaakt (grootte opgeefbaar). Daarna kubectl apply -f resources/<namespace>.yaml voor de workloads. L3 (wekelijks): elke tar wordt uitgepakt en het aantal bestanden vergeleken met wat de datamover zag.

L4: opstarten (Proxmox)

Voor proxmox-vm-opdrachten plant Zekura maandelijks een boot-test: de verifier op de Proxmox-node zet de vzdump terug als nieuwe VM (qmrestore, zonder netwerk), start hem en meet de tijd tot de guest agent antwoordt; daarna wordt de proef-VM weggegooid. Het verdict en de boottijd komen in de keten. Instelbaar per opdracht: testVmid, testStorage, bootTimeoutSecs. Alleen een verifier die zichzelf als Proxmox-node meldt (qmrestore aanwezig) krijgt deze taken. De restore met qmrestore is in het lab getest; de opstarttest zelf wacht op een node met echte virtualisatie, want in het lab draait Proxmox zelf geëmuleerd en start een VM daarin te traag.

Applicatie-healthcheck (L3 voor bestanden)

Voor filesystem-opdrachten kunt u zelf bewijzen dat de terugzetting werkt, niet alleen dat de bytes kloppen: zet in de spec een healthcheck, een shell-opdracht die de verifier wekelijks tegen de teruggezette map draait ($RESTORE_DIR, ook de werkmap; max. 15 min; exit 0 = geslaagd).

{ "paths": ["/srv/app"], "healthcheck": "test -f \"$RESTORE_DIR/config.php\" && php -l \"$RESTORE_DIR/config.php\"" }

Dump-opdrachten hebben hun L3 ingebouwd: postgres-dump wordt wekelijks in een wegwerp- Postgres teruggeladen en per databank nageteld tegen de metriek van de run; mysql-dump idem in een wegwerp-MariaDB/MySQL (de rijtellingen van MySQL zijn schattingen: tolerantie 20 %, kleine tabellen exact).

Planning

Cron-achtig, in Belgische tijd. Elke run krijgt automatisch tot tien minuten willekeurige vertraging zodat niet al uw hosts om exact 02:00 tegelijk naar de opslag stormen. "Handmatig" betekent: alleen via Nu draaien. Na elke run wordt de volgende automatisch ingepland; u ziet het tijdstip in de lijst.

Wat er na een run gebeurt

Wat is er precies geback-upt? Open de run: onder "Wat er is geback-upt" staat per pad of onderdeel het aantal bestanden, de logische en nieuwe omvang, het aantal fouten en de snapshot. Bij een databank staan de metingen van de agent (tabellen, rijen, WAL) erbij. Ging iets mis, dan staat bovenaan de fout in gewone taal en daaronder het logboek van de agent: de laatste regels van de backup-engine, zodat u de oorzaak ziet zonder op de server te moeten kijken.

1. De agent maakt de snapshot en stuurt een ondertekend rapport: hoeveel data nieuw was, hoeveel bestanden, de snapshot-ID.
2. Het platform controleert de handtekening en schrijft record snapshot_completed in de keten.
3. Er wordt meteen een L1-verificatie ingepland. Een verifier haalt ze op, verbindt met de opslag met een lege cache (alsof het een nieuwe machine is), leest élk object van de snapshot terug en controleert alle checksums.
4. De verifier stuurt een ondertekend verdict; het platform schrijft record verification_passed of verification_failed.

Waarom die lege cache er zo nadrukkelijk staat: tijdens de bouw bleek dat een repository die op de bronmachine kerngezond lijkt, op een verse machine onleesbaar kan zijn, de lokale cache maskeert het. Daarom verifieert Zekura zoals een restore, niet zoals de bron.

Op de pagina van een run ziet u de snapshot, de handtekening van de agent, en per verificatie het bewijsmateriaal (aantal objecten gelezen, duur, versie van de engine).

Mislukt een run, dan wordt dat óók ondertekend en vastgelegd (snapshot_failed). Het register verzwijgt niets.

Microsoft 365 en Google Workspace

Cloudbronnen back-upt Zekura via een connector-host: een kleine Linux-VM van u of van uw IT-partner waarop de gewone agent draait. Die haalt mail en bestanden via de API van Microsoft of Google op, houdt een incrementele spiegel bij en snapshot die naar uw opslag, versleuteld zoals alles. De verbindingsgegevens staan versleuteld op die VM (<state>/cloud, sleutel alleen leesbaar door root) en gaan nooit naar het platform; een opdracht verwijst alleen naar de naam van de verbinding.

Microsoft 365. Maak in Entra ID een app-registratie met applicatiemachtigingen voor Microsoft Graph en geef beheerderstoestemming: User.Read.All, Files.Read.All, Sites.Read.All, Mail.Read (voor terugzetten in de tenant ook Files.ReadWrite.All, Sites.ReadWrite.All, Mail.ReadWrite). Noteer tenant-id, client-id en een client-secret. Op de connector-host:

zekura-agent cloud add --name klantA --provider m365 --tenant-id <tenant> --client-id <client> --client-secret <geheim>
zekura-agent cloud test --name klantA

Google Workspace. Maak in Google Cloud een serviceaccount met een JSON-sleutel, zet in de Workspace-beheerconsole domeinbrede delegatie aan voor dat account met de scopes admin.directory.user.readonly, drive.readonly, gmail.readonly (voor terugzetten drive en gmail.modify). Op de connector-host:

zekura-agent cloud add --name klantB --provider google --service-account-file sa.json --subject beheerder@bedrijf.be
zekura-agent cloud test --name klantB

Binnen enkele minuten staan de gebruikers, mailboxen, OneDrives en sites van die verbinding op het tabblad Onderdelen van de connector-host; met één klik maakt u er een opdracht voor. De soorten: OneDrive en SharePoint, Exchange Online, Google Drive, Gmail. Google-documenten worden als docx, xlsx, pptx of pdf bewaard. Mail komt per bericht als .eml in de snapshot, dus ook zonder Zekura leesbaar.

Terugzetten. Naar een map op de connector-host, of rechtstreeks terug in de tenant met een doel zoals cloud:klantA/onedrive/jan@bedrijf.be of cloud:klantA/mail/jan@bedrijf.be. Dat komt altijd onder een map Zekura-restore, nooit over het origineel. Elke week zet Zekura een kleine steekproef terug onder Zekura-verify, leest ze terug, vergelijkt en ruimt op: dat is niveau 3 voor cloudbronnen en staat als bewijs bij de run.

Een restore uitvoeren

Ga naar Herstel en bewijs → Terugzetten, kies de opdracht en het moment (of open een geslaagde run onder Backups → Activiteit en kies Deze snapshot terugzetten). Kies de doelhost (mag een andere zijn dan de bron, als daar een agent draait), de doelmap, en optioneel alleen bepaalde paden binnen de snapshot. De agent op de doelhost haalt de opdracht op, zet terug, telt en hasht wat er staat, en meldt het ondertekend terug. Het resultaat staat op de run-pagina en als record restore_completed in de keten, mét duur, want gemeten hersteltijd is precies wat een auditor wil zien.

Wat u moet weten:

• Bestaande bestanden in de doelmap worden overschreven. Zet terug naar een lege map als u wil vergelijken.
• Een Postgres-dump komt als bestanden terug (<db>.pgdump, globals.sql, zekura-metrics.json). Inladen: pg_restore -d <db> <db>.pgdump. Vanaf fase 3 gebeurt dat automatisch, met tijdkiezer.
• Zonder portaal, op de host zelf: kopia snapshot restore <id> <map> met de configuratie in /var/lib/zekura-agent/repos/<repository>/.

Wijzigingen met uitstel

Even pauzeren voor onderhoud. Op de opdrachtpagina of de hostpagina zet u een pauze van één uur tot drie dagen, met een reden. Die gaat meteen in: de agent slaat de opdracht(en) over en er komt geen "backup niet gestart"-melding. Alle beheerders krijgen een melding en het staat in de bewijsketen. Na afloop loopt alles vanzelf weer; een gemiste run wordt meteen ingehaald. Langer stilleggen kan alleen met de wachttijd hieronder.

Een systeem verwijderen. Op de hostpagina, onder "Host buiten dienst stellen". Heeft de host geen opdrachten, dan gaat het meteen in. Heeft hij er wel, dan is het een verzwakking en geldt de wachttijd van 72 uur, met melding en annuleerknop onder Wijzigingen. Daarna wordt de agent niet meer aanvaard en staan de opdrachten uit. Runs, verificaties en de bewijsketen blijven bewaard, en de backups in de opslag blijven staan zolang hun bewaartermijn loopt; u kunt ze dus nog terugzetten.

Alles wat uw bescherming verzwakt, een opdracht uitschakelen, een bewaartermijn inkorten, gaat pas 72 uur later in. Iedereen krijgt meteen een melding (change_requested), de wijziging staat onder Wijzigingen met een annuleerknop, en de aanvraag én de uitvoering komen in de bewijsketen. Wie uw account overneemt, kan uw backups dus niet dezelfde dag nog waardeloos maken; u heeft drie dagen om het terug te draaien.

Onderhoud, opruimen en de ransomware-remmen

De agent ruimt nooit op. Een aparte worker (eigen host, eigen sleutel met wisrechten, nooit op een klantserver) doet het onderhoud van de repository: dagelijks een lichte beurt, wekelijks een volledige. Elke beurt is een ketenrecord maintenance_completed met het aantal verwijderde blobs. Onder object lock zijn die verwijderingen alleen delete markers; de gelockte versies blijven staan tot de bewaartermijn om is en de lifecycle-regel van de bucket ze fysiek opruimt.

Reclaim en herstel. Bij een opslagpartij zonder lifecycle-regels (Impossible Cloud kent ze niet) ruimt Zekura wekelijks zelf de verlopen niet-actuele versies op met de worker-sleutel, gelockte versies weigeren, en dat is de bedoeling (reclaim_completed in de keten). De knop Herstel overschrijvingen onder Instellingen → Opslag verwijdert rommelversies van blobs die iemand met schrijfrechten overschreven heeft, zodat het gelockte origineel weer actueel is (repair_completed).

Delete-marker-monitor. Dagelijks telt Zekura de delete markers onder elke bestemming en vergelijkt dat met wat de keten verklaart (onderhoud plus de sessiemarkers van de agent). Onverklaarde markers, iemand met worker-rechten die objecten verbergt, geven een critical melding unexplained_delete_markers. De data zelf is dan nog niet weg.

Anomaliedetectie. Springt het aandeel nieuwe data in een run plots omhoog ten opzichte van de vorige runs (en gaat het om meer dan 50 MB), dan is dat hoe versleuteling door ransomware eruitziet. Zekura meldt anomaly_detected, schrijft het in de keten en zet een hold op de opdracht: de worker ruimt niets meer op van die opdracht tot u de hold opheft, zodat de snapshots van vóór de versleuteling blijven bestaan.

Aanvalssimulatie. lab/attack-sim.sh in de repository speelt een aanvaller met root op een klanthost en de agent-sleutel: recursief wissen, versies wissen, retentie wissen, overschrijven, onderhoud draaien, alle snapshots verwijderen. Daarna wordt de data hersteld via het root-object dat in de keten staat. Dat is de test waarmee we het model onderbouwen.

Meldingen instellen

Meldingen → Kanaal toevoegen. Drie soorten: webhook (POST met JSON, optioneel een geheim in de header x-zekura-secret), e-mail (SMTP) en Matrix (bot-token en kamer). Per kanaal kiest u vanaf welke ernst het meldt. Gebruik Test om te zien of het aankomt.

Wat Zekura meldt:

Alle meldingen staan ook onder Meldingen in het portaal, met per kanaal of ze afgeleverd zijn.

De Restore Assurance Score

Eén getal per organisatie, 0–100, uit drie delen:

• Dekking (30 %): wat volgens de inventaris beschermd zou moeten zijn (draaiende Postgres-, MySQL- en Gitea-containers, en /etc van elke host) versus wat een opdracht heeft. Het overzicht toont de gaten met een knop om een opdracht te maken.
• Versheid (30 %): leeftijd van de laatste geslaagde run ten opzichte van het verwachte interval van de opdracht (uit de planning of het WAL-interval).
• Bewijs (40 %): de diepste geslaagde verificatie (L1 integriteit 0,5 · L2 steekproef 0,7 · L3 applicatie 0,9 · L4 opstart 1,0), verouderend na een dag, een week, een maand. Een anomalie-hold halveert het bewijs tot u hem opheft.

De score wordt dagelijks bewaard; het overzicht toont de laatste veertien dagen.

Omvangsschatting. Bij een nieuwe bestandsopdracht schat de agent eerst de omvang (met uw uitsluitingen) vóór de eerste run; boven 5 GB krijgt u een waarschuwing. Onder object lock blijft alles wat geschreven wordt de hele bewaartermijn staan, beter één keer meten.

Rapporten voor auditors

Herstel en bewijs → Rapporten → Rapport uitgeven maakt een kwartaal- of maandrapport als PDF (Nederlands, Frans of Engels): Restore Assurance Score, beschermde systemen met laatste geslaagde run, runs, verificaties per niveau, herstellingen met gemeten hersteltijd, opslag en onveranderlijkheid per bestemming, sleutelmodel en escrow-test, en de ketenankerpunt aan het einde van de periode met de datum en ankerpunt van de onafhankelijke publicatie. Daarna de normmapping: per vereiste uit NIS2 art. 21(2)(c), ISO/IEC 27001:2022 A.8.13 en A.5.30, CyFun PR.IP-4 en PR.DS/PR.PT, DORA art. 11 en 12, GDPR art. 32(1)(c) welk bewijs in het rapport staat en of de vereiste voldaan, gedeeltelijk of niet voldaan is, beoordeeld op de feiten van de periode, niet op beloften.

Het rapport is zelf bewijs: de sha256 van het PDF wordt ondertekend met de platformsleutel en als ketenrecord report_issued vastgelegd (met keyId en het ankerpunt waarop het rapport steunt). De knop handtekening geeft dat als JSON. Een auditor rekent na met drie stappen die op de laatste pagina van elk rapport staan: sha256 van het bestand, zekura-verify op de ketenexport met --root, en de publieke roots-repository. Demo-tenants krijgen een rapport met de vermelding "synthetische gegevens, geen bewijs".

De bewijsketen narekenen

Herstel en bewijs → Bewijsketen → Exporteer voor zekura-verify geeft een JSON-bestand met alle records en de publieke sleutel van het platform. Reken hem na met het losse hulpprogramma: één bestand, alleen de ingebouwde cryptografie van Node, bewust zonder afhankelijkheden zodat een auditor het in vijf minuten kan lezen:

npx tsx zekura-verify/verify.ts zekura-chain-<tenant>.json

Het controleert per record: de hash van de inhoud, de verwijzing naar het vorige record, de Ed25519-handtekening, en de doorlopende nummering. Verander één cijfer ergens en alles vanaf dat record breekt.

Het ankerpunt wordt elke dag gepubliceerd in de publieke repository git.gotrust.be/gotrust/zekura-roots (openbaar, bevat alleen controlegetallen en publieke sleutels, geen namen of gegevens): per tenant per dag de laatste recordHash, ondertekend met de platformsleutel, in git, met tijdstempel en historiek die ook wij niet kunnen herschrijven zonder dat het opvalt. Controleer uw export ertegen: zekura-verify chain.json --root <recordHash uit de publicatie>. Er is ook een statische binary (zekura-verify, Rust, geen afhankelijkheden) met dezelfde controles.

De publieke sleutel staat op de ketenpagina; geef hem aan uw auditor.

Gebruikers, rollen en units

Beheer → Gebruikers. Iedereen die in uw organisatie mag, staat daar met een rol. Vijf rollen, met vaste betekenis (ADR-0010):

Uitnodigen gaat per e-mail; bestaat het adres al in Zekura, dan krijgt die persoon meteen de rol (één account, meerdere organisaties, wisselen via het vak linksboven). Niemand kan een rol toekennen die hoger is dan de zijne; er blijft altijd minstens één eigenaar. Elke wijziging is een ketenrecord (member_invited, member_added, member_role_changed, member_removed).

Units (business unit, land, team, divisie) zijn scopes binnen één organisatie: hosts en opdrachten kunnen aan een unit hangen, en een gebruiker kan tot units beperkt worden, dan ziet hij alleen de hosts, opdrachten, runs en verificaties van zijn units (plus wat organisatiebreed is). Units delen keten, bestemmingen en sleutels; wie echt gescheiden ketens per divisie wil, maakt er aparte organisaties van onder één ouder.

IT-partners krijgen hun rol op de partner-organisatie en erven die in alle klanten eronder; een klant kan iemand ook rechtstreeks een (ruimere) rol geven. Platformbeheer (Zekura zelf) is een aparte organisatie zonder backups: het ziet tenants, gebruikers, releases en uitgaande mail, maar kan niet in uw organisatie werken tenzij u zelf iemand van Zekura uitnodigt, en dat staat dan in uw keten.

Meldingen, capaciteit en instellingen

• Meldingen (bovenaan het menu, met teller): alles wat het platform meldde, voor uw organisatie en, voor IT-partners, voor alle klanten. Waarschuwingen en kritieke meldingen bevestigt u (ketenrecord alert_acknowledged); zo ziet een collega dat iemand ermee bezig is. Onder Mijn voorkeuren kiest u vanaf welke ernst u persoonlijk mail wil. Instellingen → Meldingen (webhook, e-mail, Matrix) staan apart onder Beheer.
• Capaciteit: wat beschermd is (logisch), wat er fysiek staat na deduplicatie, wat er de laatste 30 dagen verstuurd is, de groei per dag, de grootste opdrachten en hosts, en de quota: een zachte limiet met meldingen bij 80 % en 100 % en een schatting wanneer hij vol is. Een quota blokkeert nooit een backup.
• Instellingen (eigenaar): naam, quota, uitrolkanaal voor agent-updates, organisatie-id.

Meerdere organisaties en IT-partners

Elke organisatie is een tenant: eigen gebruikers, hosts, bestemmingen, opdrachten en een eigen bewijsketen die bij record 1 begint. Niets is over de grens zichtbaar; dat wordt bij elke wijziging opnieuw bewezen door de isolatiesuite (model- én HTTP-tests over elke route en elke rol, in CI).

Een nieuwe tenant aanmaken (platformbeheer → Tenants) doet in één keer: eigen prefix in de Zekura-opslag, eigen IAM-gebruikers (agent: alleen toevoegen; worker: ook opruimen; geen van beide buiten de eigen prefix), lifecycle-regel waar de opslagpartij dat kan, sleutelmodel (managed: de klant haalt de delen zelf op onder Aan de slag; sovereign: vingerafdruk), beheerder met wachtwoord, enrollment-token, en het eerste ketenrecord tenant_provisioned. De geschiktheidstest draait meteen met de nieuwe agent-sleutel en moet "kan niet wissen" zeggen. Wachtwoord en token worden één keer getoond.

IT-partners (MSP)

Een IT-partner is een tenant met klant-tenants eronder. Wat hij krijgt:

• Klanten: alle klanten op één scherm, gesorteerd op risico (laagste Restore Assurance Score bovenaan), met dekking, versheid, bewijs, hosts, laatste run en laatste melding.
• Werken in een klanttenant: één klik, en u ziet en doet alles wat de klant zou zien en doen. Er staat een gele balk bovenaan, en alles wat u doet komt met úw e-mailadres in de keten van de klant. Alleen langs de ouderlijn, nooit zijwaarts naar een andere klant.
• Overerving: nieuwe klanten krijgen een kopie van uw beleidsregels; uw meldingskanalen ontvangen ook de meldingen van uw klanten, met de klantnaam ervoor.
• Huisstijl: productnaam, logo, kleuren, eigen domein (CNAME naar app.zekura.eu; het certificaat wordt automatisch aangevraagd), afzender en support-adres. Uw klanten zien uw merk, ook op de aanmeldpagina van uw domein.
• Verbruik & facturatie: per klant per maand hosts, opslag en verkeer, met de factuurregel volgens het tarief; CSV-export; één klik naar uw facturatiesysteem (webhook), vastgelegd in de keten als billing_submitted. Demo-tenants worden nooit gefactureerd.

Wat werkt vandaag, wat komt eraan

Problemen oplossen

De host verschijnt niet. Op de server: journalctl -u zekura-agent -n 50. Meest voorkomend: het token was al gebruikt of verlopen (maak een nieuw), of de server kan {{BASE}} niet bereiken.

Status "stale" of "offline" bij een host. Stale: vijf minuten niets gehoord; offline: een kwartier. Kijk of de service draait: systemctl status zekura-agent. Bij "offline" krijgt u een melding.

Een host toont "gespoold: 3". De agent kon drie rapporten niet kwijt omdat dit portaal onbereikbaar was; de backups zelf zijn gewoon gemaakt. Zodra de verbinding er is, haalt hij ze in en verschijnen ze hier.

Een run staat op "fail". Open de run; de foutmelding staat bovenaan. Bij bestanden: bestaat het pad, mag root het lezen? Bij Postgres: klopt de containernaam (docker ps), werkt docker exec -u postgres <container> psql -c 'select 1'?

Een verificatie blijft "pending". Er is geen verifier actief, of hij is de opslag niet kunnen bereiken. journalctl -u zekura-verifier -n 50 op de verifier-machine.

Een verificatie is "fail". Dit is het geval waarvoor het systeem bestaat. Kijk naar het bewijsmateriaal op de run-pagina en neem contact op. Verwijder niets.

Hoe het beveiligd is

• Uw data wordt versleuteld op uw server (AES-256-GCM in de engine) vóór ze vertrekt. De opslagpartner ziet alleen versleutelde blokken.
• De agent kan niets wissen. Zijn opslagcredentials mogen toevoegen en lezen. Verwijderen kan alleen een aparte worker, en fysiek opruimen gebeurt pas na de bewaartermijn: ook voor ons niet eerder (object lock in compliance mode).
• De agent kan geen onderhoud draaien. De engine kent een onderhoudseigenaar; dat is de worker, nooit de agent. Ook met gestolen agent-credentials kan er geen maintenance gedraaid worden.
• Agents praten met client-certificaten. Bij registratie krijgt elke host een certificaat van onze eigen CA; zonder geldig certificaat komt een verzoek niet eens bij de applicatie (nginx weigert het). Daarbovenop een per-host token, en daarbovenop de handtekening hieronder. Drie sloten, drie verschillende dreigingen (ADR-0007).
• Uw sleutel is van u. Het repositorywachtwoord wordt afgeleid uit een klantsleutel die u als 3-van-5-shares in handen hebt; in sovereign-modus heeft Zekura hem nooit gehad (zie Uw herstelsleutel).
• Elk rapport is ondertekend door de machine die het maakte (Ed25519), en elk record in de keten door het platform. Twee onafhankelijke handtekeningen per gebeurtenis.
• Dit portaal slaat wachtwoorden op met scrypt, sessies in een ondertekende cookie, en opslaggeheimen versleuteld met een serversleutel. Er draait geen analytics.

Het volledige ontwerp, de beslissingen en hun onderbouwing staan in de repository onder docs/ (architectuur, bouwplan, ADR's).