SSD Nodes Learn 🎉 VPS від $5.50/міс
Посібники Matt ConnorВід Matt Connor · Оновлено 2026-08-13

Seafile чи Nextcloud: що краще для синхронізації файлів

Порівняйте Seafile 13 і Nextcloud 34: швидкість синхронізації, RAM, резервні копії та шифрування, а також різницю між блоками й файлами на диску.

Seafile проти Nextcloud: коротка відповідь

Порівняння Seafile і Nextcloud зводиться до однієї відмінності: чим є файл після потрапляння на сервер. Seafile розбиває кожен файл на блоки та зберігає їх у сховищі об’єктів, яке може читати лише Seafile, тому синхронізація відбувається швидко, а резервне копіювання стає завданням із двох частин. Nextcloud записує файл на диск як звичайний файл і розглядає синхронізацію як одну з функцій платформи, яка також підтримує календарі, контакти, документи та посилання для спільного доступу. Вибір залежить саме від цієї відмінності, оскільки решта випливає з неї.

Станом на серпень 2026 року Seafile має серію 13.0, а Nextcloud — серію 34. Обидва продукти зрілі, і жоден із них найближчим часом не змінюватиме свою модель зберігання.

Як Seafile зберігає ваші файли

Seafile моделює бібліотеку так само, як git моделює репозиторій. В адміністративному посібнику внутрішню модель описано як Repo, Commit, FS і Block; також зазначено, що repo називають library. Кожен файл розділяється на блоки змінної довжини за допомогою content-defined chunking (CDC, алгоритму, який визначає межі блоків на основі самих даних). У посібнику вказано, що середній розмір блока становить приблизно 8 MB. Блоки отримують імена за своїм вмістом. Тому дві версії великого файла спільно використовують усі незмінені блоки, а дві бібліотеки також спільно використовують ідентичні блоки.

Реляційна база даних містить лише невеликий обсяг метаданих про бібліотеки. Усе інше — коміти, об’єкти каталогів і блоки — зберігається в каталозі даних. У Docker-структурі, яку використовують серії 12 і 13, це /opt/seafile-data/seafile/seafile-data. Виконання ls у цьому каталозі не дає корисної інформації, оскільки ви бачите каталоги з іменами у вигляді хешів, а не Invoices/2026/march.pdf.

Синхронізація працює за тією самою моделлю. Клієнт запитує сервер про зміни, отримує список хешів блоків і завантажує лише ті блоки, яких у нього ще немає. Саме тому Seafile ефективно працює з великою бібліотекою: обсяг переданих даних пропорційний кількості змінених блоків, а не розміру файла, який їх містить.

Як Nextcloud зберігає ваші файли

Nextcloud розміщує файл на диску там, де ви очікуєте. Шлях data/<username>/files/ відповідає тому, що користувач бачить у вебінтерфейсі. Таблиця бази даних oc_filecache відображає це саме дерево та містить розміри, час зміни й etag. Nextcloud довіряє таблиці, а не диску.

Desktop-клієнт працює через WebDAV (web distributed authoring and versioning) поверх HTTPS. Для кожного файла потрібен щонайменше один запит. Тому Nextcloud додав API для масового завантаження: у посібнику розробника зазначено, що завантаження великої кількості малих файлів може бути повільнішим, оскільки пропускна здатність мережі використовується не повністю. Через це малі файли об’єднуються в пакети. Великі файли передаються через API фрагментованого завантаження. Стандартний розмір фрагмента в desktop-клієнті становить 5 MiB (OWNCLOUD_CHUNK_SIZE за замовчуванням дорівнює 5242880 байтам).

Перевага зберігання файлів на диску полягає в тому, що будь-який наявний у вас інструмент може читати ці дані. Недолік полягає в тому, що Nextcloud не помічає зміни, внесені без його відома. Якщо скопіювати файли безпосередньо до data directory, вони залишатимуться невидимими у вебінтерфейсі, доки ви не виконаєте сканування:

sudo -E -u www-data php occ files:scan --all -vv

В адміністративному посібнику точно зазначено випадки, коли потрібно повторно просканувати дані: після безпосереднього копіювання файлів до data directory, після міграції та під час перевірки невідповідностей file cache.

Який варіант швидше синхронізує велику бібліотеку?

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 спочатку завантажує блоки, а запис commit, який на них посилається, створює в кінці. Тому після переривання завантаження бібліотека залишається на попередньому commit, а не переходить у стан із частково записаним деревом.

Що потрібно кожному варіанту на невеликому VPS

