fren
Log In

Back up application data

3 min read07 November 2026

An untested backup is an assumption. For a Python application, data lives in uploaded files, a database and configuration. The goal is a consistent copy, readable somewhere other than the server, with a restore that has already been verified.

1. Inventory what matters

Data Usual location Method
User files uploads/ folder tar archive
SQLite database .db or .sqlite3 file native SQLite backup
MySQL or PostgreSQL database server mysqldump or pg_dump
Configuration panel environment variables encrypted export, outside the repository
Code Git repository clone or version archive

Logs, caches, virtual environments and __pycache__ folders do not need saving: they are reproducible and bloat the archive. An application token or key, however, is critical data: without it, the restored app will not start.

2. Copy consistently

Copying a database file during a write can produce an inconsistent image. Use each engine's proper method.

SQLite has a backup command that handles WAL mode:

Bash
sqlite3 /var/www/my-app/app.db ".backup '/tmp/app.db'"

MySQL and MariaDB, on InnoDB tables:

Bash
mysqldump --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 \
  -u user -p YOUR_DB > /tmp/db.sql

PostgreSQL:

Bash
pg_dump -Fc -U user YOUR_DB > /tmp/db.dump

For files, build an archive and exclude what is useless:

Bash
tar -czf /tmp/app-files.tar.gz \
  --exclude='.venv' --exclude='__pycache__' \
  -C /var/www my-app

On application hosting, use the panel file manager or SFTP access when offered. If the panel provides a database backup, trigger it from the interface; otherwise export the database with the available tool. Do not invent a shell command the panel does not expose.

3. Move the copy off the server

An archive left on the same disk protects against neither accidental deletion nor hardware failure. Download it, then copy it to another machine:

Bash
scp /tmp/app-files.tar.gz user@backup-host:/backups/

Keep three copies on two media, one of them offsite. If the archive holds personal data, encrypt it before transfer with age or gpg. Name files with the date and application, for example my-app-2026-11-07.tar.gz.

4. Restore and test

Restore into an isolated location first, never over production:

Bash
mkdir -p /tmp/restore
tar -xzf my-app-2026-11-07.tar.gz -C /tmp/restore

For the database, create a test database, import the dump, compare row counts on the main tables and open the application. Check restored file permissions. A restore that silently fails is more dangerous than no backup, because it creates false confidence.

5. Automate and verify

  • Schedule the daily copy with cron on a VPS, or use the panel backup if available.
  • Keep, for example, seven daily and four weekly copies.
  • Monitor task failures: an empty or abnormally small backup must raise an alert.
  • Run a restore test after every major schema change.

Backups included in a plan never replace a tested offsite copy.

Advertisement

Was this article helpful?

Read next