KEEPING PODMAN CHAMP STATUS WITH A HANDY-DANDY SIDE KICK GUIDE

What is this?

You’ve got podman up and running in one of many ways.
You’ve decided to stay for the longer haul.
The passage of time quickly erases your memory so you don’t remember what’s important or what commands to run and all that stuff and you lose your Podman Champ Status
You open up this page and quickly refresh yourself and once again – you’ve got Podman Champ Status

Some quick Podman controls

First, here are some quick commands using nextcloud and its containers as a kind of framework. Adjust accordingly:

Impress people with these commands:

Individual Podmen Containers:
(Assuming mariadb, nextcloud_app and caddy are the container names)

1. Take all containers down with podman stop -a
2. Bring up mariadb with podman start mariadb
3. Bring up nextcloud with podman start nextcloud_app
4. Bring up Caddy with podman start caddy
5. Bring DOWN just mariadb with podman stop mariadb (and other containers same way)
6. Bring up all containers from your podman-compose.yaml file: podman compose up -d
7. Bring up a podman-compose yaml container group up so they join a specific pod: podman --in-pod=1 up -d

Pods:
(Assuming ‘nextcloud’ is the pod name)

1. Bring up whole POD with podman pod start nextcloud
2. Bring down a whole POD with podman pod stop nextcloud
3. Destroy the pod (and all the containers with it!): podman pod rm nextcloud (you can recreate the same way you did the first time)

How to Update your (Nextcloud) image

I threw ‘Nextcloud’ into brackets there because you should be able to update whatever you’re doing in the same way.

Here is what you need to know that I learned the hard way but with very little damage since I was still testing: if you plan to upgrade from, say, 27-fpm to 30-fpm (example) then you have to upgrade your databases as you go. All seasoned admins know this but although I am seasoned, I’m not a seasoned admin.

I just swapped out the image from 27 to 30 and ran the command again and killed my database (without having first backed up).

You should absolutely back up everything in your /home/.podman directory that you created with my fancy command above before doing any of this so at least you have a hope of backing up.

You should also refer to your project community and check their upgrading instructions to make sure you are doing it in the right order / right way.

Interesting learning point: I ran this entire setup above changing only the nextcloud image and it worked (with Maria 11 image).

How to Backup your (Nextcloud) Container Database

Continuing with Nextcloud as our guinea pig example…

I will assume you know roughly how to back up a MySQL database. If not I have several blogs around or the internet is pretty full of help. For now, we’re just looking at doing it in a containerized environment. In fact, we should really make a script on the server to run this every few days, however, for now, let’s try a manual command to make sure we’ve got the ability to do it.

But first, just a quick note to let you know I first tried to back this up in the container itself but because of the rootless situation I set up (podman can run rootlessly), it was getting really hard. I would have had to create a dedicated ‘backup’ directory in the container itself with the appropriate permissions, etc, so what I found was it was totally fine to just back it up to the root user account instead of bothering with all the other stuff since that’s ultimately where I was going to put the backup file anyways.

Here is the command I ran which is applicable to the nextcloud mariadb database. You’ll have to adjust if you are using postgres or something different but the basic flow is the same:

podman exec mariadb sh -c 'mariadb-dump -u root -p"YourSecretPasswordHere" --all-databases' > $HOME/.podman/nextcloud/backups/nc_db_all.sql

That is your foundational command. Let’s walk through it in pieces so we’re comfortable and can adapt it however we like:

podman exec -> says ‘I’m doing this next move inside the container, not in the host machine’
mariadb -> this is the name of your mariadb container in podman. You might have named it ‘mariadeebeeso adjust it if you did... sh -c-> this says 'I'm about to give a longer command within two single quotations which needs to run in the container" mariadb-dump…-> everything inside the single quotes is the command we're running inside the container mariadb-dump-> this is a cool containerized version (I guess?) of the ol' mysqldump command I remember running back in the day... –all-databases -u root-> this should be self explanatory if you've dumped in the past... -p”YourSecretPasswordHere” -> This part messed me up. I always have a SPACE after a-pkind of a flag but this time it failed when I added the space. I had assumed I was reading a typo and added the space. Key: **there should NOT be a space after the -p flag in this command!** –all-databases’ -> backup all databases, not just a specific one > $HOME/.podman/nextcloud/backups/nc_db_all.sql` -> this part says ‘stick the backup .sql file named ‘nc_db_all.sql’ into a directory called ‘backups’ which is located in the .podman directory (a directory I created on my host machine outside of the container)

• Check to make sure it’s there, adjusting paths as required: ls -al ~/.podman/nextcloud/backups
• Make sure it doesn’t have any glaring integrity errors with md5sum ~/.podman/nextcloud/backups/nc_db_all.sql

Congrats. You have your database file from Nextcloud successfully backed up into a non-Nextcloud directory on the host volume.

How to Backup your (Nextcloud) data and other Podman Stuff

Finally, let’s back up our actual data directories and other key stuff that’s sitting on the host machine.

Think about this, too, as a kind of higher-level thought: this part also assures your ‘portability’ and one of the main reasons I got into this. Because everything is packaged on the host, really, the entire backup process (other that the database files which should be treated differently and extracted from the container and into another place) is just a matter of backing up two things, from my somewhat-fresh understanding:

1. The container data directories
2. Your podman-compose.yaml file (if you have one)

In my case, I have my podman compose files sitting outside of my container directories, but now that I type this section, I think I am going to change that and stick it at the top level of the container directory. My original reason was to put them into one ‘execution folder’ so I could spin them up and down faster, but for the amount of time it takes to type some extra paths it’s probably smarter and cleaner to leave it at the top. So, now the two items above are reduced to one and here is the revised list of things you need to regularly backup:

1. Your container data directories

All you need to do here is back it up however you like. To be honest, I’ve never actually done an off-server backup in this context other than SFTP. You can read about how I did that here if you are curious. However, I think there are other tools for doing this better and probably on a schedule. Maybe this is a good tool for n8n, one of my new containers?

In either case, copy that container directory with your podman-compose.yaml file somewhere safe off of the machine and that is pretty much all you need to do to both back it up and move the entire instance to another server.

I should add in as a ‘gotcha’ that you also would need your Caddyfile or reverse proxy configs so maybe it might also make sense to copy the current caddy file, once in a while, to the top level directory of the container, too? Just wanted to point that out in case it got forgotten.

I hope this helps you keep your Podman Champ Status as I am endeavouring to do the same.