У документації Seafile зазначено: «щонайменше 2G RAM і 2-ядерний CPU (> 2GHz)». У документації Nextcloud обсяг пам’яті вказано для кожного PHP-процесу: мінімум 128 MB і рекомендовано 512 MB на процес. Перед розрахунком потрібно помножити це значення на кількість worker-процесів, а потім додати ресурси для бази даних, кешу та створення preview. Нижче наведено початкові значення, які я б використав для невеликої команди. Це орієнтири, а не результати вимірювань.

ChartStarting point for about five users, and SQL databases per stack
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
  }
]

Обидва варіанти належать до одного класу: 4 GB RAM і 2 ядра. Тому обсяг ресурсів не визначає вибір між ними. Syncthing працює на 1 GB і 1 ядрі, і саме це є обґрунтованою причиною розглянути його. Відмінностей у компонентах більше, ніж у вимогах до пам’яті. Seafile використовує 3 SQL-баз даних, тоді як 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, паролі root і бази даних MySQL, початковий обліковий запис адміністратора та JWT_PRIVATE_KEY. У посібнику вимагається випадковий рядок довжиною не менше 32 символів для цього ключа. Він зчитується під час першого запуску, тому згенеруйте його до запуску stack:

openssl rand -base64 40
docker compose up -d

Під час першого запуску буде створено три бази даних і обліковий запис адміністратора. Аналогічні рішення для Nextcloud, зокрема TLS і reverse proxy, розглянуто в посібнику з Nextcloud на VPS із Docker, TLS і резервними копіями.

Чим відрізняються резервні копії?

Це аспект, який часто недооцінюють. Саме тут продукти відрізняються найбільше.

Для 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/

У цих рядках є дві важливі деталі. Використовуйте mariadb-dump, оскільки серія команд mysql є застарілою в образі MariaDB, який постачається із Seafile. Приберіть прапорець -t з docker exec, коли перенаправляєте вивід у файл. TTY змінює символи завершення рядків і пошкоджує дамп.

Дві частини створюються окремо, тому їхній стан може розійтися. Після будь-якого відновлення перевірте сховище, перш ніж йому довіряти:

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.. Якщо пропустити цю операцію на рік, резервні копії й надалі займатимуть місце даними, які користувачі вже видалили.

У Nextcloud виникає та сама проблема узгодженості двох частин, але в іншій формі, оскільки каталог даних і база даних мають описувати одне й те саме дерево:

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 випускається з двома програмами для настільних систем. Клієнт синхронізації зберігає локальну копію вибраних бібліотек. Клієнт Drive (SeaDrive) монтує бібліотеки як віртуальний диск і завантажує файли під час доступу до них: у Windows він використовує cloud files API від Microsoft, у macOS версія 3.0 є розширенням Finder, а в Linux починаючи з версії 3.0.12 постачається як AppImage і монтує бібліотеки в ~/SeaDrive. Зашифровані бібліотеки працюють на всіх трьох настільних платформах. Мобільні застосунки призначені для доступу до файлів — і лише для цього.

Настільний клієнт Nextcloud також підтримує віртуальні файли, а його мобільні застосунки доповнюють платформу іншими функціями: разом із доступом до файлів доступні календар, контакти, Talk і нотатки. Якщо користувачі переважно працюють зі смартфонів і їм потрібні не лише файли, у щоденному використанні це дає помітну перевагу.

Під час планування варто врахувати одну особливість Seafile: бібліотека є одиницею спільного доступу, синхронізації, керування дозволами та шифрування. Визначте структуру бібліотек до того, як завантажите 500 GB в одну бібліотеку. Переміщення між бібліотеками — це копіювання та видалення, а не перейменування, тому історія файлу не переноситься разом із ним.

Шифрування: що саме захищає кожен варіант

Зашифровані бібліотеки Seafile використовують шифрування на стороні клієнта. Пароль ніколи не зберігається на сервері. Разом із бібліотекою зберігається магічний токен, отриманий із пароля та ідентифікатора бібліотеки. Завдяки цьому клієнт може перевірити пароль до початку синхронізації. Ключ файлу шифрується за допомогою ключа та IV (вектора ініціалізації), отриманих із вашого пароля за допомогою AES 256/CBC. Дані файлу шифруються цим ключем файлу.

Ознайомтеся з описаними обмеженнями, оскільки їх часто не враховують. Зашифрована бібліотека шифрує лише вміст файлів. Імена папок і файлів не шифруються. Розмір файлів і історія редагування також не шифруються. Перегляд зашифрованої бібліотеки у веббраузері не є наскрізним шифруванням: ви вводите пароль, сервер використовує його для розшифрування ключа файлу, а потім зберігає пароль у пам’яті протягом однієї години. У документації також прямо зазначено, що зашифрована бібліотека не забезпечує цілісність даних. Адміністратор сервера може змінити частину вмісту файлу, а клієнт не зможе цього виявити.

