DEV Community: Max Diamond

Automated PostgreSQL Backups in Docker: Complete Guide with pg_dump

Max Diamond — Fri, 12 Sep 2025 19:30:48 +0000

Databases fail for many reasons: a bad deployment, dropped tables, disk corruption, or even something as simple as accidentally running a destructive query. When PostgreSQL is containerized, another layer of risk is introduced. If your container or volume is removed without a backup, your data is gone for good.

If you are serious about your application, automated PostgreSQL backups are non-negotiable. In this guide, we'll walk through practical approaches to setting up automated backups for PostgreSQL inside Docker. We'll cover the tools PostgreSQL provides, how to schedule backups, how to rotate and prune them, and what to consider for larger or production systems.

By the end, you'll have a working strategy that runs on autopilot and keeps your database safe.

Postgres Setup

For demonstration, here’s a minimal docker-compose.yml file running PostgreSQL:

services:
  db:
    image: postgres:16
    container_name: postgres
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypass
      POSTGRES_DB: mydb
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

This gives you a working Postgres instance with persistent storage. The database lives inside the db_data volume. If that volume is lost or corrupted, so is your data. Backups need to live outside of this container lifecycle.

Want to deploy PostgreSQL on your server? Check out our guide to deploying PostgreSQL on a VPS using Docker.

Creating a Manual Backup with pg_dump

pg_dump is the most common way to generate a logical backup of a PostgreSQL database. It exports your schema and data into a SQL file, which makes it portable and easy to restore. Running it inside Docker is straightforward with docker exec:

docker exec postgres pg_dump -U myuser mydb > backup.sql

This works fine for smaller databases, but keep in mind that logical dumps can take a long time and consume significant disk space as your dataset grows. For very large databases, you might prefer physical backups with pg_basebackup or file system snapshots. For most applications though, pg_dump strikes the right balance between simplicity and reliability.

The downside of running pg_dump manually is that it only works if you remember to do it. And let’s be honest, engineers are great at automating everything except the things they’re supposed to do daily. So lets get into automating the backups so you can sleep easy at night knowing your data is safe.

Automating Backups with a Sidecar Container

To automate backups, you can run a lightweight container alongside your database that executes pg_dump on a schedule. A common approach is to loop with sleep, writing a new dump file every day.

Here’s an example backup service added to docker-compose.yml:

  backup:
    image: postgres:16
    container_name: pg_backup
    depends_on:
      - db
    volumes:
      - ./backups:/backups
    entrypoint: >
      bash -c 'while true; do
        pg_dump -h db -U myuser mydb > /backups/db-$(date +%F-%H-%M-%S).sql;
        sleep 86400;
      done'
    environment:
      PGPASSWORD: mypass

This setup:

Connects to the db service.
Dumps the database once every 24 hours.
Saves the output into a mounted ./backups directory with a timestamp.

It’s simple, but surprisingly effective. For many small projects, this sidecar approach is all you need.

Scheduling postgresql backups with Cron

While looping with sleep inside a container is fine for simple setups, cron is the tool most engineers reach for when they want proper scheduling. Cron gives you full control over when backups run, how often, and how they integrate with other maintenance tasks.

On the host machine, you can add a cron entry like this:

0 2 * * * docker exec postgres pg_dump -U myuser mydb > ~/backups/db-$(date +\%F).sql

This creates a new backup every day at 2 AM. If you need more frequent dumps, you can schedule them hourly or every few minutes just by adjusting the expression.

The advantage of cron is its flexibility. You can add post-processing steps in the same job, such as compressing the file or pushing it to cloud storage. And unlike a backup container running in a loop, cron makes it easy to see and manage schedules across your server.

For environments where cron is not available, you can achieve the same effect inside a dedicated container running a cron daemon. This approach keeps all logic inside Docker and avoids relying on host-level configuration.

Compression to Save Space

As soon as you start keeping more than a handful of backups, file size becomes an issue. Logical dumps are plain text, and plain text compresses very well. The solution is to pipe the output through a compression tool like gzip:

docker exec postgres pg_dump -U myuser mydb | gzip > backup.sql.gz

This can reduce backup file sizes by 70-90%, depending on your data. For production systems with daily backups, compression is essential to keep storage costs manageable.

Backup Retention and Cleanup

Without proper cleanup, your backup directory will eventually consume all available disk space. A good retention policy keeps recent backups readily available while pruning older ones to save space.

Here's a simple retention strategy using find:

# Keep daily backups for 7 days, delete older ones
find ./backups -name "db-*.sql.gz" -mtime +7 -delete

# More sophisticated: keep daily for 7 days, weekly for 4 weeks
find ./backups -name "db-*.sql.gz" -mtime +7 ! -name "*-01.sql.gz" -delete

You can integrate this directly into your cron job:

# Complete backup and cleanup pipeline  
0 2 * * * docker exec postgres pg_dump -U myuser mydb | gzip > ~/backups/db-$(date +\%F).sql.gz && find ~/backups -name "db-*.sql.gz" -mtime +7 -delete

For production systems, consider a more nuanced retention policy:

