Wat u opzet
Aanvallers die een netwerk binnendringen, proberen meestal eerst de back-ups te verwijderen of te versleutelen en pas daarna de servers. Een back-up die een gestolen beheerdersaccount kan verwijderen, is daarom niet genoeg. Deze gids bouwt met BackupZit een gelaagde bescherming: een primaire back-up op lokale opslag, een kopie op een andere plek en opslag waarop back-ups niet vernietigd kunnen worden voordat een vastgestelde periode voorbij is, zelfs niet met de inloggegevens van de opslag. BackupZit is gratis en open source (AGPLv3); alles hieronder hoort bij het gratis product.
De 3-2-1-regel, en 3-2-1-1-0
De 3-2-1-regel: 3 kopieën van uw gegevens, op 2 verschillende media, waarvan 1 buiten de deur. De uitbreiding 3-2-1-1-0 voegt 1 kopie toe die onveranderlijk of offline is, en 0 fouten bij het controleren van de back-ups. In BackupZit:
| Onderdeel | In BackupZit |
|---|
| 3 kopieën | De productiegegevens, een back-uptaak en een kopieertaak. |
| 2 media | Twee opslagdoelen, bijv. een NAS via SMB of SFTP en een S3-bucket. |
| 1 extern | De kopie gaat naar de cloud (S3, Azure Blob Storage) of naar een geharde repository in een ander gebouw. |
| 1 onveranderlijk of offline | S3 met Object Lock, een geharde repository of wisselende USB-schijven. |
| 0 fouten | Automatische hersteltests en de controle van alle opgeslagen gegevens, met een melding als iets mislukt. |
U hebt een BackupZit-console nodig met agents op de machines die u beschermt; de handleidingen voor Proxmox VE, Hyper-V en Windows-schijfimages laten die eerste stappen zien.
Stap 1 — Primaire opslag voor snel herstel
Open in de console Opslag → Opslagdoel toevoegen. Kies voor de eerste kopie opslag in het lokale netwerk, zodat back-ups en herstel op volle snelheid lopen: een SMB-share op een bestandsserver of NAS, of een Linux-server of NAS via SFTP (de hostsleutel wordt vastgelegd). Geef het doel een eigen account dat alleen in de back-upmap mag schrijven, en neem de back-upopslag niet op in het Windows-domein.
Bij het opslaan test de console het doel meteen — een verkeerd wachtwoord, een verkeerde hostsleutel of share ziet u nu en niet pas bij de eerste back-up. Verbinding testen in de opslaglijst herhaalt de test.
Stap 2 — Onveranderlijke opslag toevoegen
BackupZit kent twee soorten opslag waarop back-ups niet verwijderd of overschreven kunnen worden voordat hun periode voorbij is. Liefst staat die ook buiten de deur, zodat één doel beide dekt.
Optie A: S3 met Object Lock
- Maak de bucket aan met Object Lock ingeschakeld — bij AWS, Wasabi en Backblaze B2 een optie bij het aanmaken van de bucket, bij MinIO
mc mb --with-lock.
- Voeg een lifecycle-regel toe die niet-actuele versies na één dag verwijdert (MinIO:
mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Een vergrendelde back-up verwijderen voegt alleen een verwijdermarkering toe; de regel maakt de ruimte vrij zodra de vergrendelingen aflopen.
- Voeg in de console een doel van het type S3-compatibel (AWS, Wasabi, Backblaze B2, MinIO, …) toe met endpoint, bucket en een toegangssleutel voor die bucket.
- Vink Onveranderlijke back-ups (S3 Object Lock, compliance-modus) gedurende … dagen aan (standaard 30) en kies een periode die minstens zo lang is als het bewaarbeleid dat u wilt beschermen.
Elk bestand dat de agents schrijven, wordt dan voor die periode plus één dag vergrendeld in compliance-modus: niemand — geen aanvaller met de sleutels, niet de eigenaar van de bucket — kan het eerder verwijderen of overschrijven. Gegevens die een nieuwe back-up uit oudere hergebruikt, krijgen een verlengde vergrendeling, zodat elk herstelpunt de volle periode beschermd is. Op onveranderlijke opslag meldt de verbindingstest zich alleen aan en maakt een lijst, en controleert hij of de bucket echt Object Lock heeft.
Azure en Google Cloud: schakel voor Azure Blob Storage in Azure onveranderlijkheid op versieniveau in met een tijdgebonden bewaarbeleid op de container. Google Cloud Storage werkt als S3-doel, maar zonder de optie Object Lock; stel in plaats daarvan in Google Cloud een bewaarbeleid voor de bucket in (en vergrendel het).
Optie B: geharde repository op uw eigen Linux-server
Op een eigen Linux-server draait backupzit-repo (deb- en rpm-pakketten zitten bij elke GitHub-release):
apt install ./backupzit-repo_*.deb # of: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console # toont de toegangssleutel één keer
backupzit-repo fingerprint # vingerafdruk van het certificaat
Voeg in de console een doel van het type Geharde repository (backupzit-repo op Linux, onveranderlijk) toe met het serveradres (standaard poort 8500), de toegangssleutel en de vingerafdruk.
- Agents en console kunnen alleen bestanden toevoegen; bestaande bestanden worden nooit overschreven.
- Elk bestand krijgt het onveranderlijk-attribuut (
chattr +i) voor de periode die op die server is ingesteld, plus één dag. Zelfs root kan het niet verwijderen zonder eerst het attribuut weg te halen.
- Verwijderingen door clients — door het bewaarbeleid of door een aanvaller met de toegangssleutel — verbergen bestanden alleen tot hun periode voorbij is.
- De periode wordt alleen op de repositoryserver ingesteld; console en agents kunnen haar niet wijzigen.
Schakel na de installatie SSH en andere toegang op afstand uit op die server en bescherm de lokale console, iDRAC/iLO of hypervisortoegang: de bescherming is zo sterk als het root-account van die machine.
Stap 3 — Versleuteling en herstelsleutel
Laat Back-ups versleutelen (AES-256) aan staan (standaard). Bestandsinhoud, namen, mappenstructuur en snapshotlijsten worden met AES-256-GCM versleuteld voordat ze de agent verlaten, en elke wijziging aan de gegevens wordt opgemerkt. Onveranderlijkheid voorkomt verwijderen, versleuteling voorkomt lezen — u wilt beide.
Voor elk versleuteld doel toont de console een Herstelsleutel en biedt een herstelblad aan. Bewaar het offline en gescheiden van de back-ups: met de sleutel, de opslaglocatie en de inloggegevens kunt u ook zonder console herstellen; zonder de sleutel kan niemand de back-ups lezen — ook BackupZit-support niet.
Stap 4 — Back-uptaak en bewaarbeleid
Maak de taak aan onder Back-uptaken met de primaire opslag uit stap 1. Stel onder Back-ups bewaren de nieuwste N plus dagelijkse, wekelijkse en maandelijkse herstelpunten in — bijvoorbeeld 3 recente, 7 dagelijkse, 4 wekelijkse en 6 maandelijkse bewaren ongeveer een half jaar met zo'n 20 herstelpunten. Deduplicatie slaat ongewijzigde gegevens maar één keer op.
Herstelpuntdoel (RPO), uren bepaalt hoe oud de nieuwste goede back-up mag worden, bijv. 26 voor een dagelijkse taak. Een taak die dat niet haalt, verschijnt op het dashboard en wordt gemeld; zo valt ook een agent op die dagenlang offline is of een per ongeluk verwijderd schema.
Stap 5 — Externe kopie met een kopieertaak
Maak een tweede taak aan en kies Back-upkopie. Kies onder De back-ups kopiëren van de taak uit stap 4 en als Opslagdoel het onveranderlijke of externe doel uit stap 2.
- De agent van de brontaak kopieert de bestaande back-ups; de beschermde machine wordt niet opnieuw gelezen.
- Alleen gegevens die nog niet op de bestemming staan, worden verzonden, opnieuw versleuteld met de sleutel van de bestemming.
- Na elke back-up van de brontaak (standaard) houdt de kopie actueel; een gewoon schema kan ook, bijv. eenmaal per nacht bij een trage lijn.
- De kopie heeft een eigen bewaarbeleid, bijv. 7 dagelijkse op de NAS en 12 maandelijkse in de cloud. Elk herstelpunt is N dagen vanaf het ontstaan vergrendeld; bij een vergrendeling van 30 dagen zijn oudere maandelijkse punten dus niet meer beschermd. Een langere vergrendeling beschermt er meer, maar neemt ook meer ruimte in.
Bestands- en VM-back-ups (Proxmox VE, Hyper-V, VMware) worden uit de kopie hersteld zoals uit het origineel; kopieën van schijfimages met de opdrachtregelagent. Nu kopiëren start meteen een kopie.
Offlinekopie voor kleine kantoren: het doeltype Wisselende USB- / verwisselbare schijven (offlinekopieën) vindt schijven aan hun volumelabel (BZBACKUP1, BZBACKUP2 …). Richt een kopieertaak erop, wissel de schijven bijv. wekelijks en bewaar de losgekoppelde op een veilige plek. Is er geen schijf aangesloten, dan mislukt de uitvoering met een melding.
Stap 6 — Hersteltests en gegevenscontrole
Een back-up is pas bewezen als hij is hersteld. Onder Instellingen → Hersteltests:
- De nieuwste back-up van elke taak automatisch testen (standaard wekelijks): een willekeurige steekproef van bestanden uit de nieuwste back-up wordt in een tijdelijke map hersteld, byte voor byte gecontroleerd tegen de opgeslagen controlesommen en weer verwijderd; bij schijfimages worden willekeurige blokken gecontroleerd. Zo worden opslagtoegang, inloggegevens, sleutel en gegevens getest.
- Opgeslagen gegevens controleren (standaard maandelijks): elk stuk gegevens in elke repository wordt gelezen en gecontroleerd, zodat een falende NAS-schijf of sluipend gegevensverval vroeg opvalt. Op S3 en Azure loopt dit alleen met Ook op cloudopslag (S3, Azure) aan — het downloadt alles, let op de downloadkosten.
- Proxmox-VM-taken kunnen een opstarttest toevoegen die elke VM vanuit de back-up start met losgekoppeld netwerk.
Herstel testen en Gegevens controleren op de pagina van een taak starten ze meteen. Resultaten verschijnen onder Activiteit en Rapporten; een mislukte test stuurt een melding zoals elke fout.
Stap 7 — Meldingen en ransomwaredetectie
Een externe kopie die al weken mislukt, is geen kopie. Stel Instellingen → E-mailmeldingen in (controleer met Testmail verzenden) en laat Fouten aan staan: één e-mail per mislukte uitvoering met de reden — back-ups, kopieën, herstel en hersteltests — plus desgewenst een dagrapport. Instellingen → Chat en webhooks stuurt hetzelfde naar Slack, Microsoft Teams of een willekeurig HTTP-endpoint. Op het dashboard toont Vraagt aandacht mislukte taken, gemiste schema's en RPO's, offline agents en opslag die voor 90 % vol is of binnen 30 dagen vol zal zijn.
Elke back-up wordt bovendien vergeleken met de recente geschiedenis van zijn taak. Hij wordt als verdacht gemarkeerd als er veel meer bestanden dan normaal zijn gewijzigd, nieuwe gegevens niet meer comprimeren (versleutelde bestanden lijken willekeurig), het aantal bestanden met een derde of meer is gedaald of de hoeveelheid nieuwe gegevens plotseling is gestegen. BackupZit stuurt dan een melding, toont hem onder verdachte back-ups om te controleren en pauzeert het bewaarbeleid van de taak (Bewaarbeleid is gepauzeerd), zodat de laatste schone back-ups niet worden verwijderd, ook als er beschadigde blijven binnenkomen. Klik na controle van de machine op Gecontroleerd — bewaarbeleid hervatten.
Stap 8 — De console beschermen
Onveranderlijke opslag beschermt de back-ups; de console bepaalt nog altijd wat er wordt geback-upt en bewaard. Vereis onder Instellingen → Aanmelden en beveiliging tweestapsverificatie voor beheerders en schakel Vier-ogengoedkeuring in: taken of opslagdoelen verwijderen, het bewaarbeleid inkorten, het bewaarbeleid hervatten na een verdachte back-up en de goedkeuring uitschakelen vragen dan een tweede gebruiker. Houd de console in het interne netwerk, publiceer poort 8443 niet op internet en gebruik een VPN voor beheer op afstand. Met Instellingen → Consoleback-up maakt de console bovendien elke dag een back-up van zichzelf op een netwerkopslagdoel.
Na een aanval
Zijn back-ups verwijderd of overschreven, lees de opslag dan zoals die vóór de aanval was — alleen lezen, op S3 met Object Lock en op de geharde repository:
backupzit-agent snapshots --repo <repository> --as-of 2026-10-01T14:30
backupzit-agent restore --repo <repository> --as-of 2026-10-01T14:30 --target D:\Restore latest
Op een geharde repository kan de beheerder verborgen bestanden ook terughalen, zodat de back-ups normaal doorlopen:
backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00
Beperkingen
- Onveranderlijkheid duurt alleen zo lang als de vergrendeling. Een verwijderde back-up is na afloop van zijn periode echt weg; kies de periode dus met het oog op hoe lang een aanval onopgemerkt kan blijven.
- Een geharde repository is zo veilig als zijn root-account en de toegang tot zijn console, iDRAC/iLO of hypervisor.
- SMB, SFTP en lokale schijven hebben geen eigen onveranderlijkheid; combineer ze met een onveranderlijke of offline kopie.
- Vergrendelde gegevens nemen ruimte in tot hun vergrendeling afloopt, ook na verwijderen; zonder de lifecycle-regel komt S3-ruimte niet vrij.
- Onveranderlijkheid maakt gegevens niet schoon: bestanden die vóór de back-up zijn versleuteld, worden versleuteld geback-upt. Herstel een punt van vóór de aanval — de detectie houdt die vast door het bewaarbeleid te pauzeren.
- Zonder de herstelsleutel kan niemand versleutelde back-ups lezen.
- Vier-ogengoedkeuring geldt voor de console; beheerdersgroepen in Active Directory of Entra ID moet u daar beschermen.
