Відхід від Nextcloud: три легші шляхи залежно від того, для чого ви ним користувалися

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

Скарга під усіма трьома випадками та сама: людям потрібен був один надійний робочий сценарій від пакета, побудованого, щоб покривати їх багато.

У мене є екземпляр Nextcloud на VPS у Франкфурті, який я підняв за вихідні два роки тому й відтоді відкривав разів чотири. Встановлення спрацювало. Екземпляр досі працює. Я просто перестав у нього заходити, бо виявилося: дев'ять із десяти речей, які вміє Nextcloud, мені ніколи не були потрібні.

Офіційна збірка All-in-One вимагає щонайменше 2 ГБ ОЗП, щойно ввімкнено будь-який необов'язковий контейнер, а її рекомендації щодо продуктивності радять додавати приблизно 1 ГБ ОЗП на активного користувача понад базову вимогу. Отже, командним розгортанням потрібен більший запас у міру зростання одночасного використання. До того ж у спільноти відкрита тема на help.nextcloud.com із проханням до проєкту розглянути полегшену версію.

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

Коротко

• Якщо ви користувалися Nextcloud лише для синхронізації файлів між власними пристроями, Syncthing — хороший варіант: peer-to-peer, без обов'язкового центрального сервера, з кількома важливими застереженнями на мобільних платформах.
• Якщо ви використовували Nextcloud як спільний файловий ресурс команди на кількох користувачів, Seafile CE — хороший варіант. Задокументований мінімум — 2 ГБ ОЗП і 2 ядра процесора, а вужча спеціалізація спрощує добір ресурсів, коли головне завдання — обмін файлами.
• Якщо ви користувалися Nextcloud здебільшого як вебоглядачем файлів, Cloudreve або AList дає значно вужчий стек, не тягнучи за собою весь пакет спільної роботи Nextcloud.
• Дві точки тертя за будь-якого переїзду — розрив із CalDAV/CardDAV (календар і контакти) та резервне копіювання фотографій на iOS. Обидва розібрані в карті міграції нижче.

Чому Nextcloud здається важким (і чому це не вада)

На свіжому встановленні Nextcloud All-in-One htop показує справжній багатоконтейнерний стек: головний контейнер AIO, Apache, сервер застосунку Nextcloud, PostgreSQL, Redis і Notify Push. Office, Talk, Talk Recording, ClamAV, повнотекстовий пошук, Imaginary, Whiteboard і резервні копії на базі Borg — необов'язкові. Ядро важче за вузькоспеціалізований демон синхронізації, але ці необов'язкові сервіси витрачають ОЗП лише тоді, коли ви їх вмикаєте.

Офіційне обговорення All-in-One на GitHub задає задокументований мінімум у 2 ГБ ОЗП, але він швидко зростає: 3 ГБ, щойно ввімкнено ClamAV, Talk Recording або повнотекстовий пошук, 5 ГБ за ввімкненого всього, плюс приблизно 1 ГБ на активного користувача понад базу.

Це рекомендації щодо добору ресурсів, а не виміряне усталене споживання ОЗП: AIO потребує більше пам'яті в міру ввімкнення необов'язкових сервісів і радить додатковий запас на кожного активного користувача. Це архітектурна ціна за те, щоб зібрати понад тридцять функцій в один самостійно розміщуваний пакет. Джерело: github.com/nextcloud/all-in-one/discussions/1335.

Спільнота Nextcloud помітила це й сама. Тему на help.nextcloud.com під назвою «Nextcloud Lite, discuss» відкрили в грудні 2024 року з питанням, чи варто проєкту випускати урізану збірку для користувачів, яким потрібні лише файли та спільний доступ. Частина користувачів, зокрема ті, кому Nextcloud загалом подобається, попросили легшу збірку. Більшість відповідей були проти: казали, що непотрібні функції можна просто вимкнути, а різати застосунки безпеки — поганий обмін. Тема відкрита, і супровідники не стали на жоден бік. Посилання: help.nextcloud.com/t/nextcloud-lite-discuss/213611.

Контраргумент важить. AIO вже постачає PostgreSQL, Redis і APCu. Його власні рекомендації щодо продуктивності радять вимикати необов'язкові контейнери та застосунки Nextcloud, які вам не потрібні. Якщо ваш екземпляр здається важким саме тому, що ви ввімкнули Office, Talk, ClamAV, повнотекстовий пошук чи інші сервіси, якими більше не користуєтеся, спершу підріжте саме їх. Якщо ви справді використовуєте ці сервіси разом, більший слід робить корисну роботу.

