Ubuntu 24.04 安裝 PostgreSQL 16：原生部署、帳號設定與備份還原

本次實測環境

虛擬化平台	Proxmox VE 9.2.18，新建測試 VM
CPU	2 vCPU（x86-64-v2-AES）
記憶體	4 GiB RAM
虛擬磁碟	32 GiB，HDD-backed、VirtIO SCSI、ext4
作業系統	Ubuntu 24.04.5 LTS，amd64
PostgreSQL	16.15，Ubuntu 原生套件
驗證日期	2026-10-02

本文使用新建的 Ubuntu 測試主機實際執行。這是本次實測配置，並非最低硬體需求；以少量範例資料確認功能，不作為效能或大規模負載測試結果。

文章目錄

實測結果：原生安裝、互動式密碼登入、應用帳號權限、SQL 讀寫、備份與同主機新資料庫還原均通過，並已確認重開機後資料庫與資料仍正常。

在 Ubuntu 24.04 LTS 上安裝 PostgreSQL，可以直接使用 APT 套件與 systemd 服務管理。這篇從一台尚未安裝資料庫的 Ubuntu 主機開始，完成 PostgreSQL 16 安裝、建立應用程式帳號、測試讀寫，再做一次備份與隔離還原。

整個流程採原生安裝，不使用 Docker。連線先限制在本機，適合學習 SQL，或讓同一台主機上的程式使用資料庫。

終端畫面說明：下方截圖來自測試主機實際執行的 PTY 紀錄，使用瀏覽器終端樣式呈現；提示符統一為 lab$，不顯示內網主機識別。echo $? 的0表示上一個指令成功。畫面沒有改寫執行結果，文字指令仍保留供複製。

開始前，確認環境與版本

準備一台 Ubuntu 24.04 LTS，以及可執行 sudo 的一般帳號。Ubuntu 24.04 的預設 PostgreSQL 主版本是 16；本文明確安裝版本16，避免已加入其他套件來源的環境意外取得不同主版本。小版本會隨套件更新而變動，可查看 Ubuntu 的 PostgreSQL 套件資料。

cat /etc/os-release
sudo apt update
apt-cache policy postgresql-16 postgresql-client-16

確認系統是24.04、代號 noble，且套件來源符合自己的管理政策。若使用公司的內部鏡像，請先確認鏡像提供對應的 noble 套件；不需要為了這份教學更換既有來源。

以下服務名稱、路徑與5432連接埠，以新安裝的 16/main 單一資料庫叢集為例。如果主機已有 PostgreSQL，先用 pg_lsclusters 確認版本、叢集名稱與連接埠，再對照操作。

一、安裝 PostgreSQL 與命令列工具

sudo apt install postgresql-16 postgresql-client-16
pg_lsclusters
psql --version

postgresql-16 是資料庫伺服器；postgresql-client-16 提供 psql、pg_dump 與 pg_restore 等工具。一般安裝會建立名為 main 的叢集。先確認 pg_lsclusters 的版本16、叢集 main、連接埠5432與狀態；若沒有這個叢集，先查安裝紀錄，不要對已有資料的主機重新初始化。

二、確認真正的資料庫服務有啟動

sudo systemctl enable postgresql
sudo systemctl start postgresql@16-main
systemctl status postgresql@16-main --no-pager
pg_isready -h 127.0.0.1 -p 5432
sudo -u postgres psql -d postgres -c "SELECT version();"

叢集服務應顯示 active (running)，連線檢查應回覆 accepting connections。最後的 SQL 會顯示實際伺服器版本；psql --version 只代表用戶端版本。

Ubuntu 的 postgresql.service 是管理多個叢集的總入口，可能顯示 active (exited)。這不代表資料庫當掉，也不能單靠它判斷資料庫可用；請同時看 postgresql@16-main、pg_lsclusters 與實際 SQL 連線。

Ubuntu 24.04.5 與 PostgreSQL 16.15，叢集 online、服務 active、連線 accepting connections — 圖1：實際版本、叢集與服務可用狀態。（點圖可開啟原尺寸）

三、建立應用程式專用帳號與資料庫

PostgreSQL 安裝後會有 Linux 的 postgres 帳號，以及資料庫內的 postgres 管理角色。管理時可以使用本機 peer 驗證，以 Linux 的 postgres 身分連入，不必先為管理角色設定密碼。peer 會核對作業系統使用者身分，詳見 PostgreSQL peer 驗證說明。

sudo -u postgres psql -d postgres

進入 psql 後，執行下列內容。範例帳號為 app_user，資料庫為 appdb；請依應用程式用途命名。這些名稱必須尚未存在。

CREATE ROLE app_user WITH LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;
\password app_user
CREATE DATABASE appdb OWNER app_user;
\q

\password 會要求輸入兩次密碼，畫面不顯示密碼內容。不要把真實密碼直接寫成 SQL 字串或命令列參數。這個角色可以管理自己擁有的 appdb，但沒有超級使用者、建立其他資料庫、建立角色或複寫權限；相關屬性可查 CREATE ROLE 官方文件。

