Seafile বনাম Nextcloud: ফাইল সিঙ্কিংয়ের জন্য কোনটি সেরা?

Seafile বনাম Nextcloud: সংক্ষিপ্ত উত্তর

Seafile এবং Nextcloud-এর মধ্যে মূল পার্থক্য হলো: সার্ভারে ফাইল পৌঁছানোর পর সেটি কীভাবে সংরক্ষিত হয়। Seafile প্রতিটি ফাইলকে ছোট ছোট ব্লকে বিভক্ত করে এবং এমন একটি অবজেক্ট স্টোরে রাখে যা শুধুমাত্র Seafile-ই পড়তে পারে; ফলে সিঙ্কিং দ্রুত হয় এবং ব্যাকআপের কাজটি দুটি ধাপে সম্পন্ন করতে হয়। অন্যদিকে, Nextcloud আপনার ফাইলটিকে সরাসরি ডিস্কে একটি ফাইল হিসেবেই সংরক্ষণ করে। এটি সিঙ্কিংকে একটি প্ল্যাটফর্মের ফিচার হিসেবে বিবেচনা করে, যেখানে ক্যালেন্ডার, কন্টাক্ট, ডকুমেন্ট এবং শেয়ার লিঙ্কের মতো অন্যান্য সুবিধাও থাকে। এই পার্থক্যের ওপর ভিত্তি করেই সিদ্ধান্ত নিন, কারণ বাকি সবকিছুই এর ওপর নির্ভর করে।

আগস্ট 2026 অনুযায়ী, Seafile 13.0 সিরিজে এবং Nextcloud 34 সিরিজে রয়েছে। উভয়ই বেশ পরিপক্ক এবং কোনোটিই তাদের স্টোরেজ মডেলে কোনো পরিবর্তন আনছে না।

Seafile যেভাবে আপনার ফাইল সংরক্ষণ করে

Seafile একটি লাইব্রেরিকে ঠিক সেভাবে মডেল করে যেভাবে git একটি রিপোজিটরিকে মডেল করে। অ্যাডমিন ম্যানুয়ালে অভ্যন্তরীণ মডেল হিসেবে Repo, Commit, FS এবং Block-এর কথা উল্লেখ করা হয়েছে এবং বলা হয়েছে যে একটি রিপোজিটরিকে লাইব্রেরিও বলা হয়। প্রতিটি ফাইলকে কন্টেন্ট-ভিত্তিক চাঙ্কিং (CDC, একটি অ্যালগরিদম যা ডেটা থেকেই ব্লকের সীমানা নির্ধারণ করে) ব্যবহার করে পরিবর্তনশীল দৈর্ঘ্যের ব্লকে বিভক্ত করা হয়। ম্যানুয়াল অনুযায়ী, একটি ব্লকের গড় আকার প্রায় 8 MB। ব্লকগুলোর নামকরণ করা হয় সেগুলোর বিষয়বস্তুর ওপর ভিত্তি করে, তাই একটি বড় ফাইলের দুটি সংস্করণ অপরিবর্তিত থাকা প্রতিটি ব্লক শেয়ার করে এবং দুটি ভিন্ন লাইব্রেরিও অভিন্ন ব্লকগুলো শেয়ার করতে পারে।

রিলেশনাল ডেটাবেসে লাইব্রেরি সম্পর্কে খুব সামান্য মেটাডেটা থাকে। বাকি সবকিছু, অর্থাৎ কমিট, ডিরেক্টরি অবজেক্ট এবং ব্লকগুলো ডেটা ডিরেক্টরির অধীনে থাকে। 12 এবং 13 সিরিজের Docker লেআউটে এটি হলো /opt/seafile-data/seafile/seafile-data। সেখানে ls কমান্ডটি চালালে কোনো কার্যকর তথ্য পাওয়া যায় না, কারণ আপনি সেখানে Invoices/2026/march.pdf-এর পরিবর্তে হ্যাশ নামযুক্ত ডিরেক্টরি দেখতে পাবেন।

