SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

セルフホスト型Dropbox代替4サービスを比較

Nextcloud、Seafile、Syncthing、オブジェクトストレージを、同期トポロジーと小規模VPSの実費で比較します。同期はバックアップではない理由も解説します。

運用するセルフホスト型Dropbox代替サービスはどれですか?

時間をかけて検討する価値があるセルフホスト型Dropbox代替サービスは、Nextcloud、Seafile、Syncthing、そしてクライアントを組み合わせて使うオブジェクトストレージの4つです。これらは互換的に使えるものではありません。ほかの人がファイルを受け取る必要がある家庭や小規模チームには、Nextcloudが適しています。非常に多くの小さなファイルを同期し、ディスク上でのデータの見え方より同期速度を重視する個人やチームには、Seafileが適しています。自分のデバイス間で同期し、外部の人にリンクを渡す必要がない個人には、Syncthingが適しています。ほとんど開かないデータを安価に保存するアーカイブには、オブジェクトストレージが適しています。

機能を比較する前に、同期の仕組みを基準に選んでください。機能一覧はどれも同じように見えます。どのマシンが、ほかのすべてのマシンで合意されたコピーを保持するのかというトポロジーが、6か月後も満足して使えているかどうかを決めます。

同期トポロジ: 基準サーバー、またはサーバーを持たないピア構成

2 つの設計を選択肢として検討します。以降の多くは、どちらを選ぶかで決まります。

基準サーバー。 Nextcloud、Seafile、オブジェクトストレージはすべてこの方式です。通常は VPS (virtual private server) である 1 台のマシンが、正本を保持します。すべてのデバイスがそのマシンと通信します。ノート PC を 1 か月間オフラインにしても、復帰後に自動で追いつけます。空き容量が 6 GB のスマートフォンには一部だけを保持し、サーバーにはすべてを保持できます。ブラウザーからファイルにアクセスできるため、共有リンクも利用できます。

サーバーを持たないピア構成。 Syncthing はこの方式です。デバイス同士が検出し合い、暗号化接続を介してファイル一覧を直接交換します。正本となるコピーはありません。ファイルは、そのファイルを保持するデバイス上にだけ存在します。変更を相互に反映するには、2 台のデバイスが同時にオンラインである必要があります。ページを配信するマシンがないため、誰かに渡す URL もありません。

次の 4 つの点が結果として生じます。実際に問題になるのは、これらの点です。

  • ソフトウェアをインストールしない相手にファイルを送るには、基準サーバーが必要です。リンクは URL であり、URL にはポートで待ち受けるプロセスが必要です。
  • 管理権限のないマシン、たとえば職場のノート PC からファイルにアクセスするには、基準サーバーが必要です。
  • 数週間オフラインだったデバイスは、起動するとサーバーから追いつけます。ピア構成では、そのデータを保持する別のデバイスもオンラインの間にだけ追いつけます。そのため、多くの Syncthing ユーザーは VPS 上でインスタンスを 1 つ実行し、常時オンラインのピアとして利用します。
  • ストレージの使用量も異なります。基準サーバーは完全なコピーを 1 つ保持し、各デバイスがローカルに保持する分が追加されます。1 つのフォルダーを共有する 4 台のピアでは、各ピアがフォルダー全体を保持するため、完全なコピーが 4 つ存在します。

Nextcloud: ユーザー、グループ、公開リンク

Nextcloud は PHP Web アプリケーションです。データディレクトリ内に通常のファイルとしてファイルを保存し、データベースで管理します。フォルダーは、ユーザー、グループ、またはパスワードと有効期限を設定した公開リンクで共有できます。バージョン履歴はデフォルトで有効になっており、削除したファイルはまずごみ箱に移動します。デスクトップクライアントは Linux、macOS、Windows に対応し、iOS と Android の公式アプリもあります。Dropbox を離れる理由が、他の人にファイルを受け取ってもらう必要があることなら、これが率直な答えです。

