著者 SeafileとNextcloudの違いは？同期速度・容量・バックアップ比較
Seafileはファイルを平均約8 MBのブロックに分割して高速同期します。Nextcloudはファイルをディスクに保存し、アプリを追加できます。RAM、バックアップ、暗号化の違いを比較します。
Seafile と Nextcloud の比較: 要点
Seafile と Nextcloud の違いは、ファイルがサーバーに到達した後にどのように扱われるかです。Seafile は各ファイルをブロックに分割し、Seafile だけが読み取れるオブジェクトストアに保存します。そのため同期は高速ですが、バックアップは 2 段階の作業になります。Nextcloud はファイルを通常のファイルとしてディスクに書き込みます。同期は、カレンダー、連絡先、ドキュメント、共有リンクも提供するプラットフォームの 1 機能として扱われます。この違いを基準に選択してください。他の違いはここから派生します。
2026 年 10 月時点で、Seafile は 13.0 系列、Nextcloud は 35 系列です。どちらも成熟しており、ストレージモデルが近く変更される予定はありません。
Seafile によるファイルの保存方法
Seafile では、git がリポジトリを扱うのと同じようにライブラリをモデル化します。管理者マニュアルでは、内部モデルを Repo、Commit、FS、Block として説明しており、repo は library とも呼ばれると記載されています。各ファイルは、コンテンツ定義チャンク分割（CDC。データ自体からブロック境界を決めるアルゴリズム）によって可変長のブロックに分割されます。マニュアルでは、ブロックサイズの平均は約 8 MB とされています。例外は Web インターフェース経由のアップロードです。この場合、file server はファイルをデフォルトで 8 MB の固定サイズブロックに分割します。ブロック名には内容が使われるため、1 つの大きなファイルの 2 つのバージョンでは、変更されていないすべてのブロックが共有されます。同一のブロックを含む 2 つのライブラリも同様です。
リレーショナルデータベースには、ライブラリに関する少量のメタデータだけが保存されます。それ以外の commit、ディレクトリオブジェクト、ブロックは、data directory 配下に保存されます。12 系列および 13 系列で使用される Docker レイアウトでは、そこが /opt/seafile-data/seafile/seafile-data です。そこで ls を実行しても、役立つ情報は得られません。表示されるのはハッシュ名のディレクトリであり、Invoices/2026/march.pdf ではないためです。
同期も同じモデルに従います。クライアントはサーバーに変更内容を問い合わせ、ブロックハッシュの一覧を受け取り、まだ保持していないブロックだけを取得します。そのため、Seafile は大きなライブラリでも効率よく動作します。転送されるバイト数は、ファイル全体のサイズではなく、変更されたブロックの量に比例するためです。
Nextcloud によるファイルの保存方法
Nextcloud は、想定どおりディスク上にファイルを配置します。パス data/<username>/files/ は、Web インターフェースでユーザーに表示される構成を反映します。データベーステーブル oc_filecache も同じツリー構造を保持し、サイズ、更新時刻、etag を記録します。Nextcloud はディスク上の内容ではなく、このテーブルを信頼します。
デスクトップクライアントは、HTTPS 経由の WebDAV（web distributed authoring and versioning）を使用します。各ファイルにつき少なくとも 1 回のリクエストが必要です。そのため、Nextcloud には一括アップロード API が追加されています。開発者向けマニュアルによると、ネットワーク帯域幅を十分に使用できないため、多数の小さなファイルのアップロードは本来より遅くなります。そこで、小さなファイルをまとめて送信します。大きなファイルには、代わりにチャンク API を使用します。デスクトップクライアントは 100 MiB のチャンクから開始します（chunkSize のデフォルトは 104857600 bytes）。サイズは、最小 5 MiB から最大 100 MiB の範囲で動的に調整できます。
ファイルをディスク上に保存する利点は、既存の任意のツールでデータを読み取れることです。一方、Nextcloud の認識外で行われた変更は検出されません。ファイルをデータディレクトリに直接コピーすると、スキャンするまで Web インターフェースには表示されません。
sudo -E -u www-data php occ files:scan --all -vv管理者向けマニュアルでは、再スキャンが必要になるケースとして、ファイルをデータディレクトリに直接コピーした後、移行後、ファイルキャッシュの不整合を調査する場合を挙げています。
大規模なライブラリをより高速に同期できるのはどちらですか？
Seafileです。差が出やすいのは、数万個の小さなファイルを扱う場合と、大きなファイルを繰り返し編集する場合です。Seafileはブロックレベルの重複排除を使用するため、中央部分を変更した 4 GB のディスクイメージでも、数個のブロックだけをアップロードします。Nextcloudは一括アップロードによって小さなファイルの差を縮めますが、大きなファイルの差は解消できません。転送単位がファイル全体だからです。
差の大きさを私の説明だけで判断しないでください。ベンダーのベンチマークもそのまま信用しないでください。自分のライブラリに近いテスト用ライブラリを作成し、所要時間を測定します。
mkdir -p ~/synctest && cd ~/synctest
for i in $(seq 1 20000); do head -c 4096 /dev/urandom > "file_$i.bin"; done
du -sh ~/synctest各サーバーの同期フォルダーにそのディレクトリを入れ、クライアントが処理を完了するまで監視します。速度だけでなく、信頼性も重要です。Seafileクライアントは先にブロックをアップロードし、それらを参照するコミットを最後に書き込みます。そのため、アップロードが中断されても、ライブラリは不完全なツリーではなく、直前のコミットの状態に戻ります。
小規模 VPS で必要になるリソース
Seafile のドキュメントでは、「2G RAM 以上、2 コア CPU（> 2GHz）」が必要とされています。一方、Nextcloud では PHP プロセス単位でメモリを示しており、最小 128 MB、推奨 512 MB です。データベース、キャッシュ、プレビュー生成に必要な容量を加える前に、これらへワーカー数を掛けます。以下は、小規模チーム向けに私なら使う開始点です。実測値ではなく、開始点としての目安です。
このグラフのデータ
[
{
"label": "Seafile CE 13",
"start_ram_gb": 4,
"start_cpu_cores": 2,
"sql_databases": 3
},
{
"label": "Nextcloud 35",
"start_ram_gb": 4,
"start_cpu_cores": 2,
"sql_databases": 1
},
{
"label": "Syncthing 2",
"start_ram_gb": 1,
"start_cpu_cores": 1,
"sql_databases": 0
}
]どちらも同じクラスに入り、4 GB の RAM と 2 コアを使用するため、リソース量だけでは選択を決められません。Syncthing は 1 GB、1 コアで動作します。これが、Syncthing を検討する正直な理由です。メモリ容量よりも、構成要素の違いのほうが大きくなります。Seafile では SQL データベースを 3 個使用するのに対し、Nextcloud では 1 個を使用します。また、Seafile のデフォルトの Docker 構成では、あらかじめダウンロードしたファイルから server、MariaDB、Redis、SeaDoc、Caddy を起動します。
mkdir /opt/seafile
cd /opt/seafile
wget -O .env https://manual.seafile.com/13.0/repo/docker/ce/env
wget https://manual.seafile.com/13.0/repo/docker/ce/seafile-server.yml
wget https://manual.seafile.com/13.0/repo/docker/seadoc.yml
wget https://manual.seafile.com/13.0/repo/docker/caddy.yml
nano .env.env で SEAFILE_SERVER_HOSTNAME、MySQL の root パスワードとデータベースパスワード、初期管理者アカウント、JWT_PRIVATE_KEY を設定します。マニュアルでは、このキーに 32 文字以上のランダムな文字列を指定するよう求めています。このキーは初回起動時に読み込まれるため、stack を起動する前に生成します。
openssl rand -base64 40
docker compose up -d初回起動時に、3 個のデータベースと管理者ユーザーが作成されます。TLS とリバースプロキシを含む Nextcloud での同様の判断については、Docker、TLS、バックアップを使用して VPS に Nextcloud を構築するガイドで説明しています。
バックアップの違い
この違いは過小評価されがちですが、2 つの製品が最も大きく異なる点です。
Seafile では、順序を変えられません。マニュアルでは、最初に SQL をバックアップし、その後でデータディレクトリをバックアップするよう定めています。これにより、データベース内のすべてのレコードが参照先となる有効なオブジェクトを持つため、ライブラリが破損しません。順序を逆にすると、データベースの行が、スナップショットに含まれていないブロックを指す可能性があります。
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt ccnet_db > ccnet_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seafile_db > seafile_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seahub_db > seahub_db.sql
rsync -az /opt/seafile-data/seafile /backup/data/これらの行には 2 つの注意点があります。mariadb-dump を使用してください。Seafile のマニュアルでは mariadb 系列のコマンドを推奨しています。mysql 名は新しい MariaDB リリースで廃止が進んでおり、MariaDB 11.0 以降の公式 Docker イメージには mysqldump という名前がまったく含まれていません。Seafile 13 の Compose ファイルは現在も MariaDB 10.11 をデフォルトにしているため、より新しいデータベースイメージへ移行するときに特に重要です。docker exec の出力をファイルへリダイレクトする場合は、-t フラグを外してください。TTY は改行を変換し、ダンプを破損させるためです。
2 つの部分は別々に取得されるため、内容にずれが生じる可能性があります。復元後は、信頼して使用する前にストアを確認してください。
docker exec -it seafile bash
cd /opt/seafile/seafile-server-latest
./seaf-fsck.sh不足しているものがある場合、ツールがオブジェクト名を表示します。
Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing.
Repo ca1a860d HEAD commit is corrupted, need to restore to an old version.ガベージコレクションも計画してください。重複排除を使用している場合、削除したファイルやライブラリのブロックは、同じディレクトリから ./seaf-gc.sh を実行するまで保持されます。実行結果には、GC finished. 507 blocks total, about 507 reachable blocks, 0 blocks can be removed. のように検出内容が表示されます。1 年間実行しないと、ユーザーが削除したデータの分までバックアップの容量を使い続けることになります。
Nextcloud にも同じ 2 つの部分に関する問題がありますが、現れ方が異なります。データディレクトリとデータベースが同じツリーを記述している必要があるためです。
sudo -E -u www-data php occ maintenance:mode --on
rsync -Aavx /srv/nextcloud/ /backup/nextcloud-dirbkp/
mariadb-dump --single-transaction --default-character-set=utf8mb4 -u nextcloud -p"$DB_PASS" nextcloud > /backup/nextcloud-sqlbkp.bak
sudo -E -u www-data php occ maintenance:mode --offconfig フォルダー、data フォルダー、カスタムアプリ、テーマ、およびそのダンプを保持してください。同じ時点の 2 つの部分を復元します。データディレクトリのほうがデータベースより新しい場合、ユーザーには、ファイルキャッシュが認識していないファイルが表示されます。occ files:scan --all がこれを修復します。データベースのほうが新しい場合、キャッシュの行がすでに存在しないファイルを指します。occ files:cleanup は、storage テーブルに対応するエントリがないキャッシュエントリを削除します。
どちらの場合も、多数の小さなファイルを処理でき、履歴を保持できるバックアッププログラムが必要です。restic と BorgBackup の違いはそこにあります。
デスクトップとモバイルのクライアント
Seafile にはデスクトップ向けプログラムが 2 種類あります。同期クライアントは、選択したライブラリのローカルコピーを保持します。Drive クライアント（SeaDrive）は、ライブラリを仮想ドライブとしてマウントし、アクセス時にダウンロードします。Windows では Microsoft の cloud files API を使用し、macOS では version 3.0 が Finder 拡張機能です。Linux では 3.0.12 以降、AppImage として提供され、~/SeaDrive にマウントします。Windows と macOS では、暗号化されたライブラリは、トレイメニューから選択してパスワードを入力するまで Drive クライアントに表示されません。モバイルアプリはファイルにアクセスするためのもので、それ以外の機能は対象としていません。
Nextcloud のデスクトップクライアントも仮想ファイルに対応しています。モバイルアプリにはプラットフォームの他の機能も含まれるため、ファイルアクセスに加えてカレンダー、連絡先、Talk、ノートも利用できます。ユーザーが主にスマートフォンを使い、ファイル以外の機能も必要とする場合、日常の利用で明確な違いになります。
Seafile では、ライブラリが共有、同期、権限、暗号化の単位になります。1 つのライブラリに 500 GB を保存する前に、ライブラリの構成を決めてください。ライブラリ間の移動は名前の変更ではなく、コピーと削除として処理されるため、ファイルの履歴は移行されません。
暗号化が実際に保護する対象
Seafile の暗号化ライブラリはクライアント側で暗号化します。パスワードがサーバーに保存されることはありません。パスワードとライブラリ ID から導出したマジックトークンがライブラリとともに保存されるため、クライアントは同期前にパスワードを確認できます。パスワードから AES 256/CBC を使用して導出した鍵と IV (初期化ベクトル) でファイルキーを暗号化し、そのファイルキーでファイルデータを暗号化します。
文書化された制限事項を確認してください。見落とされやすいためです。暗号化ライブラリが暗号化するのはファイルの内容だけです。フォルダー名とファイル名は暗号化されず、ファイルサイズと編集履歴も暗号化されません。Web ブラウザーで暗号化ライブラリを参照する場合、エンドツーエンド暗号化にはなりません。パスワードを入力すると、サーバーがそのパスワードを使ってファイルキーを復号し、パスワードを 1 時間メモリにキャッシュします。マニュアルにも明記されているとおり、暗号化ライブラリは完全性を保証しません。サーバー管理者がファイル内容の一部を変更しても、クライアントはそれを検出できないためです。
Nextcloud には、名前がよく似た 2 つの機能があります。サーバー側暗号化は保存中のファイルを暗号化しますが、鍵は同じサーバーに保持されます。そのため、外部ストレージに保存されたデータの保護には有効ですが、そのサーバー上で root 権限を持つ者からの保護には十分ではありません。エンドツーエンド暗号化アプリは、選択したフォルダーをクライアント上で暗号化します。設計上、サーバーはその内容を読み取れないため、Web インターフェース、サーバー側検索、プレビューからもそれらのフォルダーの内容を参照できません。
どちらの製品の暗号化も、暗号化されたバックアップの代わりにはなりません。バックアップは別途暗号化してください。
カレンダー、連絡先、オフィス機能、アプリプラットフォーム
この点では両者に大きな差があります。Nextcloud は CalDAV（WebDAV 経由のカレンダー）と CardDAV（WebDAV 経由の連絡先）をコア機能として提供し、ドキュメントには Collabora または OnlyOffice を統合できます。その他の機能はアプリストアから追加できます。Seafile 13 は共同編集用ドキュメントと wiki ページ向けに SeaDoc を提供し、別途デプロイした OnlyOffice server を介して Office ファイルを開いて編集できますが、機能はそこまでです。カレンダーもアドレス帳もありません。
このプラットフォームには、アップグレードという代償があります。インストールするアプリが増えるほど、Nextcloud のアップグレードを妨げたり、アップグレード後に正常に動作しなくなったりする要素も増えます。そのため、ユーザーが依存する機能が多いほど、アップグレードの実施時間帯を慎重に計画する必要があります。Seafile は提供する機能が少ないため、壊れる可能性も低くなります。また、ドキュメント内の全文検索とフォルダーレベルの権限を追加するのは Community Edition ではなく Seafile Professional である点にも注意してください。Professional は最大 3 ユーザーまでは有料ライセンスなしで実行できますが、それを超える場合はライセンスが必要です。そのため、利用を予定しているエディションに、前提としている機能が含まれていることを確認してください。
それぞれで知られている障害パターン
Seafile は、データベースとオブジェクトストアの状態がずれると障害が発生します。開けないライブラリや、消えたように見えるファイルが現れ、seaf-fsck.sh に欠落したブロックが表示されます。手作業で修復できるファイルツリーはないため、データベースのダンプとオブジェクトストアを正しい順序で復元する必要があります。その復元を予備の VPS で一度テストしてください。一度も復元していないバックアップは、推測にすぎません。
Nextcloud は、通常、Nextcloud に通知せずに何かがデータディレクトリへ書き込んだことで、ファイルキャッシュとディスクの内容が一致しなくなると障害が発生します。Web インターフェースに表示されないファイルがディスク上に存在したり、フォルダーのサイズが正しく表示されなかったりします。この場合は occ files:scan で修復します。ほかの弱点は、多数の小さなファイルを扱う際のプロトコル処理速度と PHP のメモリ使用量です。前者は CPU を増やしても改善しません。後者では、大きな画像や動画のプレビュー生成でメモリ使用量が急増することが多いため、1 プロセスあたり 512 MB を確保し、リクエスト中ではなくスケジュールされたジョブでプレビューを生成してください。
どちらでもない: ファイル同期だけが必要なら Syncthing
実際の要件がマシン間で1つのフォルダーをミラーリングすることだけなら、どちらの製品も必要以上に多機能です。Syncthing にはサーバーもアカウントもありません。すべてのデバイスがピアになり、VPS はノートPCがスリープしている間も稼働し続けるピアになります。Syncthing 2 が現在の系列で、パッケージはプロジェクト独自のリポジトリから提供されます。
sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthing通常のユーザーとして実行し、root では決して実行しないでください。そうすれば、書き込まれるファイルの所有者が適切になります。
sudo systemctl enable --now syncthing@youruser
systemctl status syncthing@youruserWeb インターフェースはデフォルトで 127.0.0.1:8384 に bind するため、インターネットから到達できません。これは適切なデフォルトです。ノートPCから SSH トンネル経由でアクセスします。
ssh -L 8384:127.0.0.1:8384 youruser@your-server次に、ノートPCで http://127.0.0.1:8384 を開きます。同期自体は TCP と QUIC でポート 22000 を使用し、ローカルディスカバリーは UDP 21027 を使用します。UDP 21027 はインターネット越しには機能しません。VPS では 22000 を開き、インターフェースは閉じたままにします。
sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp失うのは、サーバーとしてのすべての機能です。Syncthing を実行していない人向けの共有リンク、Web ファイルブラウザー、ユーザーアカウントはありません。また、フォルダーごとにファイルバージョニングを有効にしない限り、サーバー側のごみ箱もありません。典型的な問題は競合ファイルです。2台のデバイスが互いに接続されていない間に同じファイルを編集すると、notes.sync-conflict-20260806-142233-ABCD1EF.md のような名前の別ファイルが作成されます。警告は表示されないため、ときどき sync-conflict を検索してください。
同期フォルダーではなく、アプリケーションが書き込むバケットが必要な場合は、別のツールが必要です。自己ホスト型の S3 互換オブジェクトストレージを参照してください。より広い選択肢については、自己ホスト型 Dropbox 代替製品の比較で、この比較に含めなかった製品も確認できます。
選定ルール
- 処理内容が大規模な同期である場合は Seafile を選びます。多数のファイル、大容量ファイル、複数のデバイスを扱い、Seafile だけが読み取れるデータストアを受け入れられる場合に適しています。
- 処理内容がプラットフォームである場合は Nextcloud を選びます。カレンダー、連絡先、ドキュメント、共有リンクを利用し、ディスク上にバックアップツールで読み取れる通常のファイルを保持したい場合に適しています。
- ミラーリングするフォルダーだけが必要で、それ以外の機能が不要な場合は Syncthing を選びます。
ここで慎重に選んでください。Seafile と Nextcloud の間の移行が、実際のロックイン要因だからです。変換ツールはありません。すべてのデータをクライアントに同期し、別のサーバーへアップロードし直す必要があります。その間、帯域幅と時間が必要になり、バージョン履歴と共有リンクは移行されません。2 年目に切り替えるよりも、今後 3 年間を見据えて現在の選択肢の容量を設計するほうが安価です。
FAQ
Seafile は大容量ライブラリの同期で Nextcloud より高速ですか？
通常ボトルネックになる2つのケースでは高速です。理由も確認できます。Seafile はファイルを平均約 8 MB のブロックに分割し、変更されたブロックだけを転送します。そのため、大きなファイルの一部を編集しても、数個のブロックだけが転送されます。Nextcloud の転送単位はファイル全体です。同じ編集ではファイル全体が再アップロードされます。また、多数の小さなファイルでは、それぞれ少なくとも1回の WebDAV リクエストが発生します。そのため、Nextcloud の一括アップロード API は小さなファイルをまとめて送信します。実際に利用する前に、自分の VPS で両方の所要時間を測定してください。プロトコルだけでなく、CPU、ディスク、ネットワーク回線も同程度に影響します。
データディレクトリで rsync を実行すれば Seafile をバックアップできますか？
データベースと組み合わせ、文書化された順序で実行する場合に限ります。Seafile のマニュアルでは、まず SQL をバックアップし、その後にデータディレクトリをバックアップするよう説明しています。これにより、データベースの各レコードがバックアップ内に存在するオブジェクトを参照します。コマンド rsync -az /opt/seafile-data/seafile /backup/data/ は conf、seafile-data、seahub-data をコピーしますが、これだけでは復元できません。オブジェクトストアには読み取り可能なファイルツリーがなく、データベースがそのインデックスだからです。両方を復元した後、seaf-fsck.sh を実行し、結果を信頼する前に出力を確認してください。
ファイル同期だけが必要な場合、Nextcloud は必要ですか？
いいえ。Nextcloud はプラットフォームです。カレンダー、連絡先、アプリストアは、利用するかどうかにかかわらず、メモリとアップグレード対応の負担になります。単純なファイル同期では、Seafile のほうが軽量でプロトコルも高速です。Syncthing はサーバー側で実行するものがないため、さらに軽量です。追加のアプリケーションが必要な場合に Nextcloud を選び、標準の選択肢として導入しないでください。
暗号化された Seafile ライブラリではファイル名も隠せますか？
いいえ。暗号化されたライブラリでは、クライアント上でファイルの内容が暗号化され、パスワードがサーバーに届きません。ただし、フォルダー名、ファイル名、ファイルサイズ、編集履歴はすべてサーバーから見えます。Web インターフェースで暗号化されたライブラリを開くと、パスワードもサーバーに送信されます。サーバーはそのパスワードでファイルキーを復号し、パスワードを1時間メモリに保持します。名前自体が機密情報である場合は、そのライブラリを Web インターフェースで扱わず、別の層で暗号化してください。
VPS で Seafile または Nextcloud に割り当てる RAM はどの程度ですか？
少数のユーザーで運用する場合は、どちらも 4 GB の RAM と 2 コアから始め、プレビュー生成や検索中のメモリ使用量を監視してください。Seafile の公式ドキュメントでは、最低要件として RAM 2 GB、2 GHz 超の 2 コア CPU を示しています。Nextcloud のドキュメントでは、PHP プロセス 1つあたり 512 MB を推奨しています。これにワーカー数を掛け、その後にデータベースとキャッシュの分を加えます。Syncthing は 1 GB で無理なく動作します。