ResticとCronを使ってNextcloudをバックアップする方法

具体例（架空）：ジョーダンはUbuntu上で小規模なNextcloudサーバーを管理しています。アプリケーションファイルは/var/www/nextcloud、ユーザーファイルは/srv/nextcloud-data、MariaDBにNextcloudデータベースが保存されており、オフサイトのLinuxホストがSSH経由で利用可能です。ジョーダンは、エラーなく実行されるcronエントリだけでなく、検査および復元可能な毎晩のバックアップを求めています。

この例では、Jordan に再現可能な Restic と cron のワークフローを提供します。パス、サービス アカウント、データベース名、スケジュールは例です。ご自身のインストール環境に合わせて値を変更してください。これらのコマンドは、この設定が実際のサーバーで実行またはテストされたことを意味するものではありません。

実用的なNextcloudバックアップには何が含まれているべきか

フォルダのコピーだけでは、Nextcloudがファイル、ユーザー、共有、設定を再接続するために必要な情報が欠落する可能性があります。最新のNextcloud 35管理マニュアルでは、保持すべき項目として、設定ディレクトリ、カスタムアプリ（存在する場合）、データディレクトリ、テーマディレクトリ、データベースの5つが挙げられています。復元ガイドでは、データベース、データディレクトリ、設定ファイルが必須であるとされています。この例を適用する前に、インストールされているNextcloudリリースに対応するマニュアルをお読みください。

ジョーダンは、設定、アプリ、テーマを含むアプリケーションディレクトリ全体に加え、データディレクトリとデータベースダンプもバックアップすることを選択しました。Nextcloudがユーザーコンテンツを外部ストレージに保存している場合は、外部ストレージの場所ごとに個別のコピーも必要です。Restic/srv/nextcloud-dataは、バックアッププロセスが読み取れるパスのみを保護できます。

Nextcloudの公式バックアップ手順書には、メンテナンスモードとデータベースのバックアップについて説明されています。復元手順書には、データベースとファイルツリーを互換性のある復元ポイントから復元する必要がある理由が示されています。

1. Resticとその認証情報を準備する

信頼できるパッケージソースからResticをインストールし、ジョブを実行するアカウントで利用可能であることを確認してください。このサンプルでは、​​Nextcloudファイルとデータベースダンプを読み取るために、ジョブがroot権限で実行されることを前提としています。また、リモートSFTPリポジトリを使用しているため、Jordanのアプリケーションサーバーが障害を起こしても、唯一のバックアップコピーが消去されることはありません。

restic version

install -d -m 700 /root/.config/restic
install -d -m 700 /root/.config/nextcloud

Resticリポジトリ用の強力なパスワードを作成し、/root/.config/restic/nextcloud-passwordroot権限のみで保存してください。そのパスワードの安全な復元用コピーを、サーバーやリポジトリとは別の場所に保管してください。Resticはリポジトリデータを暗号化しますが、パスワードを紛失すると、暗号化されたバックアップが使用できなくなる可能性があります。スクリプトやcronの行にパスワードを直接記述しないでください。

リモートホスト上のバックアップアカウントに対して、非対話型のSSHアクセスを設定し、信頼できるチャネルを介してホストキーを検証します。以下のリポジトリの場所を、そのアカウントが書き込み可能なディレクトリに設定してください。

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'
restic init

リポジトリの初期化は一度だけ行ってください。Resticのリポジトリ準備ガイドには、サポートされているストレージバックエンドと初期化方法が記載されています。パスワードファイルとSSHキーは機密情報として扱い、アクセスを制限してください。

2. データベースとファイルを互換性のある状態に保つ

Nextcloud は、データの不整合を防ぐために新規ログインをブロックし、既存のセッションをロックするため、バックアップにはメンテナンス モードを推奨しています。このコマンドは HTTP ユーザーとして実行する必要があります。一般的な Ubuntu パッケージ設定では、そのユーザーは ですwww-data。Jordan のメンテナンス ウィンドウはデータベース ダンプと Restic バックアップの間続くため、その間はユーザーは Nextcloud で作業できません。

