Seafile vs Nextcloud เลือกตัวไหนดีสำหรับการซิงค์ไฟล์

Seafile กับ Nextcloud: คำตอบโดยสรุป

ความแตกต่างระหว่าง Seafile กับ Nextcloud ขึ้นอยู่กับประเด็นเดียว คือสถานะของไฟล์เมื่อถูกจัดเก็บไว้บนเซิร์ฟเวอร์ Seafile จะแบ่งไฟล์ทุกไฟล์ออกเป็นบล็อกย่อยและจัดเก็บไว้ในรูปแบบ object store ซึ่งมีเพียง Seafile เท่านั้นที่อ่านได้ ส่งผลให้การซิงค์ข้อมูลทำได้อย่างรวดเร็ว แต่การสำรองข้อมูลจะกลายเป็นงานที่ต้องทำสองส่วน ส่วน Nextcloud จะเขียนไฟล์ลงดิสก์ในรูปแบบไฟล์ปกติ และมองว่าการซิงค์เป็นเพียงฟีเจอร์หนึ่งของแพลตฟอร์มที่รองรับทั้งปฏิทิน รายชื่อผู้ติดต่อ เอกสาร และการแชร์ลิงก์ ให้ตัดสินใจจากความแตกต่างนี้ เพราะรายละเอียดส่วนอื่นทั้งหมดจะขึ้นอยู่กับจุดนี้

ณ เดือนสิงหาคม 2026 Seafile อยู่ในซีรีส์ 13.0 และ Nextcloud อยู่ในซีรีส์ 34 ทั้งสองซอฟต์แวร์มีความเสถียรสูง และไม่มีแนวโน้มที่จะเปลี่ยนแปลงรูปแบบการจัดเก็บข้อมูลของตนเอง

วิธีการจัดเก็บไฟล์ของ Seafile

Seafile จำลองรูปแบบของไลบรารีในลักษณะเดียวกับที่ git จำลอง repository คู่มือผู้ดูแลระบบระบุถึงโมเดลภายในว่าประกอบด้วย Repo, Commit, FS และ Block โดยระบุว่า repo ยังถูกเรียกว่าไลบรารีอีกด้วย ไฟล์แต่ละไฟล์จะถูกแบ่งออกเป็นบล็อกที่มีขนาดไม่คงที่โดยใช้เทคนิค content defined chunking (CDC ซึ่งเป็นอัลกอริทึมที่เลือกขอบเขตของบล็อกโดยอ้างอิงจากข้อมูลภายในตัวมันเอง) และคู่มือระบุว่าขนาดบล็อกเฉลี่ยอยู่ที่ประมาณ 8 MB บล็อกเหล่านี้จะถูกตั้งชื่อตามเนื้อหาภายใน ดังนั้นไฟล์ขนาดใหญ่สองเวอร์ชันจะใช้บล็อกร่วมกันในส่วนที่ไม่เปลี่ยนแปลง และไลบรารีสองแห่งที่เหมือนกันก็จะใช้บล็อกร่วมกันเช่นกัน

ฐานข้อมูลเชิงสัมพันธ์จะเก็บเพียงข้อมูลเมตา (metadata) จำนวนเล็กน้อยเกี่ยวกับไลบรารีเท่านั้น ส่วนข้อมูลอื่นทั้งหมด ได้แก่ commit, ออบเจกต์ไดเรกทอรี และบล็อก จะถูกจัดเก็บไว้ภายใต้ไดเรกทอรีข้อมูล ในโครงสร้างแบบ Docker ที่ใช้ในซีรีส์ 12 และ 13 คือ /opt/seafile-data/seafile/seafile-data การรันคำสั่ง ls ในตำแหน่งดังกล่าวจะไม่ให้ข้อมูลที่เป็นประโยชน์ เนื่องจากคุณจะเห็นเพียงไดเรกทอรีที่เต็มไปด้วยชื่อแบบแฮช ไม่ใช่ Invoices/2026/march.pdf

