Data-Tier

Tested on: Ubuntu 24.04 LTS and AlmaLinux 9.4, restic 0.16.x. The patterns translate to restic 0.15+ unchanged; older versions have a few CLI differences flagged inline. Why this matters The most common “we had backups, but…” incidents reduce to one of four failures: The backup was on the same disk as the data. When the disk failed, both went together. The backup tool never encrypted anything. A misconfigured S3 bucket leaked the entire database — including the personal data the business had promised to protect. The encryption passphrase died with the original server. The off-site backups still exist; nobody can read them. The backup ran nightly and the most recent twelve failed silently. No alert, no log review, no drill. restic addresses every one of these as a default. It encrypts in the client, deduplicates, supports a wide range of off-site targets, exposes a clean check command for integrity, and reports non-zero exit codes on failure that integrate cleanly with cron and CI. It is not the only acceptable choice — borgbackup is the close runner-up, and for some local-first workloads it is the better fit — but for the EEA-region, S3-compatible, off-site target this site recommends, restic is the path of least resistance. ...

Tested on: PostgreSQL 16.x on Ubuntu 24.04 LTS, restic 0.16.x. The patterns are version-portable to PostgreSQL 14+ with minor command differences; the principles are unchanged. Why this matters A backup you have never restored is a hope. Most “we have backups” incidents reduce to: The backup ran nightly for two years and the most recent twelve failed silently. The backup ran successfully, but the dump’s permissions excluded a schema the application started using six months ago. The backup ran successfully and is intact, but lives on the same disk as the database — so when the disk dies, both die. The backup ran successfully, off-site, encrypted, restorable — but the encryption key was on the same server, and that server is the one that just died. This guide gives you a PostgreSQL backup baseline that survives each of those failure modes. It covers logical backups (pg_dump) for portability, physical backups with WAL archiving for point-in-time recovery, encrypted off-site storage, and a restoration drill cadence. ...

Tested on: Ubuntu 24.04 LTS, Redis 7.2.x (from the official redis apt repository at packages.redis.io). Configuration paths use /etc/redis/redis.conf — RHEL-family installs use /etc/redis/redis.conf as well, so the file paths below are portable. Why this matters Almost every newsworthy Redis incident reduces to one of three failures: The server was bound to 0.0.0.0 “for testing” and reachable from the internet. There was no password (or the password was the example one from a tutorial). FLUSHALL, CONFIG, or DEBUG were left available, so a connected client could wipe data, exfiltrate keys, or write arbitrary files through CONFIG SET dir / BGSAVE. Redis is fast, in-memory, and trusts its clients by default. That trust is appropriate inside a private subnet with disciplined access controls. It is catastrophic everywhere else. This guide closes those three holes and adds the obvious next layer (TLS, resource limits, persistence safety). ...

What this script does redis-check is a read-only Bash + redis-cli script that reports on each recommendation from the Redis hardening guide: Network exposure (bind, protected-mode) Authentication (default user state, any ACL user with nopass) Dangerous-command accessibility (FLUSHALL, FLUSHDB, DEBUG, CONFIG, SHUTDOWN) TLS (tls-port vs cleartext port) Resource limits (maxmemory, maxmemory-policy, timeout) Persistence (appendonly) It uses only PING, INFO, CONFIG GET, ACL LIST, and COMMAND DOCS — no writes. If CONFIG has been renamed or disabled (recommended in the guide), the affected checks are skipped with a WARN rather than failing the whole run. ...

Tested on: Ubuntu 24.04 LTS, PostgreSQL 16.x (apt package from pgdg repository). Commands assume the default data directory at /etc/postgresql/16/main/. Why this matters PostgreSQL ships with defaults that are reasonable for a development laptop and wrong for an internet-exposed server. Three settings in particular cause most real-world incidents: listen_addresses = 'localhost' is fine — until someone changes it to '*' for “convenience” and the database is suddenly reachable from anywhere the firewall lets through. pg_hba.conf defaults still allow trust and md5 in some packaging. trust is no authentication. md5 is no longer considered safe and should be replaced with scram-sha-256. TLS is off by default. Application traffic to the database — including passwords and query results — travels in cleartext on the loopback or on the LAN. This guide fixes those three problems and tightens a handful of related items. It does not cover row-level security, backup hardening, or replication — those get their own guides. ...

What this script does postgres-audit is a read-only Bash + psql script that reports on each recommendation from the PostgreSQL hardening guide: Network exposure (listen_addresses) Authentication: password_encryption, pg_hba.conf entries (no trust, no md5, remote rules using hostssl) TLS (ssl, minimum protocol version) Logging defaults (log_connections, log_disconnections, log_hostname, log_statement) Roles and privileges (non-default SUPERUSER, PUBLIC schema CREATE) It issues only SELECT and SHOW queries. Output is colourised in a terminal and plain text in a pipe, so it works cleanly under cron. ...