7-Point Database Hardening Checklist for VPS (2026)

Database hardening is the set of configuration changes between "the database is installed" and "the database is production-ready": removing installer leftovers, running the engine unprivileged, keeping it patched, and making sure the backups both exist and are protected. This page documents the 7 checks in the CtrlOps Database Configuration and Hardening audit, in the order the audit runs them.

It is a different layer from authentication (who can connect) and network isolation (who can reach the port). Every threshold below is transcribed from the audit script itself, not from general advice. Where the script passes a value, this page says it passes; where the script warns rather than fails, this page says so and explains why the distinction matters.

Key takeaways

Seven checks, and four of them are about backups. That weighting is deliberate: a hardened database you cannot restore is still a total loss.

• Four are rated HIGH: the service user, pending patches, backup permissions and backup encryption. Two are LOW, and both of those are about resilience rather than exposure.
• Five need root. The service-user check reads the process table and the patch check reads package metadata, both of which work unprivileged. Everything touching backup paths and database internals needs sudo.
• The whole audit takes about 19 seconds when CtrlOps runs it over your existing SSH connection, against roughly 20 to 30 minutes by hand.
• This is the longest database audit for a reason. It reads the process table, queries two engines, compares mount points, greps every cron source and walks five backup directories.

Check 1: Do the database engines run as root?

Every database engine ships with a dedicated unprivileged account: mysql, postgres, mongodb, redis. If the process runs as root instead, a vulnerability in the engine stops being a database problem and becomes a full server compromise. The service account is the containment boundary, and without it there is no containment.

The audit finds the running process for each of mysqld, mariadbd, postgres, mongod and redis-server, then reads the owner from the process table. No privileged access is needed, which is why this HIGH check needs no sudo.

How to check manually

ps -eo user,comm | grep -E 'mysqld|mariadbd|postgres|mongod|redis-server'

The SKIP is worth reading carefully. This check inspects running processes, not unit files, so a database that is installed and stopped produces a skip rather than a pass. If you expected a result and got a skip, the first question is whether the service is actually up.

How to fix it

# Set the account on the unit
sudo systemctl edit mysql
# [Service]
# User=mysql
# Group=mysql

# Give the new account its data
sudo systemctl stop mysql
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl daemon-reload
sudo systemctl start mysql

Check 2: Are installer defaults still in place?

Installers leave artefacts behind. The audit asks two specific questions rather than surveying everything:

• MySQL: does the test database still exist? It ships writable by any account and is the thing mysql_secure_installation removes first.
• PostgreSQL: does PUBLIC still hold CREATE on the public schema? That was the default before PostgreSQL 15, and it means any role can create objects in a schema every role can see.

MongoDB is always reported as not audited here, because checking its default test database needs an interactive mongosh session that a read-only audit will not open.

How to check manually

# MySQL
sudo mysql -N -e "SHOW DATABASES LIKE 'test'"

# PostgreSQL
sudo -u postgres psql -X -tAc "SELECT has_schema_privilege('public','public','CREATE')"

How to fix it

# MySQL: the whole-job fix
sudo mysql_secure_installation

# Or by hand
sudo mysql -e "DROP DATABASE IF EXISTS test; DELETE FROM mysql.db WHERE Db LIKE 'test%'; FLUSH PRIVILEGES;"

# PostgreSQL: close the public schema
sudo -u postgres psql -c "REVOKE CREATE ON SCHEMA public FROM PUBLIC;"

Check 3: Are there pending database security patches?

An unpatched database engine with a published CVE is the most direct attack path there is: the vulnerability is documented, the exploit is usually public, and the version number is often visible from outside. This check filters your package manager's pending update list down to the database engines.

How to check manually

# Refresh first, or the answer is meaningless
sudo apt update

# Debian/Ubuntu
apt-get -s upgrade 2>/dev/null | grep '^Inst ' | grep -iE 'mysql|mariadb|postgres|mongo|redis'

# RHEL/Rocky/Alma
dnf check-update 2>/dev/null | grep -iE 'mysql|mariadb|postgres|mongo|redis'

FAIL only happens on apt. Separating security updates from ordinary ones is only done on the Debian family here, so on RHEL, SUSE and Alpine every pending database update reports as a WARN regardless of what it fixes. A warning on a Rocky host is not evidence that nothing security-related is waiting; run dnf updateinfo list security yourself.