การซิงค์ข้อมูลใช้โมเดลเดียวกันนี้ โดยไคลเอนต์จะสอบถามเซิร์ฟเวอร์ว่ามีอะไรเปลี่ยนแปลงไปบ้าง จากนั้นจะได้รับรายการแฮชของบล็อกและดึงเฉพาะบล็อกที่ตนเองยังไม่มี นี่คือเหตุผลที่ Seafile สามารถรองรับไลบรารีขนาดใหญ่ได้ เพราะจำนวนไบต์ที่ถ่ายโอนจะแปรผันตามบล็อกที่มีการเปลี่ยนแปลง ไม่ใช่ขนาดของไฟล์ที่บรรจุบล็อกเหล่านั้นอยู่

วิธีการจัดเก็บไฟล์ของ Nextcloud

Nextcloud จะจัดเก็บไฟล์ลงในดิสก์ตามตำแหน่งที่คุณคาดไว้ โดย path data/<username>/files/ จะสะท้อนโครงสร้างเดียวกับที่ผู้ใช้เห็นในเว็บอินเทอร์เฟซ ตารางในฐานข้อมูลที่ชื่อ oc_filecache จะทำหน้าที่จำลองโครงสร้างต้นไม้นี้เช่นกัน โดยเก็บข้อมูลขนาดไฟล์ เวลาที่แก้ไขล่าสุด และ etags ซึ่ง Nextcloud จะเชื่อถือข้อมูลในตารางมากกว่าสิ่งที่อยู่บนดิสก์

เดสก์ท็อปไคลเอนต์สื่อสารผ่านโปรโตคอล WebDAV (web distributed authoring and versioning) บน HTTPS ไฟล์แต่ละไฟล์จะใช้คำขออย่างน้อยหนึ่งครั้ง ซึ่งเป็นเหตุผลที่ Nextcloud เพิ่ม API สำหรับการอัปโหลดแบบกลุ่ม (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) ไว้ชัดเจน ได้แก่ หลังจากคัดลอกไฟล์ลงในไดเรกทอรีข้อมูลโดยตรง, หลังจากดำเนินการย้ายระบบ (migration) และเมื่อคุณกำลังตรวจสอบความไม่สอดคล้องกันของแคชไฟล์ (file cache inconsistencies)

ตัวเลือกใดซิงค์ไลบรารีขนาดใหญ่ได้เร็วกว่ากัน

Seafile ทำได้เร็วกว่าในสองกรณีที่ส่งผลกระทบมากที่สุด ได้แก่ ไฟล์ขนาดเล็กจำนวนหลายหมื่นไฟล์ และการแก้ไขไฟล์ขนาดใหญ่ซ้ำๆ กลไกของ Seafile คือการทำ block-level deduplication ดังนั้นหากมีการเปลี่ยนแปลงข้อมูลภายในไฟล์ disk image ขนาด 4 GB ระบบจะอัปโหลดเฉพาะบล็อกที่เปลี่ยนแปลงเพียงไม่กี่บล็อกเท่านั้น ในขณะที่ Nextcloud พยายามลดช่องว่างเรื่องไฟล์ขนาดเล็กด้วยการอัปโหลดแบบกลุ่ม (bulk upload) แต่ก็ไม่สามารถแก้ปัญหาเรื่องไฟล์ขนาดใหญ่ได้ เนื่องจากหน่วยการโอนถ่ายข้อมูลของ 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 ระบุว่าต้องการ "RAM อย่างน้อย 2G และ CPU 2 คอร์ (> 2GHz)" ในขณะที่เอกสารของ Nextcloud ระบุหน่วยความจำต่อกระบวนการ PHP แทน โดยกำหนดขั้นต่ำไว้ที่ 128 MB และแนะนำที่ 512 MB ต่อกระบวนการ ซึ่งคุณต้องนำไปคูณกับจำนวน worker ก่อนจะบวกเพิ่มด้วยส่วนของฐานข้อมูล, แคช และการสร้างภาพตัวอย่าง ด้านล่างนี้คือจุดเริ่มต้นที่ผมแนะนำสำหรับทีมขนาดเล็ก ซึ่งเป็นเพียงค่าเริ่มต้น ไม่ใช่ค่าที่วัดผลได้จริง