সিঙ্ক (Sync) প্রক্রিয়াটিও একই মডেল অনুসরণ করে। ক্লায়েন্ট সার্ভারকে জিজ্ঞাসা করে কী পরিবর্তন হয়েছে, তারপর ব্লক হ্যাশের একটি তালিকা গ্রহণ করে এবং শুধুমাত্র সেই ব্লকগুলো সংগ্রহ করে যা তার কাছে আগে থেকে নেই। এই কারণেই Seafile বড় লাইব্রেরির ক্ষেত্রেও কার্যকর থাকে: স্থানান্তরিত বাইটের পরিমাণ শুধুমাত্র পরিবর্তিত ব্লকের সমানুপাতিক, পুরো ফাইলের আকারের ওপর তা নির্ভর করে না।

Nextcloud যেভাবে আপনার ফাইল সংরক্ষণ করে

Nextcloud ফাইলগুলোকে ডিস্কে এমনভাবে রাখে যা আপনি প্রত্যাশা করেন। data/<username>/files/ পাথটি ওয়েব ইন্টারফেসে ব্যবহারকারী যা দেখেন তার প্রতিফলন ঘটায়। oc_filecache নামক একটি ডাটাবেস টেবিল একই ফাইল কাঠামোকে ফাইলের আকার, পরিবর্তনের সময় এবং etag-সহ সংরক্ষণ করে, এবং Nextcloud ডিস্কের চেয়ে এই টেবিলটিকে বেশি নির্ভরযোগ্য মনে করে।

ডেস্কটপ ক্লায়েন্ট HTTPS-এর মাধ্যমে WebDAV (web distributed authoring and versioning) প্রোটোকল ব্যবহার করে। প্রতিটি ফাইলের জন্য অন্তত একটি রিকোয়েস্ট প্রয়োজন হয়, আর এই কারণেই Nextcloud একটি bulk upload API যুক্ত করেছে: ডেভেলপার ম্যানুয়াল অনুযায়ী, অনেকগুলো ছোট ফাইল আপলোড করা ধীরগতির হতে পারে কারণ এতে নেটওয়ার্ক ব্যান্ডউইথ পুরোপুরি ব্যবহৃত হয় না, তাই ছোট ফাইলগুলোকে একসাথে প্যাক করা হয়। বড় ফাইলগুলো chunking API-এর মাধ্যমে পাঠানো হয় এবং ডেস্কটপ ক্লায়েন্টের ডিফল্ট chunk সাইজ হলো 5 MiB (OWNCLOUD_CHUNK_SIZE ডিফল্টভাবে 5242880 বাইট)।

ডিস্কে ফাইল রাখার সুবিধা হলো, আপনার কাছে থাকা যেকোনো টুল দিয়ে আপনি আপনার ডাটা পড়তে পারবেন। এর অসুবিধা হলো, Nextcloud-এর অগোচরে কোনো পরিবর্তন করা হলে তা সিস্টেম বুঝতে পারে না। আপনি যদি সরাসরি ডাটা ডিরেক্টরিতে ফাইল কপি করেন, তবে যতক্ষণ না আপনি স্ক্যান করছেন, ততক্ষণ সেগুলো ওয়েব ইন্টারফেসে দেখা যাবে না:

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

অ্যাডমিন ম্যানুয়ালে ঠিক এই ক্ষেত্রগুলোর জন্যই rescan করার কথা বলা হয়েছে: সরাসরি ডাটা ডিরেক্টরিতে ফাইল কপি করার পর, মাইগ্রেশনের পর এবং যখন আপনি ফাইল ক্যাশে কোনো অসামঞ্জস্যতা তদন্ত করছেন।

কোনটি বড় লাইব্রেরি দ্রুত সিঙ্ক করে?

Seafile, বিশেষ করে দুটি ক্ষেত্রে যা পারফরম্যান্সে প্রভাব ফেলে: হাজার হাজার ছোট ফাইল এবং বড় ফাইলে বারবার পরিবর্তন। এর কার্যপদ্ধতি হলো ব্লক-লেভেল ডিডুপ্লিকেশন (block level deduplication), তাই 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) লেখে, তাই আপলোড মাঝপথে বাধাগ্রস্ত হলেও লাইব্রেরিটি অসম্পূর্ণ না থেকে আগের কমিটেই অক্ষত থাকে।

