Nextcloudのデータフォルダを安全に外付けハードドライブに移行する方法

Nextcloudのデータフォルダをより容量の大きい外付けハードドライブに移動するのは、単純なコピー＆編集作業のように思えるかもしれません。しかし、そうではありません。重要なのは、Nextcloudがローカルストレージをディスク上の絶対パスで識別している点です。このパスが不用意に変更されると、サーバーはファイルを別のストレージ場所として認識してしまい、重複したファイルレコードや孤立したファイルレコード、破損したメタデータ、共有関係の喪失などが発生する可能性があります。

既存のインストール環境において最も安全かつ実用的なアプローチは、Nextcloud が認識するデータディレクトリパスはそのままに、実際のデータを外部ディスクに移動することです。Nextcloud の最新の管理マニュアルでは、ディレクトリを移動してから、元のパスから新しい場所へのシンボリックリンクを作成することを明示的に推奨しています。また、マニュアルでは、直接変更するとdatadirectoryデータベースの変更が必要となり、サポートされていない移行方法であると警告しています。Nextcloudのデータディレクトリに関するトラブルシューティングガイドを参照してください。

始める前に：何が検証済みで、何が設定に依存するのか？

質問	実践的な回答
`datadirectory`編集してもいいですか`config.php`？	単独では安全ではありません。Nextcloudのドキュメントによると、ローカルストレージの絶対パスを変更すると、データベースとの関連付けが壊れる可能性があるとのことです。シンボリックリンクを使用して元のパスを保持することをお勧めします。
完全なバックアップは必要ですか？	はい。Nextcloudのバックアップに関するドキュメントには、設定、データディレクトリ、データベース、および関連するカスタムアプリケーション/テーマデータが含まれています。古いディスクを唯一のロールバックコピーとして扱わないでください。
外付けドライブはext4形式である必要がありますか？	この手順では、特定のファイルシステムの使用は義務付けられていません。以下の例では、通常のLinuxの所有権とパーミッションの動作が単純明快であるため、ext4を使用しています。他のファイルシステムでは、異なるマウントオプションが必要になる場合があります。
その後、走った方がいいでしょうか`files:scan --all`？	通常、パスを維持したまま移動する場合には使用しません。ファイルキャッシュからファイルが実際に欠落している場合、またはファイルがNextcloud外部のデータツリーにコピーされ、すぐに再スキャンが必要な場合に使用します。
USBハードドライブは内蔵ディスクと同じくらい信頼できるのでしょうか？	それは、筐体、ケーブル、電源、ファイルシステム、ホストによって異なります。リムーバブルドライブが使用不能になることは可用性のリスクとなるため、マウントを永続化し、Nextcloudを起動する前に検証してください。

1. 外付けドライブを安定した場所に取り付ける

まず、デバイスとファイルシステムを特定します。Linux では、などのコマンドlsblk -fでblkidファイルシステムの UUID を確認できます。などのデバイス名に基づいて永続的な設定を作成することは避けてください/dev/sdb1。Linux のデバイス名は、ハードウェアの追加や検出順序の変更によって変更される可能性があります。Linux のfstab マニュアルでは、永続的なマウントには UUID または LABEL 識別子を使用することを推奨しています。

lsblk -f
sudo blkid /dev/sdb1
sudo mkdir -p /mnt/nextcloud-data-storage

に適切なエントリを追加してください/etc/fstab。例の UUID とファイルシステムタイプを、ご自身のディスクの値に置き換えてください。

UUID=YOUR-FILESYSTEM-UUID  /mnt/nextcloud-data-storage  ext4  defaults  0  2

次に、Nextcloudを操作する前にマウントをテストしてください。

sudo mount -a
findmnt /mnt/nextcloud-data-storage
df -h /mnt/nextcloud-data-storage

Linuxターミナルに、外部Nextcloudドライブのlsblk、blkid、fstabのUUIDエントリ、mount -a、およびfindmntが表示されている。

Nextcloudファイルを移動する前に、UUIDを使用して外部ディスクを検証し、マウントポイントを確認してください。

よくある誤解：という名前のディレクトリ/mnt/nextcloud-data-storageが存在するからといって、そこにディスクがマウントされているとは限りません。ドライブが存在しない場合でも、マウントポイントディレクトリはシステムディスク上に存在し得ます。対処法：移行テスト時および再起動後には、findmntまたはを使用してください。mountpoint

2. Nextcloudをバックアップし、書き込みを停止する

Nextcloudの最新のバックアップガイドによると、復元可能なバックアップには、データディレクトリ、設定、データベース、およびカスタムアプリやテーマなどのデプロイメント固有のコンテンツが含まれます。Nextcloudの公式バックアップドキュメントを確認し、バックアップが再パーティション化または用途変更しようとしているドライブとは別の場所に保存されていることを確認してください。

