Self-hosting Plausible Analytics offers a number of advantages, particularly if you’re keen on owning your data as much as you reasonably can, independent of the constraints any sort of managed plan might offer. But there are trade-offs — the big one being that you don’t get dedicated backups.
Fortunately, it’s straightforward to create and restore these backups yourself.
Since all of Plausible’s self-hosted data lives inside Docker volumes, we’ll be able to use Jarek Lipski’s volume-backup utility for managing backups sourced from those volumes. But first, we’ll need to determine where the relevant volumes are living.
Locating Your Volumes
If you’re used the Plausible Bootstrapper to set up your self-hosted instance of Plausible (or if you used the docker-compose.yml file found in the plausible/hosting repository), your volume names are db-data and event-data. You can confirm that by running logging into your virtual machine and running docker volume ls.
listing docker volumes
The volumes you’re interested in should be obvious to spot.
Preparing for the Backup
Before we actually back up anything, we need to ensure no active containers are relying on those volumes. That’s as simple as temporarily turning off our containers. To do that, you can run the following. This’ll vary a smidge based on where you placed Plausible inside your machine.
# This should be wherever you put Plausible!
cd /opt/plausible
# Turn off all active containers.
docker compose down
After that’s finished, verify that your Plausible volumes are now “dangling,” meaning they’re not connected to a running container:
docker volume ls -qf dangling=true
Assuming all went well, you should see your Plausible volumes named in that list.
Running the Backup
Lipski’s utility makes this next step fairly easy. For each volume, we’ll use the following template:
docker run -v [volume-name]:/volume --rm --log-driver none loomchild/volume-backup backup > [archive-path].tar.bz2
I’ll put my backups in a backups directory within my home directory, so I’ll need to make that first:
# Create backup directory.
mkdir ~/backups
# Run backup.
docker run -v plausible_db-data:/volume --rm --log-driver none loomchild/volume-backup backup > ~/backups/plausible_db-data.tar.bz2
If it’s the first time you’ve run that command, you’ll see some output indicating it’s being downloaded. Future runs will be a little quieter.
running the backup for the first time
Do that for both of the named volumes you listed above.
Restoring Backups
Restoring a backup requires a very similar command — this time using the restore command, but targeting the same backup files:
docker run -i -v plausible_db-data:/volume --rm loomchild/volume-backup restore < ~/backups/plausible_db-data.tar.bz2
Once you’re restored, you can safely docker back on your containers.
Putting Together a Backup Script
It’s easy enough to wrap this in a script you can run on a regular schedule. Of course, it won’t do you any good if your entire virtual machine is trashed, but it’ll at least be there if your specific Plausible instance becomes corrupted, or if a Docker volume is accidentally removed.
#!/bin/bash
# Create "backups" directory if it doesn't already exist.
mkdir -p ~/backups >/dev/null 2>&1
# Turn off docker containers. Important!
docker compose down
# Back up volumes.
docker run -v plausible_db-data:/volume --rm --log-driver none loomchild/volume-backup backup > ~/backups/plausible_db-data.tar.bz2
docker run -v plausible_event-data:/volume --rm --log-driver none loomchild/volume-backup backup > ~/backups/plausible_event-data.tar.bz2
# Turn on containers again.
docker compose up -d
Wire that up to a reguarly scheduled cron job, and you’re good to go.
Top comments (0)