একটি ছোট VPS-এ প্রতিটি অ্যাপের যা প্রয়োজন

Seafile-এর ডকুমেন্টেশনে "কমপক্ষে 2G RAM এবং 2-core 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 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 RAM এবং 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, MySQL রুট ও ডাটাবেস পাসওয়ার্ড, প্রাথমিক অ্যাডমিন অ্যাকাউন্ট এবং JWT_PRIVATE_KEY সেট করুন। ম্যানুয়াল অনুযায়ী এই কী-এর জন্য কমপক্ষে 32 অক্ষরের একটি র‍্যান্ডম স্ট্রিং প্রয়োজন। এটি প্রথমবার চালু হওয়ার সময় পড়া হয়, তাই স্ট্যাকটি আপ করার আগেই এটি জেনারেট করে নিন:

openssl rand -base64 40
docker compose up -d

প্রথমবার চালু হওয়ার সময় তিনটি ডাটাবেস এবং অ্যাডমিন ইউজার তৈরি হয়। TLS এবং রিভার্স প্রক্সি সহ Nextcloud-এর সমতুল্য সিদ্ধান্তগুলো Docker, TLS এবং ব্যাকআপ সহ Nextcloud অন VPS গাইড-এ বিস্তারিত আলোচনা করা হয়েছে।

ব্যাকআপের মধ্যে পার্থক্য কী?

এটি এমন একটি বিষয় যা মানুষ অবমূল্যায়ন করে, এবং এখানেই দুটি প্রোডাক্টের মধ্যে সবচেয়ে বেশি পার্থক্য দেখা যায়।

Seafile-এর ক্ষেত্রে এই ক্রমটি ঐচ্ছিক নয়। ম্যানুয়ালের নিয়ম হলো প্রথমে SQL ব্যাকআপ নেওয়া এবং তারপরে data directory ব্যাকআপ নেওয়া। কারণ এতে ডাটাবেসের প্রতিটি রেকর্ডের জন্য একটি বৈধ অবজেক্ট রেফারেন্স হিসেবে থাকে, ফলে লাইব্রেরিগুলো ক্ষতিগ্রস্ত হয় না। যদি এর উল্টোটা করেন, তবে ডাটাবেসের একটি সারি এমন কোনো ব্লককে নির্দেশ করতে পারে যা আপনার স্ন্যাপশটে কখনোই ক্যাপচার করা হয়নি।

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 ব্যবহার করুন, কারণ Seafile যে MariaDB ইমেজ সরবরাহ করে তাতে mysql সিরিজের কমান্ডগুলো এখন আর ব্যবহৃত হয় না (deprecated)। যখন কোনো ফাইলে রিডাইরেক্ট করবেন, তখন docker exec থেকে -t ফ্ল্যাগটি বাদ দিন, কারণ TTY লাইন এন্ডিংগুলো নতুন করে লিখে ফেলে এবং ডাম্পটিকে নষ্ট করে দেয়।

দুটি অংশ আলাদাভাবে ক্যাপচার করা হয়, তাই এগুলোর মধ্যে সময়ের পার্থক্য (drift) তৈরি হতে পারে। যেকোনো রিস্টোরের পর, স্টোরটিকে বিশ্বাস করার আগে অবশ্যই পরীক্ষা করে নিন:

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-এর ক্ষেত্রেও একই দুই অংশের সমস্যা ভিন্নভাবে দেখা দেয়, কারণ data directory এবং ডাটাবেসকে অবশ্যই একই ট্রি (tree) বর্ণনা করতে হবে:

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 ফোল্ডার, যেকোনো কাস্টম অ্যাপ এবং আপনার থিম, সেই সাথে ডাম্প ফাইলটি সংরক্ষণ করুন। উভয় অংশই একই সময়ের পয়েন্ট থেকে রিস্টোর করুন। যদি data directory ডাটাবেসের চেয়ে নতুন হয়, তবে ব্যবহারকারীরা এমন ফাইল দেখতে পাবেন যা ফাইল ক্যাশে জানে না, এবং occ files:scan --all তা মেরামত করে। যদি ডাটাবেস নতুন হয়, তবে ক্যাশ সারিগুলো এমন ফাইলকে নির্দেশ করে যা আর নেই, এবং occ files:cleanup এমন ক্যাশ এন্ট্রিগুলো মুছে ফেলে যার কোনো মিল স্টোরেজ টেবিলে নেই।

