Backup & Restore - What are best practices?

maxmoon

There are a lot of posts about backups and restoring Flarum and all are completely different and there are a lot of different opinions.

@matunixe backups the complete flarum directory
There is a script to backup, but it's a little bit old and backups the complete flarum directory, too.

I am trying to figure out what exactly must be backuped to be able to restore the forum again?

And how to restore the old forum if something went horribly wrong after e.g. updating?

Important: Only necessary data and steps. No cache, trash or temporary data should be backuped. The minimum.

What I figured out so far?

The public directory of Flarum

Backup /<path_to_flarum>/public

It contains all data of the forum, like uploaded data, icons, logos, avatars, fonts, etc.

IMHO the whole flarum dir don't have to be backuped. Please tell me if I am wrong.

The composer file

Backup /<path_to_flarum>/composer.json

It contains all information to install all needed extensions. Is composer.lock needed?

Dump the database

mysqldump -u <username> -p"<password>" <database_name> > flarum.sql

It contains the whole database. Are there tables not needed? Maybe temporary tables?

Is this correct?

Is this all what should be backuped?
Did I forget something?

If everything is correct, I will create a script and publish it so others can use it to make minimal and clean backups and restore forums.

clarkwinkelmann

You technically don't need all of public, all the user-generated data is usually in public/assets unless an extension tries doing something fancy.

Extensions are allowed to place non-temporary data under storage. I'm not sure any of them do though.

composer.lock is not strictly necessary but it contains data about which exact version of everything is installed, rather than just the desired minimum version definition. If you need to quickly restore a backup, having the lock file will make the restoration quicker and will make sure you restore the dependencies as they were rather than performing any missing updates at the same time.

It might be useful to also copy config.php, particularly if you made any customization other than the database name.

If you want to optimize for quick restore on a fresh server, you can backup everything and just exclude vendor and the content of the storage/cache, storage/formatter, etc. folders. The archive will not be much larger and this way restoring is as simple as extracting the archive and running composer install, and of course restoring the database. You won't have to download the Flarum skeleton again.

Best way to know if your recovery plan is complete is to test it. Try restoring the forum to a second test hosting, and see if you can login with various users and see all images, downloads, etc.

maxmoon

clarkwinkelmann If you need to quickly restore a backup, having the lock file will make the restoration quicker and will make sure you restore the dependencies as they were rather than performing any missing updates at the same time.

Will be composer install enough in both cases or is there a special command for this?

clarkwinkelmann It might be useful to also copy config.php, particularly if you made any customization other than the database name.

It looks like it only contains database credentials. What else could be there?

clarkwinkelmann If you want to optimize for quick restore on a fresh server, you can backup everything and just exclude vendor and the content of the storage/cache, storage/formatter, etc. folders.

In this case I would be very thankful if you could list the "etc. folders" part, too, because I am not sure which one are really useful and which are not.

luceos I would also backup extend.php in the root if you made customizations.

What exactly can I do with this file? It only returns an empty array atm...

Darkle it's not the most user-friendly (especially if you prefer not to deal with the terminal)

For me user friendly == terminal, because in most cases there isn't everything implemented in the gui I need, but functionality exists.

Darkle but it's a great way to automate the whole process and send the copies to off-server storage.

I don't think it's great to just throw everything in an archive, no matter what it is. It's really important to know what is needed and what not, which could save a lot of storage in the end (depending on how often you create backups and how huge the forum is). So I hope to figure everything out soon, because most of the backup script already works pretty good 🙂

luceos

I would also backup extend.php in the root if you made customizations.

Darkle

The script you mention from @r4nchy is a great resource, it's not the most user-friendly (especially if you prefer not to deal with the terminal), but it's a great way to automate the whole process and send the copies to off-server storage.

clarkwinkelmann

config.php can contain custom PDO connection attributes, custom cookie naming and sone extensions may also use it for optional global settings.

extend.php can contain local extension code for quick customizations.

Both of these files are never edited by Flarum, they can only be customized by the webmaster. So you would know if you have customized them.

Some if the folders under storage are created by extensions so it's not really possible to give an extensive list of which does what.