Schedule backups on docker image percona/percona-backup-mongodb:1.8.1

Hi folks,

Sorry for the amount of text, but I’m describing what I already tried in detail. That said, let’s go for it.

I’m using the pbm docker image 1.8.1 to create backups for my 3 node replica set. So far, so good.
I want to schedule backups. If found Schedule backups in the manual which describes how to do it with cron in a regular installation of PBM - but not in the docker image. Anyway I was planning to use cron to do that. And then the horror began…

[root@mongo-backup1 yum.repos.d]# microdnf install cron

(microdnf:2627): librhsm-WARNING **: 10:39:06.317: Found 0 entitlement certificates

(microdnf:2627): librhsm-WARNING **: 10:39:06.319: Found 0 entitlement certificates
Downloading metadata…
error: cannot update repo ‘ubi-8-baseos’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for [SSL certificate problem: EE certificate key too weak]

  • Having a look which repositories are used:

[root@mongo-backup1 yum.repos.d]# ls /etc/yum.repos.d/
percona-original-release.repo percona-pbm-release.repo percona-prel-release.repo percona-psmdb-42-release.repo redhat.repo ubi.repo

  • All repositories in the ubi.repo file are referring to /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release which was created with Version: GnuPG v1.2.6 (GNU/Linux)
  • If I disable the Red Hat repositories (from ubi.repo) the package manager can use Percona repositories to upgrade PBM:

[root@mongo-backup1 yum.repos.d]# microdnf --disablerepo=ubi-8-appstream --disablerepo=ubi-8-baseos --disablerepo=ubi-8-codeready-builder update
(microdnf:2776): librhsm-WARNING **: 10:50:59.268: Found 0 entitlement certificates

(microdnf:2776): librhsm-WARNING **: 10:50:59.270: Found 0 entitlement certificates
Package Repository Size
percona-backup-mongodb-2.0.0-1.el8.x86_64 pbm-release-x86_64 17.3 MB
replacing percona-backup-mongodb-1.8.1-1.el8.x86_64
Transaction Summary:
Installing: 0 packages
Reinstalling: 0 packages
Upgrading: 1 packages
Obsoleting: 0 packages
Removing: 0 packages
Downgrading: 0 packages
Downloading packages…
Running transaction test…
Updating: percona-backup-mongodb;2.0.0-1.el8;x86_64;pbm-release-x86_64
Cleanup: percona-backup-mongodb;1.8.1-1.el8;x86_64;installed

  • The Percona repositories point to the Perconas key located in /etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY which was created with Version: GnuPG v2

The problem is that the key used by the Red Hat repos is created with a GnuPG Version 1.x which is not accepted by microdnf.
I tried the following things to solve the problem:

  • Update Red Hat key /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release looking at Product Signing Keys - Red Hat Customer Portal. I tried this key and this key, but non worked.
  • Then I tried to lower the security limit to be able to also use Keys created with GnuPG v1.x, but it seems that microdnf doesn’t have an option to lower it. dnf has :expressionless:.
  • Then I tried to find an RPM package here to install it with rpm, but didn’t know which to pick… and even if that works, I need to bring all dependencies as well, so it would be much easier to have the red hat repositories working somehow.

Any advice on how to get a key that works or another repository that works?
Once cron is installed the rest is easy.

By the way, a text editor like nano isn’t installed neither, what makes it really hard to work on the machine.

Many thanks, cheers, Daniel

1 Like

It turned out that microdnf works if I’m not using the company proxy :face_with_peeking_eye:.

1 Like

thanks for your feedback @dcamarena !
We do not install cron and any text editors in order to keep docker size smaller.
Also the idea of using container is coming from microservices. And in this case the life time of container should be while executing the job.
So it is recommended to run docker container by cron to execute backup and die after that

1 Like

Hi @Evgeniy_Patlan,

thanks for your suggestion, but PBM doesn’t do only the full backups scheduled by cron.d, it does also the PITR backups. pbm-agent need to run to do this.

Thanks, cheers, Daniel

1 Like