[
  {
    "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
  }
]

ทั้งสองบริการอยู่ในระดับเดียวกัน คือใช้ RAM 4 GB และ CPU 2 คอร์ ดังนั้นขนาดการใช้งานจึงไม่ใช่ปัจจัยตัดสินใจ Syncthing ทำงานได้ด้วย RAM 1 GB บน CPU 1 คอร์ ซึ่งเป็นเหตุผลที่แท้จริงในการพิจารณาเลือกใช้ ส่วนประกอบที่เคลื่อนไหวของทั้งสองบริการมีความแตกต่างกันมากกว่าเรื่องหน่วยความจำ Seafile ใช้ฐานข้อมูล SQL 3 ชุด ในขณะที่ 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 ก่อนแล้วจึงสำรองไดเรกทอรีข้อมูลตามมา เพราะจะทำให้ทุกระเบียนในฐานข้อมูลมีออบเจกต์ที่ถูกต้องให้อ้างอิง ส่งผลให้ไลบรารีไม่เสียหาย หากทำสลับกัน แถวในฐานข้อมูลอาจชี้ไปยังบล็อกข้อมูลที่สแนปชอตของคุณไม่ได้บันทึกไว้

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.

วางแผนสำหรับการทำ 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, แอปพลิเคชันที่ปรับแต่งเอง, ธีมของคุณ และไฟล์ดัมพ์นั้นไว้ ให้กู้คืนข้อมูลทั้งสองส่วนจากช่วงเวลาเดียวกัน หากไดเรกทอรีข้อมูลใหม่กว่าฐานข้อมูล ผู้ใช้จะเห็นไฟล์ที่แคชไฟล์ไม่รู้จัก และ occ files:scan --all จะช่วยซ่อมแซมส่วนนี้ หากฐานข้อมูลใหม่กว่า แถวในแคชจะชี้ไปยังไฟล์ที่ไม่มีอยู่จริง และ occ files:cleanup จะลบรายการแคชที่ไม่มีรายการที่ตรงกันในตารางจัดเก็บข้อมูลออก

ไม่ว่ากรณีใด คุณควรใช้โปรแกรมสำรองข้อมูลที่จัดการกับไฟล์ขนาดเล็กจำนวนมากได้และเก็บประวัติการเปลี่ยนแปลงไว้ ซึ่งเป็นสิ่งที่ restic และ BorgBackup ทำแตกต่างกัน

ไคลเอนต์บนเดสก์ท็อปและอุปกรณ์พกพา

Seafile มีโปรแกรมสำหรับเดสก์ท็อปให้ใช้งานสองรูปแบบ ไคลเอนต์แบบซิงค์จะเก็บสำเนาของไลบรารีที่คุณเลือกไว้ในเครื่อง ส่วนไคลเอนต์แบบ Drive (SeaDrive) จะทำการ mount ไลบรารีของคุณเป็นไดรฟ์เสมือนและดาวน์โหลดข้อมูลเมื่อมีการเข้าถึง โดยบน Windows จะใช้ cloud files API ของ Microsoft ส่วนบน macOS เวอร์ชัน 3.0 จะเป็นส่วนขยายของ Finder และบน Linux จะมาในรูปแบบ AppImage ตั้งแต่เวอร์ชัน 3.0.12 เป็นต้นไป โดยจะ mount ที่ ~/SeaDrive ทั้งนี้ไลบรารีที่มีการเข้ารหัสสามารถใช้งานได้บนแพลตฟอร์มเดสก์ท็อปทั้งสาม ส่วนแอปบนอุปกรณ์พกพานั้นมีไว้เพื่อเข้าถึงไฟล์เป็นหลัก ซึ่งเป็นหน้าที่เดียวที่แอปเหล่านี้พยายามทำ