四、以應用帳號測試連線與讀寫

離開管理用的 psql，回到一般終端機，透過本機 TCP 連線測試密碼驗證：

psql -h 127.0.0.1 -p 5432 -U app_user -d appdb -W

-h 指定主機、-U 指定角色、-d 指定資料庫，-W 要求互動輸入密碼。Ubuntu 預設的本機 TCP 驗證使用 SCRAM-SHA-256，而 Unix socket 通常使用 peer；兩者不同，設定背景可參考 Ubuntu 的 PostgreSQL 安裝說明。

成功登入後，建立一張專供本篇測試的資料表：

SELECT current_database(), current_user;

CREATE TABLE public.install_check (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    note text NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO public.install_check (note)
VALUES ('PostgreSQL 安裝完成');

SELECT id, note FROM public.install_check;
\q

你應能看到資料庫 appdb、角色 app_user，以及剛寫入的一筆文字。這比只看到服務狀態更完整：連線、密碼驗證、建立資料表、寫入與查詢都走過一次。本文的 install_check 是測試表，請勿在既有同名資料表上重複執行建立指令。

透過管理連線 SET ROLE app_user，查詢資料庫名稱、角色與測試資料 — 圖2：以管理連線 SET ROLE app_user 查詢測試資料；這張圖不代表密碼登入，互動式密碼驗證已另行實測。（點圖可開啟原尺寸）

五、查出實際設定檔與資料目錄

sudo -u postgres psql -d postgres -c "SHOW config_file;"
sudo -u postgres psql -d postgres -c "SHOW hba_file;"
sudo -u postgres psql -d postgres -c "SHOW data_directory;"
sudo -u postgres psql -d postgres -c "SHOW listen_addresses;"

一般 Ubuntu 24.04 的16/main設定檔位於 /etc/postgresql/16/main/，資料目錄通常是 /var/lib/postgresql/16/main；請以 SHOW 的結果為準。postgresql.conf 管理監聽與服務參數，pg_hba.conf 管理哪些連線可使用哪種驗證方式。

本篇維持預設本機連線，不修改 listen_addresses，也不開放5432到外網。如果應用程式之後搬到其他主機，再另外規劃指定來源、TLS與網路限制。

六、備份，並還原到另一個資料庫

服務能用之後，就可以練習備份。以下在一般帳號可寫入的目錄執行，以 custom 格式保存 appdb；umask 077 讓新建備份檔只供目前帳號讀寫。

umask 077
backup_file="$PWD/appdb-$(date +%Y%m%d-%H%M%S).dump"
sudo -u postgres pg_dump -d appdb -Fc > "$backup_file"
pg_restore --list "$backup_file"

pg_restore --list 能列出備份目錄，適合初步確認檔案可讀，但還不是還原成功。接著建立一個獨立的 appdb_restore，實際還原並查詢測試資料；目標名稱必須尚未存在。

sudo -u postgres createdb --owner=app_user appdb_restore

sudo -u postgres pg_restore \
  --exit-on-error \
  --no-owner \
  --role=app_user \
  --dbname=appdb_restore < "$backup_file"

sudo -u postgres psql -d appdb_restore \
  -c "SELECT id, note FROM public.install_check;"

這次測試保留原 appdb，還原內容放在另一個資料庫；--role=app_user 讓還原物件由應用角色建立，--no-owner 不執行備份內原有的擁有者設定。確認查詢結果與來源相同，再把備份複製到獨立保存位置。備份包含資料內容，保存與傳輸時都應限制存取。

單一資料庫的 pg_dump 不包含全伺服器角色等共用物件。這份還原範例沿用已存在的 app_user；若要搬到全新主機，還需要規劃角色、權限與相關環境。進一步說明見 SQL Dump 備份文件及 pg_restore 官方文件。

遇到問題時，先看這三個地方

Peer authentication failed

通常是省略 -h、走 Unix socket 時，Linux 使用者與資料庫角色不符。管理登入用 sudo -u postgres psql；app_user 的本機密碼測試則明確指定 -h 127.0.0.1。不需要為了解決這個錯誤，把驗證改成 trust。

Password authentication failed

先確認連到正確的角色、資料庫與連接埠。需要重設應用密碼時，使用管理登入後的 \password app_user；若主機曾修改驗證規則，也要檢查實際的 pg_hba.conf。

Connection refused

這通常表示指定位置沒有服務監聽。先確認叢集與連接埠，再看實際服務日誌：

pg_lsclusters
sudo journalctl -u postgresql@16-main -n 50 --no-pager

完成以上步驟，你就有一套能透過應用帳號讀寫、並已練習隔離還原的 PostgreSQL 環境。後續可依應用需求加入定期備份、容量監控與更新安排；跨主版本升級則需要另外準備相容性與還原計畫。