如何為 ownCloud 伺服器設定自動資料庫備份

你會在最糟糕的時刻發現備份計畫的缺陷：升級失敗、資料庫表損壞或伺服器消失，而唯一的「備份」只是使用者檔案的副本。這對於 ownCloud Server 來說遠遠不夠。資料庫保存關鍵的應用程式狀態，例如使用者、共享、檔案元資料和配置資料。一個可靠的復原計畫需要資料庫以及屬於同一時間點的檔案和配置。

本指南展示了一種在 Linux 系統上自動化 ownCloud 資料庫備份的實用方法，從手動匯出資料庫開始，最終實現定時備份並進行驗證。範例主要針對 MySQL/MariaDB，因為 ownCloud 推薦使用這些資料庫引擎，同時也包含 PostgreSQL 的範例。這些指令與最新的 ownCloud Server 11.0 管理文件一致，同時也指出了傳統非 Docker 安裝方式的指令差異。

首先，要了解資料庫備份不包含哪些內容。

資料庫轉儲只是 ownCloud 備份的一部分。 ownCloud Server 11.0 備份文件列出了資料庫以及設定目錄、資料目錄、應用程式目錄（如有）和自訂主題檔案。資料目錄也可能包含加密金鑰，因此僅備份資料庫無法在儲存空間完全遺失後重建完整的伺服器。

使用下列自動化流程保護資料庫，但對於 ownCloud 安裝的其他部分，請同時採用檔案層級備份或快照策略。當您需要完全一致的復原點時，請在同一維護視窗內協調資料庫轉儲和檔案備份作業。

步驟 1：確認 ownCloud 使用的資料庫

在編寫備份指令之前，請先確定資料庫類型、主機、資料庫名稱和使用者。在傳統的 ownCloud 安裝中，這些值通常位​​於 `/etc/owncloud/` 目錄下config/config.php。您也可以使用 ownCloud 命令列工具檢查系統配置。例如，在 ownCloud 目錄中：

sudo -u www-data ./occ config:list system

在 Docker Compose 部署中，目前文件使用瞭如下命令：

docker compose exec owncloud occ config:list system

尋找諸如dbtype、dbhost、dbname和 之類的值dbuser。 ownCloud Server 11.0 正式支援 MySQL/MariaDB 和 PostgreSQL，建議在常規部署中使用 MySQL 或 MariaDB。

步驟 2：建立受保護的備份位置

建立一個無法透過 Web 存取的專用目錄。當計劃任務從 root 使用者的 crontab 執行時，root 所有權是一個合理的預設值：

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

檢查可用空間df -h /var/backups/owncloud-db。備份作業如果悄悄地填滿系統磁碟，可能會在試圖防止第一次故障的同時，造成第二次故障。

步驟 3：不要在 cron 指令中包含資料庫憑證

請勿將資料庫密碼直接寫入 crontab 行。對於 MySQL 或 MariaDB，使用 root 使用者可讀的客戶端選項檔案既簡單又適用於無人值守作業。創建/etc/owncloud/db-backup.cnf：

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

然後加以限制：

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

請使用 ownCloud 配置中的實際值。如果您的資料庫位於遠端，請設定相應的主機。 MySQL 手冊中記錄了客戶端程式的選項文件，這種方法可以避免在計劃命令中直接暴露密碼。

步驟 4：在維護模式下執行一次手動備份

ownCloud 的官方備份流程要求在備份資料庫之前，阻止正常存取並將實例置於維護模式。對於 Docker Compose 部署：

docker compose exec owncloud occ maintenance:mode --on

對於從 ownCloud 目錄進行的傳統安裝：

sudo -u www-data ./occ maintenance:mode --on

維護模式會在建立復原點期間封鎖正常的使用者活動。這意味著應該在流量較低的時段執行自動化作業，並且即使轉儲失敗，也必須始終關閉維護模式。

對於 MySQL 或 MariaDB，請測試手動轉儲：

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

ownCloud 文件使用了mysqldump --single-transactionmysqldump。 MySQL 本身的mysqldump 參考文件解釋說， mysqldump--single-transaction可以為 InnoDB 等交易表建立一致性快照，而不會在轉儲期間持有表鎖定。此--quick選項以串流傳輸資料行，而不是將大型表緩衝在記憶體中。

