Missing „ingredient” of PV Dashboard

PV Dashboard, my Grafana, which integrates PV data from multiple sources using NodeRED and InfluxDB after few iteration is still missing important piece.

BACKUP. WHERE IS BACKUP?

Yep, that’s me, you’re probably wondering how I ended up in this situation…

Everybody stay calm

Well, it’s not as bad as it sounds. Few components are 100% safe with configuration stored in git repository, but every day there is new data populated into DB.

What components do I have:

  • Docker Compose -> Stored in repository
  • Nginx -> Server Block stored in repository
  • Grafana -> Dashboard Model stored in repository
  • NodeRED -> Flows stored in repository
  • Influx DB -> well…

Measurements stored in Influx DB are reproducible by running flows that will gather all of them from eLicznik and SolarEdge. It will consume time, probably more and more time day by day, because the dataset is growing.

It’s good practice to back up your DB, and I want to be a good boy. Let’s do it!

Two approaches

If you remember my entry about PV Dashboard, entire solution is set up in Docker Compose file. Influx DB is containerized, so we have two ways of backing up data.

  1. Run commands in Influx DB container, make some magic to gather backup file and transfer it to S3
  2. Unmount volume with data from Influx DB container and back up entire volume

Which way is the fastest and most optimal?

Let’s Docker it out

I’m a programmer, so as you expected – I’m a lazy bastard.

Who has time for creating backup inside container?
Pff, let’s stop DB container, mount volume to temporary one, back it up and start container.

Easy? Of course, it’s easy. Docker documentation here I come!

I don’t recommend such solution, but in my case and only two writes per day at predefined time it’s a safe option. Stopping container will not affect any writes or availability.

Bash script

It’s stated in Docker documentation that we will need only one command. Great, let’s add a pinch of container state management to that, and voilà.

#!/bin/bash

#Stop docker container that will be backed up
docker stop $1

#Run temporary container that will backup our volume
docker run --rm --volumes-from $1 -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar $2

#Start docker container that was stopped for being backed up
docker start $1

Executing the script is easy, we need to provide those parameters:

  • container name
  • volume path

In my example, it will look like this:

#Remember to add appropriate permissions
#chmod +x backup_docker.sh

#Run script
./backup_docker.sh pv-dashboard_influxdb_1 /var/lib/influxdb

The above version is in the purest form as it can be. After a little refactoring and preparing the script for execution from crontab + uploading file to Scaleway S3 (lot of free GB), it will look as below.

#!/bin/bash

#In some cases specifing path is required
#export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

#Set variables
CONTAINER_NAME=$1
VOLUME_PATH=$2

#Go to directory where backup.tar will be saved
cd /var/backups/

#Stop docker container that will be backed up
docker stop $CONTAINER_NAME

#Run temporary container that will backup our volume
docker run --rm --volumes-from $CONTAINER_NAME -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar $VOLUME_PATH

#Start docker container that was stopped for being backed up
docker start $CONTAINER_NAME

#-------Start of S3 part-------
#Prepare archive name
ARCHIVE_NAME="volume-backup__$(date +%Y-%m-%d)_$(date +%H:%M:%S).tar"

#Apply archive name
mv backup.tar $ARCHIVE_NAME

#Upload archive to S3
s3cmd put $ARCHIVE_NAME s3://<bucket_name> --no-progress
#-------End of S3 part-------

#Remove archive
rm -f $ARCHIVE_NAME

Crontab entry

Creating backups should be automated and performed during „service hours”.
In my case, backup will be done every day at 1:30 am.

#Open crontab
crontab -e

#Add below entry (edit script location, container name and volume path)
30 1 * * * /var/backups/backup_docker.sh pv-dashboard_influxdb_1 /var/lib/influxdb

Summary

Entire configuration (s3cmd) and writing script took me around 30 minutes.
Faster than I thought, without any harm to my volume. Great!

I hope that my bad practices didn’t make your head ache. Influx DB backup is working as expected, my data is safe, so are my practices so bad?

Let me know in the comment section how would you approach this case!

Join my Newsletter! 👨‍💻

Subscribe to get my latest content by email 🦾

Also read...

The best entries...