> For the complete documentation index, see [llms.txt](https://help.sentinelsoftware.com/sentinel-help-center/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.sentinelsoftware.com/sentinel-help-center/installation-and-updates/postgresql-backups/postgres-lift-and-shift.md). # Postgres - Lift and Shift 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 ``` ### 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 # 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 ``` *** **Method B — Restore from Logical Backup (`pg_dump`)** ``` # Start PostgreSQL on the new server firstsudo systemctl start # 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 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 ` 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 ` | | 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 |