MariaDBの場合、Nextcloudのマニュアルでは を使用しています。データベースの認証情報は、コマンドにパスワードを埋め込むのではなく、mariadb-dump --single-transaction保護されたクライアントのデフォルトファイル（例：）に保存してください。/root/.config/nextcloud/mariadb.cnf

[client]
user=nextcloud_backup
password=REPLACE_WITH_A_SECRET
host=localhost

ファイルへのアクセスを制限しますchmod 600 /root/.config/nextcloud/mariadb.cnf。サーバーとダンプ手順に必要な権限のみを持つデータベースアカウントを作成します。NextcloudでPostgreSQLまたはSQLiteを使用している場合は、ドキュメントに記載されているバックアップ方法を使用してください。MariaDBコマンドは変更せずに実行しないでください。

3. 保護されたバックアップスクリプトを作成する

Jordan は、以下の内容をファイルとして保存し/usr/local/sbin/nextcloud-restic-backup、実行可能にします。重複実行を避けるためにロックを使用し、ダンプを作成する前にメンテナンスモードを有効にし、アプリケーションディレクトリとデータディレクトリとともにダンプをバックアップし、後続のコマンドが失敗した場合でもメンテナンスモードをオフにしようとします。

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'

NC_DIR='/var/www/nextcloud'
DATA_DIR='/srv/nextcloud-data'
DB_NAME='nextcloud'
DB_CNF='/root/.config/nextcloud/mariadb.cnf'
DUMP_DIR='/var/backups/nextcloud'
LOCK_FILE='/run/lock/nextcloud-restic-backup.lock'
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="$DUMP_DIR/nextcloud-$STAMP.sql"
maintenance_started=0

mkdir -p "$DUMP_DIR"
exec 9>"$LOCK_FILE"
flock -n 9 || { echo 'A Nextcloud backup is already running.' >&2; exit 1; }

finish() {
  result=$?
  trap - EXIT
  if [[ "$maintenance_started" == 1 ]]; then
    sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --off || result=1
  fi
  rm -f -- "$DUMP_FILE" || result=1
  exit "$result"
}
trap finish EXIT

sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --on
maintenance_started=1
mariadb-dump --defaults-extra-file="$DB_CNF" --single-transaction \
  --default-character-set=utf8mb4 --databases "$DB_NAME" > "$DUMP_FILE"
restic backup --tag nextcloud "$NC_DIR" "$DATA_DIR" "$DUMP_FILE"

パスを確認したら、root 所有権とモードで実行可能ファイルを作成します700。このスクリプトは、インストールでwww-data、MariaDB、およびリストされているパスが使用されることを前提としていますconfig/config.php。まず、これらをWebサーバーの設定と照らし合わせて確認してください。また、他の管理者が既にメンテナンスモードを有効にしていないことも前提としています。コマンド、ダンプ、または Restic のアップロードが失敗した場合、シェルはエラーで終了し、トラップはサービスの復旧を試みます。ログを確認して、復旧が行われたことを確認してください。ダンプは制限付きパーミッションで保存され、実行後に削除されます。

このシンプルなパターンでは、Resticのスキャンとアップロードが完了するまでサイトが利用できなくなります。データディレクトリが大きい場合、この処理時間は長すぎる可能性があります。ファイルシステムまたはストレージプラットフォームが対応している場合は、データベースのダンプとストレージのスナップショットを連携させるか、アプリケーションと整合性のある別のバックアップ設計を使用してください。データベースとファイルのスナップショットが互換性のある時点を表していることを確認してください。稼働中のデータベースと変化するデータディレクトリを個別にコピーすると、復元が困難なバックアップが作成される可能性があります。

4. cronでジョブをスケジュールする

手動実行が正常に完了したら、Jordan はスクリプトをインストールし、静かな時間帯に実行するようにスケジュールします。root 権限で、root の crontab を編集しsudo crontab -e、以下を追加します。

15 2 * * * /usr/local/sbin/nextcloud-restic-backup >> /var/log/nextcloud-restic.log 2>&1

