How to Back Up Claude Code Linux Projects the Right Way

If you’re running a real site with Claude Code on Linux, backups are not optional. The hard part is not making a backup. It’s making one that you can actually restore when a deploy goes sideways, a disk fills up, or you accidentally overwrite something useful at 11:47 p.m.

This guide walks through a practical backup strategy for Claude Code Linux projects: what to back up, how often to run backups, where to store them, and how to test a restore before you need one. The goal is simple: protect your code, data, and configuration without turning your host into a pile of fragile scripts.

What should a backup include?

For most Claude Code Linux projects, a complete backup is a mix of application files, data, and environment settings. If you only save the source tree, you’ll still lose important state. If you only save the database, you’ll still have to rebuild the app around it.

A good backup set usually includes:

• Application code — your project directory, excluding build artifacts you can regenerate.
• Database dumps — PostgreSQL, MySQL, SQLite, or whatever persistent store your app uses.
• Uploaded files — user uploads, media libraries, generated assets, and anything stored outside git.
• Environment files — examples: .env, service configs, reverse proxy settings, cron jobs, and systemd units.
• Deployment metadata — if you keep migration history, release notes, or versioned config.

What not to back up blindly: caches, dependencies, temporary files, log spam, and anything that can be recreated from source in minutes.

Backup strategy for Claude Code Linux projects: use layers, not one giant tarball

The most reliable backup strategy for Claude Code Linux projects is layered. Instead of a single archive that tries to do everything, split your backups by purpose. That gives you smaller files, faster restores, and fewer surprises.

Layer 1: source code backup

Your code is usually in git already, which is great. But git is not a full disaster recovery plan. You still want periodic snapshots of the working directory so you preserve uncommitted changes, local config, and files outside version control.

Recommended approach:

• Keep code in a private repository.
• Exclude node_modules, virtualenvs, compiled output, and caches.
• Archive only the project directory and any hand-edited config you cannot recreate quickly.

Layer 2: data backup

This is the critical one. If your site stores orders, comments, user accounts, or analytics events, the database is the source of truth. Back it up separately and on a schedule that matches how much data you can afford to lose.

For example:

• High-change app: backup every hour.
• Moderate-change app: backup every 6–12 hours.
• Low-change marketing site: daily may be enough.

If your database is PostgreSQL, use pg_dump for logical backups. If you need faster recovery on larger systems, pair that with periodic snapshots or physical backups.

Layer 3: file backup

Many apps quietly store important files outside the database. Common examples: user uploads, generated PDFs, image thumbnails, and cached exports. Put these in a clearly named directory and back them up alongside the database.

If you can, make your storage layout boring and obvious:

• /var/www/app/uploads
• /var/www/app/data
• /srv/app/media

That way, your restore process is mostly a matter of copying known paths back into place.

How often should you back up?

The right schedule depends on two numbers: how much data you can lose and how much time you can spend restoring. This is often described as RPO and RTO.

• RPO (Recovery Point Objective): how much recent data you can afford to lose.
• RTO (Recovery Time Objective): how long you can be down.

For a small production site, a useful starting point is:

• Daily full backup of code, config, and files.
• Hourly or 6-hour database backup depending on change volume.
• Retention policy of 7 daily, 4 weekly, and 3 monthly backups.

If you’re running on a hosted environment like Vibesies, tiered backup schedules can be a big help. The point is not the brand name. The point is having a schedule that matches your app’s risk, instead of a random cron job you forgot existed.

Where should backups live?

Backups on the same disk as the original files are not backups. They are delayed failure. If the machine dies, the filesystem gets corrupted, or the disk fills up, your “backup” goes with it.

Use the 3-2-1 rule as a baseline:

• 3 copies of your data.
• 2 different storage types.
• 1 offsite copy.

Practical options for offsite storage include:

• Encrypted object storage such as S3-compatible storage.
• A separate server in another region.
• A provider-managed backup target with retention controls.

