Git Is Not a Backup: Cloud Backup vs Local Backup for Developers

A few years ago I would have told you my code was "backed up" because it was on GitHub. Then I started thinking about everything that isn't in the repo: the .env files, the local database, the client assets, the notes, and the config that only exists on my laptop.

If you freelance, run a small agency, or look after IT for a small business, the cloud backup vs. local backup question is worth ten minutes of your time. Here's a developer-friendly way to think about it, plus a setup you can copy.

First, a myth: Git is not a backup

Git is great at history and collaboration. It is a poor backup for the whole machine because:

• Untracked and ignored files (.env, local databases, and build artefacts you can't regenerate) aren't in it.
• A force-push or deleted remote can wipe history.
• If your remote account is locked or compromised, your copy is only as safe as that account.
• Your documents, client files, and system config aren't in any repo.

Keep using Git. Just don't call it your backup plan.

Local vs cloud in one minute

Local backup copies data to hardware you control: an external SSD, a NAS, another machine.

• ✅ Fast restores, works offline, no monthly storage bill
• ❌ Same building as the original, so theft, fire, flood, or a power surge can take both

Cloud backup sends encrypted copies to a provider's storage.

• ✅ Offsite, automatic, scalable
• ❌ Slow for huge restores, ongoing cost, depends on credentials and the vendor

Neither is enough alone. They cover different failures.

The 3-2-1 rule

• 3 copies of your data (the original plus two backups)
• 2 types of storage (local disc plus cloud, for example)
• 1 copy offsite

A simple dev workstation setup

Here's a minimal version using tools that are already on most Linux and macOS machines, plus rclone for cloud storage. Adjust paths to suit.

Local: versioned snapshots with rsync

This keeps dated snapshots, using hard links so unchanged files don't take extra space.

#!/usr/bin/env bash
set -euo pipefail

SRC="$HOME/projects/"
DEST="/mnt/backup/projects"
TODAY="$(date +%F)"

mkdir -p "$DEST"

rsync -a --delete \
  --exclude 'node_modules/' \
  --exclude '.cache/' \
  --link-dest="$DEST/latest" \
  "$SRC" "$DEST/$TODAY/"

ln -sfn "$DEST/$TODAY" "$DEST/latest"

Skipping node_modules saves a lot of space because you can rebuild it from your lockfile. Don't exclude anything you can't regenerate.

Offsite: encrypted copy with rclone

Configure a remote once with rclone config (many providers are supported, and you can layer a crypt remote on top for client-side encryption). Then:

rclone copy "$HOME/projects" remote:backups/projects \
  --exclude 'node_modules/**' \
  --exclude '.cache/**' \
  --progress

I used copy rather than sync on purpose. sync mirrors deletions, so an accidental delete or a ransomware encryption could propagate to the cloud. If you do use sync, turn on versioning or object lock at the provider, or use --backup-dir so overwritten and deleted files are kept.

Schedule it

crontab -e
# Local snapshot at 1:30 AM, cloud copy at 2:30 AM
30 1 * * * /home/you/bin/local-backup.sh >> /home/you/backup.log 2>&1
30 2 * * * rclone copy /home/you/projects remote:backups/projects --exclude 'node_modules/**' >> /home/you/backup.log 2>&1

Then add something that tells you when it fails: a notification, an email, or a health-check ping. Silent failure is how people discover three months later that nothing has run.

The part everyone skips: test the restore

# Restore a folder from the latest local snapshot to a scratch location
mkdir -p /tmp/restore-test
rsync -a /mnt/backup/projects/latest/my-important-project/ /tmp/restore-test/

# Try to open and run it
cd /tmp/restore-test && ls

Do the same from the cloud copy at least twice a year, and time it. That number is your real recovery time, and it's usually longer than you'd guess.

Things worth thinking about if you're a small business or work in a region like northern New Mexico

I live with a few real-world hazards in mind when advising local businesses: summer storms and power surges, wildfire season, dry dust, and older buildings. They all argue for the same thing: keep at least one copy somewhere other than your office, and put surge protection on anything that stores data.

If you handle client health or financial data, check which regulations apply and whether your backup provider meets them.

Quick checklist

• [ ] Code is in Git, and Git is not my only backup.
• [ ] I have a local snapshot with some version history.
• [ ] I have an encrypted offsite copy
• [ ] Deleted files can't instantly vanish from every copy.
• [ ] Secrets are stored in a password manager, not just a local``
• [ ] Backup failures notify me.
• [ ] I've restored from backup in the last six months.

Wrap-up

For the cloud backup vs local backup question, the practical answer is both. Local for speed, cloud for survival, and a restore test to prove it works.

What's in your backup setup? Let me know what tools you use in the comments.