Seafile की Nextcloud: फाइल sync साठी कोणते चांगले?

Seafile विरुद्ध Nextcloud: थोडक्यात उत्तर

Seafile विरुद्ध Nextcloud यातील मुख्य फरक असा आहे: फाइल सर्व्हरवर पोहोचल्यानंतर तिचे स्वरूप काय असते. Seafile प्रत्येक फाइलचे blocks मध्ये विभाजन करते आणि ते फक्त Seafile वाचू शकणाऱ्या object store मध्ये साठवते. त्यामुळे sync जलद होते; मात्र backup दोन भागांत करावे लागते. Nextcloud तुमची फाइल disk वर फाइल म्हणून लिहिते आणि sync ला अशा platform च्या एका feature प्रमाणे हाताळते, ज्यावर calendars, contacts, documents आणि share links देखील चालतात. हा फरक लक्षात घेऊन निर्णय घ्या; त्यानंतरचे सर्व परिणाम याच फरकातून ठरतात.

August 2026 पर्यंत, Seafile 13.0 series वर आणि Nextcloud 34 series वर आहे. दोन्ही mature आहेत आणि त्यांपैकी कोणतेही लवकरच आपले storage model बदलणार नाही.

Seafile तुमच्या फाइल्स कशा साठवते

Seafile मध्ये library ची रचना git मधील repository प्रमाणे केली जाते. Admin manual मध्ये अंतर्गत रचना Repo, Commit, FS आणि Block अशी दिली आहे. त्यात repo ला library असेही म्हटले आहे. Content-defined chunking (CDC; डेटामधूनच block च्या सीमा ठरवणारा algorithm) वापरून प्रत्येक file ला बदलत्या लांबीच्या blocks मध्ये विभागले जाते. Manual मध्ये block चा सरासरी आकार सुमारे 8 MB असल्याचे नमूद केले आहे. Blocks ना त्यांच्या contents वरून नावे दिली जातात. त्यामुळे मोठ्या file च्या दोन versions मध्ये न बदललेला प्रत्येक block समान राहतो. त्याचप्रमाणे दोन libraries मधील समान blocks देखील share केले जातात.

Relational database मध्ये libraries बद्दलचा थोडाच metadata साठवला जातो. बाकी सर्व, म्हणजे commits, directory objects आणि blocks, data directory अंतर्गत ठेवले जातात. 12 आणि 13 series मध्ये वापरल्या जाणाऱ्या Docker layout मध्ये ते /opt/seafile-data/seafile/seafile-data आहे. तेथे ls चालवून तुम्हाला उपयुक्त माहिती मिळणार नाही, कारण तुम्हाला hash names असलेल्या directories दिसतील; Invoices/2026/march.pdf दिसणार नाही.

Sync देखील याच model चे अनुसरण करते. Client server ला काय बदलले आहे ते विचारतो, block hashes ची यादी प्राप्त करतो आणि त्याच्याकडे आधीपासून नसलेले blocksच fetch करतो. त्यामुळे मोठ्या library साठी Seafile कार्यक्षम राहते: transfer होणाऱ्या bytes चे प्रमाण बदललेल्या blocks वर अवलंबून असते, त्या blocks असलेल्या file च्या आकारावर नाही.

Nextcloud तुमच्या फाइल्स कशा साठवते

Nextcloud फाइल तुम्हाला अपेक्षित असलेल्या ठिकाणी disk वर ठेवते. data/<username>/files/ हा path user ला web interface मध्ये दिसणाऱ्या रचनेशी जुळतो. oc_filecache ही database table त्याच tree ची प्रतिकृती ठेवते. त्यात size, modification time आणि etag असतात. Nextcloud disk ऐवजी या table वर विश्वास ठेवते.