代わりに、構成要素が増えます。通常のインストールでは、Web サーバー、PHP-FPM(PHP プロセスマネージャー)、MariaDB や PostgreSQL などのデータベース、ファイルロック用の Redis を実行します。バックグラウンドジョブは、cron または systemd timer から 5 分ごとに実行します。1 GB の VPS でも起動しますが、大きなアップロードや長時間実行される occ メンテナンスコマンドが、out-of-memory killer によって停止されることがあります。少人数で使う場合でも 2 GB を最低ラインとし、アプリを追加すると 4 GB が必要になると考えてください。もう 1 つの負担はアップグレードです。アプリストアのアプリは特定のコアリリース向けに構築されるため、アップグレードする前に、依存するアプリが次のメジャーバージョンをサポートしているか確認してください。

1 つのアカウントに数十万個の小さなファイルがあると、Nextcloud の処理は遅くなります。各ファイルがファイルキャッシュテーブルの 1 行と、ディスク上の実ファイルに対応し、デスクトップクライアントがそれらを 1 つずつ処理するためです。家庭規模では、この問題はまず発生しません。リソース設計、TLS(トランスポート層セキュリティ)、バックアップについては、TLS とバックアップに対応した Docker ベースの Nextcloud インストールで説明しています。導入を決めた後は、ここを参照してください。

対象範囲について、1 つ注意があります。Nextcloud ではカレンダー、連絡先、ノート、写真ライブラリも運用できますが、有効にするアプリごとにバックグラウンド処理が増え、アップグレードを妨げる要因も 1 つ増えます。実際の課題が写真なら、専用ツールのほうが適しています。セルフホスト型の Google Photos 代替となる Immichを参照してください。実際の課題がドキュメントや wiki なら、ファイルサーバーにアプリを積み重ねるのではなく、セルフホスト型の Notion 代替を検討してください。ブラウザーでこれらのドキュメントを編集するには、さらに office server が必要です。Collabora の組み込み CODE server は Nextcloud アプリとしてインストールでき、個人利用または小規模チーム向けです。一方、Nextcloud の公式マニュアルでは、スタンドアロン server よりやや遅く、性能を重視する場合は専用 server を推奨しています。そのため、2 GB の最低ラインで足りると判断する前に、OnlyOffice と Collabora の比較を確認してください。

Seafile: 非常に多数の小さなファイル向けに設計

Seafile は各ファイルをブロックに分割し、git がオブジェクトに使用する仕組みと同じく、コンテンツハッシュでアドレス指定する内部オブジェクトストアに保存します。同期と共有の単位はフォルダーツリーではなくライブラリです。クライアントはファイルごとに 1 回リクエストするのではなく、ブロックと 1 回のコミットをアップロードするため、100,000 個の小さなファイルがあるディレクトリの同期は、ファイル単位のプロトコルよりもはるかに速く完了します。同一のブロックは 1 回だけ保存されるため、大きなファイルの 2 つ目のコピーに必要な容量はほとんどありません。

その代わり、サーバー上のファイルは通常のファイルではなくなります。ストレージディレクトリを開くと、16 進数の名前を持つオブジェクトファイルが見つかります。データを取り出すには、Seafile クライアント、または Seafile 固有の export と fsck ツールが必要です。これらのオブジェクトは通常のファイルなので、バックアップは引き続き機能します。ただし、cp を使って 1 つのスプレッドシートだけを復元することはできません。これは後から後悔しやすい特性なので、許容できるかどうかを今のうちに判断してください。

Seafile には community edition と有料の professional edition があり、両者の機能分担はリリースごとに変わるため、特定の機能を前提にチームの構成を計画する前に、公式サイトで現在の利用条件を確認してください。公式のデスクトップクライアントとモバイルクライアントがあります。暗号化ライブラリはクライアント側で暗号化されるため、サーバーには読み取れない暗号文が保存されます。パスフレーズを失うと、そのライブラリは自分でも読み取れなくなります。ブラウザーで暗号化ライブラリを開く場合、そのパスフレーズを Web セッションに渡すことになります。そのため、この保証が最も強く成立するのはデスクトップクライアントとモバイルクライアントです。

