I currently have 4 different Mayan installations running: 1 on a physical Ubuntu 22.04 LTS server and 3 others on Ubuntu 20.04 servers, each of the 3 servers being a virtual machine. Each of these installation is for different client projects (or for my own documents administration).<\/p>\n\n\n\n
Theoretically, Mayan has a very granular access control model that would allow to put everything into one single Mayan instance as I have shown a previous post<\/a> on this blog. In practice, though, this approach is quite cumbersome<\/strong> as it would involve heavy ACL administration issues with each document uploaded. <\/p>\n\n\n\n On top of that clients often insist that their documents must be kept in a completely separated environment for reasons of confidentiality<\/strong>. They do indeed have a point when they insist that there should be more than a simple acces control list entry that prevents an outsider from getting access to their documents.<\/p>\n\n\n\n Furthermore, running one single Mayan instance for multiple clients would mean that backup<\/strong> jobs could only run under a “one size fits all” setup, which would effectively result in backing up the entire system at the highest of all frequencies required by customers.<\/p>\n\n\n\n Given the downsides of the single instance approach in 1.1, I opted for putting each project into a single separate Mayan EDMS installation. <\/p>\n\n\n\n While that spared me the downsides of ACL administration work, customer doubts about confidentiality problems and backup issues the solution comes with its own drawbacks: <\/p>\n\n\n\n Each machine (physical or virtual) hosting the server must be updated separately. Whenever there are security upgrades by Ubuntu, new releases from Mayan, the work multiplies<\/strong> as compared to the single Mayan instance.<\/p>\n\n\n\n The solution therefore has the typical drawbacks in terms of redundancy<\/strong> – both with regards to hours spent on system maintenance<\/strong> as well as to resource consumption<\/strong>.<\/p>\n\n\n\n Additionally, a classical dependency problem<\/strong> popped up: I first ran into problems because the new Ubuntu 22.04 LTS Server ships with Python 3.10 as the default version, while the direct deployment of Mayan until recently expected Python 3.8, so I had to trick around with the deadsnakes repository to have a Python 3.8 which I could put into the virtual environment. Now, I have two Ubuntu 20.04 LTS instances with default Python 3.8, but since Mayan 4.3, Python 3.10 is required.<\/p>\n\n\n\n So instead of running multiple servers with multiple Mayan installations, fiddling around with dependencies etc., I will give Docker a try. Ideally, there will be a virtual machine that holds has several docker-compose Mayan clusters, each for one Mayan installation. But before I will be able to try out whether this allows a less tedious maintenance, I will have some migration work to do. Allons-y!<\/p>\n\n\n\n According to the Mayan EDMS documentation, there are two components to back up:<\/p>\n\n\n\n Prior to running the backup operations, we stop Mayan: We will follow the PostgreSQL documentation<\/a> to dump the mayan database. Initially I thought it would be safer to dump the whole PostgreSQL server with all users, roles and passwords with It turned out the opposite is true: The PostgreSQL data base which is set up by the Docker compose only has a single user By default, the Mayan EDMS After a quick check to make sure that there is still enough space on our hard drive left…<\/p>\n\n\n\n … we proceed with the command suggested by the Mayan EDMS online documentation<\/a> (we leave out the Finally make sure that our backup files have really been created on the source machine:<\/p>\n\n\n\n As I would like to have all non-container data relating to Docker in a single place, I first created a Inside the Step 3 of the Mayan EDMS instruction downloads the files needed by Docker to create all necessary containers and their surrounding infrastructure (networks, volumes). Download the Edit the .env file as follows:<\/p>\n\n\n\n1.2 Downside of running separate Mayan installations<\/h3>\n\n\n\n
1.3 Hoping to get the best of both worlds with Docker<\/h3>\n\n\n\n
2. Backing up the existing Mayan Server<\/h2>\n\n\n\n
\/opt\/mayan-edms\/media<\/code> directory which holds all the files stuffed into the document manangement system<\/li><\/ul>\n\n\n\nsudo service supervisor stop<\/code><\/p>\n\n\n\n2.1 Backup PostgreSQL<\/h3>\n\n\n\n
pg_dumpall<\/code> instead of pg_dump<\/code>. <\/p>\n\n\n\nmayan<\/code> which is both superuser and owner of the mayan<\/code> database. Therefore trying to restore a complete server with the default superuser postgres<\/code> will only cause errors during the restore operation. Go for the simple dump with of the mayan<\/code> database only and everything will be fine:<\/p>\n\n\n\nilek@mayan2:~$ pg_dump -U mayan -d mayan -f mayanli_dump_20220906.backup\n<\/pre><\/div>\n\n\n\n
2.2 Backup media folder<\/h3>\n\n\n\n
media<\/code> folder which holds all the files checked into the system in their original format (not with their original name, though but labelled by uuids), resides in \/opt\/mayan-edms\/media<\/code>.<\/p>\n\n\n\nilek@mayan2:\/opt\/mayan-edms$ df -h\nFilesystem Size Used Avail Use% Mounted on\n[...output shortened...]\n\/dev\/sda2 41G 14G 26G 35% \/\n[...output shortened...]\ntmpfs 394M 0 394M 0% \/run\/user\/1000\n<\/pre><\/div>\n\n\n\n
v<\/code> flag originally given for the tar command as this would result in an endless list of files churning through the terminal window and would slow down the backup):<\/p>\n\n\n\nilek@mayan2:~$ sudo tar -zcf mayanli_media_20220906.tar.gz \/opt\/mayan-edms\/media\/\ntar: Removing leading `\/' from member names\n<\/pre><\/div>\n\n\n\n
ilek@mayan2:~$ ls -alh | grep mayan\n-rw-rw-r-- 1 ilek ilek 45M Sep 6 14:19 mayanli_dump_20220906.backup\n-rw-r--r-- 1 root root 1.6G Sep 6 15:14 mayanli_media_20220906.tar.gz\nilek@mayan2:~$ \n<\/pre><\/div>\n\n\n\n
3. Preparing the new Mayan EDMS instance<\/h2>\n\n\n\n
3.1 Prepare working directory structure<\/h3>\n\n\n\n
docker<\/code> directory directly under my home<\/code> directory.<\/p>\n\n\n\ndocker<\/code> directory I created a directory mayanli<\/code> that should hold all external data for a single mayan instance.<\/p>\n\n\n\ndocker-compose.yml<\/code> and the .env<\/code> file that we download in step 3 of the Mayan instructions<\/a>.<\/li>media<\/code> and the postgres<\/code> volumes of our dockerized Mayan installation.<\/li><\/ul>\n\n\n\n3.2 Prepare docker-compose files<\/h3>\n\n\n\n
docker-compose.yml<\/code> and the .env<\/code> file into the mayanli<\/code> directory.<\/p>\n\n\n\n[...]\nCOMPOSE_PROJECT_NAME=mayanli\n[...]\nMAYAN_APT_INSTALLS=\"tesseract-ocr-deu tesseract-ocr-fra\"\n[...]\nMAYAN_DATABASE_NAME=mayan\nMAYAN_DATABASE_PASSWORD=yourPostgreSQLUserPassword\nMAYAN_DATABASE_USER=mayan\n[...]<\/pre><\/div>\n\n\n\n
MAYAN_APP_VOLUME<\/code> and MAYAN_POSTGRES_VOLUME<\/code> in the .env<\/code> file did not work for me (while the custom postgres<\/code> directory is populated during the install, the custom media<\/code> directory remains completely empty. Furthermore, two additional volumes are still created under the default \/var\/lib\/docker\/volumes path<\/code>.