ownCloud 10 ClassicからownCloud Infinite Scaleへの移行方法

具体例：架空の32人規模のデザイン会社、Cedar Studioを想像してみてください。この会社は、LDAPディレクトリ、個人ファイルエリア、グループ共有、パブリックリンク、外部プロジェクトストレージマウントを備えたownCloud Classic 10を運用しています。同社は、新しいサーバーをインストールしてもデータや権限が引き継がれるとは限らないという前提で、ownCloud Infinite Scale（oCIS）への移行を希望しています。この例は架空のものであり、移行完了の報告ではありません。

ownCloudがサポートする手順は、migrate-to-ocisClassicサーバー上のアプリとoccコマンドを使用したガイド付き移行です。これは、Classicデータベースまたはデータディレクトリのインプレースアップグレードではなく、別のクリーンなoCISターゲットへの段階的な転送です。移行マニュアルには、ソースはプロセスの大半を通して稼働し続けると記載されていますが、継続的な同期やダウンタイムゼロの最終差分処理については説明されていません。運用開始前に、ownCloudサポートと連携して、ソースバージョンの互換性と最終的な書き込みフリーズ手順を確認し、管理された切り替えを計画してください。

以下の手順は、2026年10月6日に公開されたownCloud Server 11.0の公式移行ガイドおよびInfinite Scale 8.2の認証とバックアップに関するドキュメントに基づいています。コマンド構文、環境変数、サポート体制は変更される可能性がありますので、インストールされているバージョンのドキュメントでご確認ください。

ステップ1：クラシックインスタンスのインベントリを作成し、「移行済み」の意味を定義します。

Cedar Studioの場合、最初の作業は、LDAPに存在しないユーザー、グループ、有効/無効アカウント、共有フォルダ、リンク共有、外部マウント、およびローカルユーザーを一覧表示することです。各項目に依存しているチームを記録します。これにより、個人ファイルの転送が成功したことを、すべての古いワークフローが移行された証拠とみなすことを回避できます。

移行ガイドによると、この移行では、メンバーシップを持つ有効なユーザーとグループ、各有効ユーザーのホームディレクトリファイル、およびユーザー、グループ、リンクの共有を転送できます。ファイルは、oCIS の各ユーザーの個人スペースに配置されます。無効なユーザーとそのファイルはスキップされます。このプロセスでは、パスワードや外部マウントは移行されません。外部マウントおよび受信共有に存在するバイトは、個人ファイルの転送から除外され、別途処理する必要があります。これらの場所を一覧し、手動移行の担当者を割り当ててください。

パスワードなしの公開リンクが使用されているかどうかも記録してください。デフォルトでは、oCIS は公開リンクにパスワードを要求します。そのため、ターゲット ポリシーを変更しない限り、このようなクラシック リンクは移行に失敗する可能性があります。古い URL を維持するためだけに、そのポリシーを弱めないでください。代わりに、リンク所有者が新しいパスワード保護リンクを作成する必要があるかどうかを判断してください。移行されたパスワード保護リンクのパスワードは古いパスワードと一致しないため、ユーザーは切り替え後にパスワードをリセットする必要があります。

ステップ2：クリーンなoCISターゲットと移行接続を準備する

本番データを転送する前に、別のoCISインスタンスを構築してテストしてください。移行ガイドでは、両方のシステムが稼働中で相互にアクセスできる状態であることが求められています。また、移行先はクリーンな状態である必要があると警告しています。既存のユーザーやデータがあると、インポートされたコンテンツと競合する可能性があるためです。現在のClassicインスタンスをバックアップし、ユーザーが新しいサービスを受け入れるまでインスタンスが利用可能な状態を維持するためのロールバック計画を準備してください。

移行には、クラシックサーバーにownCloudが提供するアプリをインストールする必要があります。このアプリはガイド付き移行の一環として提供されます。ドキュメントには、管理者がownCloudサポートに連絡して入手するよう指示されています。アプリには独自のrcloneバイナリが含まれています。このアプリのドキュメントに記載されている手順の代わりに、マーケットプレイスのパッケージや無関係なファイルコピージョブを使用しないでください。