Hourly backups for the last 24 hours
Daily backups for the last 7 days
Weekly backups for the last 4 weeks
Monthly backups for the last 12 months

Restoring PostgreSQL Backups

Creating backups is only half the story. You need to know how to restore them when disaster strikes. Here's how to restore from your compressed backups:

# Restore to existing database (will overwrite existing data)
gunzip -c backup.sql.gz | docker exec -i postgres psql -U myuser mydb

# Restore to a new database for testing
docker exec postgres createdb -U myuser mydb_test
gunzip -c backup.sql.gz | docker exec -i postgres psql -U myuser mydb_test

# Restore from uncompressed backup
docker exec -i postgres psql -U myuser mydb < backup.sql

Always test your restore process on a non-production database first. A backup is only as good as your ability to restore from it.

Putting It All Together

A complete PostgreSQL backup solution combines automated scheduling, compression, and retention policies. Here's a production-ready example that ties everything together:

#!/bin/bash
# Complete backup script with error handling and cleanup
BACKUP_DIR="/backups"
DB_NAME="mydb"
RETENTION_DAYS=7
DATE=$(date +%F_%H-%M-%S)
BACKUP_FILE="$BACKUP_DIR/db-$DATE.sql.gz"

# Create backup with compression
if docker exec postgres pg_dump -U myuser "$DB_NAME" | gzip > "$BACKUP_FILE"; then
    echo "Backup successful: $(basename $BACKUP_FILE)"

    # Clean up old backups
    find "$BACKUP_DIR" -name "db-*.sql.gz" -mtime +$RETENTION_DAYS -delete
    echo "Cleaned up backups older than $RETENTION_DAYS days"
else
    echo "Backup failed!"
    exit 1
fi

Save this as a script, make it executable, and add it to your crontab. This gives you a reliable backup system that runs automatically and manages storage space.

The approaches in this guide scale from development environments to production systems. Start with the sidecar container for simplicity, then move to cron-based scheduling as your needs grow. The key is consistency: automated backups that run regularly are far more valuable than perfect backups that never happen.

Simplify with Serversinc

Sound like a lot of work? Serversinc handles all the complexity for you. Our platform combines container orchestration, cron APIs for scheduling backup commands, volume management, and automated notifications, so you can set up reliable PostgreSQL backups without the operational overhead.

Try Serversinc free at serversinc.io and get your database backups automated in minutes.

Deploy PostgreSQL on a VPS using Docker

Max Diamond — Mon, 01 Sep 2025 07:02:10 +0000

PostgreSQL is one of the most popular open-source relational databases, trusted for its stability, performance, and reliability. Whether you’re building web apps, APIs, or data-driven platforms, PostgreSQL is often the go-to choice for developers.

In this tutorial, we'll go through how to deploy a PostgreSQL docker container on a VPS. For this, we'll be using Serversinc, a server management platform that makes deploying apps and services a breeze.

You’ll also learn two recommended methods for connecting to PostgreSQL on Serversinc:

Connecting an application on the same server directly to Postgres
Accessing Postgres from your local machine or another remote server using an SSH tunnel

Step 1: Create a new application for Postgres

To begin, you’ll create a new application inside the Serversinc dashboard that will run the official PostgreSQL Docker image.

In the Serversinc dashboard, navigate to My Applications.
Click Create new application.
Select the server where you’d like to deploy PostgreSQL from the dropdown
Give the application a name, for example: Postgres.
Leave the Type as Docker Image.
Port: You don’t need to specify a port unless you plan on exposing PostgreSQL externally (which isn’t recommended for most setups). For internal usage, leave this blank.
Leave Domain blank.
In Image & Tag, enter postgres:latest (You can also pin to a specific version, such as postgres:15, if you want consistency across deployments.)

Click Create application.

After creating the app, you’ll be redirected to the Application overview page. This page is your central management hub for the Postgres container, where you can:

View deployment history
Check environment variables
Manage attached volumes
Inspect the currently running container

This is where you’ll return any time you want to update, redeploy, or check the status of your PostgreSQL instance.

Step 2: Configure environment variables

PostgreSQL relies on a few environment variables when the container starts. These tell it which user to create, what password to assign, and what the default database should be.

Open the Environment tab of your new Postgres application.
Add the required environment variables. For example:

POSTGRES_USER=myuser
POSTGRES_PASSWORD=securepassword
POSTGRES_DB=mydb

These values will:

Create a new database user (POSTGRES_USER)
Assign it a password (POSTGRES_PASSWORD)
Create a default database (POSTGRES_DB) owned by that user

You can add additional environment variables if needed (such as locale or encoding options), but for most cases, these three are enough to get started.

Step 3: Add a volume for persistence

By default, Docker containers are ephemeral, meaning all data is stored inside the container. If you redeploy, update, or remove the container, the database would be lost. To prevent this, you should mount a volume so that PostgreSQL writes data to the server’s disk.

Go to the Volumes tab of your Postgres application.
Create a new volume and mount it to Postgres’s data directory: postgres-data:/var/lib/postgresql/data
Save the volume configuration

