Nextcloud をやめる：何に使っていたかで選ぶ、3 つの軽い移行先

Nextcloud を離れる人たちから繰り返し読まされる話は、いつも同じです。同期クライアントは「完全に同期済み」と表示しているのに、ファイルが欠けている。アップグレードがデータベースの問題にぶつかる。写真のアップロードが、ユーザーの予想しない挙動をする。

3 つの根っこにある不満は同じです。多くのワークフローをカバーするために作られたスイートから、信頼できるワークフローを 1 つだけ欲しかったのです。

フランクフルトの VPS に Nextcloud のインスタンスがあります。2 年前の週末に構築し、それ以来使ったのはおそらく 4 回ほど。セットアップはうまくいきました。インスタンスは今も動いています。ただ開かなくなっただけです。Nextcloud ができる 10 のうち 9 つは、結局一度も必要なかったからです。

公式の All-in-One ディストリビューションは、オプションのコンテナを 1 つでも有効にすると最低 2 GB の RAM を要求し、パフォーマンスの指針では基本要件に加えてアクティブユーザー 1 人あたり約 1 GB の RAM を足すよう勧めています。そのためチーム運用では、同時利用が増えるほど余裕が必要になります。コミュニティにも、より軽い版の検討をプロジェクトに求めるスレッドが help.nextcloud.com に立っています。

以下は 3 つのワークフローに対応する 3 つの移行経路です。公式のリソース要件がある場合はそれを使い、ない場合は具体的な数値を出しません。移行マップでは、何が残り、何が失われ、どこで面倒になるかを扱います。

短いバージョン

• Nextcloud を自分のデバイス間でファイルを同期するためだけに使っていたなら、 Syncthing は有力な選択肢です。ピアツーピアで中央サーバーは不要ですが、モバイル側に重要な注意点がいくつかあります。
• Nextcloud を複数人のチームでのファイル共有として使っていたなら、 Seafile CE は有力な選択肢です。文書化された最小要件は RAM 2 GB と CPU 2 コアで、守備範囲が狭いぶん、ファイル共有が主な用途ならサイジングが容易です。
• Nextcloud を主に Web のファイルブラウザーとして使っていたなら、 Cloudreve または AList は、Nextcloud のコラボレーション一式を抱え込まずに、はるかに絞り込んだ構成を提供します。
• どの移行でも摩擦になるのは 2 点、CalDAV/CardDAV の穴（カレンダーと連絡先）と iOS での写真バックアップです。どちらも後述の移行マップで扱います。

Nextcloud が重く感じる理由（そして、それが欠陥ではない理由）

新規インストールしたばかりの Nextcloud All-in-One では、 htop が本物のマルチコンテナ構成を映し出します。AIO のマスターコンテナ、Apache、Nextcloud のアプリケーションサーバー、PostgreSQL、Redis、Notify Push です。Office、Talk、Talk Recording、ClamAV、全文検索、Imaginary、Whiteboard、Borg ベースのバックアップはオプションです。コアは単一目的の同期デーモンより重いものの、これらオプションのサービスは有効にしなければ RAM を消費しません。

GitHub 上の公式 All-in-One ディスカッションは、文書化された最小値を RAM 2 GB としていますが、そこから一気に上がります。ClamAV、Talk Recording、全文検索のいずれかを有効にすると 3 GB、すべてを有効にすると 5 GB、さらにベースに加えてアクティブユーザー 1 人あたり約 1 GB です。

これらは実測の定常 RAM 使用量ではなく、サイジングの推奨値です。AIO はオプションのサービスを有効にするほど多くのメモリーを必要とし、アクティブユーザーごとに追加の余裕を推奨しています。30 以上の機能を 1 つのセルフホスト型スイートに束ねたことの、アーキテクチャ上の代償です。出典： github.com/nextcloud/all-in-one/discussions/1335.

