Backups

From Justflows 0.4.1, administrators create, schedule, validate, and restore backups in Admin → Tools. A backup only counts once you have restored it, so this page also covers how to prove that a restore works.

What a backup holds#

A .jfbackup file is a portable, database-independent archive of one site: its content, design configuration, and original media from local or S3 storage, with a plugin and theme inventory and a versioned manifest checked with SHA-256. The job is cancellable and reports progress. A missing media file stops the backup instead of producing an incomplete one.

• Credentials and environment-specific values are left out. Keep .env and provider credentials in a secret store.
• Plugins and themes are listed, not included. Reinstall them from trusted packages.
• Each file covers one site. On the installation root you can back up the root site alone or every subsite in its workspace as separate files; each site is read through its own database without crossing tenant boundaries.

Schedules and destinations#

A schedule on the installation root runs daily, weekly, or monthly at a UTC time, for the root site, its subsites, or both, and delivers to one destination:

Destination credentials are encrypted, never returned to the browser, and never written into an archive. Delivery failures are reported in Tools, and the Security Center warns when the last scheduled backup failed or the schedule has stopped running.

Validate and restore#

1. 1

   Validate

   Upload the archive in Tools. Justflows checks the manifest and checksums and reports the item and media counts.

2. 2

   Install the inventory

   Install the plugins and themes the backup lists, from trusted packages.

3. 3

   Restore

   Pick the target: the root site or one of its subsites. Restore needs a clean target and the confirmation phrase. It keeps the target's administrator and secrets, rewrites site ownership, and leaves every other site unchanged.

4. 4

   Check

   Confirm that pages render, media loads, and you can sign in.

Database replacement is transactional, and media is staged first, so a failed restore rolls back the database and puts the target's previous media back.

Protect your archives#

• Encryption. The archive itself is not encrypted and holds your content and media in readable form. Use encrypted storage at the destination.
• Access. Anyone who can read a backup can read the site's data. Restrict the destination to the people and systems that need it.
• Off-host copies. A backup on the same host fails with that host. Use an external destination, ideally with a different provider.
• Retention. Justflows does not delete old backups at a destination. Set a lifecycle rule there, and keep copies old enough to predate a compromise you might discover late.

Recovery objectives and restore drills#

Write down a recovery point objective (how much recent data you can lose; a daily backup can lose up to a day) and a recovery time objective (how long the site can be down) for each site. Measure the second in a restore drill, after major upgrades and as often as your objectives need. Never drill against production:

1. Create a clean installation on an isolated host with its own database and storage, unable to send mail or call production services.
2. Use a copy of a recent backup from the real destination, not a fresh download. Treat the drill host as production data storage, or use a site with synthetic data.
3. Note the start time, install the inventory, validate the archive, and compare the counts with what you expect.
4. Restore it, then check pages, media, and sign-in.
5. Record the date, the backup used, the time taken, and any problems, and compare the time with your objective.
6. Delete the drill installation and its data.