Але якщо ви встановили Nextcloud, а потім відкривали його лише щоб кинути файли в синхронізовану теку, розмова про тонке налаштування не про вас.

Щоб зрозуміти, як Nextcloud співвідноситься зі своїм найближчим форком, подивіться наше порівняння Nextcloud проти ownCloud.

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

Діагностика за трьома архетипами: який вихід ваш?

Перш ніж обирати інструмент, оберіть робочий сценарій. Майже кожен користувач Nextcloud, з яким я говорив, чітко вкладається в один із трьох шаблонів.

Архетип А. Лише синхронізація між пристроями. «Я поставив Nextcloud, щоб тримати ноутбук, настільний комп'ютер і телефон у синхронізації. Вебінтерфейсом жодного разу серйозно не користувався. Файлами з іншими людьми не ділюся».

Архетип Б. Командний обмін файлами. «Я поставив Nextcloud, бо кільком людям треба було завантажувати файли у спільний простір і забирати їх звідти. Іноді з браузера, іноді з настільного клієнта. Мені була важлива швидкість на великих файлах».

Архетип В. Лише вебпортал. «Я поставив Nextcloud як вебоглядач файлів. Спосіб увійти й забрати свої файли звідки завгодно. Можливо, я поставив настільний клієнт. Користувався ним рідко. Синхронізація в реальному часі була ні до чого».

Якщо вам підходять два з них, оберіть той, про який скажете: «якщо це перестане працювати завтра, я помічу протягом години». Це й є сценарій, від якого ви залежите. Решта — приємні доповнення, які можна замінити пізніше або обійтися без них.

Мінімальні вимоги до ресурсів для кожного шляху:

Цифри вище для Nextcloud AIO та Seafile CE — це задокументовані вимоги або рекомендації. Syncthing, Cloudreve та AList не публікують зіставних жорстких мінімумів щодо ОЗП, які дозволили б чесне порівняння пліч-о-пліч, тож добирайте ресурси для цих інструментів за своєю реальною бібліотекою, бекендом сховища та навантаженням, а не приймайте за вимоги цифри споживання пам'яті в простої, озвучені спільнотою.

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

Архетип А. Syncthing для синхронізації між пристроями

Ноутбук, настільний комп'ютер і телефон. Ви кидаєте файл у теку на ноутбуці, і за двадцять секунд він з'являється на двох інших. Жодного вебпорталу. Жодної спільної бібліотеки. Жодної команди. Заради цього Syncthing і зробили, і це єдине, що він робить.

Syncthing працює за схемою peer-to-peer. Сервера в архітектурному сенсі тут немає. Кожен пристрій запускає той самий бінарник, а пристрої знаходять одне одного через глобальну мережу ретрансляторів або локальну мережу. Ви можете додати VPS до цієї мережі, але він буде одним вузлом серед інших, а не центральним органом. Тут немає вебоглядача файлів. Немає CalDAV. Немає командних прав доступу. Якщо ваше використання Nextcloud зводилося до «тримати мої теки синхронізованими», жодна з цих втрат не має значення.

Найбільше уваги дістається витраті ресурсів. На невеликій бібліотеці, скажімо кілька тисяч файлів у межах 50 ГБ, Syncthing у простої зазвичай тримається між 50 та 100 МБ ОЗП. Щойно бібліотека виростає до сотень тисяч файлів, витрата ОЗП може перевалити за 700 МБ. Більшість самостійних адміністраторів туди ніколи не доходять. Якщо у вас чверть мільйона файлів в одній теці — дійдете.

Цю поведінку за зростання документують два першоджерела:

• Давня тема на форумі Syncthing про використання ОЗП: forum.syncthing.net/t/ram-utilization/9769
• Власна задача проєкту на GitHub про обрив під час масштабування: github.com/syncthing/syncthing/issues/468

VPS важливий навіть у моделі peer-to-peer. Ваш ноутбук і ваш телефон не бувають у мережі одночасно. Якщо ви хочете, щоб зміни розходилися, поки один пристрій спить, потрібен третій пристрій, який увімкнено завжди. VPS із запущеним Syncthing бере цю роль на себе й віддає свіжу копію наступному пристрою, що прокинеться. Невелика бібліотека спокійно вкладається в 512 МБ ОЗП; дайте їй 1 ГБ, якщо бібліотека перевалить за кілька сотень тисяч файлів.

Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.

