ownCloudサーバーの自動データベースバックアップを設定する方法

バックアップ計画の弱点が発覚するのは、最悪のタイミングです。アップグレードが失敗したり、データベーステーブルが破損したり、サーバーがダウンしたりして、唯一の「バックアップ」がユーザーファイルのコピーだけだった場合などです。ownCloud Serverの場合、それでは不十分です。データベースには、ユーザー、共有フォルダ、ファイルメタデータ、構成データなど、アプリケーションの重要な状態が格納されています。信頼性の高い復旧計画には、データベースだけでなく、同じ時点のファイルや構成データも必要です。

このガイドでは、Linux 上で ownCloud データベースのバックアップを自動化する実践的な方法を紹介します。手動ダンプから始まり、スケジュール設定と検証済みのジョブで完了します。ownCloud が推奨する MySQL/MariaDB エンジンを中心に、PostgreSQL 版も含まれています。コマンドは、最新の ownCloud Server 11.0 管理ドキュメントに準拠していますが、従来の Docker を使用しないインストール環境におけるコマンドの違いについても説明しています。

まず、データベースのバックアップではカバーされないことを理解しましょう。

データベースのダンプは、ownCloudバックアップの一部にすぎません。ownCloud Server 11.0のバックアップに関するドキュメントには、データベースのほか、設定ディレクトリ、データディレクトリ、該当する場合はアプリディレクトリ、およびカスタムテーマファイルが記載されています。データディレクトリには暗号化キーも含まれる可能性があるため、データベースのみのバックアップでは、ストレージが完全に失われた後にサーバー全体を復元することはできません。

データベース保護には以下の自動化機能を使用してください。ただし、ownCloudのインストール環境の残りの部分については、ファイルレベルのバックアップまたはスナップショット戦略と併用してください。完全に整合性の取れた復旧ポイントが必要な場合は、データベースのダンプとファイルのバックアップを同じメンテナンス時間内に実行してください。

ステップ1：ownCloudが使用するデータベースを確認する

バックアップコマンドを作成する前に、データベースの種類、ホスト、データベース名、およびユーザーを特定してください。従来の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、、、などの値を探してください。ownCloud Server 11.0 はdbhost、MySQL/MariaDB および PostgreSQL を正式にサポートしており、通常のデプロイメントには MySQL または MariaDB の使用が推奨されます。dbnamedbuser

ステップ2：保護されたバックアップ場所を作成する

ウェブからアクセスできない専用ディレクトリを作成してください。スケジュールされたタスクが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。システムディスクを静かに満杯にするバックアップジョブは、最初の障害を防ごうとしている間に、2回目の障害を引き起こす可能性があります。

ステップ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：メンテナンスモードで手動バックアップを1回実行する

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-transaction。MySQL の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、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、 で実行可能にしてからchmod 700、手動で実行してください。ownCloud がコンテナ化されている場合は、 2occ行を、デプロイメントに合った 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_dumpPostgreSQL用のアーカイブ形式が使用されています。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サーバーすべてに適合する単一のデータ保持期間はありません。データの変更頻度、利用可能なストレージ容量、および復元が必要になる可能性のある期間に応じて、保持期間を設定してください。小規模サーバーの場合、1日14回のデータベースダンプは妥当な例ですが、これはすべてのサーバーに共通する要件ではありません。

最終自己点検

自動データベースバックアップは、以下のすべての条件が満たされた場合にのみ準備完了となります。

• サーバーがMySQL/MariaDBまたはPostgreSQLを使用しているかどうかを把握しており、正しいデータベース名とホスト名を確認済みである。
• バックアップディレクトリは保護されており、十分な空き容量があります。
• crontabコマンドでは認証情報は公開されません。
• スケジュール設定が有効になる前に、手動バックアップが正常に完了します。
• スクリプトは、ダンプが失敗した場合も含め、必ずメンテナンスモードを終了します。
• スケジュールされたジョブは、ログを書き込み、空でないバックアップを予定時刻に作成します。
• 古いゴミ捨て場は、計画的な保存方針に基づいて撤去される。
• 最近のバックアップが非本番環境のデータベースに正常に復元されました。
• データベースのバックアップは、ownCloudのデータ、設定、およびその他の必要なディレクトリのバックアップとセットになっています。

これらのチェックのいずれかが失敗した場合は、自動化に頼る前にその問題を修正してください。バックアップシステムは、復旧経路がテストされている場合にのみ有効です。