Ga naar inhoud
HexaTransfer
Terug naar blog
Cloud & opslag

Bestandsversiebeheer: verlies nooit meer uw wijzigingen

Implementeer bestandsversiebeheer ter bescherming tegen dataverlies. Strategieën voor versiebeheer, opslagoptimalisatie en herstelworkflows.

Bestandsversiebeheer slaat elke revisie op zodat je per ongeluk overschreven, verwijderde of door ransomware beschadigde bestanden kunt terugzetten. Schakel het in op platformniveau — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, Dropbox-versiegeschiedenis, SharePoint major/minor versies — en combineer dit met levenscyclusregels die oude versies na 30–180 dagen laten verlopen. Zonder versiebeheer kan één rm -rf of een falende synchronisatieclient jaren werk in seconden vernietigen, en de "cloudbackup" die je dacht te hebben is slechts een gesynchroniseerde kopie van de schade.

Wat platformversiebeheer werkelijk doet

Wanneer versiebeheer is ingeschakeld, vervangt een overschrijving het object niet — het maakt een nieuwe versie aan met een nieuw VersionId. De oude bytes blijven op schijf staan en zijn ophaalbaar via dat ID. Een verwijdering wordt een "verwijdermarkering" in plaats van een destructie; de vorige versies blijven herstelbaar totdat je ze expliciet verwijdert.

Dit is belangrijk omdat de meeste dataverlies geen catastrofale hardwarestoring is (cloudduurzaamheid vangt dat op). Het gaat om iemand die een lege spreadsheet opslaat over een gevulde, of een script met een bug dat duizend bestanden afkapt, of ransomware die alles versleutelt wat het kan bereiken. Versiebeheer laat je 30 dagen teruggaan en het punt ophalen waar alles nog klopte.

De kosten van het bewaren van elke versie

Versies verbruiken opslag, en opslag kost geld. Een bucket met 10 TB bestanden en actief bewerken kan in een jaar 30–50 TB aan versies ophopen. De oplossing: levenscyclusregels die niet-actuele versies na een bepaalde periode laten verlopen, of ze verplaatsen naar goedkopere lagen.

Een praktisch S3-levenscyclusbeleid:

  • Niet-actuele versies: overgang naar S3 Standard-IA na 7 dagen
  • Niet-actuele versies: overgang naar Glacier Flexible Retrieval na 30 dagen
  • Niet-actuele versies: verwijderen na 180 dagen
  • Verwijdermarkeringen zonder niet-actuele versies: verwijderen na 1 dag

Voor Azure en GCS gebruiken equivalente regels blobVersion-leeftijd of Noncurrent-voorwaarden. Bereken de kosten: 10 TB aan versies in S3 Standard kost €230/maand; in Glacier Flexible is dat €36/maand. De tierovergang is een paar minuten YAML waard.

Major versus minor versies

Documentgeoriënteerde systemen zoals SharePoint, Google Workspace en Notion onderscheiden major (gepubliceerd) van minor (concept) versies. Concepten hopen zich op tussen mijlpalen; majors vertegenwoordigen een stabiele toestand die iemand heeft goedgekeurd. Voor contracten, beleidsDocumenten en specificaties is dit onderscheid goud — je kunt de "major v3"-link publiek delen terwijl je privé verder werkt aan concept v3.1, v3.2.

Gebruik major versies als referentiepunt voor externe belanghebbenden. Vergrendel ze met leesrechten of goedkeuringsworkflows zodat niemand per ongeluk de gepubliceerde toestand overschrijft. SharePoint's "Inhoudgoedkeuring vereist" is één klik; de goedkeuringsflow van Google Drive is een setup van 2 minuten.

Versiebeheer voor broncode versus documenten

Git werkt uitstekend voor tekst (broncode, markdown, .tf-bestanden) omdat diffs zinvol zijn per regel. Voor binaire bestanden werkt het slecht: een .psd-bestand van 50 MB dat twee keer wordt ingecheckt verdubbelt de repositorygrootte, en git diff helpt niet. Git LFS (Large File Storage) verplaatst binaire bestanden naar een aparte opslag en bewaart pointers in de repository — verstandig voor kunstassets, minder geschikt voor algemene documenten.

Voor .docx, .xlsx, .pptx en .pdf-bestanden gebruik je de ingebouwde versiebeheer van het cloudplatform, niet Git. SharePoint, Drive en Dropbox slaan per-versie delta's native op en tonen een tijdlijn-UI die zakelijke gebruikers kunnen navigeren. Voor gemengde inhoud (code plus PDF's plus ontwerpbestanden) gebruiken sommige teams DVC of LakeFS als Git-voor-data-lagen over objectopslag — de moeite waard voor ML- en datateams.

Retentie gekoppeld aan nalevingskalenders

