Server — MariaDB — Introduction

MariaDB did not get its own article when it was first installed. It arrived as a prerequisite in the PowerDNS article, was set up in a few commands, and immediately put to work storing zone data. That is fine as far as it goes, but it undersells what is actually on February now.

A running, properly configured MariaDB instance is not just a PowerDNS dependency. It is a piece of shared infrastructure that every service on February which needs relational storage can use. PowerDNS and PowerDNS Admin are already using it. Future services, including anything that needs structured persistent data, will use it too. It is worth treating it as a first-class component rather than an incidental installation.

This article is the introduction: what MariaDB is doing on February, why a shared instance is the right model for a homelab server, and what the install and hardening articles that follow will cover. The actual installation and security configuration are covered separately because they deserve enough space to be done properly.

What is already using it

At this point in the series, MariaDB is running two databases on February:

powerdns holds the zone data, record sets, DNSSEC key material, and domain metadata for the PowerDNS Authoritative Server. Every DNS record you have added with pdnsutil or through the PowerDNS Admin interface is a row in this database. Every TSIG key, every SSHFP record, every TLSA record: all of it lives here.

pdnsadmin holds the PowerDNS Admin application state: user accounts, API keys, session tokens, and the web interface configuration. This is separate from the PowerDNS zone data deliberately, so the two applications can be managed and backed up independently.

Both databases are already in the borgmatic backup scope via the /var/lib/mysql directory. That is worth confirming explicitly: MariaDB stores its data files there by default on Ubuntu, and since borgmatic includes that path in its source directories, every backup includes a consistent snapshot of the database files.

Why a shared instance

The alternative to a shared MariaDB instance is running a separate database for each service that needs one, either as individual MariaDB instances on different ports, or as containerised databases spun up alongside each application. Both approaches are defensible in larger environments where isolation and independent scaling matter. For a homelab server running a handful of services, they add complexity without adding meaningful benefit.

A shared instance means one set of MariaDB logs to read, one backup to verify, one upgrade to apply, one service to monitor. Each application gets its own database and its own user with access scoped only to that database, so the isolation that matters, preventing one application from touching another’s data, is still in place. The operational overhead is consolidated rather than multiplied.

The tradeoff is that a single MariaDB failure takes down every service that depends on it simultaneously. On a homelab server where the UPS, the backup strategy, and the monitoring are all already in place, this is an acceptable tradeoff. It would not be acceptable in production where services have independent availability requirements.

What is coming in the next articles

Install and initial hardening covers the parts that were glossed over when MariaDB arrived as a PowerDNS dependency: running mysql_secure_installation properly, understanding what each step does and why, setting up the root account correctly, and confirming the service is configured to listen only on localhost.

User and permission management covers the right way to create database users for each application: minimum necessary privileges, no reuse of credentials across applications, and a consistent naming convention that makes the user list readable six months from now.

Backup and restore covers how to take consistent database dumps with mysqldump or mariabackup, how those integrate with the borgmatic schedule already running on February, and how to verify a restore actually works. The borgmatic setup backs up the MariaDB data directory, but a file-level backup of a running database is not always sufficient on its own: this article explains when it is and when it is not.

Maintenance covers the ongoing operational tasks that are easy to forget once a database is running and seemingly fine: checking the error log periodically, running mysqlcheck after unexpected shutdowns, keeping the MariaDB version current, and understanding what SHOW STATUS and SHOW PROCESSLIST tell you about a server that is misbehaving.

A note on SQLite

For some services, MariaDB is the right choice. For others, SQLite is sufficient and simpler: no separate process, no user management, the database is a single file that lives in the application’s data directory and gets backed up with everything else. When future services are added to February, the decision between MariaDB and SQLite is worth making deliberately rather than defaulting to one or the other. MariaDB makes sense for services that expect concurrent writes, need to be queried from multiple applications simultaneously, or will grow large enough that file-level backups become unreliable. SQLite makes sense for everything else.

PowerDNS specifically needs MariaDB because it writes records from multiple processes concurrently and the gmysql backend has decades of production use behind it. Not every application on February will have those requirements.