যাই হোক, আপনার এমন একটি ব্যাকআপ প্রোগ্রাম প্রয়োজন যা অনেক ছোট ছোট ফাইল নিয়ে কাজ করতে পারে এবং হিস্ট্রি বজায় রাখে, যা restic এবং BorgBackup ভিন্নভাবে করে।

ডেস্কটপ এবং মোবাইলে ক্লায়েন্ট

Seafile দুটি ডেস্কটপ প্রোগ্রাম সরবরাহ করে। সিঙ্কিং ক্লায়েন্ট আপনার নির্বাচিত লাইব্রেরিগুলোর একটি লোকাল কপি রাখে। ড্রাইভ ক্লায়েন্ট (SeaDrive) আপনার লাইব্রেরিগুলোকে একটি ভার্চুয়াল ড্রাইভ হিসেবে মাউন্ট করে এবং প্রয়োজনের সময় ফাইল ডাউনলোড করে: Windows-এ এটি Microsoft-এর cloud files API ব্যবহার করে, macOS-এ 3.0 সংস্করণটি একটি Finder extension, এবং Linux-এ 3.0.12 সংস্করণ থেকে এটি AppImage হিসেবে আসে এবং ~/SeaDrive পাথে মাউন্ট হয়। এনক্রিপ্ট করা লাইব্রেরিগুলো তিনটি ডেস্কটপ প্ল্যাটফর্মেই কাজ করে। মোবাইল অ্যাপগুলো মূলত ফাইল অ্যাক্সেস করার জন্য তৈরি, এবং সেগুলো কেবল সেই কাজটিই করে।

Nextcloud-এর ডেস্কটপ ক্লায়েন্টও ভার্চুয়াল ফাইল সুবিধা দেয় এবং এর মোবাইল অ্যাপগুলো পুরো প্ল্যাটফর্মের সুবিধা বহন করে, তাই ফাইল অ্যাক্সেসের পাশাপাশি ক্যালেন্ডার, কন্টাক্টস, Talk এবং নোটসও পাওয়া যায়। যদি আপনার ব্যবহারকারীরা ফোনে বেশি সক্রিয় থাকেন এবং ফাইলের বাইরেও আরও কিছু চান, তবে দৈনন্দিন ব্যবহারের ক্ষেত্রে এটি একটি বড় পার্থক্য।

Seafile-এর একটি বিষয় পরিকল্পনার দাবি রাখে: লাইব্রেরি হলো শেয়ারিং, সিঙ্ক, পারমিশন এবং এনক্রিপশনের একক ইউনিট। 500 GB ডেটা একটি লাইব্রেরিতে লোড করার আগেই আপনার লাইব্রেরি লেআউট ঠিক করে নিন। কারণ এক লাইব্রেরি থেকে অন্য লাইব্রেরিতে ফাইল সরানো মানে হলো ফাইল কপি করা এবং ডিলিট করা, এটি কোনো রিনেম অপারেশন নয়; তাই ফাইলের হিস্ট্রি নতুন লাইব্রেরিতে স্থানান্তরিত হয় না।

এনক্রিপশন: প্রতিটি আসলে কী সুরক্ষা দেয়

Seafile-এর এনক্রিপ্টেড লাইব্রেরিগুলো ক্লায়েন্ট সাইডে কাজ করে। পাসওয়ার্ড কখনোই সার্ভারে সংরক্ষণ করা হয় না। পাসওয়ার্ড এবং লাইব্রেরি আইডি থেকে তৈরি একটি ম্যাজিক টোকেন লাইব্রেরির সাথে জমা থাকে, যাতে সিঙ্ক করার আগে ক্লায়েন্ট পাসওয়ার্ডটি যাচাই করতে পারে। ফাইল কি (file key) AES 256/CBC ব্যবহার করে আপনার পাসওয়ার্ড থেকে প্রাপ্ত একটি কি এবং IV (initialisation vector) দিয়ে এনক্রিপ্ট করা হয় এবং ফাইলের ডেটা সেই ফাইল কি দিয়ে এনক্রিপ্ট করা থাকে।