oCIS側では、auth-appサービスとアプリケーション認証設定を有効にします。移行ガイドでは、偽装を有効にし、oCIS管理者用のアプリトークンを作成する必要があることも示されています。Infinite Scale 8.2のauth-appドキュメントには、偽装は移行を目的としたものであり、本番環境では有効にしておくべきではないと明記されています。これは一時的な移行設定として扱い、トークンを保護し、アクセスできるユーザーを制限し、作業完了後に移行専用の偽装を無効にします。分散環境では、ドキュメントの指示に従って、適切なサービスに設定を適用します。

Cedar Studio を想定する場合、oCIS ターゲットは、Classic サーバーが使用する LDAP サービスと同じサービスでテストする必要があります。認証情報は、バインド パスワードをシェル履歴や共有ランブックに貼り付けるのではなく、デプロイメントのシークレット メカニズムに保持してください。ownCloud の公式移行ガイドには、ターゲット要件が記載されており、移行アプリに対する ownCloud のサポートが示されています。oCIS 8.2 認証アプリ ガイドでは、アプリ トークンと偽装について説明しています。

ステップ3：IDマッピングの一貫性を確保し、準備状況チェックを実行する

oCIS は、ファイルや共有が移行される前に、ユーザーとグループを解決できる必要があります。Cedar Studio は既に LDAP を使用しているため、管理者は oCIS を同じディレクトリに接続し、ユーザーがログインできることを確認し、識別子が目的のアカウントにマッピングされていることを確認します。ownCloud ガイドでは、有効になっているすべての Classic ユーザーに対して、一意で有効なメールアドレスを明記しています。LDAP ベースの Classic ユーザーについては、通常uidまたは のユーザー名属性samAccountNameと、対応する oCIS LDAP スキーマ設定も明記しています。属性を実際のディレクトリに一致させてください。サンプル値をそのままコピーしないでください。

Classicがローカルアカウントを使用しているが、oCISが外部LDAPディレクトリを使用する場合は、ファイル転送前に、一致するユーザーとグループをそのディレクトリに作成または移行してください。ユーザー名とグループ名は一致している必要があります。oCISの内部IDMは、小規模なセットアップやテストを目的とした限定的な組み込みディレクトリです。ownCloudは、本番環境では実際のLDAPまたは外部ID管理システムの使用を推奨します。公式の移行手順では、ローカルアカウントとLDAPアカウントを使用するClassicユーザーが混在する移行ブランチはサポートされていません。途中で場当たり的な対応をするのではなく、サポート担当者と相談してこのアーキテクチャを解決してください。

Classic に移行アプリをインストールして有効化したら、ドキュメントに記載されているパスとサービスアカウントをインストール環境に合わせて変更してください。ガイドでは、/var/www/owncloud以下www-dataの例を使用しています。

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

検証コマンドは、有効化されたユーザーが有効な重複のないメールアドレスを持っていることを確認します。検証をスキップするのではなく、報告された問題を修正してから先に進んでください。無効化されたユーザーを移動する必要がある場合は、アカウントを確認し、検証前にClassicで有効化し、移行計画に含めてください。Cedar Studioは、データ転送を開始する前に、複数の代表ユーザーを使用してoCISへのLDAPサインインも検証する必要があります。

ステップ4：ユーザーとグループのブランチを完成させ、ファイルと共有を移行します。

公式ガイドで、ご自身のID設定に合ったブランチに従ってください。Classicユーザーがローカルで、oCISに組み込まれているIDMを使用する場合は、ガイドの手順には、ユーザーの移行、oCISロールの割り当て、グループの移行が含まれます。移行されたユーザーには1つのロールが割り当てられます。Classicロールは1対1で保持されず、Classicサブ管理者権限にはoCISで同等のロールはありません。管理者アクセスを手動で確認してください。両方のシステムで同じLDAPディレクトリを使用する場合は、ユーザーとグループがすでにoCISで利用可能であることを確認し、重複を作成するのではなくLDAPブランチに従ってください。