この例では、サーバーの cron タイムゾーンに従って午前 2 時 15 分に開始します。メンテナンス期間が許容できる時間を選択してください。Cron は対話型シェルよりも環境が小さいため、スクリプトはPATH明示的に絶対パスを設定します。制限付きパーミッションでログ ファイルを作成し、ログ ローテーションを設定するか、出力をシステムの通常のログ サービスに送信してください。Cron スケジューリングはジョブを開始するだけで、バックアップが完了したことやリストアが正常に機能することを確認するものではありません。

5. 保持期間を設定し、結果を確認する

バックアップが正常に完了した後、ジョーダンはスナップショットが表示されていることを確認します。

restic snapshots --tag nextcloud
restic check

restic checkリポジトリ構造をチェックします。定期実行でrestic check --read-dataは保存されたデータも読み取るため、ネットワークとディスクにかなりの時間を要する場合があります。リポジトリのサイズと復旧ニーズに合わせてスケジュールを設定してください。Resticのスナップショット保持ガイドでは、スナップショットの削除と参照されていないデータの削除は別々の作業であり、削除を行うとリポジトリがロックされることが説明されています。まずはドライランを行い、保持要件に合ったポリシーを設定してください。

restic forget --tag nextcloud --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --dry-run

削除対象として提案されたスナップショットを確認してください。問題がなければ削除し--dry-runて追加し--prune、夜間バックアップと競合しないタイミングでプルーニングを実行してください。これらの保持期間はあくまで例であり、普遍的なポリシーではありません。法的保持期間、利用可能なストレージ容量、および復元が必要となる可能性のある期間を考慮してください。

重要なテストは復元訓練です。JordanのライブNextcloudパスではなく、別のシステムの一時ディレクトリに最新のスナップショットを復元してください。

restic restore latest --tag nextcloud --target /tmp/nextcloud-restore-check

復元されたツリーに、想定どおりの構成、データ、およびデータベースダンプが含まれていることを確認し、代表的なファイルを検査してください。完全な復元を行うには、隔離された環境で Nextcloud の復元マニュアルに従い、手順を実行する前にログイン、ファイルアクセス、および想定どおりの共有設定を確認してください。Restic の復元に関するドキュメントには、スナップショットの選択方法と復元対象について記載されています。

このアプローチを変更する必要がある時期をどのように判断するか

Jordan氏のcronジョブは、メンテナンス期間がバックアップ期間に合致し、必要なデータパスがすべてローカルかつ読み取り可能な場合にのみ適しています。以下のいずれかの兆候が見られた場合は、設計を変更してください。

• サイトがメンテナンスモードのままになっている期間が、ユーザーの許容範囲を超えています。定期的なスナップショットの取得、またはアプリケーションと整合性の取れた別の方法を計画してください。
• ログには、パスの欠落、権限エラー、データベースダンプの失敗、またはゼロ以外のRestic終了コードが表示されています。スナップショットが完了したとみなす前に、これらの問題を修正してください。
• データは外部ストレージまたは別のサーバーに保存されています。復旧計画には、そのストレージの一貫性のあるバックアップを含めてください。
• テスト復元では、ファイル、構成、データベースの状態、または必要なアプリ/テーマコードが不足しています。バックアップ入力を更新して、手順を繰り返してください。
• ResticのパスワードまたはSSH認証情報は、バックアップ対象のサーバー上にのみ存在します。復旧用認証情報は別途保管し、権限のある管理者がアクセスできることを確認してください。

ジョーダンにとって、成功は目に見える形で現れます。cronログには実行完了が記録され、restic snapshots最近タグ付けされたスナップショットが一覧表示され、リポジトリチェックではエラーが報告されず、復元手順を実行すると整合性の取れたNextcloudインスタンスが復元されます。スケジュールされたコマンドはバックアップルーチンの始まりに過ぎません。データベース、構成、アプリケーション、ユーザーデータの完全かつ復元可能なセットがあって初めて、実用的な復旧パスが実現するのです。

公式資料

• Nextcloud 35 管理マニュアル：バックアップ
• Nextcloud 35 管理マニュアル：バックアップの復元
• Restic 0.19.1 ドキュメント