ডকুমেন্টেড সীমাবদ্ধতাগুলো পড়ে দেখুন, কারণ অনেকেই এগুলো এড়িয়ে যায়। একটি এনক্রিপ্টেড লাইব্রেরি শুধুমাত্র ফাইলের বিষয়বস্তু এনক্রিপ্ট করে। ফোল্ডার ও ফাইলের নাম এনক্রিপ্ট করা হয় না, এমনকি ফাইলের আকার বা এডিট হিস্ট্রিও এনক্রিপ্ট হয় না। ওয়েব ব্রাউজারে এনক্রিপ্টেড লাইব্রেরি ব্রাউজ করা এন্ড-টু-এন্ড নয়: আপনি পাসওয়ার্ড টাইপ করলে সার্ভার তা ব্যবহার করে ফাইল কি ডিক্রিপ্ট করে এবং পাসওয়ার্ডটি এক ঘণ্টার জন্য মেমরিতে ক্যাশ করে রাখে। ম্যানুয়ালে স্পষ্টভাবে বলা আছে যে, এনক্রিপ্টেড লাইব্রেরি ডেটার অখণ্ডতা (integrity) নিশ্চিত করে না, কারণ সার্ভার অ্যাডমিন ফাইলের বিষয়বস্তুর কোনো অংশ পরিবর্তন করলে ক্লায়েন্ট তা শনাক্ত করতে পারে না।

Nextcloud-এ বিভ্রান্তিকরভাবে একই রকম নামের দুটি ফিচার আছে। Server side encryption ফাইলগুলোকে স্টোরেজে থাকা অবস্থায় এনক্রিপ্ট করে কিন্তু কি (key) একই সার্ভারে রাখে, তাই এটি এক্সটার্নাল স্টোরেজে থাকা ডেটার জন্য ভালো সুরক্ষা দিলেও সার্ভারে root অ্যাক্সেস থাকা কারো হাত থেকে আপনাকে খুব একটা সুরক্ষা দেয় না। End to end encryption অ্যাপটি ক্লায়েন্টে নির্বাচিত ফোল্ডারগুলোকে এনক্রিপ্ট করে এবং ডিজাইনের কারণেই সার্ভার সেগুলো পড়তে পারে না, তাই ওয়েব ইন্টারফেস, সার্ভার সাইড সার্চ এবং প্রিভিউগুলোও সেই ফোল্ডারগুলোর ভেতরে দেখতে পায় না।

কোনো প্রোডাক্টের এনক্রিপশনই এনক্রিপ্টেড ব্যাকআপের বিকল্প নয়। ব্যাকআপকে আলাদাভাবে এনক্রিপ্ট করুন।

ক্যালেন্ডার, কন্টাক্ট, অফিস এবং অ্যাপ প্ল্যাটফর্ম

এই দিকটি সুনির্দিষ্ট নয়। Nextcloud-এর কোরে CalDAV (WebDAV-এর মাধ্যমে ক্যালেন্ডার) এবং CardDAV (WebDAV-এর মাধ্যমে কন্টাক্ট) অন্তর্ভুক্ত থাকে। এটি ডকুমেন্ট সম্পাদনার জন্য Collabora বা OnlyOffice-এর সাথে ইন্টিগ্রেট করা যায় এবং অন্যান্য সবকিছুর জন্য এতে একটি অ্যাপ স্টোর রয়েছে। Seafile 13-এ কোলাবোরেটিভ ডকুমেন্ট এবং উইকি পেজের জন্য SeaDoc রয়েছে, তবে এর বাইরে আর কোনো সুবিধা নেই। এতে কোনো ক্যালেন্ডার বা অ্যাড্রেস বুক নেই।