The other thing to know: this check does not refresh package metadata. Every check in the catalog is strictly read-only and apt update writes to disk, so a host that has not refreshed in three weeks can report a clean pass while patches sit waiting upstream.

How to fix it

sudo apt update
sudo apt install --only-upgrade mysql-server postgresql redis-server

# RHEL family
sudo dnf upgrade --security

Check 4: Do transaction logs share a disk with the data?

MySQL binary logs and the PostgreSQL write-ahead log are the recovery mechanism. If they live on the same partition as the data files and that partition fills, you lose the ability to write data and the ability to recover from that at the same moment.

The audit compares mount points rather than paths. For MySQL it only looks when log_bin is actually on, then compares the mount of the data directory against the mount of the binary log directory using df. For PostgreSQL it tests whether pg_wal inside the data directory is a symlink, which is how a separate WAL disk is conventionally arranged.

How to check manually

# MySQL: is binary logging even on, and where does it write?
sudo mysql -N -e "SELECT @@log_bin, @@datadir, @@log_bin_basename"
df -P /var/lib/mysql /var/log/mysql | awk 'NR>1{print $6, $1}'

# PostgreSQL: is pg_wal a symlink to another disk?
PDD=$(sudo -u postgres psql -X -tAc 'SHOW data_directory')
sudo test -L "$PDD/pg_wal" && echo "separate" || echo "same disk"

This is LOW severity because on a single-disk VPS you often cannot fix it, and the check knows that. Treat a warning here as a documented limitation rather than a task: it tells you that a full disk is a two-failure event on this host, which is useful when you are deciding how much headroom to leave and how loudly to alert on disk usage.

How to fix it

# MySQL: point the binary log at another mount
# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin

# PostgreSQL: symlink pg_wal onto a separate disk (needs downtime)
sudo systemctl stop postgresql
sudo mv "$PDD/pg_wal" /mnt/waldisk/pg_wal
sudo ln -s /mnt/waldisk/pg_wal "$PDD/pg_wal"
sudo chown -h postgres:postgres "$PDD/pg_wal"
sudo systemctl start postgresql

Check 5: Is there a scheduled database backup?

A database with no scheduled backup is a database you have decided you can lose. This check looks for evidence that something dumps it on a schedule.

The search is broader than most people expect. It matches mysqldump, mariadb-dump, pg_dump, pg_basebackup, mongodump, xtrabackup, mariabackup, and also borg and restic, across /etc/crontab, the four /etc/cron.* directories, /etc/cron.d, user crontabs under /var/spool/cron, and finally systemd timers whose name mentions backup or dump.

How to check manually

sudo grep -rhiE 'mysqldump|mariadb-dump|pg_dump|pg_basebackup|mongodump|xtrabackup|mariabackup|borg|restic' \
  /etc/crontab /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /var/spool/cron 2>/dev/null

systemctl list-timers --all --no-legend | grep -iE 'backup|dump'

Two limits worth stating. The check confirms a job exists, never that it runs, completes, or produces a valid dump. And it only sees scheduling that lives on this host, so a backup driven by an external orchestrator, a cloud snapshot policy or a managed service will warn here despite being perfectly real.

How to fix it

# /etc/cron.d/db-backup, encrypted at creation
0 2 * * * root umask 077; mysqldump --all-databases --single-transaction \
  | gzip | gpg --encrypt --recipient backups@your-domain \
  > /var/backups/mysql/$(date +\%Y\%m\%d).sql.gz.gpg

Check 6: Are backup files world-readable?

A dump file is the entire database in one file: every table, every row, every credential your application stored. If it is world-readable, any account on the server can copy the lot without ever connecting to the database or knowing a password.

The audit walks the five backup paths for the four dump extensions and tests the world-readable bit.

How to check manually

sudo find /var/backups /backup /opt/backup /srv/backup /root/backups -maxdepth 3 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.dump' -o -name '*.bak' \) \
  -perm -004 2>/dev/null

The test is world-readable specifically, so mode 640 passes here. That is looser than it looks: the group on a backup file is usually root, so 640 and 600 are effectively the same. Set 600 anyway, because the group can change without anyone noticing.

How to fix it