ไคลเอนต์เดสก์ท็อปของ Nextcloud ก็มีฟีเจอร์ไฟล์เสมือนเช่นกัน และแอปบนอุปกรณ์พกพายังรองรับการทำงานส่วนอื่นๆ ของแพลตฟอร์มด้วย ทำให้สามารถใช้งานปฏิทิน รายชื่อผู้ติดต่อ Talk และบันทึกย่อได้ควบคู่ไปกับการเข้าถึงไฟล์ หากผู้ใช้งานของคุณเน้นการใช้งานบนโทรศัพท์และต้องการฟังก์ชันมากกว่าแค่การจัดการไฟล์ นี่คือความแตกต่างที่สำคัญในการใช้งานประจำวัน

มีรายละเอียดหนึ่งของ Seafile ที่ควรวางแผนล่วงหน้า คือไลบรารีเป็นหน่วยพื้นฐานสำหรับการแชร์ การซิงค์ การกำหนดสิทธิ์ และการเข้ารหัส คุณควรตัดสินใจเรื่องโครงสร้างไลบรารีให้เรียบร้อยก่อนที่จะอัปโหลดข้อมูลขนาด 500 GB ลงในไลบรารีเดียว เพราะการย้ายข้อมูลระหว่างไลบรารีจะเป็นการคัดลอกและลบไฟล์ ไม่ใช่การเปลี่ยนชื่อ ดังนั้นประวัติการแก้ไขของไฟล์จะไม่ถูกย้ายตามไปด้วย

การเข้ารหัส: สิ่งที่แต่ละวิธีปกป้องจริง ๆ

ไลบรารีที่เข้ารหัสของ Seafile เป็นแบบ client side โดยรหัสผ่านจะไม่ถูกจัดเก็บไว้บนเซิร์ฟเวอร์ แต่จะมี magic token ที่ได้จากรหัสผ่านและ library id จัดเก็บไว้พร้อมกับไลบรารี เพื่อให้ไคลเอนต์ตรวจสอบรหัสผ่านก่อนเริ่มการซิงค์ ข้อมูล file key จะถูกเข้ารหัสด้วยคีย์และ IV (initialisation vector) ที่ได้จากรหัสผ่านของคุณโดยใช้ AES 256/CBC และข้อมูลไฟล์จะถูกเข้ารหัสด้วย file key นั้นอีกชั้นหนึ่ง

โปรดอ่านข้อจำกัดที่ระบุไว้ในเอกสาร เพราะผู้ใช้มักมองข้าม ไลบรารีที่เข้ารหัสจะเข้ารหัสเฉพาะเนื้อหาของไฟล์เท่านั้น ชื่อโฟลเดอร์และชื่อไฟล์จะไม่ถูกเข้ารหัส รวมถึงขนาดไฟล์และประวัติการแก้ไขด้วย การเรียกดูไลบรารีที่เข้ารหัสผ่านเว็บเบราว์เซอร์ไม่ใช่การเข้ารหัสแบบ end to end เนื่องจากเมื่อคุณพิมพ์รหัสผ่าน เซิร์ฟเวอร์จะนำรหัสผ่านนั้นไปใช้ถอดรหัส file key และจะเก็บรหัสผ่านไว้ในหน่วยความจำชั่วคราวเป็นเวลาหนึ่งชั่วโมง นอกจากนี้ คู่มือยังระบุชัดเจนว่าไลบรารีที่เข้ารหัสไม่รับประกันความถูกต้องของข้อมูล (integrity) เนื่องจากผู้ดูแลระบบเซิร์ฟเวอร์สามารถแก้ไขเนื้อหาบางส่วนของไฟล์ได้โดยที่ไคลเอนต์ไม่สามารถตรวจพบ