এই প্ল্যাটফর্ম ব্যবহারের একটি মূল্য আছে, আর তা হলো আপগ্রেড। আপনি যত বেশি অ্যাপ ইনস্টল করবেন, Nextcloud আপগ্রেডের সময় তত বেশি জটিলতা তৈরি হতে পারে বা আপগ্রেডের পর অ্যাপগুলো সঠিকভাবে কাজ নাও করতে পারে। তাই ব্যবহারকারীরা যত বেশি ফিচারের ওপর নির্ভরশীল হবেন, আপগ্রেডের সময় আপনাকে তত বেশি সতর্ক থাকতে হবে। Seafile-এর কাজের পরিধি কম হওয়ায় এতে সমস্যা হওয়ার সম্ভাবনাও কম। এছাড়া মনে রাখবেন, Seafile-এর Community Edition-এ নয়, বরং Professional সংস্করণে পেইড লাইসেন্সের মাধ্যমে ডকুমেন্টের ভেতর ফুল টেক্সট সার্চ এবং ফোল্ডার লেভেল পারমিশনের মতো সুবিধা পাওয়া যায়। তাই আপনি যে সংস্করণে কাজ করতে চান, তাতে আপনার প্রয়োজনীয় ফিচারগুলো আছে কি না তা নিশ্চিত হয়ে নিন।

প্রতিটি সার্ভিসের পরিচিত ব্যর্থতার ধরন

Seafile ব্যর্থ হয় যখন ডাটাবেস এবং অবজেক্ট স্টোর একে অপরের থেকে বিচ্ছিন্ন হয়ে যায়। আপনি এমন একটি লাইব্রেরি দেখতে পাবেন যা খুলছে না, অথবা ফাইল হারিয়ে যাচ্ছে, এবং seaf-fsck.sh কমান্ডটি অনুপস্থিত ব্লকের তথ্য প্রদর্শন করবে। এখানে হাতে মেরামত করার মতো কোনো ফাইল ট্রি নেই, তাই পুনরুদ্ধারের একমাত্র উপায় হলো আপনার ডাটাবেস ডাম্প এবং অবজেক্ট স্টোরকে সঠিক ক্রমে রিস্টোর করা। একটি অতিরিক্ত VPS-এ এই রিস্টোর প্রক্রিয়াটি অন্তত একবার পরীক্ষা করুন, কারণ যে ব্যাকআপ আপনি কখনো রিস্টোর করে দেখেননি, তা কেবল একটি অনুমান মাত্র।

Nextcloud ব্যর্থ হয় যখন ফাইল ক্যাশ এবং ডিস্কের তথ্যের মধ্যে অমিল দেখা দেয়, সাধারণত যখন Nextcloud-কে না জানিয়েই কেউ সরাসরি ডাটা ডিরেক্টরিতে কিছু লিখে ফেলে। আপনি ডিস্কে এমন ফাইল দেখতে পাবেন যা ওয়েব ইন্টারফেসে তালিকাভুক্ত নয়, অথবা কোনো ফোল্ডারের আকার ভুল দেখাবে, এবং occ files:scan কমান্ডটি এর সমাধান হিসেবে কাজ করে। এর অন্য দুটি দুর্বল দিক হলো অনেক ছোট ফাইলের ক্ষেত্রে প্রোটোকলের গতি, যা কোনো CPU দিয়েই বাড়ানো সম্ভব নয়, এবং PHP মেমোরি: বড় ছবি ও ভিডিওর প্রিভিউ তৈরির সময় সাধারণত মেমোরির চাহিদা বেড়ে যায়, তাই প্রতি প্রসেসের জন্য 512 MB মেমোরি বরাদ্দ রাখুন এবং প্রিভিউ তৈরির কাজটি সরাসরি রিকোয়েস্টের সময় না করে একটি শিডিউলড জব হিসেবে সম্পন্ন করুন।

কোনটিই নয়: শুধুমাত্র ফাইল সিঙ্ক করতে চাইলে Syncthing ব্যবহার করুন

