توسط مقایسه Seafile و Nextcloud برای همگامسازی فایل
تفاوت Seafile و Nextcloud در نحوه ذخیرهسازی فایل و سرعت همگامسازی است. در این بررسی تا آگوست 2026، مصرف RAM، امنیت و روشهای پشتیبانگیری را برای انتخاب بهترین گزینه مقایسه میکنیم.
مقایسه Seafile و Nextcloud: پاسخ کوتاه
تفاوت اصلی بین Seafile و Nextcloud به یک نکته برمیگردد: ماهیت فایل پس از رسیدن به سرور. Seafile هر فایل را به بلوکهای کوچکتر تقسیم کرده و آنها را در یک object store ذخیره میکند که فقط توسط خود Seafile قابل خواندن است؛ در نتیجه همگامسازی (sync) سریع انجام میشود اما پشتیبانگیری به فرآیندی دو مرحلهای تبدیل میگردد. در مقابل، Nextcloud فایل شما را دقیقاً به همان شکل روی دیسک مینویسد و همگامسازی را تنها یکی از قابلیتهای پلتفرمی میداند که مدیریت تقویم، مخاطبین، اسناد و لینکهای اشتراکگذاری را نیز بر عهده دارد. تصمیمگیری خود را بر اساس همین تفاوت بنا کنید، زیرا سایر ویژگیها از این ساختار تبعیت میکنند.
تا آگوست 2026، Seafile در سری 13.0 و Nextcloud در سری 34 قرار دارند. هر دو نرمافزار به بلوغ رسیدهاند و هیچکدام قصد تغییر مدل ذخیرهسازی خود را ندارند.
نحوه ذخیرهسازی فایلها در Seafile
Seafile یک کتابخانه (library) را به همان شکلی مدلسازی میکند که git یک مخزن (repository) را مدلسازی میکند. راهنمای مدیر سیستم، مدل داخلی آن را شامل Repo، Commit، FS و Block میداند و اشاره میکند که یک repo همان کتابخانه است. هر فایل با استفاده از الگوریتم Content Defined Chunking (یا به اختصار CDC، الگوریتمی که مرزهای بلوک را بر اساس خودِ دادهها تعیین میکند) به بلوکهایی با طول متغیر تقسیم میشود؛ راهنما میانگین اندازه هر بلوک را حدود 8 MB ذکر کرده است. نامگذاری بلوکها بر اساس محتوای آنها انجام میشود؛ بنابراین دو نسخه از یک فایل بزرگ، تمام بلوکهایی را که تغییر نکردهاند به اشتراک میگذارند و دو کتابخانه نیز بلوکهای یکسان را با هم شریک میشوند.
پایگاه داده رابطهای تنها مقدار کمی از متادیتای مربوط به کتابخانهها را نگهداری میکند. باقی موارد، یعنی commitها، اشیاء دایرکتوری و بلوکها، همگی در دایرکتوری داده قرار دارند. در ساختار Docker که در سریهای 12 و 13 استفاده میشود، این مسیر /opt/seafile-data/seafile/seafile-data است. اجرای دستور ls در آنجا اطلاعات مفیدی به شما نمیدهد، زیرا شما دایرکتوریهایی پر از نامهای هششده میبینید، نه Invoices/2026/march.pdf.
همگامسازی (Sync) نیز از همین مدل پیروی میکند. کلاینت از سرور میپرسد چه چیزی تغییر کرده است، لیستی از هشهای بلوک را دریافت میکند و تنها بلوکهایی را که هنوز در اختیار ندارد، دریافت میکند. به همین دلیل است که Seafile در کتابخانههای بزرگ عملکرد پایداری دارد: تعداد بایتهای منتقلشده متناسب با بلوکهای تغییریافته است، نه اندازه فایلی که آن بلوکها را در خود جای داده است.
نحوه ذخیرهسازی فایلها در Nextcloud
Nextcloud فایلها را دقیقاً در همان مسیری که انتظار دارید روی دیسک ذخیره میکند. مسیر data/<username>/files/ بازتابی از ساختار درختی است که کاربر در رابط کاربری وب مشاهده میکند. یک جدول در پایگاه داده به نام oc_filecache نیز همین ساختار را به همراه اطلاعاتی نظیر حجم، زمان آخرین تغییر و etagها در خود نگه میدارد؛ Nextcloud برای مدیریت فایلها، به این جدول بیش از خودِ دیسک اعتماد دارد.
کلاینت دسکتاپ از پروتکل WebDAV (مخفف Web Distributed Authoring and Versioning) بر بستر HTTPS استفاده میکند. هر فایل حداقل یک درخواست شبکه ایجاد میکند؛ به همین دلیل Nextcloud یک API برای آپلود دستهجمعی (bulk upload) اضافه کرده است. در راهنمای توسعهدهندگان توضیح داده شده که آپلود تعداد زیادی فایل کوچک به دلیل عدم استفاده کامل از پهنای باند شبکه، کندتر از حد بهینه است؛ بنابراین فایلهای کوچک با هم بستهبندی میشوند. فایلهای حجیم از طریق API قطعهبندی (chunking) ارسال میشوند و اندازه پیشفرض هر قطعه در کلاینت دسکتاپ 5 مگابایت است (OWNCLOUD_CHUNK_SIZE بهطور پیشفرض برابر با 5242880 بایت است).
مزیت ذخیره فایلها روی دیسک این است که تمام ابزارهای موجود در سیستم شما میتوانند دادهها را بخوانند. هزینه این کار این است که Nextcloud تغییراتی را که مستقیماً در فایلسیستم (خارج از کنترل آن) اعمال میشوند، تشخیص نمیدهد. اگر فایلها را مستقیماً در دایرکتوری داده کپی کنید، تا زمانی که عملیات اسکن را انجام ندهید، در رابط کاربری وب قابل مشاهده نخواهند بود:
sudo -E -u www-data php occ files:scan --all -vvراهنمای مدیریت دقیقاً به همین موارد برای اسکن مجدد (rescan) اشاره میکند: پس از کپی مستقیم فایلها در دایرکتوری داده، پس از مهاجرت (migration) و زمانی که در حال بررسی عدم تطابق در کش فایلها هستید.
کدامیک کتابخانهای بزرگ را سریعتر همگامسازی میکند؟
Seafile، در دو سناریویی که عملکرد را مختل میکنند: دهها هزار فایل کوچک، و ویرایشهای مکرر روی فایلهای بزرگ. مکانیزم این ابزار، deduplication در سطح بلاک است؛ بنابراین یک disk image به حجم 4 GB که بخشی از آن تغییر کرده، تنها به صورت چند بلاک آپلود میشود. Nextcloud با استفاده از bulk upload فاصله در مدیریت فایلهای کوچک را کاهش میدهد، اما نمیتواند فاصله در مدیریت فایلهای بزرگ را جبران کند، زیرا واحد انتقال در آن، کل فایل است.
به حرف من درباره اندازه این فاصله اکتفا نکنید و به بنچمارکهای ارائهشده توسط فروشندگان نیز اعتماد نکنید. کتابخانهای مشابه کتابخانه خود بسازید و زمان آن را اندازهگیری کنید:
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 حداقل 2 گیگابایت رم و یک پردازنده 2 هستهای (بیش از 2 گیگاهرتز) را درخواست میکنند. در مقابل، مستندات Nextcloud حافظه مورد نیاز را بر اساس هر پردازش PHP محاسبه میکنند: حداقل 128 مگابایت و مقدار پیشنهادی 512 مگابایت برای هر پردازش که باید آن را در تعداد workerها ضرب کرده و سپس مقدار مصرفی پایگاه داده، کش و تولید پیشنمایش را به آن اضافه کنید. در ادامه، مقادیر اولیهای که برای یک تیم کوچک پیشنهاد میکنم آمده است. اینها نقاط شروع هستند، نه اندازهگیریهای دقیق.
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 گیگابایت رم با 2 هسته پردازنده؛ بنابراین میزان مصرف حافظه عامل تعیینکننده بین آنها نیست. Syncthing با 1 گیگابایت رم روی 1 هسته اجرا میشود که دلیل صادقانهای برای در نظر گرفتن آن است. اجزای متحرک این سرویسها تفاوت بیشتری نسبت به حافظه دارند. Seafile تعداد 3 پایگاه داده SQL را مدیریت میکند در حالی که Nextcloud از 1 پایگاه داده استفاده میکند. استقرار پیشفرض Seafile با Docker، سرور، 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 و سپس از دایرکتوری دادهها پشتیبان تهیه کنید؛ زیرا در این صورت، هر رکورد در پایگاه داده یک شیء معتبر برای ارجاع دارد و کتابخانهها دچار خرابی نمیشوند. اگر این ترتیب را معکوس کنید، ممکن است یک ردیف در پایگاه داده به بلوکی اشاره کند که در snapshot شما ثبت نشده است.
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 انتهای خطوط را بازنویسی کرده و فایل dump را خراب میکند.
این دو بخش بهصورت جداگانه ثبت میشوند، بنابراین ممکن است با هم اختلاف زمانی پیدا کنند. پس از هر بار بازیابی، پیش از اعتماد به مخزن، آن را بررسی کنید:
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.برای garbage collection نیز برنامهریزی کنید. به دلیل deduplication، فایلها و کتابخانههای حذفشده تا زمانی که ./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پوشهٔ config، پوشهٔ data، هرگونه برنامهٔ سفارشی و تم خود را به همراه آن dump حفظ کنید. هر دو بخش را از یک لحظهٔ زمانی یکسان بازیابی کنید. اگر دایرکتوری دادهها جدیدتر از پایگاه داده باشد، کاربران فایلهایی را میبینند که cache فایل از آنها بیاطلاع است و occ files:scan --all آن را تعمیر میکند. اگر پایگاه داده جدیدتر باشد، ردیفهای cache به فایلهایی اشاره میکنند که دیگر وجود ندارند و occ files:cleanup ورودیهای cache که هیچ مطابقی در جدول ذخیرهسازی ندارند را حذف میکند.
در هر صورت، شما به یک برنامهٔ پشتیبانگیری نیاز دارید که با تعداد زیادی فایل کوچک کنار بیاید و تاریخچه را حفظ کند؛ این همان کاری است که restic و BorgBackup به شکلی متفاوت انجام میدهند.
کلاینتهای دسکتاپ و موبایل
Seafile دو برنامه دسکتاپ ارائه میدهد. کلاینت همگامسازی (syncing client) یک کپی محلی از کتابخانههای انتخابی شما را نگه میدارد. کلاینت Drive (یا همان SeaDrive) کتابخانههای شما را به عنوان یک درایو مجازی mount میکند و فایلها را هنگام دسترسی دانلود میکند: در ویندوز از API فایلهای ابری مایکروسافت استفاده میکند، در macOS نسخه 3.0 یک افزونه Finder است و در لینوکس از نسخه 3.0.12 به بعد به صورت AppImage ارائه شده و در مسیر ~/SeaDrive mount میشود. کتابخانههای رمزگذاریشده در هر سه پلتفرم دسکتاپ کار میکنند. اپلیکیشنهای موبایل صرفاً برای دسترسی به فایلها طراحی شدهاند و هدف دیگری ندارند.
کلاینت دسکتاپ Nextcloud نیز فایلهای مجازی را ارائه میدهد و اپلیکیشنهای موبایل آن، تمامی قابلیتهای پلتفرم را به همراه دارند؛ بنابراین تقویم، مخاطبین، Talk و یادداشتها در کنار دسترسی به فایلها در دسترس هستند. اگر کاربران شما بیشتر از موبایل استفاده میکنند و به چیزی فراتر از فایلها نیاز دارند، این یک تفاوت واقعی در استفاده روزمره است.
یک نکته در Seafile نیازمند برنامهریزی است: کتابخانه (library) واحد اصلی اشتراکگذاری، همگامسازی، مجوزها و رمزگذاری است. پیش از آنکه 500 GB داده را در یک کتابخانه واحد بارگذاری کنید، ساختار کتابخانههای خود را تعیین کنید؛ زیرا جابهجایی فایل بین کتابخانهها در واقع یک عملیات کپی و حذف است، نه تغییر نام، بنابراین تاریخچه فایل به مقصد منتقل نمیشود.
رمزنگاری: هر کدام واقعاً از چه چیزی محافظت میکنند
کتابخانههای رمزنگاریشده در Seafile سمت کلاینت هستند. رمز عبور هرگز روی سرور ذخیره نمیشود. یک توکن جادویی که از رمز عبور و شناسه کتابخانه مشتق شده، همراه با کتابخانه ذخیره میشود تا کلاینت بتواند پیش از همگامسازی، رمز عبور را بررسی کند. کلید فایل با استفاده از یک کلید و IV (بردار مقداردهی اولیه) که از رمز عبور شما با الگوریتم AES 256/CBC مشتق شده، رمزنگاری میشود و دادههای فایل نیز با همان کلید فایل رمزنگاری میشوند.
محدودیتهای مستندشده را مطالعه کنید، زیرا کاربران اغلب از آنها غافل میشوند. یک کتابخانه رمزنگاریشده فقط محتوای فایلها را رمزنگاری میکند. نام پوشهها و فایلها، اندازه فایلها و تاریخچه ویرایشها رمزنگاری نمیشوند. مرور یک کتابخانه رمزنگاریشده در مرورگر وب، رمزنگاری سرتاسری (end to end) نیست: شما رمز عبور را وارد میکنید، سرور از آن برای رمزگشایی کلید فایل استفاده کرده و رمز عبور را به مدت 1 ساعت در حافظه کش میکند. دفترچه راهنما بهصراحت بیان میکند که کتابخانه رمزنگاریشده تضمینکننده یکپارچگی داده نیست، زیرا مدیر سرور میتواند بخشی از محتوای فایل را تغییر دهد و کلاینت قادر به تشخیص آن نخواهد بود.
Nextcloud دو قابلیت با نامهای مشابه و گیجکننده دارد. رمزنگاری سمت سرور (Server side encryption)، فایلها را در حالت سکون (at rest) رمزنگاری میکند اما کلیدها را روی همان سرور نگه میدارد؛ بنابراین این قابلیت از دادههای موجود در فضای ذخیرهسازی خارجی بسیار بهتر از محافظت در برابر شخصی با دسترسی root روی سرور محافظت میکند. اپلیکیشن رمزنگاری سرتاسری (end to end encryption)، پوشههای انتخابشده را در سمت کلاینت رمزنگاری میکند و طبق طراحی، سرور نمیتواند آنها را بخواند؛ بنابراین رابط کاربری وب، جستجوی سمت سرور و پیشنمایشها نیز نمیتوانند محتوای آن پوشهها را مشاهده کنند.
رمزنگاری هیچکدام از این محصولات جایگزین پشتیبانگیری (backup) رمزنگاریشده نیست. از پشتیبانها بهصورت جداگانه محافظت کنید.
تقویمها، مخاطبین، آفیس و پلتفرم اپلیکیشنها
این محور نهایی نیست. Nextcloud پروتکلهای CalDAV (تقویم بر بستر WebDAV) و CardDAV (مخاطبین بر بستر WebDAV) را در هستهٔ خود ارائه میدهد، Collabora یا OnlyOffice را برای اسناد یکپارچه میکند و برای سایر موارد، یک فروشگاه اپلیکیشن دارد. Seafile 13 قابلیت SeaDoc را برای اسناد اشتراکی و صفحات ویکی ارائه میدهد و در همینجا متوقف میشود. در این سرویس خبری از تقویم یا دفترچه تلفن نیست.
این پلتفرم هزینهای دارد و آن هزینه، ارتقاها است. هر اپلیکیشنی که نصب میکنید، عاملی است که میتواند مانع ارتقای Nextcloud شود یا پس از آن دچار اختلال گردد؛ بنابراین هرچه کاربران شما به قابلیتهای بیشتری وابسته باشند، پنجرهٔ ارتقای شما حساستر میشود. Seafile به دلیل انجام کارهای کمتر، خرابیهای کمتری نیز دارد. همچنین توجه داشته باشید که قابلیت جستجوی تماممتن در اسناد و مجوزهای سطح پوشه، در نسخهٔ Seafile Professional (و نه Community Edition) تحت لایسنس پولی ارائه میشود؛ بنابراین پیش از هر چیز مطمئن شوید قابلیتی که روی آن حساب کردهاید، در نسخهای که قصد اجرای آن را دارید موجود است.
حالتهای خرابی شناختهشده برای هر سرویس
سرویس Seafile زمانی دچار مشکل میشود که پایگاه داده و object store با یکدیگر همگام نباشند. در این حالت، کتابخانهای باز نمیشود یا فایلها ناپدید میشوند و seaf-fsck.sh بلوکهای گمشده را گزارش میکند. از آنجا که ساختار درختی فایلها برای تعمیر دستی وجود ندارد، بازیابی تنها از طریق بازگردانی dump پایگاه داده و object store با ترتیب صحیح امکانپذیر است. این فرآیند بازیابی را یکبار روی یک VPS یدکی تست کنید، زیرا بکآپی که هرگز بازیابی نشده است، صرفاً یک حدس و گمان است.
سرویس Nextcloud زمانی دچار مشکل میشود که کش فایلها با دیسک همخوانی نداشته باشد؛ این اتفاق معمولاً زمانی رخ میدهد که فایلی بدون اطلاع Nextcloud مستقیماً در دایرکتوری دادهها نوشته شده باشد. در این وضعیت، فایلی روی دیسک وجود دارد که در رابط کاربری وب نمایش داده نمیشود یا اندازه یک پوشه اشتباه گزارش میشود که occ files:scan راه حل آن است. دو نقطه ضعف دیگر این سرویس، سرعت پروتکل در مواجهه با تعداد زیادی فایل کوچک است که با هیچ مقدار CPU قابل اصلاح نیست، و همچنین محدودیت حافظه PHP؛ پیشنمایش تصاویر و ویدیوهای بزرگ معمولاً باعث جهش ناگهانی مصرف حافظه میشود، بنابراین برای هر پردازش 512 MB حافظه در نظر بگیرید و تولید پیشنمایشها را به جای زمان درخواست کاربر، به یک job زمانبندیشده بسپارید.
هیچکدام: Syncthing، اگر فقط همگامسازی فایل میخواهید
اگر نیاز واقعی شما آینهسازی یک پوشه بین چند دستگاه است، هر دو محصول بیش از حد نیاز شما هستند. Syncthing هیچ سرور یا حساب کاربری ندارد. هر دستگاه یک peer است و یک VPS به peerای تبدیل میشود که هنگام خواب لپتاپ شما، روشن میماند. 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 tunnel از لپتاپ خود به آن دسترسی پیدا کنید:
ssh -L 8384:127.0.0.1:8384 youruser@your-serverسپس http://127.0.0.1:8384 را در لپتاپ باز کنید. خود Sync از پورت 22000 روی TCP و QUIC استفاده میکند و کشف محلی (local discovery) از UDP 21027 استفاده میکند که در اینترنت کاری انجام نمیدهد. روی یک VPS، پورت 22000 را باز کنید و رابط کاربری را بسته نگه دارید:
sudo ufw allow 22000/tcp
sudo ufw allow 22000/udpآنچه از دست میدهید تمام ویژگیهای سروری است: هیچ لینک اشتراکگذاری برای افرادی که Syncthing ندارند، هیچ مرورگر فایل تحت وب، هیچ حساب کاربری و هیچ سطل زباله سمت سرور وجود ندارد، مگر اینکه نسخهبندی فایل (file versioning) را برای هر پوشه فعال کنید. غافلگیری کلاسیک، فایل conflict است. اگر یک فایل را روی دو دستگاه در حالی که نمیتوانند یکدیگر را ببینند ویرایش کنید، یک فایل همزاد با نامی شبیه به notes.sync-conflict-20260806-142233-ABCD1EF.md ایجاد میشود. هیچ هشداری دریافت نمیکنید، بنابراین هر از گاهی برای sync-conflict جستجو کنید.
اگر آنچه میخواهید یک پوشه همگامسازیشده نیست، بلکه یک bucket است که برنامهها در آن مینویسند، این ابزار متفاوتی است: به ذخیرهسازی شیء سازگار با S3 به صورت self-hosted مراجعه کنید. برای حوزه گستردهتر، بررسی جایگزینهای Dropbox به صورت self-hosted مواردی را که در این مقایسه نیامدهاند، پوشش میدهد.
قانون تصمیمگیری
- اگر وظیفه مورد نظر همگامسازی در مقیاس بزرگ است (تعداد زیاد فایل، فایلهای حجیم، چندین دستگاه) و میپذیرید که دادهها در مخزنی ذخیره شوند که فقط توسط Seafile قابل خواندن است، Seafile را انتخاب کنید.
- اگر وظیفه مورد نظر ایجاد یک پلتفرم است (تقویمها، مخاطبین، اسناد و لینکهای اشتراکگذاری) و میخواهید فایلها به صورت خام روی دیسک باشند تا هر ابزار پشتیبانگیری بتواند آنها را بخواند، Nextcloud را انتخاب کنید.
- اگر وظیفه مورد نظر صرفاً ایجاد یک پوشه آینهای (mirrored folder) است و هیچ چیز دیگری نیاز ندارید، Syncthing را انتخاب کنید.
در انتخاب خود دقت کنید، زیرا مهاجرت بین Seafile و Nextcloud عامل اصلی وابستگی به نرمافزار (lock-in) است. هیچ مبدلی برای این کار وجود ندارد. شما باید همه چیز را با یک کلاینت همگامسازی کرده، در سرور دیگر آپلود کنید و هزینه آن را از نظر پهنای باند و زمان بپردازید؛ در حالی که تاریخچه نسخهها و لینکهای اشتراکگذاری از دست میروند. انتخاب هوشمندانه برای 3 سال آینده، بسیار ارزانتر از تغییر سرویس در سال دوم است.
FAQ
آیا Seafile برای همگامسازی کتابخانههای بزرگ سریعتر از Nextcloud است؟
بله، در دو موردی که معمولاً باعث کندی میشوند، این موضوع صادق است و دلیلی دارد که میتوانید آن را بررسی کنید. Seafile فایلها را به بلوکهایی با میانگین حدود 8 مگابایت تقسیم میکند و فقط بلوکهای تغییریافته را انتقال میدهد؛ بنابراین یک ویرایش در داخل یک فایل بزرگ، فقط چند بلوک را جابهجا میکند. واحد انتقال در Nextcloud کل فایل است، بنابراین همان ویرایش باعث آپلود مجدد کل فایل میشود. همچنین هر فایل کوچک حداقل یک درخواست WebDAV ایجاد میکند، به همین دلیل است که API آپلود انبوه آن، فایلهای کوچک را دستهبندی میکند. پیش از تصمیمگیری نهایی، هر دو را روی VPS خود تست کنید، زیرا CPU، دیسک و لینک شبکه شما به اندازه پروتکل اهمیت دارند.
آیا میتوانم با اجرای rsync روی دایرکتوری داده، از Seafile بکآپ بگیرم؟
فقط همراه با دیتابیسها و با رعایت ترتیب مستندشده. راهنمای Seafile میگوید ابتدا از SQL بکآپ بگیرید و سپس از دایرکتوری داده، زیرا در این صورت هر رکورد دیتابیس به شیئی اشاره میکند که در بکآپ وجود دارد. دستور rsync -az /opt/seafile-data/seafile /backup/data/ فایلهای conf، seafile-data و seahub-data را کپی میکند، اما به تنهایی قابل بازیابی نیست، زیرا ذخیرهساز اشیاء (object store) فاقد ساختار درختی فایل قابل خواندن است و دیتابیس، ایندکس آن محسوب میشود. پس از بازیابی هر دو بخش، دستور seaf-fsck.sh را اجرا کنید و پیش از اعتماد به نتیجه، خروجی آن را بخوانید.
اگر فقط همگامسازی فایل میخواهم، آیا به Nextcloud نیاز دارم؟
خیر. Nextcloud یک پلتفرم است و تقویم، مخاطبین و فروشگاه اپلیکیشن آن، چه از آنها استفاده کنید و چه نکنید، حافظه مصرف میکنند و نیاز به مراقبت هنگام ارتقا دارند. برای همگامسازی ساده فایل، Seafile محصول سبکتری با پروتکل سریعتر است و Syncthing حتی از آن هم سبکتر است، زیرا سمت سرور برای اجرا ندارد. زمانی Nextcloud را انتخاب کنید که به اپلیکیشنهای اضافی آن نیاز دارید، نه به عنوان انتخاب پیشفرض.
آیا کتابخانه رمزگذاریشده Seafile نام فایلهای من را مخفی میکند؟
خیر. یک کتابخانه رمزگذاریشده، محتوای فایلها را در سمت کلاینت رمزگذاری میکند و رمز عبور هرگز به سرور نمیرسد، اما نام پوشهها، نام فایلها، اندازه فایلها و تاریخچه ویرایشها همگی روی سرور قابل مشاهده باقی میمانند. باز کردن یک کتابخانه رمزگذاریشده در رابط وب نیز رمز عبور را به سرور میفرستد؛ سرور کلید فایل را رمزگشایی کرده و رمز عبور را به مدت یک ساعت در حافظه نگه میدارد. اگر خودِ نامها حساس هستند، آن کتابخانه را از رابط وب دور نگه دارید و در لایهای دیگر رمزگذاری کنید.
برای Seafile یا Nextcloud روی یک VPS چقدر رم اختصاص دهم؟
برای هر کدام با تعداد کمی کاربر، با 4 گیگابایت رم و 2 هسته CPU شروع کنید و سپس هنگام تولید پیشنمایش و جستجو، میزان حافظه را زیر نظر بگیرید. مستندات خودِ Seafile حداقل 2 گیگابایت رم و یک CPU دو هستهای با فرکانس بالای 2 گیگاهرتز را تعیین کردهاند. Nextcloud برای هر پردازش PHP، مقدار 512 مگابایت را توصیه میکند که باید آن را در تعداد workerها ضرب کرده و سپس دیتابیس و کش را به آن اضافه کنید. Syncthing به راحتی با 1 گیگابایت رم اجرا میشود.