Backups and restore
blysis backup
Writes one archive containing the database and the uploads directory, named with the date and time, into the backup directory the installer chose. Nothing else is in it and nothing else needs to be: the code comes from the image, the secrets come from the environment file, and the modules are reinstalled from their own ZIPs.
What a backup contains
- The database. Every table, including the ones modules created. A module's tables are part of the dump whether or not the module is currently enabled.
- The uploads directory. Avatars, module images, anything an operator or a member uploaded.
It does not contain the environment file, because a backup travels and secrets should not. Keep that separately, and keep it: without it a restore starts a site that cannot decrypt its own stored credentials.
Restoring
blysis restore
With no argument it lists what it can see and asks which one. It stops the application, replaces the database and the uploads, and starts it again.
Restoring onto a different machine works and is the thing worth practising:
- Install Blysis on the new machine, and let it finish.
- Copy the environment file from the old machine, or at minimum the encryption key from it.
- Copy the archive across and run
blysis restore. - Update the site URL if the address changed.
Where it goes
The installer puts backups on the same disk by default, which protects you
against a mistake and not against the disk. Copy them somewhere else on a
schedule; rclone, restic and a cron entry are all fine, and none of them
need to know anything about Blysis.
A backup you have not restored
Restore one, once, onto a machine you do not care about. It takes ten minutes and it is the only way to find out that the archive is complete, that you still have the encryption key, and that you know the commands under pressure.