У Nextcloud є дві функції зі схожими назвами, які легко сплутати. Шифрування на стороні сервера шифрує файли у стані спокою, але зберігає ключі на тому самому сервері. Тому воно значно краще захищає дані на зовнішньому сховищі, ніж від доступу користувача з root на сервері. Застосунок наскрізного шифрування шифрує вибрані папки на стороні клієнта. За задумом сервер не може їх прочитати. Тому вебінтерфейс, пошук на стороні сервера та попередній перегляд також не можуть бачити вміст цих папок.

Шифрування в жодному з продуктів не замінює зашифровану резервну копію. Шифруйте резервну копію окремо.

Календарі, контакти, офіс і платформа застосунків

За цим критерієм різниця значна. Nextcloud має в ядрі CalDAV (календар через WebDAV) і CardDAV (контакти через WebDAV), інтегрується з Collabora або OnlyOffice для роботи з документами та має магазин застосунків для інших функцій. Seafile 13 постачається із SeaDoc для спільної роботи з документами та wiki-сторінками — на цьому його можливості завершуються. Календаря й адресної книги немає.

Платформа має свою ціну, і ціна — це оновлення. Кожен встановлений застосунок може заблокувати оновлення Nextcloud або некоректно працювати після нього. Тому що більше функцій потрібні вашим користувачам, то ретельніше потрібно планувати вікно оновлення. У Seafile менше компонентів, які можуть вийти з ладу, оскільки він має менше функцій. Також зверніть увагу: повнотекстовий пошук у документах і дозволи на рівні папок доступні за платною ліцензією лише в Seafile Professional, а не в Community Edition. Переконайтеся, що функція, на яку ви розраховуєте, доступна у версії, яку плануєте використовувати.

Типова причина відмови кожного з них

Seafile виходить з ладу, коли база даних і об’єктне сховище втрачають узгодженість. Ви бачите бібліотеку, яка не відкривається, або файли, що зникають, а seaf-fsck.sh виводить відсутній блок. Дерева файлів, яке можна було б відновити вручну, немає, тому для відновлення потрібні дамп бази даних і об’єктне сховище, відновлені в правильному порядку. Один раз перевірте це відновлення на резервному VPS, оскільки резервна копія, з якої ви ніколи не виконували відновлення, є лише припущенням.

Nextcloud виходить з ладу, коли кеш файлів і диск містять різні дані. Зазвичай це відбувається через запис у каталог даних без повідомлення Nextcloud. Ви бачите файл на диску, якого немає у вебінтерфейсі, або каталог із неправильним розміром, і occ files:scan усуває цю проблему. Інші дві проблемні зони — швидкість протоколу під час роботи з великою кількістю малих файлів, яку не можна підвищити лише додаванням CPU, і використання пам’яті PHP. Попередній перегляд великих зображень і відео зазвичай спричиняє різкий стрибок споживання пам’яті, тому виділіть 512 MB на процес і створюйте попередні перегляди за запланованим завданням, а не під час обробки запитів.

Не те й не інше: Syncthing, якщо вам потрібна лише синхронізація файлів

Якщо насправді вам потрібно дзеркально синхронізувати одну папку між машинами, обидва продукти надають більше можливостей, ніж потрібно. У Syncthing немає сервера й облікових записів. Кожен пристрій є вузлом, а VPS стає вузлом, який залишається доступним, коли ноутбук переходить у режим сну. 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@youruser

Вебінтерфейс за замовчуванням прив’язаний до 127.0.0.1:8384, тому він недоступний з інтернету. Це правильне значення за замовчуванням. Підключайтеся до нього через SSH-тунель із ноутбука:

ssh -L 8384:127.0.0.1:8384 youruser@your-server

Потім відкрийте http://127.0.0.1:8384 на ноутбуці. Для синхронізації використовуються порт 22000 через TCP і QUIC, а для виявлення пристроїв у локальній мережі — UDP 21027. Через інтернет цей механізм не працює. На VPS відкрийте 22000, а вебінтерфейс залиште закритим:

sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp

Ви відмовляєтеся від усіх серверних функцій: немає посилань для спільного доступу користувачам, які не запускають Syncthing, немає вебфайлового браузера, облікових записів користувачів і серверного кошика, якщо не ввімкнути версіювання файлів для кожної папки. Типова несподіванка — конфліктний файл. Якщо редагувати один файл на двох пристроях, поки вони не можуть бачити один одного, з’явиться сусідній файл із назвою на кшталт notes.sync-conflict-20260806-142233-ABCD1EF.md. Система не попереджає про це, тому час від часу шукайте sync-conflict.