Regelgeving bepaalt hoe lang versies moeten leven. AVG beperkt aan de andere kant — bewaar persoonsgegevens niet langer dan nodig. SEC Rule 17a-4 vereist effectenmakelaarrecords gedurende 3–6 jaar. HIPAA bewaart records minimaal 6 jaar. SOX wil 7 jaar voor financiële records.

Tag gevoelige bestanden zodat levenscyclusregels de regelgevende minimum- en maximumwaarden respecteren. Een S3-tag zoals retention-class: sox-7y kan levenscyclusovergangen, Object Lock-duren en uiteindelijke verwijdering sturen. Gebruik S3 Object Lock met Compliance Mode voor onveranderlijke regelgevende kopieën — zelfs rootgebruikers kunnen niet verwijderen binnen de retentieperiode, wat precies is wat WORM-regels (Write Once Read Many) vereisen.

Ransomwarebescherming via versies

Een ransomware-aanval die je synchronisatieclients bereikt, versleutelt bestanden op het eindpunt en pusht de versleutelde versies naar de cloud. Versiebeheer redt je — de pre-versleuteling-versies bestaan nog steeds. Maar alleen als twee dingen kloppen: versiebeheer was ingeschakeld vóór de aanval, en de retentie is lang genoeg om de detectietijd te overbruggen.

De gemiddelde verblijfsduur van ransomware bij middelgrote bedrijven lag in 2025 rond de 11 dagen. Een versieretentie van 30 dagen is het minimum; 90 dagen is veiliger. Combineer versiebeheer met verwijderbeveiliging (S3 MFA Delete, Azure soft delete met een andere beheerder) zodat een aanvaller die één account comprometteert de versiegeschiedenis niet kan opschonen. Test het herstel elk kwartaal — simuleer verwijdering van een testmap en meet de hersteltijd.

Naamgevingsconventies voor gedeelde versies

Wanneer je een specifieke versie extern deelt — een klant "de goedgekeurde v3 van het contract" sturen — heb je een stabiele aanwijzer nodig die niet verschuift wanneer iemand bewerkt. Gebruik één van drie patronen:

  1. Voorondertekende URL naar een specifiek VersionId (S3: ?versionId=...) — geldig voor maximaal 7 dagen, onveranderlijk
  2. Een kopie van de goedgekeurde versie in een aparte /published/-bucket met de versie in de bestandsnaam (contract-v3.0-2026-12-15.pdf)
  3. Een PDF-exportmomentopname zodat wijzigingen na bewerking de gedeelde kopie niet kunnen beïnvloeden

Voor eenmalig delen van een specifieke momentopname met iemand buiten je platform sturen end-to-end versleutelde overdrachtstools een specifiek bestand met een eenmalige link. HexaTransfer werkt hiervoor: upload de bevroren versie, stuur de link en de ontvanger krijgt precies wat je bedoelde zonder toegang tot je hele platform.

Bewaken en waarschuwen bij versiegebeurtenissen

Versiegeschiedenis is alleen nuttig als je merkt wanneer je het nodig hebt. CloudTrail (AWS), Activiteitenlog (Azure) en Cloud Audit Logs (GCP) loggen elke versiegebeurtenis. Waarschuw bij ongebruikelijke verwijderingssnelheden — 10.000 DeleteObject-aanroepen in een uur is waarschijnlijk geen gebruiker die opruimt.

Bouw een eenvoudig dashboard met per-bucket versietellingen, totale versieopslag en verwijdermarkering-ratios. Een bucket waarbij verwijdermarkeringen plotseling de live objecten overtreffen is een alarmsignaal: ofwel heeft er een massaverwijdering plaatsgevonden, ofwel staat versieretentie op het punt dingen te verwijderen die je wilde bewaren. Wekelijkse e-mailsamenvattingen zijn beter dan wachten op de kwartaalaudit.

Het herstelrunbook

Documenteer het herstelproces vóórdat je het nodig hebt. Een goed runbook omvat:

  1. Hoe versies te vermelden (aws s3api list-object-versions, az storage blob list --include v)
  2. Hoe een specifiek VersionId te herstellen als de huidige versie (S3: kopiëren met --version-id)
  3. Hoe een volledig prefix bulksgewijs te herstellen naar een tijdstip (scripts met tijdstempelfilters)
  4. Hoe verwijderde objecten te herstellen (verwijdermarkeringen verwijderen)
  5. Wie toestemming heeft voor elk onderdeel (doorgaans niet dezelfde persoon die het verlies veroorzaakte)

Druk het af. Loop het eens per kwartaal door met een nep-scenario. Wanneer het echte incident plaatsvindt, wint spiermemorie het van documentatie lezen onder druk.

Probeer het op hexatransfer.com — gratis, geen account vereist, maximaal 10 GB.

Verstuur grote bestanden veilig met end-to-end-versleuteling

Draag bestanden tot 10 GB gratis over met end-to-end-versleuteling. Geen account nodig. Uw bestanden worden in uw browser versleuteld voordat ze worden geüpload — niemand anders kan ze lezen.

Een bestand verzenden