必要なリソースは Nextcloud に近い水準です。データベース、メモリーキャッシュ、2 つのアプリケーションプロセスを実行するため、ここでも 2 GB が現実的な下限です。

Syncthing: ログインする必要がない

Syncthing は単一の Go バイナリです。フォルダーを監視し、discovery server または relay を介して接続先を見つけ、デバイス間で直接同期します。同期相手のユーザーアカウントやログインページはありません。ID で 2 台のデバイスをペアリングし、双方でフォルダーを受け入れます。実行するものがほとんどないため、ここで扱う構成の中では運用の手間が最も少なくなります。

一方で、共有機能全体を失います。その項目は Device pairing only, no links です。クライアント、会計担当者、親族にリンクを渡すことはできません。もう 1 つの不足はモバイル対応です。Community apps only, no official mobile app。公式 Android アプリは 2024 年 12 月の最終リリース後に提供終了となり、現在のプロジェクトのドキュメントでは、Syncthing-Fork などのコミュニティ製 Android アプリを案内しています。iOS について、プロジェクトの FAQ は「現在の Syncthing チームが近い将来に iOS を公式にサポートする予定はありません」と明記しています。iOS ではバックグラウンド処理に大きな制限があり、安定した同期が難しいためです。iOS ユーザーにはサードパーティ製アプリしか選択肢がありません。

リソース使用量は少ないですが、知っておくべき点が 1 つあります。Syncthing は同期するすべてのファイルについてインデックスエントリを保持するため、メモリ使用量と初回スキャンの負荷は合計サイズではなくファイル数に応じて増えます。大きなフォルダーを初回にハッシュ化すると、しばらく CPU を使用しますが、その後は落ち着きます。最小構成の VPS プランでも快適に動作します。

競合が発生した場合は、双方のファイルを保持します。2 台のデバイスが相互に接続できない間に同じファイルを変更すると、Syncthing は一方のコピーの名前を変更し、もう一方のコピーの隣に保持します。そのため、notes.sync-conflict-20260802-141530-K7MB3QT.md のようなファイルが作成されます。データは失われません。ただし、マージも行われないため、手動で解決します。

クライアントを使ったオブジェクトストレージ: 安価なデータ置き場であり、同期フォルダーではない

オブジェクトストレージとは、S3(simple storage service)互換のバケットです。MinIO を使って自己ホストすることも、プロバイダーから借りることもできます。自己ホストする前に、MinIO のコミュニティリポジトリは 2026 年 4 月 25 日以降アーカイブ済みで読み取り専用となっており、メンテナンス終了と表示されていることを確認してください。コミュニティ向けの事前コンパイル済みバイナリも提供されなくなったため、新規インストールではソースからビルドする必要があり、今後パッチが提供される保証もありません。バケットにはツールでアクセスします。コマンドラインでは rclone、デスクトップではバケットをドライブとして表示するクライアントを使います。シェルではなく Web ページからバケットを参照したい場合は、自己ホスト型ファイルマネージャーの比較にある複数のツールが、S3 バケットをバックエンドとして受け取り、その上に独自の共有リンクを追加します。共有には presigned URL を使います。これは、有効期限を自身に含めて生成するリンクです。バージョニングはバケットの設定です: Bucket versioning, off by default。後から有効にしても、バケット内にすでにあるオブジェクトが対象になります。各オブジェクトには null のバージョン ID が付与され、次回の上書きや削除では、そのコピーが破棄されず旧バージョンとして保持されます。ただし、バージョニングを有効にする前に上書きまたは削除したデータを復元することはできません。そのため、バケットの作成時に有効にしてください。