Nextcloud มีฟีเจอร์สองอย่างที่มีชื่อคล้ายกันจนอาจสับสนได้ การเข้ารหัสฝั่งเซิร์ฟเวอร์ (server side encryption) จะเข้ารหัสไฟล์ที่จัดเก็บไว้ (at rest) แต่เก็บคีย์ไว้บนเซิร์ฟเวอร์เดียวกัน ดังนั้นจึงช่วยปกป้องข้อมูลที่เก็บไว้ใน external storage ได้ดีกว่าการป้องกันผู้ที่มีสิทธิ์ root บนเครื่องนั้น ส่วนแอปการเข้ารหัสแบบ end to end จะเข้ารหัสโฟลเดอร์ที่เลือกไว้บนฝั่งไคลเอนต์ ซึ่งตามการออกแบบแล้วเซิร์ฟเวอร์จะไม่สามารถอ่านข้อมูลเหล่านั้นได้ ทำให้หน้าเว็บอินเทอร์เฟซ ระบบค้นหาฝั่งเซิร์ฟเวอร์ และการแสดงตัวอย่างไฟล์ไม่สามารถเข้าถึงเนื้อหาภายในโฟลเดอร์เหล่านั้นได้

การเข้ารหัสของทั้งสองผลิตภัณฑ์ไม่สามารถทดแทนการสำรองข้อมูลแบบเข้ารหัสได้ คุณควรเข้ารหัสไฟล์สำรองข้อมูลแยกต่างหากด้วยตนเอง

ปฏิทิน รายชื่อผู้ติดต่อ สำนักงาน และแพลตฟอร์มแอปพลิเคชัน

แกนนี้ยังไม่จบสิ้น Nextcloud มาพร้อมกับ CalDAV (ปฏิทินผ่าน WebDAV) และ CardDAV (รายชื่อผู้ติดต่อผ่าน WebDAV) ในตัวหลัก มีการรวม Collabora หรือ OnlyOffice สำหรับจัดการเอกสาร และมี App Store สำหรับฟังก์ชันอื่นๆ ทั้งหมด ส่วน Seafile 13 มาพร้อมกับ SeaDoc สำหรับเอกสารที่ทำงานร่วมกันและหน้าวิกิ แต่มีเพียงเท่านี้ โดยไม่มีปฏิทินและสมุดรายชื่อผู้ติดต่อ

แพลตฟอร์มนี้มีราคาที่ต้องจ่าย นั่นคือการอัปเกรด แอปพลิเคชันทุกตัวที่คุณติดตั้งเป็นอีกหนึ่งปัจจัยที่อาจขัดขวางการอัปเกรด Nextcloud หรือทำงานผิดพลาดหลังจากอัปเกรด ดังนั้นยิ่งผู้ใช้ของคุณพึ่งพาแอปพลิเคชันมากเท่าใด ช่วงเวลาในการอัปเกรดของคุณก็ยิ่งต้องใช้ความระมัดระวังมากขึ้นเท่านั้น Seafile มีส่วนที่อาจเสียหายได้น้อยกว่าเพราะทำหน้าที่น้อยกว่า โปรดทราบด้วยว่า Seafile Professional ไม่ใช่ Community Edition ที่เป็นตัวเพิ่มฟีเจอร์การค้นหาข้อความแบบเต็มภายในเอกสารและการกำหนดสิทธิ์ระดับโฟลเดอร์ภายใต้ใบอนุญาตแบบชำระเงิน ดังนั้นโปรดตรวจสอบให้แน่ใจว่าฟีเจอร์ที่คุณต้องการใช้งานนั้นอยู่ในรุ่นที่คุณวางแผนจะติดตั้ง

รูปแบบความล้มเหลวที่แต่ละบริการมักพบ