sudo chmod 600 /var/backups/mysql/*.sql.gz*

# Fix the cause, not the symptom
# At the top of the backup script:
umask 077

Check 7: Are backups encrypted at rest?

Permissions protect a dump from other accounts on this server. Encryption protects it from everywhere else it ends up: the offsite copy, the object storage bucket, the laptop someone pulled it onto to debug something.

This check has the most nuanced logic on the page. It counts plaintext dumps, counts encrypted archives (.gpg, .enc, .age, .aes), and separately checks whether an encrypting backup tool (borg, restic or duplicity) is installed at all.

How to check manually

# Plaintext dumps
sudo find /var/backups /backup /opt/backup /srv/backup /root/backups -maxdepth 3 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.dump' -o -name '*.bak' \) 2>/dev/null | wc -l

# Encrypted archives
sudo find /var/backups /backup /opt/backup /srv/backup /root/backups -maxdepth 3 -type f \
  \( -name '*.gpg' -o -name '*.enc' -o -name '*.age' -o -name '*.aes' \) 2>/dev/null | wc -l

# An encrypting tool at all
command -v borg restic duplicity

The WARN branch is the interesting one and it exists to avoid a common false alarm. A perfectly good restic setup often writes a plaintext dump to a staging directory, encrypts it into the repository, and deletes it, so an audit that happens to land mid-cycle sees plaintext. Rather than failing that host, the check notices the tool is installed and asks you to confirm. If you have no such tool and plaintext dumps on disk, that ambiguity does not exist and it fails.

How to fix it

# Encrypt during creation so plaintext never lands
mysqldump --all-databases --single-transaction \
  | gzip | gpg --encrypt --recipient backups@your-domain \
  > /var/backups/mysql/$(date +%Y%m%d).sql.gz.gpg

# Or with age
... | age -r age1yourpublickeyhere > backup.sql.gz.age

What this audit does not cover

Being explicit about scope is part of the point of publishing thresholds.

• Whether the database asks for a credential. That is the authentication audit.
• Whether the port is reachable. That is the network isolation audit.
• Whether backups actually restore. Checks 5, 6 and 7 confirm a job exists, that dumps are not world-readable and that something is encrypting. None of them opens a dump or tests a restore.
• Backup paths outside the five searched. Dumps written to object storage, to a mounted share, or to a custom directory produce a SKIP on checks 6 and 7 rather than a pass.
• Retention and offsite copies. A single encrypted dump from last March passes checks 6 and 7 exactly as well as a healthy rotation does.
• Managed database services. RDS, Cloud SQL and Azure Database expose none of these processes, sockets or files to a host session.

The manual audit problem at scale

Running these 7 checks by hand takes 20 to 30 minutes per server, and it is the most tedious database audit in the set because every check reads a different kind of thing: a process table, two live SQL queries, package metadata, mount points, four cron locations, and a walk over five backup directories.

The backup half is where manual auditing fails in practice. Confirming a cron entry exists is fast. Confirming that the entry has been producing non-empty, non-truncated, encrypted output for the last thirty days is not something anyone does from a terminal, so it does not get done, and the gap only surfaces when someone needs a restore.

Patch state has the opposite problem: it is easy to check and it goes stale immediately. A clean result from last Tuesday says nothing about today, which is the same server management drift problem that compounds across every audit category.

How CtrlOps runs all 7 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Configuration and Hardening audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH & Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal. The written steps that follow cover the same ground if you would rather read than watch.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Configuration & Hardening

Choose it from the Database category. All 7 checks are listed with their descriptions, severity levels and the estimated run time (about 19 seconds in total). Toggle off any check you want to skip.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table you can sort and filter

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here: several of these fixes stop a database service.

Step 6: Re-run and compare

Run the same audit again after applying the fixes and watch the hardening score move. Patch state in particular is worth re-running weekly, because it is the one finding on this page that reappears on its own.

Conclusion

Hardening is the layer nobody revisits. The service account was correct on install day, the test database was going to be dropped later, the backup job was written once and never restore-tested, and the dumps have been sitting in /var/backups unencrypted since the day they started.

Four of these seven are HIGH severity, and three of those four are about backups, because a database you cannot restore safely is a database you have already lost. The CtrlOps Security Audit runs the set in about 19 seconds per server, agentlessly.

The neighbouring checklists cover the other database layers: authentication, credential storage, least-privilege permissions, network isolation and transport encryption.

Frequently asked questions