バケットを同期フォルダーとして扱うと、問題が起きます。デフォルトでは Documents ディレクトリを監視しません。rclone bisync は双方向同期を行いますが、rclone の公式ドキュメントも、慎重な運用が必要だと明記しています。オブジェクトストレージが得意なのは、その下支えです。バックアップ先や、アプリケーションの背後にあるストレージ層として使います。MinIO による自己ホスト型 S3 互換オブジェクトストレージでは、サーバー側を説明しています。

ここではリソースコストが特殊です。MinIO は 1 つのバイナリで動作し、アイドル時の使用量も小さいです。実際に支払うコストはディスクです。VPS では、これは 1 GB 単位で借りるブロックボリュームと、オブジェクトの入出力に使う帯域幅を意味します。これらは free -h には表示されないため、アーカイブの容量を決める前にVPS の実際の月額費用を確認してください。

共有、モバイルクライアント、バージョン管理の比較

グラフSharing, mobile clients and versioning, by tool
このグラフのデータ
[
  {
    "tool": "Nextcloud",
    "sharing": "Public links, users and groups",
    "mobile": "Official iOS and Android apps",
    "versioning": "On by default, plus trash"
  },
  {
    "tool": "Seafile",
    "sharing": "Public links with password and expiry",
    "mobile": "Official iOS and Android apps",
    "versioning": "Library history and snapshots"
  },
  {
    "tool": "Syncthing",
    "sharing": "Device pairing only, no links",
    "mobile": "Community apps only, no official mobile app",
    "versioning": "Optional per folder, off by default"
  },
  {
    "tool": "Object storage",
    "sharing": "Presigned URLs you generate",
    "mobile": "Third party clients only",
    "versioning": "Bucket versioning, off by default"
  }
]

4 個の選択肢は、1 つの基準で分かれます。3 つは、ブラウザー以外に何も持っていない相手にもファイルを渡せます。1 つは、すでに所有しているデバイスとの通信に限られます。Seafile のバージョン管理に関する項目 Library history and snapshots には注意が必要です。履歴はライブラリ単位で保持されるため、削除したライブラリは履歴とともに Seafile のシステムごみ箱へ移動します。管理者はそこから復元できますが、ごみ箱を空にすると履歴も失われます。

データを再び取り出す

移行コストは、今確認するなら低く、後で判明すると高くつきます。そのため、導入を決める前に確認してください。

Nextcloud は実際のファイルを実際のディレクトリに保存するため、データディレクトリの tar があれば、アプリケーションを二度と起動できなくなってもドキュメントを取得できます。Syncthing でも各ピアに同じ状態が保たれるため、この中では最も移行しやすい構成です。ファイルが各デバイス上にそのまま存在するからです。Seafile のオブジェクトストアでは、ブロックをファイルに再構成するために Seafile またはそのエクスポートツールが必要です。オブジェクトストレージでは rclone または同等のツールが必要ですが、1 つのコマンドで実行できます。

同期はバックアップではなく、その差がデータ損失につながります

ここで扱うツールはすべて、マシン間で変更をコピーします。削除も変更です。ノート PC でフォルダーを削除すると、クライアントがその変更をサーバーに通知し、サーバーが適用します。その結果、ほかのすべてのデバイスからも削除されます。ランサムウェアも同じ経路を使います。ローカルでファイルを暗号化すると、クライアントは変更されたファイルとして検出し、暗号化後の内容をアップロードします。同期は正しく動作しています。データは失われたままです。

ごみ箱とバージョン履歴があれば、こうした事態の影響を軽減できます。ただし、これらにも有効期限があります。誤操作をしたのと同じアカウントで消去できる場合もあります。また、ライブコピーと同じディスク上に保存されます。ボリュームに障害が発生すると、ファイルとその履歴が同時に失われます。

