著者 SeafileとNextcloudの違いは？同期速度・容量・バックアップ比較
Seafileはファイルを平均約8 MBのブロックに分割して高速同期します。Nextcloudはファイルをディスクに保存し、アプリを追加できます。RAM、バックアップ、暗号化の違いを比較します。
Seafile と Nextcloud の比較: 要点
Seafile と Nextcloud の違いは、ファイルがサーバーに到達した後にどのように扱われるかです。Seafile はすべてのファイルをブロックに分割し、Seafile だけが読み取れるオブジェクトストアに保存します。そのため同期は高速ですが、バックアップは 2 つの作業に分かれます。Nextcloud はファイルをディスク上のファイルとして保存し、カレンダー、連絡先、ドキュメント、共有リンクも提供するプラットフォームの 1 機能として同期を扱います。この違いを基準に選択してください。その他の違いも、ここから決まります。
2026 年 8 月時点で、Seafile は 13.0 系列、Nextcloud は 34 系列です。どちらも成熟しており、いずれもストレージモデルを変更する予定はありません。
Seafile によるファイルの保存方法
Seafile は、git がリポジトリをモデル化するのと同じように、ライブラリをモデル化します。管理者マニュアルでは、内部モデルを Repo、Commit、FS、Block と説明しており、repo は library とも呼ばれると記載しています。各ファイルは、コンテンツ定義チャンク化（CDC。データ自体からブロックの境界を決めるアルゴリズム）によって可変長のブロックに分割されます。マニュアルでは、ブロックサイズの平均は約 8 MB とされています。ブロック名には内容が使われるため、大きなファイルの 2 つのバージョンは、変更されていないすべてのブロックを共有します。同一のブロックは、2 つのライブラリ間でも共有されます。
リレーショナルデータベースには、ライブラリに関する少量のメタデータだけが保存されます。その他すべて、つまり commit、ディレクトリオブジェクト、ブロックは、data directory の下に保存されます。12 系および 13 系で使用される Docker レイアウトでは、/opt/seafile-data/seafile/seafile-data です。そこで ls を実行しても、有用な情報は得られません。表示されるのは hash 名のディレクトリであり、Invoices/2026/march.pdf ではないためです。
同期も同じモデルに従います。クライアントはサーバーに変更内容を問い合わせ、block hash の一覧を受け取り、まだ保持していないブロックだけを取得します。そのため、Seafile は大きなライブラリでも効率よく動作します。転送されるバイト数は、そのブロックを含むファイルのサイズではなく、変更されたブロックの量に比例するためです。
Nextcloud におけるファイルの保存場所
Nextcloud は、想定どおりの場所にファイルをディスクへ保存します。パス data/<username>/files/ は、Web インターフェースでユーザーに表示される構成を反映します。データベースの oc_filecache テーブルにも同じツリー構造が記録され、サイズ、更新日時、etag が保存されます。Nextcloud はディスクではなく、このテーブルを信頼します。
デスクトップクライアントは、HTTPS 経由の WebDAV（web distributed authoring and versioning）を使用します。ファイルごとに少なくとも 1 回のリクエストが必要です。そのため Nextcloud には一括アップロード API が追加されています。開発者マニュアルでは、多数の小さなファイルをアップロードするとネットワーク帯域幅を十分に使用できず、本来より遅くなるため、小さなファイルをまとめて送信すると説明されています。大きなファイルには代わりにチャンク API が使用されます。デスクトップクライアントのデフォルトのチャンクサイズは 5 MiB です（OWNCLOUD_CHUNK_SIZE のデフォルトは 5242880 bytes です）。
ファイルをディスクに保存する利点は、既存の任意のツールでデータを読み取れることです。一方、Nextcloud は、外部から変更された内容を認識しません。ファイルをデータディレクトリへ直接コピーしても、次のスキャンを実行するまで Web インターフェースには表示されません。
sudo -E -u www-data php occ files:scan --all -vv管理者マニュアルでは、再スキャンが必要になるケースとして、ファイルをデータディレクトリへ直接コピーした後、移行後、ファイルキャッシュの不整合を調査するときの 3 つを明確に挙げています。
大規模なライブラリをより高速に同期できるのはどちらですか？
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 としています。これにワーカー数を掛け、その後にデータベース、キャッシュ、プレビュー生成に必要な容量を加えます。以下は、小規模チーム向けに使用する初期値です。実測値ではなく、開始点としての値です。
The data behind this chart
[
{
"label": "Seafile CE 13",
"start_ram_gb": 4,
"start_cpu_cores": 2,
"sql_databases": 3
},
{
"label": "Nextcloud 34",
"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
}
]どちらも同じクラスに属し、RAM は 4 GB、CPU は 2 コアです。そのため、必要リソースの規模だけでは選択を決められません。Syncthing は 1 GB、1 コアで動作します。これが、Syncthing を検討する正直な理由です。メモリ使用量よりも、構成要素の違いのほうが大きくなります。Seafile では SQL データベースを 3 個使用しますが、Nextcloud では 1 個を使用します。また、Seafile のデフォルトの Docker 構成では、先にダウンロードしたファイルを使って server、MariaDB、Memcached、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 つの注意点があります。Seafile が提供する MariaDB イメージでは mysql 系列のコマンドが非推奨のため、mariadb-dump を使用します。ファイルへリダイレクトする場合は、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 --off設定フォルダー、データフォルダー、カスタムアプリ、テーマに加えて、そのダンプも保持してください。両方の部分を同じ時点から復元します。データディレクトリがデータベースより新しい場合、ユーザーにはファイルキャッシュが認識していないファイルが表示され、occ files:scan --all が修復します。データベースのほうが新しい場合、キャッシュの行が存在しないファイルを参照するため、occ files:cleanup がストレージテーブルに対応するエントリのないキャッシュ項目を削除します。
いずれの場合も、多数の小さなファイルを処理でき、履歴を保持できるバックアッププログラムが必要です。restic と BorgBackup の違いはそこにあります。
デスクトップとモバイルのクライアント
Seafile にはデスクトップ用プログラムが 2 つあります。同期クライアントは、選択したライブラリのローカルコピーを保持します。Drive クライアント（SeaDrive）は、ライブラリを仮想ドライブとしてマウントし、アクセス時にダウンロードします。Windows では Microsoft の cloud files API を使用します。macOS では version 3.0 から Finder extension です。Linux では 3.0.12 以降、AppImage として提供され、~/SeaDrive にマウントされます。暗号化されたライブラリは、3 つすべてのデスクトッププラットフォームで使用できます。モバイルアプリはファイルにアクセスするためのもので、それ以外の機能は対象としていません。
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 を搭載していますが、それで終わりです。カレンダーもアドレス帳もありません。
プラットフォームには代償があり、その代償はアップグレードです。インストールするアプリが増えるほど、Nextcloud のアップグレードを妨げたり、アップグレード後に正常に動作しなくなったりする要素が増えます。そのため、ユーザーが依存する機能が多いほど、アップグレードの実施時間帯を慎重に計画する必要があります。Seafile は機能が少ない分、問題が発生する可能性も低くなります。なお、ドキュメント内の全文検索とフォルダーレベルの権限を有料ライセンスで追加できるのは Community Edition ではなく Seafile Professional です。利用する予定のエディションに、必要な機能が含まれていることを確認してください。
それぞれで知られている障害パターン
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 で無理なく動作します。