Grinnell’s dockerized version of Omeka-S has been running for several weeks now, and we recently ran out of disk space for object data on the host, a CentOS node we named DGDocker2. My posts 041, Configuring DGDocker2 and 042, My dockerized-server Config address the original configuration of DGDocker2 in detail.

Omeka-S is configured on DGDocker2 to reside in /opt/omeka-s-docker, and inside that directory is a subdirectory named volume. The portions of the application stack that deliver Omeka-S are configured largely in /opt/omeka-s-docker/docker-compose.yml, and portions of that file related to this discussion include:

services:
  ...
  omeka:
    ...
    volumes:
      - omeka:/var/www/html/volume
volumes:
  ...
  omeka:

So, there’s a Docker-managed volume named omeka that maps into the omeka container as /var/www/html/volume. This ../volume directory contains two subdirectories, ./config and ./files. We are really only interested in ./files, but because of the way things are mapped I found it prudent to deal with /opt/omeka-s-docker/volume itself, rather than trying to separate ./config from ./files.

The quick and easy solution to change this configuration did NOT work! Consequently, I’m hiding that work from public view…until a long-term solution is found.

Since the quick-fix didn’t work, we are going to extend the original system, or “root”, disk and supplement the stack with some automated “backup” operations to capture any changes made so that we can eventually roll those into a properly configured and dockerized Omeka-S. The backup operations involve the following:

In the mariadb container, a new script at /daily-script.sh with the following contents:

#!/bin/bash
## This is daily-script.sh for the Omeka-S "mariadb" container.
/usr/bin/mysqldump -u root --password=${MYSQL_ROOT_PASSWORD} omeka > omeka-database-backup.sql

On the DGDocker2 host, there’s a new script at /opt/omeka-s-docker/daily-backup.sh with contents of:

#!/bin/bash
mkdir -p /omeka-digital/temporary
docker exec mariadb ./daily-script.sh       
docker cp mariadb:/omeka-database-backup.sql /omeka-digital/temporary/omeka-database-backup.sql
docker cp omeka:/var/www/html/modules /omeka-digital/temporary
docker cp omeka:/var/www/html/themes /omeka-digital/temporary
tar -zcvPf "/omeka-digital/backups/$(date '+%Y-%m-%d').tar.gz" /omeka-digital/temporary --remove-files

And finally, there’s a new “root” crontab entry on DGDocker2 of:

0 18 * * * /opt/omeka-s-docker/daily-backup.sh

The result of all this should be a daily backup of about 17MB saved on the NFS share at /omeka-digital/backups/<today>.tar.gz, where <today> is the current date in a format like 2019-11-15. For example, a test backup run earlier today produced:

╭─root@dgdocker2 /omeka-digital/backups
╰─# ll
total 17M
-rw-r--r--. 1 root root 17M Nov 15 14:44 2019-11-15.tar.gz

And that’s a wrap. Until next time…