# Backup & Restore Guide This covers the two things that hold your real business data: 1. **The database** (`backend/db/freedom_fitness.db`) — every trainer, plan, price, testimonial, transformation story, contact message, and admin account. 2. **Uploaded media** (`backend/uploads/`) — every photo, video, and PDF anyone has uploaded through the admin panel. Both now have backup systems. Read this before you need it, not after something goes wrong. --- ## Database backups ### Automatic (recommended — already on by default) As long as your backend server process is running, it automatically backs up the database once a day. This is controlled by three settings in `backend/.env`: ``` DB_BACKUP_ENABLED=true DB_BACKUP_HOUR=3 DB_BACKUP_RETENTION=30 ``` - `DB_BACKUP_ENABLED` — set to `false` to turn this off entirely. Leave it `true` unless you have a specific reason not to. - `DB_BACKUP_HOUR` — the hour (0–23, server's local time) it tries to back up each day. Default is 3am, when traffic is lowest. - `DB_BACKUP_RETENTION` — how many backups to keep. Once you have more than this many, the oldest ones are deleted automatically. Default is 30, meaning roughly a month of daily history. **Important limitation:** this only runs while the Node process is alive. If your host restarts the server frequently, or if you want backups to exist somewhere other than the same disk as the live database (recommended for real disaster recovery — a backup next to the thing it's backing up doesn't protect you if the whole server is lost), also set up one of: - Your hosting platform's own scheduled-job/cron feature, running `npm run backup-db` on a schedule. - A traditional OS-level cron entry if you manage your own server: ``` 0 3 * * * cd /path/to/backend && npm run backup-db ``` - Periodically copying the `backend/db-backups/` folder somewhere off-server (S3, another machine, etc.) — this app doesn't do that automatically; it only creates the local backup files. ### Manual, any time ```bash cd backend npm run backup-db ``` This creates a new file in `backend/db-backups/`, named `freedom_fitness-.db`. Safe to run any time, including while the server is live and being actively used — it uses SQLite's official online-backup mechanism, not a plain file copy, so it can never capture a half-written or corrupted snapshot. ### Listing available backups ```bash cd backend node utils/restoreDatabase.js --list ``` --- ## Restoring the database ```bash cd backend # Restore the MOST RECENT backup: npm run restore-db # Restore a SPECIFIC backup: npm run restore-db -- freedom_fitness-2026-07-24T04-46-12-278Z.db ``` **What happens when you restore:** 1. Whatever database is currently live gets safety-copied first (into a file named `freedom_fitness-pre-restore-.db`), even if it's broken or empty. This means restoring is never a one-way door — if you restore the wrong backup by mistake, that pre-restore snapshot is right there to restore again. 2. The chosen backup file is copied into place as the live database. 3. **You must restart the backend server** (`npm start` / restart your process manager) for the restored data to actually take effect — the running server has the old data loaded in memory/open file handles until it's restarted. ### Verifying a restore worked After restarting the server, check that the data you expected is back — for example: ```bash curl http://localhost:4000/api/trainers ``` or simply log into the admin panel and check the content. --- ## Uploaded media backups Separate system, same idea, but manual-only (photos/videos are large, so this isn't run on an automatic daily schedule the way the database is): ```bash cd backend npm run backup-uploads ``` This copies the entire `backend/uploads/` folder into `backend/uploads-backups//`. Restoring is manual: copy the folder you want back from `uploads-backups/` over `backend/uploads/` (back up the current one first, the same way the database restore does automatically). Old upload backups are never auto-deleted — clean them up yourself if disk space becomes a concern, since media backups can be large. --- ## What these backups do NOT protect against - **They live on the same disk as the live data by default.** If the entire server/disk is lost (hardware failure, account termination, etc.) and you never copied `db-backups/` or `uploads-backups/` anywhere else, the backups are lost too. For real disaster-recovery protection, periodically copy these folders to a second location. - **They don't protect against a bad deploy that changes the database schema in an incompatible way** without also handling migration of old data — that's a code-review/testing concern, not something a file backup fixes after the fact. - **Environment variables and secrets are not included.** Your `.env` file (JWT secret, SMTP password, etc.) is separate from the database and isn't part of either backup system. Keep your own secure copy of `.env` if you customize it.