ユーザー、グループ、ロールの準備が整ったら、ドキュメントに記載されているファイルおよび共有コマンドは、最終引数としてoCIS管理者ユーザー名を使用します。クラシック管理者パスワードは対話形式で要求されます。

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

移行手順の説明に従って、共有転送の前にファイル転送を実行してください。ログインしたことがなくファイルも持っていないユーザー、またはoCISに登録されていないユーザーは、ファイル転送ステップでスキップされます。ユーザーまたはグループが登録されていない共有は、移行の進行中にエラーとして報告される可能性があります。Cedar Studioの場合、これはチームがコマンド出力と共有インベントリを検査する必要があることを意味します。致命的な停止なしに完了したとしても、すべての共有が正常に機能していることの証明にはなりません。

移行ガイドには、作成されたターゲットデータを先に削除せずに、正常に完了したステージを単純に繰り返すことはできないと記載されています。初期--force化のリセットでは、oCIS から既に移行されたファイルは削除されません。リセットフラグをルーチン的な再試行戦略として使用しないでください。ステージが失敗した場合は、ログを保存し、作成された内容を特定し、ターゲットを修復するか、クリーンなターゲットで再開するかを決定する前に、移行ガイドまたはサポートに問い合わせてください。

ステップ5：意図的な検証および復旧ウィンドウを使用して切り替える

安全な切り替えのために、Cedar Studio は、従業員が Classic でファイルの変更を停止する期間を設定し、承認された移行を実行し、チェックが完了した後にのみクライアントとユーザーを oCIS に誘導します。この書き込み停止は運用上の安全対策であり、移行アプリがリアルタイム同期を実行するという保証ではありません。公開されている移行ガイドには、継続的な同期や最終的な差分コピーコマンドに関する説明はありません。書き込み停止を許容できない場合は、ダウンタイムなしの移行を約束する前に、ownCloud サポートにバージョン固有の移行計画を問い合わせてください。

単一の管理者ログインではなく、チェックリストを使用して検証する。

• oCISに想定どおりに有効化されたユーザー、グループ、およびグループメンバーシップが表示されていることを確認し、特に以前の管理者に対する役割の割り当てを確認してください。
• ユーザーに、複数の個人スペースから移行された代表的なファイル（大容量ファイルや最近編集したドキュメントなど）を開いてもらいます。
• 所有者アカウントと受信者アカウントの両方を使用して、内部ユーザー共有とグループ共有をテストします。
• 公開リンクをプライベートブラウザセッションで開き、移行された保護リンクのパスワードをリセットし、ポリシーチェックに失敗したリンクを再作成します。
• 外部マウントを再作成し、それらが指していたデータを個別に移行または再接続してから、ユーザーが意図したアクセス権を持っていることを確認します。
• 新しいアドレスを発表する前に、デスクトップおよびモバイルクライアントのサインイン、同期、パスワードリセットのサポート経路を確認してください。

ビジネスオーナーが承認し、必要なレコードの確認が完了するまで、Classic を制御された読み取り専用状態、またはその他の凍結状態で利用可能にしておきます。不要になったら、一時的ななりすまし機能を削除し、移行アプリのトークンを取り消します。次に、ストレージレイアウトの手順に従って oCIS バックアップを取得し、テストします。公式のoCIS 8.2 バックアップに関する考慮事項では、ドキュメント化されたバックアップ手順を実行するにはインスタンスを完全にシャットダウンする必要があり、メタデータとファイル ブロブは別々のストレージ パスを持つ可能性があることが説明されています。

成功した移行とはどのようなものか

Cedar Studioの例では、oCISのWebインターフェースが読み込まれることだけが成功ではありません。従業員が意図したIDソースで認証を行い、ホームディレクトリの内容を見つけ、チームファイルを開き、再作成または移行された共有を期待どおりのアクセス許可で使用できることが成功の条件となります。パスワードのリセット、外部マウント、パブリックリンクの変更も考慮され、Classicは承認されるまで引き続き利用可能です。これらのチェックのいずれかが失敗した場合は、切り替えを一時停止し、影響を受けるユーザーとオブジェクトを記録し、oCISを正式なシステムとして扱う前にギャップを解消してください。