Nextcloud のコミュニティ自身も気づいています。help.nextcloud.com に「Nextcloud Lite, discuss」と題したスレッドが 2024 年 12 月に立ち、ファイルと共有だけを求めるユーザー向けに機能を削ったディストリビューションを出すべきかが問われました。Nextcloud を普段は気に入っている人を含め、一部のユーザーが軽いビルドを求めています。ただし返信の多くは反対で、不要な機能は無効化すればよい、セキュリティ関連のアプリを削るのは割に合わない、という主張でした。スレッドは開いたままで、メンテナーはどちらにも踏み込んでいません。参照： help.nextcloud.com/t/nextcloud-lite-discuss/213611.

反論にも重みがあります。AIO にはすでに PostgreSQL、Redis、APCu が同梱されています。その自前のパフォーマンス指針も、必要のないオプションコンテナや Nextcloud アプリを無効にするよう勧めています。Office、Talk、ClamAV、全文検索など、もう使っていないサービスを有効にしたせいでインスタンスが重いなら、まずそこを削りましょう。逆にそれらを実際に併用しているなら、大きなフットプリントは役に立つ仕事をしています。

ただし、Nextcloud を入れたあと、同期フォルダーにファイルを放り込むためだけに開いていたのなら、チューニングの話はあなたには当てはまりません。

Nextcloud が最も近いフォークとどう並ぶかについては、 Nextcloud vs ownCloudの比較.

このセクションの要点：Nextcloud は、多くのセルフホスターが実際に使っているたった 1 つのワークフローに対しては過剰です。

3 つの原型による診断：あなたの出口はどれか

ツールを選ぶ前に、ワークフローを選びましょう。私が話を聞いた Nextcloud ユーザーのほぼ全員が、3 つのパターンのいずれかにきれいに収まります。

原型 A。デバイス間同期だけ。 「ノート PC、デスクトップ、スマホを同期させるために Nextcloud を入れました。Web UI を本気で使ったことはありません。他人とファイルを共有することもありません。」

原型 B。チームでのファイル共有。 「複数人が共有のファイル置き場にアップロードしたりダウンロードしたりする必要があったので Nextcloud を入れました。ブラウザーからのときもあれば、デスクトップクライアントからのときもあります。大きなファイルでの性能を気にしていました。」

原型 C。Web ポータルだけ。 「Web のファイルブラウザーとして Nextcloud を入れました。ログインしてどこからでも自分のファイルを取り出す手段です。デスクトップクライアントは入れたかもしれませんが、ほとんど使いませんでした。リアルタイム同期が目的ではありませんでした。」

2 つ当てはまるなら、「これが明日止まったら 1 時間以内に気づく」と言えるほうを選んでください。それがあなたの依存しているワークフローです。残りは、あとで置き換えられる、あるいはなくても済む「あれば嬉しいもの」です。

各経路のリソースの下限：

上の Nextcloud AIO と Seafile CE の数値は、文書化された要件または推奨値です。Syncthing、Cloudreve、AList は横並びで比較できるだけの明確な RAM 最小値を公表していないため、コミュニティが挙げるアイドル時のメモリー値を要件として扱うのではなく、実際のライブラリー、ストレージバックエンド、ワークロードに合わせてサイジングしてください。

このセクションの要点：機能リストが最も長いツールではなく、あなたが Nextcloud を使っていたワークフローに合うツールを選びましょう。

原型 A。デバイス間同期には Syncthing

ノート PC 1 台、デスクトップ 1 台、スマホ 1 台。ノート PC のフォルダーにファイルを置けば、20 秒後には残り 2 台に現れます。Web ポータルはありません。共有ライブラリーもありません。チームもありません。Syncthing はそのために作られ、それしかしません。

Syncthing はピアツーピアです。アーキテクチャ上の意味でのサーバーは存在しません。各デバイスが同じバイナリーを実行し、グローバルなリレーネットワークか LAN を通じて互いを見つけます。VPS をメッシュに加えることはできますが、それも中央の権威ではなく、多数のピアのうちの 1 つです。Web のファイルブラウザーはありません。CalDAV もありません。チームの権限管理もありません。Nextcloud の使い方が「自分のフォルダーを同期し続ける」だけだったなら、これらの喪失はどれも問題になりません。

