When it comes to backing up Mayan, we essentially have to back up two components:
- The
/opt/mayan-edms/mediadirectory - The PostgreSQL database
Remote storage location
First thing we need is a remote storage location. We go for an NFS share which we mount on the Mayan System.
Initial setup
Setup on the storage machine is the same as section 1.1 of the Raspibackup instructions.
The backup path on the destination machine is: /home/nfs/mayanha with ownership privileges for nobody:nogroup.
On the Mayan server, set up a mount point as follows:
|
1 2 |
sudo mkdir -p /mnt/nfs sudo chown nobody:nogroup /mnt/nfs |
Mounting the NFS system
In order to perform a backup, mount the remote NFS system to the mountpoint you created on the Mayan machine:
|
1 |
sudo mount 192.168.4.41:/home/nfs/mayanha /mnt/nfs |
In case you get a message like the one below, your client machine lacks the nfs-common (distros other than Ubuntu may call it nfs-utils) package. Just issue sudo apt install nfs-common.
|
1 |
mount: /mnt/nfs: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program. |
Backup Operation
To backup the PostgreSQL data base, on the Mayan Machine issue the following command:
|
1 |
sudo -u postgres pg_dumpall | gzip > /mnt/nfs/20220727_mayan_postgresql.gz |
We prefer to have the complete PostgreSQL Server dumped instead of the single Mayan data base because we don’t have to care about user privileges and passwords that way.
Next we will backup the /opt/mayan-edms/media directory as per the backup instructions of the Mayan online documentation.
We slightly deviate from the instructions given in the Mayan documentation in two points:
- We stop the
supervisordaemon to prevent Mayan EDMS from altering the files in the media directory while the backup is running. - We leave out the
verbose option in thetarcommand as the verbose option results in an endless list of files which (a) slows down the creation of the tar.gz file and (b) prevents us from properly noticing error messages that might be relevant but gets lost in the file list.
|
1 2 |
sudo service supervisor stop sudo tar -zcf /mnt/nfs/20220728_mayan_media.tar.gz /opt/mayan-edms/media/ |
After the backup don’t forget to reengage the supervisor service:
|
1 |
sudo service supervisor start |
Open Questions
Notice that the there are other files and directories under /opt/mayan-edms/media:
|
1 2 3 4 5 6 7 8 9 10 11 |
ilek@mayanha:/opt/mayan-edms$ ls -alh total 32K drwxr-xr-x 7 mayan mayan 4.0K Jun 8 20:24 . drwxr-xr-x 3 root root 4.0K Jun 8 19:07 .. drwxr-xr-x 3 mayan mayan 4.0K Jul 23 13:15 bin drwxr-xr-x 3 mayan mayan 4.0K Jun 8 19:08 include drwxr-xr-x 3 mayan mayan 4.0K Jun 8 19:07 lib lrwxrwxrwx 1 mayan mayan 3 Jun 8 19:07 lib64 -> lib drwxrwxr-x 10 mayan mayan 4.0K Jun 11 10:39 media -rw-r--r-- 1 mayan mayan 70 Jun 8 19:07 pyvenv.cfg drwxrwxr-x 3 mayan mayan 4.0K Jun 8 19:08 share |
This means that upon restore writing just expanding the backup of the media subdirectory will not reproduce the complete mayan installation.
It should rather be assumed that you have an ’empty’ Mayan EDMS installation installed for which you will have to overwrite the media directory with the content from your backup file.
– the postgres super user of your database
– the mayan user of your database
– the redis user password
– the rabbitiq user password
Furthermore, looking at the upgrade instructions in the Mayan online documentation, there are additional files that (might) have to be customized:
/etc/supervisor/conf.d/mayan-edms.conf(this is even outside the/opt/mayan-edms/directory), this file looks unsuspicious though and unless there have not been explicit customizations, the conf file created from an empty Mayan installation should be fine.- /etc/redis/redis.conf (again outside the /opt/mayan-edms/ directory), note that this file holds the redis password