手動備份完成後，使用對應的指令關閉維護模式：

docker compose exec owncloud occ maintenance:mode --off

或者：

sudo -u www-data ./occ maintenance:mode --off

步驟 5：將備份邏輯放入故障安全性腳本中

腳本應在出錯時停止，記錄時間戳，啟用維護模式，建立轉儲文件，驗證壓縮文件，應用保留策略，並確保在退出時禁用維護模式。以下範例假設採用經典安裝方式，/var/www/owncloud並使用名為 `<database_name>` 的 MySQL/MariaDB 資料庫owncloud：

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

將其儲存為/usr/local/sbin/owncloud-db-backup.sh，使用 `docker compose up` 命令使其可執行chmod 700，然後手動執行。如果您的 ownCloud 已容器化，請將這兩occ行替換為與您的部署相符的 Docker Compose 維護模式命令。

步驟 6：使用 cron 進行調度

手動運行成功後，設定腳本的定時任務。開啟 root 使用者的 crontab 檔：

sudo crontab -e

每天凌晨 2:15 跑步：

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

選擇符合您實際使用模式的時間。如果資料庫很大，請先測量手動運行所需的時間，因為維護模式會造成明顯的服務中斷。此外，請確保 cron 具有可預測的環境：如果所需的命令不在 cron 的預設配置中，請在腳本中使用絕對路徑PATH。

步驟 7：驗證每個備份，而不是只依賴時間戳記。

文件日期為今天並不能證明備份可以恢復。至少，應驗證檔案是否為空、gzip 壓縮後未發現檔案損壞，以及作業日誌中是否有轉儲錯誤：

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

為了進行更嚴格的測試，請將最近的資料庫轉儲還原到非生產系統上的臨時資料庫。切勿透過覆蓋生產資料庫來測試復原。真正的復原演練不僅檢查檔案完整性，還會驗證憑證、資料庫權限、轉儲相容性以及團隊實際會使用的復原流程。

步驟 8：確認 ownCloud 已恢復正常運作

腳本運行完畢後，維護模式應該關閉，使用者可以正常登入。請檢查 Web 介面並查看備份日誌。一個完善的自動化流程不僅能夠建立轉儲文件，還能安全地應對故障，避免服務一直處於維護模式。

如果使用PostgreSQL，會有哪些變化？

ownCloud 的備份文件使用pg_dump歸檔格式來備份 PostgreSQL 資料庫。 PostgreSQL官方的 pg_dump 文件指出，pg_dump即使資料庫正在使用中，它也能建立一致的匯出檔案。 PostgreSQL備份和復原章節也區分了邏輯轉儲、檔案系統備份和連續歸檔。

一個簡單的 ownCloud 相關指令是：

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

對於自動化操作，建議使用 PostgreSQL 支援的密碼檔案機制，而不是將其嵌入PGPASSWORD腳本中。維護模式、資料保留、日誌記錄和復原測試原則應保持一致。

應該保留多少個備份？

沒有一個統一的保留期限適用於所有 ownCloud 伺服器。保留期限應根據資料變化的速度、可用儲存空間以及可能需要恢復的時間跨度來選擇。對於小型伺服器來說，每天備份 14 次資料庫是一個合理的範例，但這並非普遍要求。

最終自檢

只有當以下所有條件都滿足時，您的自動資料庫備份才能準備就緒：

• 您知道伺服器使用的是 MySQL/MariaDB 還是 PostgreSQL，並且已經驗證了正確的資料庫名稱和主機。
• 備份目錄已受保護，且有足夠的可用空間。
• crontab 指令中不會公開憑證。
• 在啟用計劃備份之前，手動備份已成功完成。
• 即使在轉儲失敗後，腳本也會始終退出維護模式。
• 排程任務會按時寫入日誌並建立非空備份。
• 舊垃圾場將根據既定的保留政策進行清除。
• 最近的備份已成功還原到非生產資料庫。
• 資料庫備份與 ownCloud 資料、配置和其他所需目錄的備份一起進行。

如果任何一項檢查失敗，請在依賴自動化功能之前修復該問題。備份系統只有在恢復路徑經過測試後才能發揮作用。