バックアップとは、別のハードウェア上に別のコピーをスケジュールに従って作成し、少なくとも 1 回は復元したものです。ファイルと同じ実行でデータベースもバックアップしてください。データベースなしで Nextcloud のデータディレクトリを復元すると、それらのファイルの存在を認識できないインスタンスになります。その後に occ files:scan を実行するとファイルは復元できますが、テーブルに保存されていた共有設定とバージョンメタデータは失われます。以前のバージョン自体は data/[user]/files_versions 配下のファイルであるため、データディレクトリとともに内容が復元されます。VPS からの定期的な restic バックアップでは、暗号化と重複排除を行うこの方式について、復元を想定するだけでなくテストする方法も説明しています。

私なら選ぶもの

多くの読者には Nextcloud を勧めます。Dropbox を離れた後に困りやすいのは、何もインストールしない相手にリンクを渡すことと、スマートフォンでファイルを開くことです。Nextcloud は公式クライアントでその両方に対応しており、そのために 2 GB の RAM を使うのは妥当です。自分でインストールする無料のサーバー版を運用してください。Nextcloud の Enterprise サブスクリプションは 100 users から始まります。また、サポートだけでなく機能も販売しています。2026年10月17日時点で、料金ページでは Nextcloud Assistant と Nextcloud Flow は最上位の Ultimate プランにのみ含まれています。Whiteboard と大半のサードパーティー連携も、プランごとに利用が制限されています。私が認める例外は 2 つです。フォルダーを自分だけが使い、自分が所有するハードウェア上でしか利用しないなら、Syncthing を運用してください。パッチを適用するサーバーも、防御する Web ログインも不要になります。数十万個のファイルがある作業ディレクトリを同期するなら、Seafile を運用してください。保存領域が不透明になる代わりに、速度を得られます。Object storage は、選んだソフトウェアの下にバックアップ先として配置してください。同期ツールとして、その前段に置くものではありません。

FAQ

Syncthing は laptop のバックアップになりますか?

いいえ。Syncthing はデバイス間で変更をコピーします。削除も他の変更と同じ扱いになるため、誤って削除したファイルは数秒以内にペアリング済みのすべてのデバイスから消えます。フォルダー単位のファイルバージョニングが役立ちますが、各フォルダーで有効にするまで無効です。別のハードウェアに、スケジュールに従って実際のバックアップを保存してください。一度復元して、復元が機能することも確認してください。

Nextcloud と Syncthing を同じ VPS で実行できますか?

はい。異なるポートで待ち受けるため、競合しません。Syncthing のフォルダーを Nextcloud のデータディレクトリに指定しないでください。Nextcloud はすべてのファイルをデータベースで管理します。そのため、配下のディスク上に現れたファイルは occ files:scan を実行するまで認識されません。配下から削除されたファイルについては、存在しない対象を指すデータベース行が残ります。Syncthing 専用のディレクトリを用意してください。または、そのディレクトリを外部ストレージとして Nextcloud に接続し、Nextcloud がそこを確認できるようにしてください。

アカウントを持たない相手とリンクを共有できるのはどれですか?

Nextcloud と Seafile は、任意のパスワードと有効期限を設定した公開リンクを作成できます。オブジェクトストレージでは、設定した時間が経過すると自動的に使えなくなる presigned URL を作成できます。Syncthing にはこの機能がありません。共有モデルはデバイスのペアリングです。そのため、相手は Syncthing をインストールし、デバイス ID を知らせ、フォルダーを受け入れる必要があります。

サーバーにはどの程度のディスク容量が必要ですか?

正本サーバーとして運用する場合は、共有データの全容量に加えて、バージョン履歴とごみ箱の容量、およびアップロード中の作業領域を確保してください。見積もりで過小評価されやすいのはバージョン履歴です。毎日変更される 2 GB のファイルをすべてのバージョンで保持すると、容量は急速に増えます。そのため、早い段階で保持ポリシーを設定してください。データを別のボリュームに置くと、この増加分を root ファイルシステムから分離できます。ディスクが満杯になると、1 件のアップロードではなくサーバー全体が停止するためです。

この記事は役に立ちましたか?