If you store sensitive data, encrypt backups before they leave the box. That matters whether you’re keeping personal data, payment-adjacent logs, or just don’t want your config files readable by anyone with bucket access.

A simple backup workflow you can automate

You don’t need a massive backup platform to get this right. A small, repeatable workflow is often better than a complex one you never verify.

Step 1: freeze what needs freezing

For database-backed apps, use a short lock window or a transaction-safe dump so you capture a consistent state. For file-heavy apps, make sure uploads aren’t mid-write during backup if your storage layer doesn’t handle that cleanly.

Step 2: export the database

Example for PostgreSQL:

pg_dump -Fc -f /backups/app/db/app-$(date +%F-%H%M).dump mydb

The custom format (-Fc) is convenient because it restores cleanly with pg_restore.

Step 3: archive code and config

Use tar with exclusions so you don’t waste space on build outputs:

tar --exclude='node_modules' --exclude='venv' --exclude='dist' \
  -czf /backups/app/code/app-$(date +%F-%H%M).tar.gz /var/www/app

Step 4: copy files to offsite storage

Push the backup to your offsite destination right away. Don’t leave it sitting on the same host until “later.” Later is where backups go to die.

Step 5: verify checksums

Generate and store checksums so you can tell whether the backup was corrupted in transit or at rest. A tiny integrity step now saves huge confusion later.

Step 6: delete old backups on purpose

Retention matters. Without pruning, backups become expensive and hard to navigate. Keep the last few frequent backups, plus longer-term monthly snapshots if you need audit or rollback history.

Test restores, not just backups

This is the step most teams skip, and it’s the one that actually tells you whether your backup plan works. A successful backup job only proves that a file was created. It does not prove that the file restores correctly, contains the right data, or starts your app cleanly.

At minimum, test this quarterly:

• Restore the database into a throwaway environment.
• Restore uploaded files.
• Launch the app against the restored copy.
• Check login, forms, uploads, and any job queue or cron behavior.

If possible, run one full restore on the same type of machine you’d use in an emergency. A restore that works on your laptop but fails on the actual host is not a real restore.

Common backup mistakes on Linux projects

Most failed backup setups make one of a few predictable mistakes:

• Backing up only git and forgetting data directories.
• Storing backups locally only.
• Not testing restores.
• Keeping every backup forever, then running out of space.
• Including secrets in plain text without encryption.
• Backing up logs and caches instead of the things that matter.

There’s also the “script once, forget forever” problem. If your backup process has not been exercised in months, assume it has drifted.

A backup checklist for Claude Code sites

Before you call your backup plan finished, check these boxes:

• Code is versioned in git.
• Working directory snapshots are archived regularly.
• Database dumps run on a schedule.
• User uploads and generated files are included.
• Backups are copied offsite.
• Backups are encrypted if they contain sensitive data.
• Old backups are pruned automatically.
• Restore tests are documented and repeatable.

If you’re using a managed environment, it helps when your host makes backups part of the workflow instead of an afterthought. For teams building on Vibesies, for example, the useful question is not “can I back it up?” but “how quickly can I restore it and keep working?”

Example backup policy for a small production app

If you need a template, here’s a sane starting point for a small site with a PostgreSQL database and user uploads:

• Code snapshot: nightly
• Database dump: every 6 hours
• Uploads folder: nightly
• Offsite copy: after each backup job
• Retention: 7 daily, 4 weekly, 6 monthly
• Restore test: monthly

That’s enough for many real-world sites without making operations feel like a second job.

Final thoughts

A solid backup strategy for Claude Code Linux projects is less about fancy tooling and more about discipline: separate code from data, copy backups offsite, encrypt what matters, and test restores before you need them. If you do those four things consistently, you’ll avoid most of the expensive mistakes people make when they first start hosting real apps.

If you’re already running your site in a Linux container or sandboxed environment, keep the backup process as simple as possible and document the restore path as clearly as the build path. That way, when something breaks, you’re recovering instead of guessing.