注目を集めるのはリソースのコストです。小さなライブラリー、たとえば 50 GB 未満の数千ファイル程度なら、Syncthing のアイドル時は通常 50〜100 MB の RAM に収まります。ライブラリーが数十万ファイル規模になると、RAM 使用量は 700 MB を超えることがあります。ほとんどのセルフホスターはそこまで到達しません。1 つのフォルダーに 25 万ファイルあるなら到達します。

このスケーリング挙動を記録した一次資料が 2 つあります。

• RAM 使用量に関する Syncthing フォーラムの長寿スレッド： forum.syncthing.net/t/ram-utilization/9769
• スケーリングの崖に関するプロジェクト自身の GitHub イシュー： github.com/syncthing/syncthing/issues/468

ピアツーピアのモデルでも VPS には意味があります。ノート PC とスマホが同時にオンラインとは限りません。片方が眠っている間も変更を伝播させたいなら、常時稼働する 3 台目が必要です。Syncthing を動かした VPS がその役を担い、次に目覚めたデバイスへ最新のコピーを渡します。小さなライブラリーなら 512 MB の RAM で余裕をもって動きます。数十万ファイルを超えるなら 1 GB を割り当ててください。

iOS に関する注意点は、Syncthing のチュートリアルが軽く流しがちなところです。バックグラウンドで確実に写真をアップロードできる公式の iOS 向け Syncthing クライアントは存在しません。サードパーティのクライアントはいくつかありますが、カメラロールのバックアップについて Nextcloud の iOS アプリに匹敵するものはありません。iPhone の写真同期が Nextcloud を動かしていた理由なら、Syncthing 単体では置き換えられません。回避策は、Syncthing のフォルダーへ送り込む PhotoSync のような有料アプリを使うか、ほかをすべて移行しつつ、そのワークフローのためだけに Nextcloud を残すことです。

読む

Google Photos代替サービスのおすすめ：クラウドとセルフホストを比較

この方向の移行の摩擦は小さいです。Syncthing は通常のファイルシステム上で動きます。ファイルがすでにあるフォルダーを指定し、ほかのマシンのデバイス ID を追加すれば、同期が始まります。変換するものも、インポートするものもありません。データはディスクにすでにあったものそのままです。

このセクションの要点：Syncthing はリソースの下限とデバイス間同期の信頼性で勝りますが、iOS の写真バックアップでは劣り、Web ポータルは完全に諦めることになります。

原型 B。チームのファイル同期には Seafile

4 人のチーム。契約書、デザインファイル、書き出しデータで 60 GB になる「Operations」という共有ライブラリー。4 人のうち 3 人がデスクトップの同期クライアントを使い、1 人はブラウザー派。ときどき誰かが 4 GB の動画をアップロードします。

ファイル共有だけの Nextcloud 構成でも、アクティブユーザーやオプションのサービスが増えるほど余裕が必要になります。Seafile は設計からして守備範囲が狭く、ファイルの同期と共有だけが必要ならサイジングが容易です。

Seafile は C と Python で作られ、バックエンドは MariaDB です。PHP の層はありません。同期モデルはブロック単位の重複排除で、ファイルを変更すると変わったブロックだけが転送され、ユーザーをまたいで同一のブロックは 1 度だけ保存されます。Nextcloud の既定の同期は、ほとんどの場面でファイル全体を対象にします。

大きなライブラリーで Seafile のほうが速いというコミュニティの報告は広く出回っており、理由はアーキテクチャにあります。比較記事で繰り返される倍率の数字は引用しません。たどっても一次資料には行き着かないからです。言えるのは、Seafile のマニュアルに記載されたブロック単位の重複排除こそが、速度差が生じる構造上の理由だということです。