যদি আপনার প্রকৃত প্রয়োজন হয় দুটি মেশিনের মধ্যে একটি ফোল্ডার মিরর করা, তবে এই দুটি প্রোডাক্টই আপনার প্রয়োজনের তুলনায় অনেক বেশি ভারী। Syncthing-এর কোনো সার্ভার বা অ্যাকাউন্টের প্রয়োজন হয় না। প্রতিটি ডিভাইস এখানে একটি পিয়ার (peer), এবং আপনার ল্যাপটপ স্লিপ মোডে থাকলেও একটি 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 হিসেবে নয়, যাতে এটি যে ফাইলগুলো তৈরি করে তার মালিকানা (ownership) সঠিক থাকে:

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 নিজে TCP এবং QUIC-এর মাধ্যমে 22000 পোর্ট ব্যবহার করে এবং লোকাল ডিসকভারির জন্য UDP 21027 পোর্ট ব্যবহার করে, যা ইন্টারনেটের মাধ্যমে কাজ করে না। VPS-এর ক্ষেত্রে, শুধুমাত্র 22000 পোর্ট ওপেন রাখুন এবং ইন্টারফেসটি বন্ধ রাখুন:

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

এখানে আপনি যা হারাবেন তা হলো সার্ভারের সব ফিচার: যারা Syncthing ব্যবহার করে না তাদের জন্য কোনো শেয়ার লিঙ্ক নেই, কোনো ওয়েব ফাইল ব্রাউজার নেই, কোনো ইউজার অ্যাকাউন্ট নেই এবং সার্ভার সাইডে কোনো ট্র্যাশ (trash) নেই, যদি না আপনি প্রতি ফোল্ডারে ফাইল ভার্সনিং (file versioning) চালু করেন। একটি সাধারণ চমক হলো কনফ্লিক্ট ফাইল। দুটি ডিভাইসে একই ফাইল এডিট করলে এবং তারা একে অপরের সাথে সংযুক্ত না থাকলে, আপনি notes.sync-conflict-20260806-142233-ABCD1EF.md নামে একটি ফাইল পাবেন। এটি নিয়ে কোনো সতর্কতা দেওয়া হয় না, তাই মাঝে মাঝে sync-conflict লিখে সার্চ করুন।

যদি আপনার সিঙ্ক করা ফোল্ডারের পরিবর্তে এমন একটি বাকেট (bucket) প্রয়োজন হয় যেখানে অ্যাপ্লিকেশনগুলো ডেটা রাইট করবে, তবে সেটি ভিন্ন একটি টুল: দেখুন self-hosted S3 compatible object storage। আরও বিস্তারিত জানতে, the roundup of self-hosted Dropbox alternatives দেখুন, যেখানে এই তুলনার বাইরে থাকা অন্যান্য বিকল্পগুলো আলোচনা করা হয়েছে।

সিদ্ধান্ত গ্রহণের নিয়ম

1. যদি আপনার কাজের ধরন হয় ফাইলের আকার অনুযায়ী সিঙ্ক করা (যেমন: অনেক ফাইল, বড় ফাইল, একাধিক ডিভাইস) এবং আপনি এমন একটি ডেটা স্টোর গ্রহণ করতে পারেন যা শুধুমাত্র Seafile-ই পড়তে পারে, তবে Seafile বেছে নিন।
2. যদি আপনার কাজের ধরন হয় একটি প্ল্যাটফর্ম হিসেবে ব্যবহার করা (যেমন: ক্যালেন্ডার, কন্টাক্ট, ডকুমেন্ট এবং শেয়ার লিঙ্ক) এবং আপনি চান ফাইলগুলো ডিস্কে সাধারণ ফরম্যাটে থাকুক যা যেকোনো ব্যাকআপ টুল পড়তে পারে, তবে Nextcloud বেছে নিন।
3. যদি আপনার কাজের ধরন শুধুমাত্র একটি ফোল্ডার মিরর করা হয় এবং অন্য কিছু না হয়, তবে Syncthing বেছে নিন।