次に、Nextcloudのインストールディレクトリからメンテナンスモードを有効にします。DebianおよびUbuntuでは、Webサーバーアカウントは通常次のようになりますwww-data。

cd /var/www/nextcloud
sudo -E -u www-data php occ maintenance:mode --on

移行に関するガイダンスでは、移行中はcronジョブを実行しないこと、およびデータの移転中はWebサーバーやアプリケーションサーバーを停止することを推奨しています。停止方法はデプロイメントによって異なります。Apache、NginxとPHP-FPM、Docker Compose、Snap、AIO、Kubernetesはそれぞれ異なるサービス境界を持っています。

対処方法： Nextcloudのcronエントリを無効にするか、関連するcronサービスを停止し、最終コピーの前にWeb/アプリサービスを停止してください。データセットが非常に大きい場合は、サイトがオンラインの状態で外部ディスクに事前にデータを投入し、メンテナンスモードに入り、書き込み処理を停止してから、最終rsyncパスを実行して変更をキャプチャできます。

3. 隠しファイルを含め、データディレクトリ全体をコピーする

ユーザーフォルダだけをコピーしないでください。データディレクトリには、.ncdataストレージに属する隠しファイルやアプリケーションデータなども含まれています。Nextcloudは、移動手順の中で隠しファイル（ドットファイル）を明示的に指定しています。

現在のディレクトリがで/var/www/nextcloud/data、外部ディスクがにマウントされていると仮定します/mnt/nextcloud-data-storage。宛先を作成し、ディレクトリをコピーします。

sudo mkdir -p /mnt/nextcloud-data-storage/data
sudo rsync -Aax --info=progress2   /var/www/nextcloud/data/   /mnt/nextcloud-data-storage/data/

Nextcloud の復元に関するドキュメントでrsync -Aaxは、ディレクトリツリーとメタデータを保持する例として、この例を使用しています。非常に大規模なインストールの場合、すべての書き込みプロセスを停止した後、2回目の処理を実行して出力を確認してください。ソースが ACL、拡張属性、特殊なファイルシステム、またはコンテナマウントストレージを使用している場合、必要なオプションは異なる場合があります。

ターミナルには、Nextcloudメンテナンスモードが表示され、cronが停止し、rsyncが.ncdataを含むデータディレクトリ全体を外部ドライブにコピーしていることが示されています。

バックグラウンドでの書き込みを停止し、非表示のNextcloudメタデータファイルを含むデータツリー全体をコピーします。

よくある誤解：コピーが完了したということは、移行が完了したことを意味する。そうではない。Nextcloudは依然として想定されるパスを必要とし、HTTPユーザーは新しい場所にアクセスして書き込みを行うことができなければならない。対策：パスを切り替える前にファイル数を確認するか、サンプルチェックサムを検証し、新しいストレージがテストに合格するまでソースディレクトリをそのままにしておく。

4. シンボリックリンクを使用して元のデータパスを保持する

これは重要な安全対策です。Nextcloudが現在使用していると仮定します。

'datadirectory' => '/var/www/nextcloud/data',

推奨されるパス保持移行では、その値を変更しないでください。代わりに、古いディレクトリをロールバックコピーとして保持し、外部ドライブを指すシンボリックリンクに置き換えてください。

sudo mv /var/www/nextcloud/data /var/www/nextcloud/data.old
sudo ln -s /mnt/nextcloud-data-storage/data /var/www/nextcloud/data
ls -ld /var/www/nextcloud/data

Nextcloudはこのシンボリックリンク方式を採用していますが、これはローカルストレージが絶対パスで識別されるためです。リンクが設定されていれば、/var/www/nextcloud/dataデータが外部ディスク上に存在していてもNextcloudは引き続き認識できます。

広範な権限変更を行う前に、所有権を確認してください。

stat -c '%U:%G %a %n' /var/www/nextcloud/data.old
stat -c '%U:%G %a %n' /mnt/nextcloud-data-storage/data
namei -l /mnt/nextcloud-data-storage/data

HTTPユーザーは、親ディレクトリをたどり、データディレクトリを読み書きできる必要があります。適切な所有者は、ディストリビューションとインストール方法によって異なります。Nextcloudのoccドキュメントによると、HTTPアカウントはwww-dataDebian/Ubuntu、apacheFedora/CentOSでは一般的に同じですが、他のシステムでは異なるとのことです。

所有権チェックと、元のNextcloudデータパスから外部ドライブへのシンボリックリンクを表示するターミナル

元のデータディレクトリのパス名を保持し、シンボリックリンクを使用して外部ディスクを指すようにします。

