We have been using Percona Pmm Server for a number of years and have migrated our server to pmm2 docker format. where previously we used the vmware appliance.
The question of backing up data (graphics) and configurations of connected clients therefore arises. since before we made a btrfs snapshot and mysql dumps that we saved.
We found some information regarding the backup:
But the renaming part:
docker rename pmm-server pmm-server-backup
Is not very clear. why rename the image?
what are the backup solutions for the configuration of connected clients and servers as well as graphed data?
hi @C80SGEEK thank you for posting to the Percona forums! We include the rename step so that we preserve the runtime container during upgrade, so that if anything goes wrong, you have a rollback point. The rename is an optional but recommended step in the upgrade process.
Regarding other PMM backup methods, you could use:
I think that the purpose of all these “how to” is not the same as mine. Their goal seems always to be migration.
My goal is to have backups for crash recovery essentially configurations and connected pmm-clients.
will pmm dump utility fit my needs ? or only dumps metrics ?
reading futher in .tar backup i came accros the following :
this should fit my needs if i skip the rename part and just backup my data on scheduled way.
does people not do scheduled backups of their pmm2 servers ?
Migration requires you to back up your instance and then restore it elsewhere, which is effectively what disaster recovery aka backups are for.
So while the links are for more extensive operations intended to be executed in a short window of time, you can benefit from just using the first half of taking the backup, and hopefully you never have a failure of the PMM Server and therefore never need to do the second half which is the restoration step.
@C80SGEEK, I had a similar question some time ago that was escalated by a customer with a significantly sized PMM instance. Our only ability to take a reasonable backup was limited to a filesystem type snapshot or stopping PMM and doing a filesystem copy of all the data. Didn’t feel like either was “enterprise” enough…not to mention there was a different approach for each way you run PMM (i.e. the commands for docker were wildly different than OVF/AMI.
So I got to tinkering and came up with this prototype. The goal was 1) hot backups of configuration and data 2) consistent approach to running it regardless of docker, AMI, OVF, K8s, 3) something that could easily be scheduled via cron and as a stretch 4) ability to restore the data to a newer version of PMM effectively performing an upgrade.
I’d love feedback on it from a wider range of users but we have used this with a considerably large customer (300GB of client and metrics data) to both perform an in-place backup/disaster/restore as well as a “lift and shift” upgrade. I believe it’s doing a nightly backup via cron for them as well. If this ends up being useful enough we can bundle it in PMM with the needed supporting tools.