Postgres - Lift and Shift

Moving your existing (old) Sentinel environment to a new server without upgrading PostgreSQL database version.

This guide describes how to migrate a Sentinel installation to a new server using a "lift and shift" approach — copying the binaries, configuration, and database from the old server to the new one and restarting services.

There are two methods for backing up and restoring the PostgreSQL database. Choose the one that fits your situation:

	Physical Backup (pg_basebackup)	Logical Backup (pg_dump)
Speed	Faster restore	Slower restore
PostgreSQL version	Same major version only	Works across major versions
Use when	Old and new server run the same PostgreSQL major version	Upgrading PostgreSQL, or a dump file already exists

---

Prerequisites

Before you begin, ensure the new server has the following installed:

• Java (same major version as the old server)

• PostgreSQL (same major version for physical backup; any supported version for logical backup)

• Nginx

---

Part 1 — On the Old ServerStep 1 — Find Your PostgreSQL Service Name

sudo systemctl list-units --type=service | grep -i postgres

Note the service name (e.g. postgres-snt or postgresql). You will need it throughout this guide.

Step 2 — Stop Services

Stop services in this order to ensure a clean shutdown before taking backups:

sudo systemctl stop sentinelsudo systemctl stop nginxsudo systemctl stop <postgres-service>

Step 3 — Back Up the Sentinel Installation

sudo tar -czf /tmp/sentinel-backup.tar.gz /opt/sentinel /u01/psmnt/sentinel

Adjust the paths if your installation uses different directories.

Also back up your environment or service file, as it contains secrets that are not inside the installation directory:

sudo cp /etc/systemd/system/sentinel.service /tmp/sentinel.service.bak

Step 4 — Back Up PostgreSQL

Choose one of the two methods below.

---

Method A — Physical Backup (pg_basebackup)

Use this when: the old and new server run the same PostgreSQL major version.

Run this on the database server (not the application server):

sudo -u postgres pg_basebackup \  -P -Ft -z -Z5 -v -Xs \  -D /data/pg_backup/$(date +%Y-%m-%d)/

Do not include the -R flag. That flag is for replication standbys and will cause PostgreSQL to start in recovery mode on the new server instead of running normally.

This creates a dated directory (e.g. /data/pg_backup/2026-07-20/) containing base.tar.gz and pg_wal.tar.gz.

---

Method B — Logical Backup (pg_dump)

Use this when: you are upgrading PostgreSQL to a newer major version, or a dump file already exists from a previous backup.

sudo -u postgres pg_dump \  -Fd \  -j 4 \  -v \  -f /data/pg_backup/$(date +%Y-%m-%d)/ \  sentinel

If a recent dump file already exists (e.g. sentinel-2026-07-17.dump), you can skip this step and use that file directly.

---

Step 5 — Copy Files to the New Server

# Copy Sentinel binaries and service filersync -avz /tmp/sentinel-backup.tar.gz newserver:/tmp/rsync -avz /tmp/sentinel.service.bak newserver:/tmp/# Copy the database backup (adjust the path to match your backup method and date)rsync -avz /data/pg_backup/$(date +%Y-%m-%d)/ newserver:/tmp/pg_backup/

---

Part 2 — On the New ServerStep 6 — Restore the Sentinel Installation

sudo tar -xzf /tmp/sentinel-backup.tar.gz -C /

Restore the service file and update any values specific to the old server (hostnames, IP addresses, file paths):

sudo cp /tmp/sentinel.service.bak /etc/systemd/system/sentinel.servicesudo systemctl daemon-reload

Step 7 — Restore PostgreSQL

Choose the method that matches how you took the backup in Step 4.

---

Method A — Restore from Physical Backup (pg_basebackup)

sudo systemctl stop <postgres-service># Find your PostgreSQL data directory if you're unsure of the pathsudo -u postgres psql -c "SHOW data_directory;"# Clear the existing data directory and restoresudo rm -rf /your/pgdata/path/*cd /tmp/pg_backup/sudo -u postgres tar -xzf base.tar.gz -C /your/pgdata/path/sudo -u postgres tar -xzf pg_wal.tar.gz -C /your/pgdata/path/pg_wal/sudo chown -R postgres:postgres /your/pgdata/pathsudo chmod 700 /your/pgdata/path

If the new server is on a different subnet or the application server has a new IP address, update pg_hba.conf before starting:

sudo nano /your/pgdata/path/pg_hba.conf

Then start PostgreSQL:

sudo systemctl start <postgres-service>

---

Method B — Restore from Logical Backup (pg_dump)

# Start PostgreSQL on the new server firstsudo systemctl start <postgres-service># Create the target databasesudo -u postgres createdb sentinel# Restore from the dump (adjust the path to your dump file)sudo -u postgres pg_restore \  -d sentinel \  -j 4 \  -v \  /tmp/pg_backup/sentinel-2026-07-17.dump

-j 4 runs the restore in parallel across 4 workers for significantly faster performance on large databases.

---

Step 8 — Update Configuration

Review and update any configuration values in the Sentinel service file or environment file that reference the old server:

• Database host (DB_HOST) if the database is on a separate server

• Oracle / PeopleSoft connection strings if the application server hostname changed

• Any hardcoded IP addresses or hostnames

Step 9 — Start All Services

sudo systemctl start <postgres-service>sudo systemctl start sentinelsudo systemctl start nginx

---

Part 3 — Verify

Confirm PostgreSQL is running as a normal primary (not in standby/recovery):

sudo -u postgres psql -c "SELECT pg_is_in_recovery();"# Should return: f

Check Sentinel logs for errors:

sudo journalctl -u sentinel -n 50

Test the Sentinel UI in a browser and confirm login works.

Test the database connection by loading a page that pulls live data.

---

Troubleshooting

Symptom	Likely Cause	Fix
pg_basebackup: connection failed: No such file or directory	Command is running on the app server, not the DB server	Run on the DB server, or add -h <db-server-ip> to the command
PostgreSQL starts but is read-only	-R flag was used — server is in standby mode	Remove standby.signal from the data directory and restart PostgreSQL
Sentinel fails with a license error	License is not valid on the new hostname	Run lein run register --license-key <KEY>
Sentinel cannot connect to the database	pg_hba.conf does not allow the new app server IP, or DB env vars point to the old server	Update pg_hba.conf and/or the service/environment file
Sentinel starts but shows no data	Oracle/PeopleSoft connection strings point to the old server	Update environment connection config in the Sentinel admin UI or service file