Desktop client HTTPS वर WebDAV (web distributed authoring and versioning) वापरतो. प्रत्येक फाइलसाठी किमान एक request लागते. त्यामुळे Nextcloud ने bulk upload API जोडली. Developer manual नुसार अनेक लहान फाइल्स upload करणे अपेक्षेपेक्षा धीमे असते, कारण network bandwidth पूर्णपणे वापरली जात नाही. म्हणून लहान फाइल्स एकत्र pack केल्या जातात. मोठ्या फाइल्ससाठी chunking API वापरली जाते. Desktop client चा default chunk size 5 MiB आहे (OWNCLOUD_CHUNK_SIZE defaults to 5242880 bytes).

Disk वर फाइल्स ठेवण्याचा फायदा असा की तुमच्याकडे आधीपासून असलेले प्रत्येक tool तुमचा data वाचू शकते. मात्र त्याची किंमत अशी की Nextcloud च्या नकळत केलेले बदल त्याला दिसत नाहीत. फाइल्स थेट data directory मध्ये copy केल्यास त्या web interface मध्ये दिसत नाहीत. त्या दिसण्यासाठी scan चालवा:

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

Admin manual मध्ये rescan आवश्यक असलेल्या या परिस्थिती स्पष्टपणे दिल्या आहेत: फाइल्स थेट data directory मध्ये copy केल्यानंतर, migration नंतर आणि file cache मधील विसंगतींची चौकशी करताना.

मोठी लायब्ररी जलदपणे कोणते sync करते?

ज्या दोन परिस्थितींमध्ये अडचण येते, त्या दोन्हींमध्ये Seafile पुढे आहे: हजारो लहान फाइल्स आणि मोठ्या फाइल्समध्ये वारंवार केलेले बदल. यामागील यंत्रणा block-level deduplication आहे. त्यामुळे 4 GB disk image च्या मध्यभागी बदल झाला, तर फक्त काही blocks upload होतात. Nextcloud bulk upload मुळे लहान फाइल्समधील फरक कमी करते. मात्र मोठ्या फाइल्समधील फरक भरून काढता येत नाही, कारण तिचे transfer unit संपूर्ण फाइल असते.

हा फरक किती आहे यासाठी माझ्या शब्दांवर किंवा vendor benchmark वर अवलंबून राहू नका. तुमच्या लायब्ररीसारखी लायब्ररी तयार करा आणि लागणारा वेळ मोजा:

mkdir -p ~/synctest && cd ~/synctest
for i in $(seq 1 20000); do head -c 4096 /dev/urandom > "file_$i.bin"; done
du -sh ~/synctest

ती directory प्रत्येक server वरील synced folder मध्ये ठेवा आणि client चे काम पूर्ण होईपर्यंत monitor करा. वेगाइतकीच reliability देखील महत्त्वाची आहे. Seafile client आधी blocks upload करतो आणि त्यांचा संदर्भ देणारा commit शेवटी लिहितो. त्यामुळे upload मध्ये व्यत्यय आल्यास library अर्धवट लिहिलेल्या tree ऐवजी मागील commit वरच राहते.

लहान VPS वर प्रत्येकासाठी आवश्यक बाबी

Seafile च्या दस्तऐवजात "किमान 2G RAM आणि 2-core CPU (> 2GHz)" अशी आवश्यकता दिली आहे. Nextcloud मध्ये त्याऐवजी प्रत्येक PHP process साठी memory दिली आहे: किमान 128 MB आणि शिफारस केलेली 512 MB प्रति process. Worker count नुसार ही संख्या गुणून त्यात database, cache आणि preview generation साठी लागणारी memory जोडा. लहान टीमसाठी मी वापरेन असे सुरुवातीचे मापदंड खाली दिले आहेत. ही सुरुवातीची मापदंड आहेत; मोजमापावर आधारित आकडे नाहीत.