Seafile มักล้มเหลวเมื่อฐานข้อมูลและที่เก็บออบเจกต์ (object store) ไม่ตรงกัน คุณจะพบว่าไลบรารีไม่สามารถเปิดได้หรือไฟล์หายไป และ seaf-fsck.sh จะแสดงบล็อกที่ขาดหายไป เนื่องจากไม่มีโครงสร้างไฟล์ให้ซ่อมแซมด้วยตนเอง การกู้คืนจึงต้องใช้การดัมพ์ฐานข้อมูลควบคู่ไปกับที่เก็บออบเจกต์ โดยต้องกู้คืนตามลำดับที่ถูกต้อง ควรทดสอบการกู้คืนบน VPS สำรองอย่างน้อยหนึ่งครั้ง เพราะการสำรองข้อมูลที่คุณไม่เคยทดสอบกู้คืนนั้นถือเป็นเพียงการคาดเดาเท่านั้น

Nextcloud มักล้มเหลวเมื่อแคชไฟล์และดิสก์ไม่ตรงกัน ซึ่งมักเกิดจากการที่มีบางอย่างเขียนข้อมูลลงในไดเรกทอรีข้อมูลโดยไม่ได้แจ้งให้ Nextcloud ทราบ คุณจะพบไฟล์บนดิสก์ที่หน้าเว็บอินเทอร์เฟซไม่แสดง หรือโฟลเดอร์ที่มีขนาดไม่ถูกต้อง ซึ่ง occ files:scan คือวิธีแก้ไข จุดอ่อนอีกสองประการคือความเร็วของโปรโตคอลเมื่อจัดการกับไฟล์ขนาดเล็กจำนวนมาก ซึ่งการเพิ่ม CPU ไม่สามารถช่วยได้ และปัญหาหน่วยความจำ PHP โดยการสร้างพรีวิวสำหรับรูปภาพและวิดีโอขนาดใหญ่มักทำให้เกิดการใช้หน่วยความจำพุ่งสูงขึ้น ดังนั้นควรสำรองหน่วยความจำไว้ 512 MB ต่อกระบวนการ (process) และตั้งค่าให้สร้างพรีวิวผ่านงานที่กำหนดเวลาไว้ (scheduled job) แทนที่จะสร้างระหว่างการร้องขอข้อมูล

ไม่ใช่ทั้งสองอย่าง: Syncthing หากคุณต้องการเพียงแค่การซิงค์ไฟล์

หากความต้องการที่แท้จริงของคุณคือการทำ mirror โฟลเดอร์ระหว่างเครื่อง ทั้งสองผลิตภัณฑ์นี้ถือเป็นซอฟต์แวร์ที่เกินความจำเป็น Syncthing ไม่มีเซิร์ฟเวอร์และไม่มีบัญชีผู้ใช้ อุปกรณ์ทุกเครื่องถือเป็น peer และ VPS จะทำหน้าที่เป็น peer ที่คอยทำงานอยู่ตลอดเวลาในขณะที่แล็ปท็อปของคุณเข้าสู่โหมด sleep Syncthing 2 คือเวอร์ชันปัจจุบัน และแพ็กเกจสามารถติดตั้งได้จาก 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

ให้รันโปรแกรมในฐานะผู้ใช้ทั่วไป ห้ามรันในฐานะ 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 บนแล็ปท็อป ตัว Syncthing เองใช้พอร์ต 22000 ผ่านโปรโตคอล TCP และ QUIC ส่วนการค้นหาอุปกรณ์ในเครือข่ายท้องถิ่น (local discovery) ใช้ UDP 21027 ซึ่งไม่มีผลผ่านอินเทอร์เน็ต สำหรับบน VPS ให้เปิดพอร์ต 22000 และปิดอินเทอร์เฟซเว็บไว้ตามเดิม:

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

