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!
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.
- Run commands in Influx DB container, make some magic to gather backup file and transfer it to S3
- 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.
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
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
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!