[
  {
    "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 cores. त्यामुळे footprint च्या आधारे त्यांच्यातील निवड ठरत नाही. Syncthing 1 GB RAM आणि 1 core मध्ये चालते; त्याचा विचार करण्याचे हेच वस्तुनिष्ठ कारण आहे. Memory पेक्षा त्यांच्या घटकांमध्ये अधिक फरक आहे. Seafile मध्ये 3 SQL databases असतात, तर Nextcloud मध्ये 1 असतात. Seafile चे default Docker deployment आधी download केलेल्या files मधून 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 आणि database passwords, initial admin account आणि JWT_PRIVATE_KEY सेट करा. त्या key साठी किमान 32 characters असलेली random string आवश्यक आहे. ही string पहिल्या start वेळी वाचली जाते. त्यामुळे stack सुरू करण्यापूर्वी ती generate करा:

openssl rand -base64 40
docker compose up -d

पहिल्या start वेळी तीन databases आणि admin user तयार होतात. TLS आणि reverse proxy यांसह Nextcloud साठीचे समतुल्य निर्णय Docker, TLS आणि backups सह VPS वरील Nextcloud मार्गदर्शकात स्पष्ट केले आहेत.

बॅकअपमध्ये काय फरक असतो?

हा असा घटक आहे ज्याचा लोक कमी अंदाज घेतात आणि याच ठिकाणी ही दोन्ही उत्पादने सर्वाधिक वेगळी ठरतात.

Seafile साठी क्रम ऐच्छिक नाही. मॅन्युअलनुसार प्रथम SQL चा बॅकअप घ्या आणि त्यानंतर data directory चा बॅकअप घ्या. त्यामुळे database मधील प्रत्येक record कडे संदर्भ देण्यासाठी वैध object असतो आणि libraries corrupt होत नाहीत. क्रम उलटा ठेवल्यास database मधील एखादी row अशा block कडे निर्देश करू शकते जो 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 वापरा, कारण Seafile ज्या MariaDB image सोबत वितरित होते त्यामध्ये mysql commands ची series deprecated आहे. docker exec चा output file मध्ये redirect करताना -t flag काढा, कारण TTY line endings पुन्हा लिहिते आणि dump खराब करते.

दोन्ही भाग स्वतंत्रपणे capture केले जातात, त्यामुळे त्यांच्यात विसंगती निर्माण होऊ शकते. कोणताही restore केल्यानंतर store वर विश्वास ठेवण्यापूर्वी तो तपासा:

docker exec -it seafile bash
cd /opt/seafile/seafile-server-latest
./seaf-fsck.sh

काहीतरी missing असल्यास tool त्या object चे नाव दाखवते:

Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing.
Repo ca1a860d HEAD commit is corrupted, need to restore to an old version.

Garbage collection साठीही नियोजन करा. Deduplication मुळे deleted files आणि deleted libraries चे blocks तुम्ही त्याच directory मधून ./seaf-gc.sh चालवत नाही तोपर्यंत तिथेच राहतात. या run मध्ये त्याला काय सापडले ते दाखवले जाते, उदाहरणार्थ GC finished. 507 blocks total, about 507 reachable blocks, 0 blocks can be removed.. हे एक वर्ष वगळल्यास, तुमचे backups users ने delete केलेल्या data साठीही storage वापरत राहतील.

Nextcloud मध्येही हीच दोन भागांची समस्या वेगळ्या स्वरूपात असते, कारण data directory आणि database यांनी त्याच 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 folder, data folder, कोणतेही custom apps आणि तुमची theme, तसेच तो dump जतन करा. दोन्ही भाग एकाच वेळेच्या स्थितीतून restore करा. data directory database पेक्षा नवीन असल्यास, users ना file cache ला माहीत नसलेल्या files दिसतात आणि occ files:scan --all त्याची दुरुस्ती करते. database नवीन असल्यास, cache rows अशा files कडे निर्देश करतात ज्या अस्तित्वात नाहीत आणि occ files:cleanup storage table मध्ये matching entry नसलेल्या cache entries काढून टाकते.

दोन्ही बाबतीत, अनेक small files हाताळू शकणारा आणि history जतन करणारा backup program आवश्यक आहे. restic आणि BorgBackup यांमध्ये हाच फरक आहे.

डेस्कटॉप आणि मोबाइलवरील क्लायंट

Seafile दोन डेस्कटॉप प्रोग्राम उपलब्ध करून देते. तुम्ही निवडलेल्या libraries ची स्थानिक प्रत syncing client ठेवतो. Drive client (SeaDrive) तुमच्या libraries virtual drive म्हणून mount करतो आणि प्रवेश केल्यावर त्या डाउनलोड करतो: Windows वर तो Microsoft's cloud files API वापरतो, macOS वर version 3.0 पासून तो Finder extension आहे आणि Linux वर version 3.0.12 पासून तो AppImage म्हणून उपलब्ध आहे व ~/SeaDrive येथे mount होतो. Encrypted libraries तिन्ही डेस्कटॉप प्लॅटफॉर्मवर कार्य करतात. मोबाइल अॅप्स फाइल्सपर्यंत पोहोचण्यासाठी आहेत; त्यांचा उद्देश एवढाच आहे.

Nextcloud चा desktop client देखील virtual files देतो. त्याचे mobile apps प्लॅटफॉर्मची उर्वरित वैशिष्ट्येही उपलब्ध करून देतात. त्यामुळे file access सोबत calendar, contacts, Talk आणि notes देखील मिळतात. तुमचे users प्रामुख्याने phones वापरत असतील आणि त्यांना फाइल्सपलीकडे अधिक सुविधा हव्या असतील, तर दैनंदिन वापरात हा खरा फरक ठरतो.

Seafile मधील एका तपशीलासाठी आधी नियोजन करणे आवश्यक आहे: library हे sharing, sync, permissions आणि encryption यांचे एकक आहे. एकाच library मध्ये 500 GB डेटा लोड करण्यापूर्वी तुमची library layout ठरवा. कारण दोन libraries मधील हलवणे म्हणजे copy आणि delete असते, rename नाही. त्यामुळे फाइलचा history तिच्यासोबत हलत नाही.

एन्क्रिप्शन: प्रत्येक पर्याय प्रत्यक्षात कशाचे संरक्षण करतो

Seafile च्या encrypted libraries client side असतात. Password server वर कधीही साठवला जात नाही. Password आणि library id पासून तयार केलेला magic token library सोबत साठवला जातो. त्यामुळे sync करण्यापूर्वी client password तपासू शकतो. Password पासून AES 256/CBC वापरून तयार केलेल्या key आणि IV (initialisation vector) ने file key encrypt केली जाते. त्यानंतर file data त्या file key ने encrypt केला जातो.

दस्तऐवजीकरणातील मर्यादा वाचा, कारण त्या अनेकदा दुर्लक्षित केल्या जातात. Encrypted library मध्ये फक्त file contents encrypt होतात. Folder आणि file names encrypt होत नाहीत. File sizes किंवा edit history देखील encrypt होत नाहीत. Web browser मध्ये encrypted library पाहणे end to end नसते. तुम्ही password टाइप करता, server त्याचा वापर file key decrypt करण्यासाठी करतो आणि password एक तास memory मध्ये cache ठेवतो. Encrypted library integrity सुनिश्चित करत नाही, हे manual मध्ये स्पष्टपणे नमूद आहे. Server admin फाइलच्या contents चा काही भाग बदलू शकतो आणि client ला तो बदल ओळखता येत नाही.

Nextcloud मध्ये नावांमध्ये गोंधळ होऊ शकणारी दोन features आहेत. Server side encryption मुळे at rest असलेल्या files encrypt होतात. मात्र keys त्याच server वर राहतात. त्यामुळे external storage वर ठेवलेल्या data चे संरक्षण चांगले होते; पण त्या server वरील root वापरणाऱ्या व्यक्तीपासून संरक्षण मिळत नाही. End to end encryption app client वर निवडलेले folders encrypt करते. रचनेनुसार server ते folders वाचू शकत नाही. त्यामुळे web interface, server side search आणि previews यांनाही त्या folders मधील contents दिसत नाहीत.

दोन्ही products चे encryption encrypted backup ची जागा घेत नाही. Backup स्वतंत्रपणे encrypt करा.

कॅलेंडर, संपर्क, ऑफिस आणि अॅप प्लॅटफॉर्म

या बाबतीत दोन्ही समान नाहीत. Nextcloud मध्ये CalDAV (WebDAV वरील कॅलेंडर) आणि CardDAV (WebDAV वरील संपर्क) हे core मध्ये उपलब्ध आहेत. दस्तऐवजांसाठी ते Collabora किंवा OnlyOffice शी integrate होते आणि इतर सर्व गरजांसाठी app store उपलब्ध आहे. Seafile 13 मध्ये collaborative documents आणि wiki pages साठी SeaDoc उपलब्ध आहे; त्यापुढील सुविधा नाहीत. त्यात calendar किंवा address book नाही.

या प्लॅटफॉर्मची किंमत म्हणजे upgrades. तुम्ही install केलेला प्रत्येक app Nextcloud upgrade अडवू शकतो किंवा upgrade नंतर चुकीच्या पद्धतीने काम करू शकतो. त्यामुळे users जितके जास्त app वर अवलंबून असतील, तितकी upgrade window अधिक काळजीपूर्वक नियोजित करावी लागते. Seafile कमी कामे करत असल्यामुळे त्यात बिघाड होण्याची शक्यता कमी असते. हेही लक्षात ठेवा की paid licence अंतर्गत documents मधील full text search आणि folder level permissions देणारी आवृत्ती Community Edition नव्हे, तर Seafile Professional आहे. त्यामुळे तुम्ही ज्या feature वर अवलंबून आहात ते तुम्ही चालवणार असलेल्या edition मध्ये उपलब्ध आहे का, हे निश्चित करा.

यापैकी प्रत्येक कोणत्या अपयशासाठी ओळखले जाते

Database आणि object store यांच्यातील स्थिती विसंगत झाल्यावर Seafile अपयशी ठरते. एखादी library उघडत नाही किंवा files अदृश्य होतात, असे दिसते आणि seaf-fsck.sh गहाळ block दाखवते. हाताने दुरुस्त करण्यासाठी file tree उपलब्ध नसते. त्यामुळे recovery साठी तुमचा database dump आणि object store योग्य क्रमाने restore करणे आवश्यक असते. हा restore spare VPS वर एकदा तपासा, कारण कधीही restore न केलेला backup हा केवळ अंदाज असतो.

File cache आणि disk यांच्यात तफावत निर्माण झाल्यावर Nextcloud अपयशी ठरते. सहसा Nextcloud ला न सांगता data directory मध्ये काहीतरी लिहिले गेल्यामुळे असे होते. Disk वर file दिसते, पण web interface मध्ये ती दाखवत नाही; किंवा folder चा size चुकीचा दिसतो. अशा वेळी occ files:scan हा उपाय आहे. त्याच्या इतर दोन प्रमुख अडचणी म्हणजे अनेक लहान files वर protocol speed कमी होणे आणि PHP memory. CPU वाढवल्याने पहिली अडचण सुटत नाही. मोठ्या images आणि videos साठी previews तयार करताना memory मध्ये नेहमी मोठी वाढ होते. त्यामुळे प्रत्येक process साठी 512 MB ठेवा आणि requests दरम्यान previews तयार करण्याऐवजी scheduled job मध्ये ते तयार करा.

दोन्हीपैकी एकही नाही: तुम्हाला फक्त फाइल sync हवे असल्यास Syncthing

तुमची खरी गरज मशीनदरम्यान एक folder mirror करण्याची असेल, तर ही दोन्ही उत्पादने तुमच्या गरजेपेक्षा अधिक आहेत. Syncthing मध्ये server किंवा accounts नसतात. प्रत्येक device हा peer असतो. तुमचा laptop sleep मध्ये असताना जागा राहणारा peer म्हणून VPS वापरता येतो. Syncthing 2 ही सध्याची मुख्य आवृत्ती आहे आणि packages project च्या स्वतःच्या repository मधून मिळतात:

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

ते normal user म्हणून चालवा, root म्हणून कधीही नाही. त्यामुळे ते लिहिणाऱ्या files ची ownership योग्य राहते:

sudo systemctl enable --now syncthing@youruser
systemctl status syncthing@youruser

Web interface default ने 127.0.0.1:8384 वर bind होते. त्यामुळे ते internet वरून पोहोचण्यायोग्य नसते आणि हाच योग्य default आहे. तुमच्या laptop वरून SSH tunnel द्वारे त्यात प्रवेश करा:

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

त्यानंतर laptop वर http://127.0.0.1:8384 उघडा. Sync साठी TCP आणि QUIC वर port 22000 वापरला जातो. Local discovery साठी UDP 21027 वापरला जातो; तो internet वर काम करत नाही. VPS वर 22000 उघडा आणि interface बंद ठेवा:

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

यामध्ये तुम्ही server ची सर्व वैशिष्ट्ये गमावता: Syncthing न चालवणाऱ्या लोकांसाठी share links नाहीत, web file browser नाही, user accounts नाहीत आणि प्रत्येक folder साठी file versioning enable केल्याशिवाय server-side trash देखील नाही. सर्वसाधारणपणे येणारे आश्चर्य म्हणजे conflict file. दोन devices एकमेकांना दिसत नसताना एकाच file मध्ये दोन्ही ठिकाणी बदल केल्यास notes.sync-conflict-20260806-142233-ABCD1EF.md सारख्या नावाची sibling file तयार होते. कोणतीही सूचना मिळत नाही. त्यामुळे वेळोवेळी sync-conflict शोधा.

तुम्हाला synced folder नव्हे, तर applications ज्या bucket मध्ये data लिहितात अशी रचना हवी असल्यास, ते पुन्हा वेगळे tool आहे: self-hosted S3 compatible object storage पहा. या क्षेत्राचा व्यापक आढावा घेण्यासाठी self-hosted Dropbox alternatives चा आढावा पहा.

निवडीचा नियम

1. कामाचा मुख्य उद्देश मोठ्या प्रमाणावर sync करणे असल्यास Seafile निवडा: अनेक फाइल्स, मोठ्या फाइल्स, अनेक devices आणि फक्त Seafile वाचू शकणारा data store स्वीकारण्याची तयारी.
2. कामाचा मुख्य उद्देश platform वापरणे असल्यास Nextcloud निवडा: calendars, contacts, documents आणि share links, तसेच disk वर plain files, ज्या कोणतेही backup tool वाचू शकते.
3. कामाचा मुख्य उद्देश फक्त mirrored folder ठेवणे असल्यास Syncthing निवडा.

आता काळजीपूर्वक निवड करा, कारण Seafile आणि Nextcloud यांच्यातील migration हाच खरा lock-in आहे. यासाठी कोणतेही converter नाही. सर्व data आधी client वर sync करून घ्यावा लागतो आणि नंतर तो दुसऱ्या server वर upload करावा लागतो. या प्रक्रियेत bandwidth आणि वेळ खर्च होतो, तसेच version history आणि share links मागील server वरच राहतात. दुसऱ्या वर्षी system बदलण्यापेक्षा आजची निवड पुढील तीन वर्षांसाठी योग्य क्षमतेनुसार करणे स्वस्त ठरते.

FAQ

मोठ्या लायब्ररी समक्रमित करण्यासाठी Seafile हे Nextcloud पेक्षा जलद आहे का?

होय, सामान्यतः ज्या दोन परिस्थितींमध्ये कार्यक्षमता कमी होते, त्या दोन्हीमध्ये Seafile जलद आहे. याचे कारण तुम्ही पडताळू शकता. Seafile फाइल्सचे सरासरी सुमारे 8 MB आकाराचे blocks मध्ये विभाजन करते आणि फक्त बदललेले blocks transfer करते. त्यामुळे मोठ्या फाइलमध्ये केलेल्या बदलासाठी काही blocks एवढेच transfer करावे लागतात. Nextcloud मध्ये transfer चे एकक संपूर्ण फाइल असते. त्यामुळे त्याच बदलासाठी संपूर्ण फाइल पुन्हा upload करावी लागते. तसेच, अनेक लहान फाइल्ससाठी प्रत्येकी किमान एक WebDAV request लागते. म्हणून त्याची bulk upload API लहान फाइल्स एकत्र pack करते. तुमच्या स्वतःच्या VPS वर दोन्हींची वेळ मोजून पाहा. कारण protocol इतकेच तुमचा CPU, disk आणि network link देखील महत्त्वाचे असतात.

Data directory वर rsync चालवून Seafile चा backup घेता येतो का?

फक्त databases सोबत आणि दस्तऐवजीकरणात दिलेल्या क्रमानेच. Seafile च्या manual नुसार प्रथम SQL चा backup घ्या आणि त्यानंतर data directory चा backup घ्या. त्यामुळे backup मधील प्रत्येक database record विद्यमान object कडे निर्देश करतो. rsync -az /opt/seafile-data/seafile /backup/data/ command conf, seafile-data आणि seahub-data copy करते. मात्र ती स्वतःहून restorable नसते. याचे कारण object store मध्ये वाचता येईल अशी file tree नसते आणि database हा तिचा index असतो. दोन्ही भाग restore केल्यानंतर seaf-fsck.sh चालवा आणि निकालावर विश्वास ठेवण्यापूर्वी त्याचे output वाचा.

मला फक्त file sync हवे असल्यास Nextcloud आवश्यक आहे का?

नाही. Nextcloud हे एक platform आहे. तुम्ही calendar, contacts आणि app store वापरत नसला तरी ते memory आणि upgrade management ची गरज वाढवतात. फक्त file sync साठी Seafile हे अधिक हलके आणि जलद protocol असलेले product आहे. Syncthing त्याहूनही हलके आहे, कारण त्यासाठी server side चालवावी लागत नाही. अतिरिक्त applications हवी असतील तेव्हा Nextcloud निवडा; default पर्याय म्हणून नाही.

Encrypted Seafile library माझी file names लपवते का?

नाही. Encrypted library मध्ये client वर file contents encrypt होतात आणि password server पर्यंत पोहोचत नाही. मात्र folder names, file names, file sizes आणि edit history server वर दिसत राहतात. Web interface मध्ये encrypted library उघडल्यास password server कडेही पाठवला जातो. Server त्याचा वापर करून file key decrypt करते आणि password एक तास memory मध्ये ठेवते. File names स्वतः संवेदनशील असल्यास ती library web interface पासून दूर ठेवा आणि दुसऱ्या layer वर encryption करा.

VPS वर Seafile किंवा Nextcloud साठी किती RAM द्यावी?

काही users असलेल्या कोणत्याही product साठी 4 GB RAM आणि 2 cores पासून सुरुवात करा. त्यानंतर preview generation आणि search दरम्यान memory monitor करा. Seafile च्या documents मध्ये किमान 2 GB RAM आणि 2 GHz पेक्षा अधिक वेगाचा 2 core CPU आवश्यक असल्याचे नमूद आहे. Nextcloud च्या documents नुसार प्रत्येक PHP process साठी 512 MB ची शिफारस आहे. Database आणि cache जोडण्यापूर्वी ही संख्या worker count ने गुणा. Syncthing 1 GB मध्ये सहज चालते.