Якщо вам потрібна не синхронізована папка, а bucket, у який застосунки записують дані, це вже інший інструмент: див. self-hosted S3-сумісне object storage. Ширший огляд self-hosted альтернатив Dropbox охоплює рішення, які не ввійшли до цього порівняння.

Правило вибору

  1. Вибирайте Seafile, якщо потрібна синхронізація у великих масштабах: багато файлів, великі файли, кілька пристроїв, і ви погоджуєтеся на сховище даних, яке може читати лише Seafile.
  2. Вибирайте Nextcloud, якщо потрібна платформа: календарі, контакти, документи та посилання для спільного доступу, а звичайні файли зберігаються на диску у форматі, який може читати будь-який засіб резервного копіювання.
  3. Вибирайте Syncthing, якщо потрібна лише синхронізована копія каталогу.

Зробіть вибір уважно, оскільки міграція між Seafile і Nextcloud є справжньою фіксацією на платформі. Конвертера немає. Потрібно синхронізувати всі дані на клієнт, завантажити їх на інший сервер і витратити додаткові ресурси на пропускну здатність та час, а історія версій і посилання для спільного доступу залишаться на попередньому сервері. Розрахувати поточний вибір на наступні три роки дешевше, ніж переходити на іншу платформу на другому році.

FAQ

Чи працює Seafile швидше за Nextcloud під час синхронізації великих бібліотек?

Так, у двох випадках, які зазвичай створюють найбільше проблем, і це можна перевірити. Seafile розбиває файли на блоки середнім розміром близько 8 MB і передає лише змінені блоки, тому під час редагування великого файлу передається кілька блоків. Одиницею передавання в Nextcloud є весь файл, тому після такого самого редагування його буде завантажено повторно повністю. Крім того, для кожного невеликого файлу потрібен щонайменше один запит WebDAV, тому його bulk upload API об’єднує невеликі файли. Перед вибором рішення виміряйте час на власному VPS, оскільки CPU, диск і мережеве з’єднання можуть впливати не менше, ніж протокол.

Чи можна створити резервну копію Seafile, запустивши rsync для каталогу даних?

Лише разом із базами даних і в порядку, описаному в документації. У посібнику Seafile зазначено, що спочатку потрібно створити резервну копію SQL, а потім каталогу даних. Тоді кожен запис бази даних посилається на об’єкт, який існує в резервній копії. Команда rsync -az /opt/seafile-data/seafile /backup/data/ копіює conf, seafile-data і seahub-data, але сама по собі така копія не придатна для відновлення, оскільки object store не містить доступного для читання дерева файлів, а база даних є його індексом. Після відновлення обох частин виконайте seaf-fsck.sh і перевірте його виведення, перш ніж вважати результат коректним.

Чи потрібен Nextcloud, якщо мені потрібна лише синхронізація файлів?

Ні. Nextcloud є платформою, а календар, контакти й app store споживають пам’ять і потребують уваги під час оновлень незалежно від того, користуєтеся ви ними чи ні. Для звичайної синхронізації файлів Seafile є легшим продуктом із швидшим протоколом, а Syncthing ще легший, оскільки для нього не потрібно обслуговувати серверну частину. Обирайте Nextcloud, якщо потрібні додаткові застосунки, а не як рішення за замовчуванням.

Чи приховує зашифрована бібліотека Seafile імена моїх файлів?

Ні. Зашифрована бібліотека шифрує вміст файлів на клієнті, а пароль ніколи не передається на сервер. Водночас імена каталогів, імена файлів, розміри файлів і історія редагувань залишаються видимими на сервері. Відкриття зашифрованої бібліотеки у вебінтерфейсі також передає пароль на сервер. Сервер розшифровує ключ файлу та зберігає пароль у пам’яті протягом однієї години. Якщо самі імена містять конфіденційні дані, не відкривайте цю бібліотеку у вебінтерфейсі та використовуйте шифрування на іншому рівні.

Скільки RAM потрібно виділити для Seafile або Nextcloud на VPS?

Для будь-якого з них із невеликою кількістю користувачів почніть із 4 GB RAM і 2 ядер CPU, а потім контролюйте використання пам’яті під час створення попередніх переглядів і пошуку. У документації Seafile мінімально рекомендовано 2 GB RAM і CPU із 2 ядрами та тактовою частотою понад 2 GHz. У документації Nextcloud рекомендовано 512 MB на процес PHP. Передбачений обсяг потрібно помножити на кількість worker-процесів, а потім додати пам’ять для бази даних і кешу. Syncthing стабільно працює з 1 GB RAM.