If you’re running an AI-built Linux site, how to set up backups for an AI-built Linux website is one of those topics that sounds boring until the day something breaks. Then it becomes the most important part of your stack.
The good news: backups do not need to be complicated. The better news: if you’re using a setup where you can talk to an AI engineer inside your own Linux environment, you can automate most of the work and keep the process repeatable. That matters whether you’re shipping a content site, a client project, or a small product with a database and uploaded files. Vibesies, for example, is built around that kind of Linux-first workflow.
This guide covers what to back up, how often to back it up, where to store it, and how to make sure your restore process actually works.
Why backups for AI-built sites are a little different
AI can spin up code quickly, but it can also make it easy to accumulate hidden assumptions. Maybe the agent modified a config file you forgot about. Maybe it added a cron job. Maybe your app stores user uploads in a directory you never documented. If the site goes down, you need more than the source code repository.
For a real Linux website, your backup plan should cover three things:
- Code — app source, templates, static assets, scripts, infrastructure config
- Data — database dumps, uploaded files, user-generated content
- Environment — .env files, cron jobs, nginx config, service definitions, SSL-related notes
If you only back up the repo, you may still be unable to restore the site cleanly.
How to set up backups for an AI-built Linux website
The simplest reliable pattern is:
- Back up the database on a schedule.
- Back up uploads and media files on a schedule.
- Back up application config and deployment files.
- Store backups off the server.
- Test restores regularly.
That’s the core. Everything else is implementation detail.
1) Decide what needs to be backed up
Before writing a single script, make a short inventory. On many Linux-hosted sites, the important paths look something like this:
/var/www/your-site/for the application code/var/www/your-site/uploads/or similar for media/etc/nginx/for nginx site configs/etc/systemd/system/for custom services- Database credentials and app settings stored in
.envor a secrets file
Ask yourself: if the VM vanished tonight, what would I need to recreate the site exactly as it was yesterday?
That list is your backup scope.
2) Use the right backup method for each layer
Different parts of the stack need different tools.
- Database: use
pg_dumpfor PostgreSQL ormysqldumpfor MySQL/MariaDB. - Files: use
rsync,tar, or a snapshot tool. - Config: copy versioned config files into a backup archive or private repo.
A common mistake is to make a filesystem snapshot and assume it’s enough. If your database lives separately, snapshotting the web root won’t capture the actual content.
3) Back up the database first
For most AI-built sites, the database is the part you can least afford to lose. A nightly dump is a good baseline. For a busy site, hourly backups may be safer.
Example PostgreSQL backup command:
pg_dump -U appuser -h localhost yourdb | gzip > /backups/yourdb-$(date +%F-%H%M).sql.gz
Example MySQL backup command:
mysqldump -u appuser -p'yourpassword' yourdb | gzip > /backups/yourdb-$(date +%F-%H%M).sql.gz
In practice, you should avoid putting plaintext passwords directly in commands. Use a protected config file, environment variables, or a backup user with limited permissions.
4) Back up uploads and persistent files
Static code can be re-deployed, but uploaded images, PDFs, generated reports, and customer attachments usually cannot. These live in persistent directories, and they deserve their own backup job.
A good pattern is to mirror only the directories that change:
rsync -a --delete /var/www/your-site/uploads/ backup-user@backup-host:/data/your-site/uploads/
If you prefer archives, bundle the directory into a compressed tarball and send it elsewhere. The key point is to make sure the data leaves the server.
5) Keep config files under version control, but still back them up
Git is great for code, but it is not a complete backup strategy. You should still keep copies of deployment-critical files like:
.envor secret configs- nginx virtual host configs
- systemd unit files
- backup scripts themselves
If your secrets are sensitive, store them in a private encrypted archive or a secrets manager. Do not casually commit them to a repo, even a private one, unless you’ve planned for rotation and access control.
A practical backup schedule for small Linux sites
If you’re not sure where to start, use this schedule and adjust later:
- Every hour: database backups for active sites with user data
- Every night: database and uploads backup
- Every week: full config archive
- Every month: restore test to a clean environment
For a simple blog with no logins and no user uploads, daily backups may be enough. For an app with orders, comments, or transactions, hourly database backups are more realistic.
How to choose backup frequency
Use this rule of thumb:
- Low-change site: daily backups
- Moderate traffic or content updates: every few hours
- Customer data or frequent writes: hourly or continuous replication
Think in terms of RPO (how much data you can afford to lose) and RTO (how long you can be down). A site with a four-hour RPO can lose four hours of changes. A site with a 15-minute RPO cannot.
Where to store backups
Never rely on the same server as your only backup location. If the box is compromised, deleted, or has disk corruption, the backup goes with it.
Use at least one off-server destination:
- Another VM or backup host
- Object storage like S3-compatible storage
- Encrypted external storage in a separate account
If you want a simple setup, send encrypted backups to object storage and keep a short local retention window for quick restores.
For teams using a hosted environment like Vibesies, the important part is still the same: make sure backups are independent of the runtime container or machine.
Retention policy: how many backups should you keep?
A practical retention policy might look like this:
- Hourly: keep 24 hours
- Daily: keep 14 or 30 days
- Weekly: keep 8 weeks
- Monthly: keep 6 to 12 months
You do not need infinite backups. You need enough history to recover from the most likely failure, plus enough room to detect a problem you didn’t notice right away.
Encrypt your backups
Backups usually contain the most sensitive version of your system: databases, tokens, email addresses, maybe even payment-related metadata. Treat them as confidential assets.
At minimum:
- Encrypt backups before leaving the server
- Restrict access to backup storage
- Rotate keys if a machine or account is compromised
Tools like gpg, age, or encrypted bucket policies can help. The specific tool matters less than the discipline of encrypting data at rest and in transit.
Test restores, not just backups
This is the part most people skip. A backup you have never restored is only a file you hope is usable.
Set up a restore test like this:
- Provision a clean Linux environment.
- Restore the latest database dump.
- Restore uploads and static assets.
- Apply config files.
- Start the app and visit key pages.
- Log in as a test user, if applicable.
Do this monthly at minimum. If the site changes often, test more frequently.
A restore test catches problems such as:
- Broken database credentials
- Missing environment variables
- Old migration assumptions
- Permissions issues on uploaded files
- Backup scripts that silently failed for weeks
A simple backup checklist for AI-built sites
Use this as a pre-launch or maintenance checklist:
- Database dump script exists and runs on schedule
- Uploaded files are included
- Config and service files are archived
- Backups are copied off-server
- Backups are encrypted
- Retention policy is defined
- Restore tests are scheduled
- Someone knows where the restore instructions live
If you want to make this easier, ask your AI engineer to generate the scripts, cron entries, and restore docs as a single bundle. That’s a nice fit for an environment where the agent can work directly inside your Linux container, like the setup Vibesies is designed around.
Example of a minimal backup workflow
If you’re looking for the shortest path to “good enough,” here’s a basic setup:
- Nightly database dump to
/backups - Nightly sync of uploads to off-server storage
- Weekly tarball of configs
- Backup files encrypted before upload
- 30-day retention
- Monthly restore test
That alone will cover a lot of real-world failures.
Conclusion
How to set up backups for an AI-built Linux website comes down to a few simple habits: back up the database, back up uploads, keep config files, store copies off-server, encrypt sensitive data, and test restores before you need them. If you do those things consistently, you’ll be ahead of most small-site operators.
AI can help you generate the scripts, but the discipline still has to come from you. Build the backup plan early, document it clearly, and make restore testing part of your routine. That’s what keeps an AI-built site from turning into a one-off project that can’t survive a bad night.