สิ่งที่คุณจะสูญเสียไปคือฟีเจอร์ระดับเซิร์ฟเวอร์ทั้งหมด: ไม่มีลิงก์แชร์สำหรับบุคคลที่ไม่ได้ใช้งาน Syncthing, ไม่มีเว็บเบราว์เซอร์สำหรับจัดการไฟล์, ไม่มีบัญชีผู้ใช้ และไม่มีถังขยะฝั่งเซิร์ฟเวอร์ เว้นแต่คุณจะเปิดใช้งานฟีเจอร์ file versioning ในแต่ละโฟลเดอร์ สิ่งที่มักจะทำให้ผู้ใช้ประหลาดใจคือไฟล์ความขัดแย้ง (conflict file) หากคุณแก้ไขไฟล์เดียวกันบนสองอุปกรณ์ในขณะที่อุปกรณ์เหล่านั้นไม่สามารถเชื่อมต่อกันได้ คุณจะได้ไฟล์คู่ขนานที่มีชื่อคล้ายกับ 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 หากงานของคุณคือการทำโฟลเดอร์สำเนา (mirrored folder) และไม่มีความต้องการอื่นเพิ่มเติม

จงเลือกอย่างระมัดระวังในตอนนี้ เพราะการย้ายข้อมูลระหว่าง Seafile และ Nextcloud คือการติดล็อก (lock-in) ที่แท้จริง เนื่องจากไม่มีเครื่องมือแปลงข้อมูล คุณต้องซิงค์ข้อมูลทั้งหมดลงมาที่ไคลเอนต์ แล้วอัปโหลดขึ้นไปยังเซิร์ฟเวอร์ใหม่ ซึ่งต้องแลกมาด้วยการใช้แบนด์วิดท์และเวลา ในขณะที่ประวัติเวอร์ชันและลิงก์แชร์เดิมจะสูญหายไป การเลือกให้เหมาะสมกับความต้องการในอีก 3 ปีข้างหน้าตั้งแต่ตอนนี้ มีต้นทุนที่ถูกกว่าการเปลี่ยนระบบในปีที่ 2

FAQ

Seafile ทำงานเร็วกว่า Nextcloud ในการซิงค์ไลบรารีขนาดใหญ่หรือไม่?

ใช่ ในกรณีที่มักจะทำให้เกิดปัญหา ซึ่งมีเหตุผลที่คุณสามารถตรวจสอบได้ Seafile จะแบ่งไฟล์ออกเป็นบล็อกขนาดเฉลี่ยประมาณ 8 MB และโอนย้ายเฉพาะบล็อกที่มีการเปลี่ยนแปลง ดังนั้นการแก้ไขภายในไฟล์ขนาดใหญ่จึงส่งผลให้มีการย้ายเพียงไม่กี่บล็อกเท่านั้น ในขณะที่หน่วยการโอนย้ายของ Nextcloud คือไฟล์ทั้งไฟล์ ดังนั้นการแก้ไขแบบเดียวกันจะต้องอัปโหลดไฟล์ใหม่ทั้งหมด และไฟล์ขนาดเล็กจำนวนมากแต่ละไฟล์จะต้องใช้คำขอ WebDAV อย่างน้อยหนึ่งรายการ ซึ่งเป็นเหตุผลว่าทำไม API สำหรับการอัปโหลดแบบกลุ่มจึงต้องรวมไฟล์ขนาดเล็กเข้าด้วยกัน คุณควรทดสอบเวลาทั้งสองระบบบน VPS ของคุณเองก่อนตัดสินใจเลือกใช้งาน เนื่องจาก CPU, ดิสก์ และการเชื่อมต่อเครือข่ายของคุณมีความสำคัญพอๆ กับโปรโตคอลที่ใช้

ฉันสามารถสำรองข้อมูล Seafile โดยใช้ rsync บนไดเรกทอรีข้อมูลได้หรือไม่?