現在の Seafile Community Edition のドキュメントは、最小要件として RAM 2 GB と CPU 2 コアを挙げています。これは、オプションのコンテナを 1 つでも有効にした場合の Nextcloud AIO の最小 2 GB と一致します。Seafile の守備範囲の狭さはファイル共有向けのサイジングを楽にしてくれますが、実際のメモリー差はワークロード、アクティブユーザー、ライブラリーの規模、そして Nextcloud のどのサービスを有効にしているかで変わります。

ファイルの同期と共有だけが必要なチームなら、Seafile によって使っていない Nextcloud の追加サービスを避けられます。それでサーバーのフットプリントは小さくできますが、差の大きさは「2 GB 対 5 GB」といった固定の規則ではなく、ワークロード次第です。

Nextcloud から Seafile へのネイティブなインポーターはないため、移行には多少の計画が要ります。Seafile サーバーを立て、既存のファイルにアクセスできるマシンに Seafile のデスクトップクライアントを入れ、移行先のライブラリーを作り、クライアントにアップロードさせます。所要時間はライブラリーの規模と使える上り帯域によって変わります。

Seafile はライブラリーのデータを、通常の閲覧できるファイルではなくブロックと内部オブジェクトとして保存します。データディレクトリーを ls で一覧すると、元のフォルダーツリーではなく Seafile の内部オブジェクト構造が見えます。暗号化は別の機能であって、オブジェクトが読み取れない理由ではありません。つまり、バックエンドのストレージから普通に見えるファイルをコピーするだけでは、Seafile のライブラリーを復元できません。

Seafile CE は手動のガベージコレクションも必要とします。ライブラリーやファイルを削除したあと、参照されていないブロックを片付けるスクリプトを実行します。Pro 版はこの部分をより自動化しますが、Community 版はしません。いつでも自分のデータをコピーして持ち出せることが運用上の安心につながっているなら、Seafile は居心地が悪く感じられるはずです。持ち出しに使うのは次のコマンドです： cp -r.

もう 1 つ織り込むべき喪失は、カレンダーと連絡先です。Seafile は CalDAV も CardDAV も実装していません。Nextcloud がスマホの裏側のアドレス帳だったなら、その穴を埋める軽量のサービスが別途必要になります。Radicale と Baikal が定番の答えです。

このセクションの要点：Nextcloud を主に複数ユーザーのファイル共有として使っていたなら、Seafile はよく噛み合います。ファイル中心のアーキテクチャのおかげで、Nextcloud の広いコラボレーション基盤を抱え込まずに済みます。代償は、ブロックとオブジェクトによるストレージモデルと、CalDAV/CardDAV の喪失です。

原型 C。Web ポータルには Cloudreve か AList

最も見落とされている出口です。このユーザーが欲しかったのは、どの端末からでもログインして自分のファイルを取り出せる Web ページでした。デスクトップクライアントはほとんど使わず、リアルタイム同期にも関心がありませんでした。その用途には、Nextcloud の機能一式は必要をはるかに超えていました。

このユーザーにとって、正解は Nextcloud でも Seafile でも Syncthing でもありません。正解は Web ポータルです。ここにきれいに収まるプロジェクトが 2 つあり、両者は 1 つの軸で分かれます。ツールがストレージを管理するのか、ただ読むだけなのか、という軸です。

Cloudreve は、Web ポータルに管理されたストレージ層が加わったものです。ファイルは Cloudreve が管理するストレージ（ローカルディスク、S3 互換のオブジェクトストレージ、その他のバックエンド）に置かれます。ユーザーアカウントとクォータがあり、Cloudreve Pro には現在、リアルタイム双方向同期に対応した公式の Windows 向けデスクトップクライアントが含まれます。アーキテクチャは Go のバイナリーとデータベースで、プロジェクトのリポジトリーは次の場所で活発です： github.com/cloudreve/cloudreve.