よくある誤解：汎用的なコマンドを再帰的に実行すればchmod 777権限が修正される。しかし、これは実際の問題を隠蔽し、セキュリティを弱める可能性がある。対処法：新しいディレクトリを元の所有権と権限と比較し、使用されているACLは保持し、HTTPユーザーに必要な最小限の修正のみを行う。

もしあなたが本当に変わりたいと思ったら`datadirectory`？

Nextcloudはシンボリックリンクを使用しない手順についても説明していますが、同じドキュメントではサポート対象外とされており、データベースが破損する可能性があると警告しています。この手順では、テーブル内のconfig.php該当するエントリを変更および更新する必要があります。local::/old-data-dir/oc_storages

これは単に同じ操作の別の構文というだけでなく、Nextcloudが内部的に記録するストレージ識別子を変更するものです。対処法：テスト済みのバックアップ、テスト済みの復元プロセス、および古いパス名を削除する具体的な運用上の理由がない限り、シンボリックリンク方式を使用してください。Nextcloudを新規インストールする場合は、インストール時に最終的なデータ保存場所を選択してください。Nextcloudは、後から移動するよりもその方が簡単だと明言しています。

5. 再起動し、マウントを確認して、Nextcloudをオンラインに戻します。

Nextcloudを起動する前に、外部ファイルシステムが正しくマウントされていること、およびシンボリックリンクがそのファイルシステムに解決されることを確認してください。

findmnt /mnt/nextcloud-data-storage
readlink -f /var/www/nextcloud/data
sudo -E -u www-data test -r /var/www/nextcloud/data/.ncdata && echo readable

ウェブ/アプリケーションサービスを再起動し、デプロイメントに適した方法を使用してNextcloudのcronジョブを再度有効にします。その後、メンテナンスモードをオフにしてサーバーの状態を確認します。

cd /var/www/nextcloud
sudo -E -u www-data php occ maintenance:mode --off
sudo -E -u www-data php occ status

ログインして、いくつかの操作をテストしてください。既存のファイルを開く、新しいファイルをアップロードする、名前を変更する、削除する、ゴミ箱から復元する、そして別のクライアントが同期できることを確認します。ホストを一度再起動して、この手順を繰り返してください。これにより、障害発生時に予期せぬ問題となる前に、findmnt無効なエントリを検出できます。/etc/fstab

Nextcloudのステータスと外部ファイルシステムのマウントを確認するターミナルと、Nextcloudファイルインターフェース

切り替え後、Nextcloudにおけるオペレーティングシステムのマウントと通常のファイル操作の両方を確認してください。

必要ですか`occ files:scan --all`？

自動的には実行されません。Nextcloudのファイルコマンドのドキュメントによると、このコマンドfiles:scanは新規または変更されたファイルのファイルキャッシュを更新し、手動でコピーした後やキャッシュの不整合を調査する際に役立ちます。パスを保持する移動を正しく実行すると、同じファイルと同一の論理的なローカルストレージパスが維持されるため、フルスキャンをデフォルトの「念のため」の手順にするべきではありません。

対処法：まずUIをテストし、想定されるファイルを比較します。ファイルがディスク上に存在しているにもかかわらずNextcloudに表示されない場合は、対象を絞ったスキャンを実行するか、必要に応じてフルスキャンを実行しますfiles:scan --all。大規模なインストール環境では、フルスキャンにかなりの時間がかかる場合があることに注意してください。

最終移行チェックリスト

移行対象のディスクとは別の場所に、最新のデータベース、構成、およびデータバックアップが存在する。
外部ファイルシステムは、UUIDまたはラベルによって構成された安定したマウントを備えています。
findmnt外付けドライブが実際にマウントされていることを確認します。
最終同期中は、Nextcloudの書き込み処理とcronジョブが停止されます。
を含むデータディレクトリ全体.ncdataがコピーされました。
元のdatadirectoryパス名はシンボリックリンクによって保持されます。
HTTPユーザーはマウントパスをたどってデータを読み書きできます。
Nextcloudはストレージエラーなく起動し、occ status正常に動作します。
アップロード、名前変更、削除、復元、ダウンロード、同期のテストはすべて成功しました。
外部ドライブが起動時に確実にマウントされることを確認するため、サーバーを一度再起動しました。
新しい設定がテストされ、別途バックアップされるまでは、古いデータディレクトリは削除されません。

最も重要な考え方はシンプルです。Nextcloudデータの移行は、単なるファイルシステムのコピーではありません。パスはNextcloudのローカルストレージの識別情報の一部です。可能な限りそのパスを保持し、外部ドライブを信頼性の高いシステムマウントに設定し、最終コピー中は書き込みを停止し、新しいストレージがアプリケーションテストと再起動の両方に合格するまでロールバックコピーを保持してください。