Ensure the postgres-data directory exists too, you can run commands on your server from the Dashboard to create it beforehand.

Now your database files will persist across redeployments and container restarts, ensuring your data stays safe.

Step 4: Deploy PostgreSQL

With everything configured, you’re ready to launch your PostgreSQL container.

Open the Deployments tab in your Postgres application.
Click Deploy.

Serversinc will now:

Pull the official PostgreSQL Docker image
Apply your environment variables (user, password, database)
Mount the persistent volume for data storage
Start the container on your selected server

Within a few moments, PostgreSQL will be up and running, ready for connections. You can confirm the deployment status and logs directly from the Application overview tab.

That’s it — you now have a fully functioning PostgreSQL database running on your server, managed through Serversinc.

Step 5: Connecting to Postgres

Once your PostgreSQL container is running, you can connect to it in a few ways depending on your setup.

Option 1: Connect from an application on the same server

If your app is running on the same server as PostgreSQL, you can connect directly using the container’s internal network:

Host: localhost or the container’s internal hostname
Port: 5432 (default PostgreSQL port)
Username: The value you set in POSTGRES_USER
Password: The value you set in POSTGRES_PASSWORD
Database: The value you set in POSTGRES_DB

For example, in Node.js using pg:

const { Pool } = require('pg');

const pool = new Pool({
  host: 'localhost',
  port: 5432,
  user: 'myuser',
  password: 'securepassword',
  database: 'mydb',
});

pool.query('SELECT NOW()', (err, res) => {
  console.log(err, res);
  pool.end();
});

This method keeps your database private and avoids exposing PostgreSQL to the internet.

Option 2: Connect via SSH tunnel

If you need to connect from your local machine or another remote server, an SSH tunnel lets you securely access PostgreSQL without opening ports publicly:

ssh -L 5432:localhost:5432 user@your-server-ip

user@your-server-ip → Replace with your server login
5432:localhost:5432 → Maps your local port to the server’s PostgreSQL port

Once the tunnel is active, you can connect using localhost:5432 as if you were on the server itself.

This method ensures that your database remains secure behind your server’s firewall while still allowing remote access.

Not already using SSH Keys? Read our guide on how to Generate SSH Keys and Connect to Your VPS Securely

Benefits of running PostgreSQL on Serversinc

Running PostgreSQL on Serversinc combines the power of a self-hosted database with simple management and monitoring:

Easy Deployment: Launch a Postgres container in just a few clicks, with environment variables and persistent storage pre-configured.
Full Control: Retain complete control over your server, database versions, and configuration.
Integrated Monitoring: Check logs, view deployment history, and receive alerts if your Postgres container stops — all from the dashboard.

Wrapping up

Deploying PostgreSQL on Serversinc is fast, secure, and fully under your control. In just a few clicks, you can launch a containerized Postgres instance, configure environment variables, attach a persistent volume, and connect your applications on the same server or remotely via SSH.

With Serversinc’s dashboard, you can monitor your database, view logs, and receive alerts if anything goes wrong, giving you peace of mind and full visibility.

For small projects up to production-grade applications, running PostgreSQL on Serversinc makes database management simple, reliable, and efficient.

How to install NGINX on ubuntu 22.04

Max Diamond — Fri, 22 Sep 2023 16:19:39 +0000

What is NGINX?

NGINX, pronounced as "engine-x," is an open-source, high-performance web server, reverse proxy server, and load balancer that has redefined the way web applications are delivered to users worldwide. In the world of node, NGINX can be considered the go-to web server for connecting your apps to internet. So lets dive into how to set it up on Ubuntu 22.04, and how to configure your app with server blocks.

Installing NGINX on Ubuntu 22.04

Firstly, we'll need to install NGINX on your server. If you're using servers provided by Digital Ocean, this may already be installed and running.

To install NGINX, start by running the following:

sudo apt update
sudo apt install nginx

Once installed, you can head to your server's IP address to see the default NGINX page.

Configuring a Server Block

Assuming you have an application running, likely with PM2, we'll move onto configuring a server block to enable access from the internet.

Firstly, we'll create a new file in /etc/nginx/sites-available/[yourapp].com .

Within this file, we'll add the following config. Be sure to change the http://localhost:3333 to point at the port your app is running on.

server {
    listen 80;  # Port to listen on (typically 80 for HTTP)
    server_name yourapp.com www.yourapp.com;  # Your domain name(s)

    location / {
        proxy_pass http://localhost:3333;  # Your Express app's address
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    # Optionally, configure access and error logs
    access_log /var/log/nginx/yourapp_access.log;
    error_log /var/log/nginx/yourapp_error.log;
}

Save this file using CTRL + X and Y .

Reload NGINX

Before we go ahead and restart NGINX, we'll test that NGINX is happy with our changes using sudo nginx -t.

Finally, we'll restart NGINX using sudo systemctl restart nginx so our changes take effect.

Accessing your app

As long as your app is running, and NGINX is configured properly, you should be able to access it via your Server's IP address or a domain pointing towards your server.