AList は、既存のストレージの上に Web インターフェイスをかぶせます。ローカルディスク、S3、Google Drive、OneDrive、SMB、WebDAV といったマウント済みのバックエンドを閲覧・操作でき、バックエンドが対応していればファイル操作も行えます。Go のバイナリーとして動き、既定で SQLite を使うため、基本的な構成なら別途データベースサーバーは不要です。ファイルがすでに対応ストレージ上に通常のファイルとして置かれているなら、AList は新しいファイル形式へ取り込むことなくそれらを見せられます。

どちらを選ぶか：

• AList ファイルがすでにディスクやクラウドストレージ上で整理されていて、その上に統一された Web UI だけが欲しい場合。移行は実質ゼロです。AList をファイルのある場所へ向けるだけです。
• Cloudreve ユーザーアカウント、クォータ、そしてポータルが端から端まで所有する単一のストレージバックエンドを備えた管理レイヤーが欲しい場合。移行は軽く、バックエンドを設定してファイルをコピーすれば終わりです。

どちらかを選ぶ前にはっきりさせておくべきことがあります。AList は同期の代わりにはならず、Cloudreve の同期は Nextcloud より守備範囲が狭いという点です。Cloudreve Pro には Windows 向けの公式デスクトップ同期クライアントがありますが、どちらのツールも Nextcloud の CalDAV/CardDAV エコシステムや、全プラットフォームに及ぶ同等の写真バックアップの流れは提供しません。それらが不可欠なら、あなたは原型 C よりも A か B に近いということです。AList と Cloudreve は軽量版の Nextcloud ではありません。狭い仕事のための、狭いツールです。

このセクションの要点：主に Nextcloud の Web ファイルブラウザーを使っていたなら、Cloudreve と AList は有力な選択肢です。既存のストレージの上に Web の層だけが必要なら、AList のほうが構成をシンプルに保てます。管理されたストレージ、ユーザーアカウント、Windows でのデスクトップ同期が欲しいなら Cloudreve のほうが筋が通ります。

移行の摩擦マップ：残るもの、失われるもの

プラグを抜く前に読むべき表がこれです。多くの移行が失敗するのはここです。

CalDAV/CardDAV の穴は、移行コストの中で最も見落とされがちなものです。スマホのアドレス帳が Nextcloud と同期していたなら、どのファイルツールに置き換えるかに関係なく、Nextcloud を止めた瞬間にその経路は切れます。Radicale と Baikal が定番の軽量な代替で、どちらも完全な Nextcloud のインストールよりはるかに小さいサービスです。Nextcloud インスタンスのプラグを抜く前に、視野に入れておくべき穴埋めです。

データを預ける前に移行を試すための別環境が欲しいなら、 CloudzyのLinux VPS がそのためのきれいな場所になります。別の検証サーバーがあれば、本番のインスタンスに触れずに移行のリハーサルができますし、次のいずれもワンクリックで展開できます：

• Seafile
• Syncthing
• Cloudreve
• AList

Nextcloud に留まるべき場合

診断は両方向に効きます。留まる理由を、重い順に 3 つ挙げます。

カレンダー、連絡先、タスク、メモのエコシステムを実際に使っている。 Nextcloud はこの 4 つを 1 つのログインの背後にまとめ、機能する CalDAV/CardDAV 実装、機能する Web UI、機能するモバイルクライアントを備えています。これを個別のサービスで置き換えるなら、カレンダーと連絡先に Radicale か Baikal、別のメモアプリ、別のタスク管理が必要です。1 つのサービスが 2 つか 3 つになり、障害点も 1 つが 2 つか 3 つになります。これが日々のワークフローなら、Nextcloud は自分の RAM コストを自分で払っています。