এখনই সতর্কতার সাথে সিদ্ধান্ত নিন, কারণ Seafile এবং Nextcloud-এর মধ্যে মাইগ্রেশন করাটাই আসল সীমাবদ্ধতা। এর কোনো কনভার্টার নেই। আপনাকে সবকিছু ক্লায়েন্টে সিঙ্ক করে নামাতে হবে, অন্য সার্ভারে আপলোড করতে হবে এবং ব্যান্ডউইথ ও সময়ের বিনিময়ে তা করতে হবে, যেখানে ভার্সন হিস্ট্রি এবং শেয়ার লিঙ্কগুলো হারিয়ে যাবে। দুই বছর পর পরিবর্তন করার চেয়ে আজকের সিদ্ধান্তটি আগামী তিন বছরের জন্য বিবেচনা করা অনেক সাশ্রয়ী।

FAQ

বড় লাইব্রেরি সিঙ্ক করার ক্ষেত্রে কি Nextcloud-এর চেয়ে Seafile দ্রুত?

হ্যাঁ, সাধারণত যে দুটি ক্ষেত্রে সমস্যা হয়, সেখানে Seafile দ্রুত কাজ করে এবং এর কারণ আপনি যাচাই করতে পারবেন। Seafile ফাইলগুলোকে গড়ে প্রায় 8 MB ব্লকে বিভক্ত করে এবং শুধুমাত্র পরিবর্তিত ব্লকগুলোই স্থানান্তর করে, তাই একটি বড় ফাইলের ভেতরে কোনো পরিবর্তন করলে মাত্র কয়েকটি ব্লক ট্রান্সফার হয়। অন্যদিকে, Nextcloud পুরো ফাইলটি স্থানান্তর করে, ফলে একই পরিবর্তনের জন্য পুরো ফাইলটি পুনরায় আপলোড করতে হয়। এছাড়া অনেকগুলো ছোট ফাইলের ক্ষেত্রে প্রতিটি অন্তত একটি WebDAV রিকোয়েস্ট খরচ করে, যে কারণে এর বাল্ক আপলোড 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 লাইব্রেরি কি আমার ফাইলের নাম গোপন রাখে?

না। একটি এনক্রিপ্টেড লাইব্রেরি ক্লায়েন্ট সাইডে ফাইলের বিষয়বস্তু এনক্রিপ্ট করে এবং পাসওয়ার্ডটি কখনোই সার্ভারে পৌঁছায় না, কিন্তু ফোল্ডারের নাম, ফাইলের নাম, ফাইলের আকার এবং এডিট হিস্ট্রি সার্ভারে দৃশ্যমান থাকে। ওয়েব ইন্টারফেসে এনক্রিপ্টেড লাইব্রেরি খুললে পাসওয়ার্ডটি সার্ভারে পাঠানো হয়, যা ফাইল কি (key) ডিক্রিপ্ট করে এবং পাসওয়ার্ডটি এক ঘণ্টার জন্য মেমরিতে রাখে। যদি ফাইলের নামগুলো সংবেদনশীল হয়, তবে সেই লাইব্রেরিটি ওয়েব ইন্টারফেস থেকে দূরে রাখুন এবং অন্য কোনো স্তরে এনক্রিপশন ব্যবহার করুন।

VPS-এ Seafile বা Nextcloud-এর জন্য আমার কতটুকু RAM বরাদ্দ করা উচিত?

কয়েকজন ব্যবহারকারীর জন্য উভয়টির ক্ষেত্রেই 4 GB RAM এবং 2 টি কোর দিয়ে শুরু করুন, এরপর প্রিভিউ জেনারেশন এবং সার্চের সময় মেমরির ব্যবহার পর্যবেক্ষণ করুন। Seafile-এর নিজস্ব নথিপত্রে সর্বনিম্ন 2 GB RAM এবং 2 GHz-এর বেশি গতির 2 কোর CPU-এর কথা বলা হয়েছে। Nextcloud প্রতি PHP প্রসেসের জন্য 512 MB RAM-এর সুপারিশ করে, যা ডেটাবেস এবং ক্যাশ যোগ করার আগে ওয়ার্কার সংখ্যার সাথে গুণ করতে হয়। Syncthing 1 GB RAM-এ অনায়াসেই চলে।