Переглянути тарифи Linux

Застереження про iOS — саме те, яке посібники з Syncthing обходять стороною. Офіційного клієнта Syncthing для iOS із надійним фоновим завантаженням фотографій не існує. Є кілька сторонніх клієнтів, але жоден не дотягує до того, що робить застосунок Nextcloud для iOS із резервною копією плівки. Якщо синхронізація фотографій з iPhone була вашою причиною тримати Nextcloud, Syncthing сам по собі її не замінить. Обхідні шляхи — платні застосунки на кшталт PhotoSync, які складають файли в теку Syncthing, або залишити Nextcloud працювати винятково заради цього одного сценарію, поки ви переносите все інше.

ЧИТАЙ

Найкращі альтернативи Google Photos: порівняння хмарних сервісів і самостійно розгорнутих рішень

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

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

Архетип Б. Seafile для командної синхронізації файлів

Команда з чотирьох людей. Спільна бібліотека «Operations», у якій лежать 60 ГБ договорів, макетів і вивантажень. Троє з чотирьох працюють із настільним клієнтом синхронізації, одна надає перевагу браузеру. Час від часу хтось заливає відео на 4 ГБ.

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

Seafile написаний на C і Python із бекендом MariaDB. Шару PHP немає. Модель синхронізації — поблокова дедуплікація: коли ви змінюєте файл, передаються лише змінені блоки, а однакові блоки в різних користувачів зберігаються один раз. Синхронізація Nextcloud за замовчуванням у більшості сценаріїв працює з файлом цілком.

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

Поточна документація Seafile Community Edition вказує мінімум у 2 ГБ ОЗП і 2 ядра процесора. Це збігається з мінімумом Nextcloud AIO у 2 ГБ, коли ввімкнено будь-який необов'язковий контейнер. Вужча спеціалізація Seafile все ж може спрощувати добір ресурсів під обмін файлами, але точна різниця за пам'яттю залежить від навантаження, активних користувачів, розміру бібліотеки й того, які сервіси Nextcloud увімкнено.

Команді, якій потрібні лише синхронізація та обмін файлами, Seafile дозволяє обійтися без додаткових сервісів Nextcloud, якими ви не користуєтеся. Це може зменшити слід на сервері, але точний розрив залежить від навантаження, а не від жорсткого правила на кшталт «2 ГБ проти 5 ГБ».

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

Seafile зберігає дані бібліотеки у вигляді блоків і внутрішніх об'єктів, а не звичайних переглядуваних файлів. Виведення вмісту каталогу даних командою ls показує внутрішню об'єктну структуру Seafile замість вашого початкового дерева тек. Шифрування — окрема функція, і не воно робить ці об'єкти непрозорими. Це означає, що відновити бібліотеку Seafile простим копіюванням нормальних на вигляд файлів із бекенда сховища не вийде.

Seafile CE до того ж потребує ручного прибирання сміття. Ви запускаєте скрипт, який вичищає блоки без посилань після видалення бібліотек або файлів. Редакція Pro автоматизує більше. Редакція Community — ні. Seafile буде вам незручним, якщо ваш операційний спокій тримається на можливості будь-якої миті скопіювати дані назовні командою cp -r.

Друга втрата, яку варто закласти: календар і контакти. Seafile не реалізує ані CalDAV, ані CardDAV. Якщо ваш Nextcloud був адресною книгою за вашим телефоном, вам знадобиться окремий легкий сервіс, щоб закрити цей розрив. Radicale і Baikal — стандартні відповіді.

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

Архетип В. Cloudreve або AList для вебпорталу

Найбільш недооцінений шлях виходу. Цьому користувачеві потрібна була вебсторінка, де він увійде з будь-якого пристрою й забере свої файли. Настільним клієнтом він майже не користувався. Синхронізація в реальному часі його не хвилювала. Для такого завдання весь функціональний стек Nextcloud був значно більший, ніж потрібно.

Для такого користувача правильна відповідь — ані Nextcloud, ані Seafile, ані Syncthing. Правильна відповідь — вебпортал. Сюди акуратно лягають два проєкти, і розходяться вони по одній осі: чи керує інструмент вашим сховищем, чи лише читає з нього.