ทำได้ก็ต่อเมื่อทำควบคู่ไปกับฐานข้อมูลและตามลำดับที่ระบุไว้ในเอกสารเท่านั้น คู่มือของ Seafile ระบุให้สำรองข้อมูล SQL ก่อนแล้วจึงสำรองไดเรกทอรีข้อมูลตามมา เพราะจะทำให้บันทึกในฐานข้อมูลทุกรายการอ้างอิงถึงออบเจกต์ที่มีอยู่ในข้อมูลสำรอง คำสั่ง rsync -az /opt/seafile-data/seafile /backup/data/ จะคัดลอก conf, seafile-data และ seahub-data แต่หากทำเพียงลำพังจะไม่สามารถกู้คืนได้ เนื่องจากที่เก็บออบเจกต์ไม่มีโครงสร้างไฟล์ที่อ่านได้และฐานข้อมูลทำหน้าที่เป็นดัชนี หลังจากกู้คืนทั้งสองส่วนแล้ว ให้รัน seaf-fsck.sh และอ่านผลลัพธ์ก่อนที่คุณจะเชื่อถือข้อมูลนั้น

ฉันจำเป็นต้องใช้ Nextcloud หรือไม่หากต้องการเพียงแค่การซิงค์ไฟล์?

ไม่จำเป็น Nextcloud เป็นแพลตฟอร์ม ซึ่งปฏิทิน รายชื่อผู้ติดต่อ และ App Store จะทำให้คุณต้องเสียทรัพยากรหน่วยความจำและต้องคอยดูแลการอัปเกรดไม่ว่าคุณจะใช้งานฟีเจอร์เหล่านั้นหรือไม่ก็ตาม สำหรับการซิงค์ไฟล์ทั่วไป Seafile เป็นผลิตภัณฑ์ที่เบากว่าและมีโปรโตคอลที่เร็วกว่า ส่วน Syncthing นั้นเบายิ่งกว่าเพราะไม่มีส่วนประกอบฝั่งเซิร์ฟเวอร์ที่ต้องรัน ให้เลือก Nextcloud เมื่อคุณต้องการแอปพลิเคชันเสริม ไม่ใช่เลือกเป็นค่าเริ่มต้น

ไลบรารีที่เข้ารหัสของ Seafile ปิดบังชื่อไฟล์ของฉันหรือไม่?

ไม่ ไลบรารีที่เข้ารหัสจะเข้ารหัสเนื้อหาไฟล์ที่ฝั่งไคลเอนต์และรหัสผ่านจะไม่ถูกส่งไปยังเซิร์ฟเวอร์ แต่ชื่อโฟลเดอร์ ชื่อไฟล์ ขนาดไฟล์ และประวัติการแก้ไขจะยังคงมองเห็นได้บนเซิร์ฟเวอร์ การเปิดไลบรารีที่เข้ารหัสผ่านเว็บอินเทอร์เฟซจะส่งรหัสผ่านไปยังเซิร์ฟเวอร์ ซึ่งจะถอดรหัสคีย์ของไฟล์และเก็บรหัสผ่านไว้ในหน่วยความจำเป็นเวลาหนึ่งชั่วโมง หากชื่อไฟล์มีความละเอียดอ่อน ให้เก็บไลบรารีนั้นไว้นอกเว็บอินเทอร์เฟซและใช้วิธีการเข้ารหัสในระดับอื่นแทน

ฉันควรจัดสรร RAM ให้ Seafile หรือ Nextcloud บน VPS เท่าใด?

เริ่มต้นที่ 4 GB พร้อม CPU 2 คอร์ สำหรับระบบใดระบบหนึ่งที่มีผู้ใช้งานจำนวนไม่มาก จากนั้นให้เฝ้าดูการใช้หน่วยความจำระหว่างการสร้างพรีวิวและการค้นหา เอกสารของ Seafile กำหนดขั้นต่ำไว้ที่ RAM 2 GB และ CPU 2 คอร์ ที่ความเร็วสูงกว่า 2 GHz ส่วน Nextcloud แนะนำให้ใช้ RAM 512 MB ต่อหนึ่งกระบวนการทำงานของ PHP ซึ่งคุณต้องคูณด้วยจำนวน worker ก่อนที่จะบวกเพิ่มส่วนของฐานข้อมูลและแคช สำหรับ Syncthing สามารถรันได้อย่างราบรื่นใน 1 GB