Nextcloud の統合されたコラボレーション基盤に頼っている。 Nextcloud は、ファイル、文書編集、カレンダー、連絡先、タスク、メモ、その他のコラボレーション機能を 1 つのアカウントと 1 つのインターフェイスの背後にまとめています。Seafile も同時編集のために Collabora や OnlyOffice を統合できるので、共同での文書作業だけを理由に除外する必要はありません。違いは、Nextcloud の広いエコシステムを置き換えるとなると、Seafile が担わない機能のために個別のサービスをつなぎ合わせることになる点です。

使っていないサービスのせいで Nextcloud が重い。 AIO にはすでに PostgreSQL、Redis、APCu が入っているので、データベースを替えたり APCu を有効にしたりすることは、ここでのチューニング手順ではありません。まずは必要のないオプションコンテナと Nextcloud アプリを無効にしてください。Office、Talk、ClamAV、全文検索、プレビュー系のサービスが実際の用途もなく動いているなら、移行を決める前にその負荷を取り除きましょう。

「機能の 10% しか使っていなかったなら去れ」という理屈は、「機能を実際に使っているなら留まれ」とも言っています。自分がどちらなのか、正直に見極めてください。

このセクションの要点：ワークフローにカレンダー、連絡先、共同での文書作業が含まれるなら、Nextcloud は今も正しいツールです。逃げ出す前に設定を直しましょう。

よくある質問

Nextcloud の最も軽い代替は何ですか？

ワークフロー次第です。AList は、既存のストレージの上に乗せられ、既定で SQLite を使えるため、Web だけでファイルにアクセスする用途では最も手軽な選択肢の 1 つです。Syncthing はデバイス間同期に絞った選択肢です。複数ユーザーでのファイル共有が必要なら、Seafile Community Edition がより完成度の高い代替で、文書化された最小要件は RAM 2 GB と CPU 2 コアです。

Seafile は Nextcloud よりメモリー使用量が少ないですか？

ファイル共有だけのワークロードなら Seafile のほうが少ないリソースで済むことはありますが、すべての構成に当てはまる固定の RAM 差はありません。Seafile CE も Nextcloud AIO も、設定次第でおよそ 2 GB を起点にできます。そのあと Nextcloud の推奨容量はアクティブユーザーと有効なサービスに応じて増えていきますが、Seafile はファイルの同期と共有という狭いワークロードを中心に作られています。

Nextcloud から Seafile へはどう移行しますか？

自動のインポーターはありません。うまくいく手順はこうです。Seafile をインストールし、Nextcloud のデータディレクトリーを読めるマシンに Seafile のデスクトップクライアントを入れ、Seafile サーバー上にライブラリーを作り、デスクトップクライアントにブロックとしてファイルを送り込ませます。カレンダーと連絡先はファイルと一緒には移りません。Radicale や Baikal のような CalDAV サーバーを別に用意し、スマホから同期し直す必要があります。所要時間はデータ量と使える上り帯域によって変わります。

写真のバックアップでは Syncthing のほうが Nextcloud より優れていますか？

モバイルでは一概にそうとは言えません。Syncthing の公式 Android アプリは 2024 年 12 月のリリースを最後に終了しましたが、コミュニティが保守する Android の選択肢は残っています。iOS には、Nextcloud のようなバックグラウンド写真バックアップを備えた公式の Syncthing クライアントが今もありません。カメラロールの自動バックアップが構成の中心なら、Syncthing が Nextcloud アプリを置き換えると考えるのではなく、モバイル対応は別の判断として扱ってください。

Nextcloud の代替を低価格の VPS で動かせますか？

動かせます。ただし、1 つのメモリー目標が 4 つすべてに当てはまると考えるのではなく、ツールとワークロードに応じて VPS をサイジングしてください。Seafile CE は公式に RAM 2 GB 以上、CPU 2 コア以上を推奨しています。Syncthing、AList、Cloudreve はここで扱うワークロードについて直接比較できる明確な RAM 最小値を出していないので、各ツールの導入要件を出発点に、ライブラリーの規模、データベース、ストレージバックエンドのための余裕を残しておきましょう。