Cloudreve — це вебпортал плюс керований шар зберігання. Файли лежать у сховищі, яким керує Cloudreve (локальний диск, об'єктне сховище, сумісне з S3, або інші бекенди). Є облікові записи та квоти, а Cloudreve Pro тепер має офіційний настільний клієнт для Windows із двосторонньою синхронізацією в реальному часі. Архітектура — бінарник на Go плюс база даних, а репозиторій проєкту активний за адресою github.com/cloudreve/cloudreve.

AList кладе вебінтерфейс поверх наявного сховища. Він уміє переглядати підключені бекенди — локальні диски, S3, Google Drive, OneDrive, SMB і WebDAV — і працювати з ними, зокрема виконувати операції з файлами там, де бекенд їх підтримує. Він запускається як бінарник на Go і за замовчуванням використовує SQLite, тож базовому розгортанню окремий сервер бази даних не потрібен. Якщо ваші файли вже лежать звичайними файлами на підтримуваному сховищі, AList може показати їх, не імпортуючи в новий формат.

Що і коли обирати:

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

Одну річ варто розуміти до вибору будь-якого з них: AList не замінює синхронізацію, а можливості синхронізації в Cloudreve вужчі, ніж у Nextcloud. У Cloudreve Pro є офіційний настільний клієнт синхронізації для Windows, але жоден із цих інструментів не дає екосистеми CalDAV/CardDAV Nextcloud чи рівноцінного сценарію резервного копіювання фотографій на всіх платформах. Якщо це принципово, ви ближче до архетипу А чи Б, ніж до В. AList і Cloudreve — не полегшені Nextcloud. Це вужчі інструменти для вужчих завдань.

Ключовий висновок розділу: Cloudreve та AList — хороші варіанти, якщо ви використовували здебільшого вебоглядач файлів Nextcloud. AList зберігає налаштування простішим, коли потрібен лише вебшар поверх наявного сховища. Cloudreve має більше сенсу, коли потрібні кероване сховище, облікові записи та настільна синхронізація у Windows.

Карта тертя під час міграції: що ви збережете, що втратите

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

Розрив із CalDAV/CardDAV — найбільш недооцінена стаття витрат під час міграції. Якщо адресна книга вашого телефона синхронізувалася з Nextcloud, цей ланцюжок рветься тієї миті, коли ви припиняєте запускати Nextcloud, хоч би яким файловим інструментом ви його замінили. Radicale і Baikal — стандартні легкі заміни, і обидва вони значно менші сервіси, ніж повне встановлення Nextcloud. Саме ці латки варто тримати в полі зору, перш ніж висмикувати вилку з екземпляра Nextcloud.

Якщо вам потрібен окремий майданчик, щоб перевірити міграцію до того, як довіряти їй свої дані, Linux VPS від Cloudzy дає чисте місце для цього. Окремий тестовий сервер дозволяє відрепетирувати переїзд, не чіпаючи робочий екземпляр, і будь-який із цих інструментів розгортається в один клік:

• Seafile
• Syncthing
• Cloudreve
• AList

Коли варто залишитися на Nextcloud

Діагностика ріже в обидва боки. Ось три причини залишитися, за спаданням ваги.

Ви активно користуєтеся зв'язкою календаря, контактів, завдань і нотаток. Nextcloud тримає всі чотири за одним входом, із робочою реалізацією CalDAV/CardDAV, робочим вебінтерфейсом і робочими мобільними клієнтами. Замінити це окремими сервісами означає запустити Radicale або Baikal для календаря й контактів, окремий застосунок для нотаток і окремий менеджер завдань. Два-три сервіси замість одного. Два-три способи зламатися замість одного. Якщо це ваша щоденна робота, Nextcloud окуповує власну витрату ОЗП.

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

Ваш Nextcloud важкий через сервіси, якими ви не користуєтеся. AIO вже постачає PostgreSQL, Redis і APCu, тож міняти базу даних чи вмикати APCu — тут не той крок налаштування. Почніть із вимкнення необов'язкових контейнерів і застосунків Nextcloud, які вам не потрібні. Якщо Office, Talk, ClamAV, повнотекстовий пошук або сервіси попереднього перегляду працюють без реальної мети, зніміть це навантаження, перш ніж наважуватися на міграцію.

Логіка, яка каже «йди, якщо ти використовував лише 10 % функцій», каже й «залишайся, якщо ти цими функціями справді користуєшся». Будьте чесні, який із двох випадків ваш.

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

Часті запитання