File Versioning Best Practices: Never Lose Changes

File versioning saves every revision so you can roll back accidental overwrites, deletions, and ransomware damage. Turn it on at the platform level — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, Dropbox version history, SharePoint major/minor versions — and pair it with lifecycle rules that expire old versions after 30-180 days. Without versioning, a single rm -rf or a rogue sync client can vaporize years of work in seconds, and the "cloud backup" you thought you had is just a synchronized copy of the damage.

What Platform Versioning Actually Does

When versioning is enabled, an overwrite doesn't replace the object — it creates a new version with a new VersionId. The old bytes stay on disk, retrievable by that ID. A delete becomes a "delete marker" rather than a destruction; the prior versions remain restorable until you explicitly purge them.

This matters because most data loss isn't catastrophic hardware failure (cloud durability handles that). It's someone saving an empty spreadsheet over a populated one, or a script with a bug that truncates a thousand files, or ransomware that encrypts everything it can reach. Versioning lets you go back 30 days and pick up where things were sane.

The Cost of Keeping Every Version

Versions consume storage, and storage costs money. A bucket with 10 TB of files and active editing might accumulate 30-50 TB of versions over a year. The mitigation: lifecycle rules that expire non-current versions after a set period, or move them to cheaper tiers.

A practical S3 lifecycle policy:

• Non-current versions: transition to S3 Standard-IA after 7 days
• Non-current versions: transition to Glacier Flexible Retrieval after 30 days
• Non-current versions: delete after 180 days
• Delete markers with no non-current versions: delete after 1 day

For Azure and GCS the equivalents use blobVersion age or Noncurrent conditions. Model the cost: 10 TB of versions in S3 Standard is $230/month; in Glacier Flexible it's $36/month. The tier transition is worth a few minutes of YAML.

Major vs Minor Versions

Document-oriented systems like SharePoint, Google Workspace, and Notion distinguish major (published) from minor (draft) versions. Drafts accumulate between milestones; majors represent a stable state someone approved. For contracts, policy documents, and specs, this distinction is gold — you can share the "major v3" link publicly while continuing to edit the draft v3.1, v3.2 privately.

Use major versions as the reference point for external stakeholders. Lock them with read-only permissions or approval workflows so nobody accidentally overwrites the published state. SharePoint's "Require content approval" column is one click; Google Drive's approval flow is a 2-minute setup.

Version Control for Source Code vs Documents

Git works magnificently for text (source code, markdown, .tf files) because diffs are meaningful per-line. It works badly for binaries: a 50 MB .psd file checked in twice doubles the repo size, and git diff can't help you. Git LFS (Large File Storage) moves binaries to a separate store and keeps pointers in the repo — sane for art assets, bad for general documents.

For .docx, .xlsx, .pptx, and .pdf files, use the cloud platform's built-in versioning rather than Git. SharePoint, Drive, and Dropbox all store per-version deltas natively and render a timeline UI that business users can navigate. For mixed content (code plus PDFs plus design files), some teams use DVC or LakeFS as Git-for-data layers over object storage — worth investigating for ML and data teams.

Retention Tied to Compliance Calendars

Regulations dictate how long versions must live. SEC Rule 17a-4 requires broker-dealer records for 3-6 years. HIPAA retains records for 6 years minimum. SOX wants 7 years for financial records. GDPR caps the other direction — don't keep personal data longer than needed.

Tag sensitive files so lifecycle rules respect regulatory minimums and maximums. An S3 tag like retention-class: sox-7y can drive lifecycle transitions, Object Lock durations, and eventual deletion. Use S3 Object Lock with Compliance Mode for immutable regulatory copies — even root users can't delete within the retention period, which is exactly what WORM (Write Once Read Many) rules require.

Ransomware Protection Through Versions

A ransomware attack that reaches your sync clients will encrypt files on the endpoint and push the encrypted versions to the cloud. Versioning saves you — the pre-encryption versions still exist. But only if two things are true: versioning is enabled before the attack, and retention is long enough to bridge detection time.

Industry average ransomware dwell time in 2025 sits around 11 days for mid-market companies. A 30-day version retention is the minimum; 90 days is safer. Pair versioning with delete protection (S3 MFA Delete, Azure soft delete with a different admin) so an attacker who compromises one account can't purge version history. Test the restore quarterly — simulate deletion of a test folder and time the recovery.

Naming Conventions for Shared Versions

When sharing a specific version externally — sending a client "the approved v3 of the contract" — you need a stable pointer that doesn't shift when someone edits. Use one of three patterns:

1. Presigned URL to a specific VersionId (S3: ?versionId=...) — valid for 7 days max, immutable
2. A copy of the approved version into a separate /published/ bucket with the version in the filename (contract-v3.0-2026-12-15.pdf)
3. A PDF export snapshot so post-edit changes can't affect the shared copy

For one-time sharing of a specific snapshot with someone outside your platform, end-to-end encrypted transfer tools send a specific file with a one-time link. HexaTransfer works for this: upload the frozen version, send the link, and the recipient gets exactly what you intended without needing access to your whole platform.

Monitoring and Alerting on Version Events

Version history is only useful if you notice when you need it. CloudTrail (AWS), Activity Log (Azure), and Cloud Audit Logs (GCP) log every versioning event. Alert on unusual deletion rates — 10,000 DeleteObject calls in an hour probably isn't a user cleaning up.

Build a simple dashboard showing per-bucket version counts, total version storage, and delete-marker ratios. A bucket where delete markers suddenly exceed live objects is a distress signal: either a mass-delete happened, or versioning retention is about to purge things you meant to keep. Weekly email summaries beat waiting for the quarterly audit.

The Recovery Runbook

Document the restore process before you need it. A good runbook covers:

1. How to list versions (aws s3api list-object-versions, az storage blob list --include v)
2. How to restore a specific VersionId to be the current version (S3: copy with --version-id)
3. How to bulk-restore an entire prefix to a point in time (scripts using timestamp filters)
4. How to restore deleted objects (remove delete markers)
5. Who has permission to do each (usually not the same person who caused the loss)

Print it. Walk through it once a quarter with a fake scenario. When the real event happens, muscle memory beats reading docs under pressure.

Try it at hexatransfer.com — free, no account, 10 GB max.