ทางเลือก Nextcloud สำหรับทำ Self-hosting ที่น่าสนใจ

ทางเลือกอื่นของ Nextcloud ที่น่าสนใจสำหรับการทำ self-hosting

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

คู่มือนี้จัดกลุ่มตัวเลือกตามลักษณะงาน ได้แก่ การซิงค์ข้อมูลเพียงอย่างเดียว, การซิงค์ด้วยเซิร์ฟเวอร์ที่เร็วกว่า, การจัดเก็บแบบ object storage ที่มีไคลเอนต์ครอบไว้ หรือการเข้าถึงไฟล์ระยะไกลแบบทั่วไป แต่ละส่วนจะระบุความต้องการของเซิร์ฟเวอร์บน VPS (virtual private server) ขนาดเล็ก และผลกระทบต่อโครงสร้างโฟลเดอร์เดิมของคุณ หากคุณย้ายมาจาก Dropbox หรือ Google Drive แทนที่จะมาจาก Nextcloud ที่คุณใช้งานอยู่แล้ว บทสรุปทางเลือกของ Dropbox สำหรับ self-hosted จะเป็นจุดเริ่มต้นที่เหมาะสมกว่าสำหรับคุณ

เหตุใด Nextcloud จึงทำงานช้าบน VPS ขนาดเล็ก

ความล่าช้ามีสาเหตุที่ระบุได้ชัดเจน และการทราบสาเหตุเหล่านี้จะช่วยให้คุณตัดสินใจได้ว่าการย้ายเซิร์ฟเวอร์จะช่วยแก้ปัญหาได้จริงหรือไม่

การโหลดหน้าเว็บแต่ละครั้งจะใช้ PHP worker หนึ่งตัว ข้อกำหนดของระบบ Nextcloud ระบุหน่วยความจำ ต่อกระบวนการ (process) ไว้ที่ขั้นต่ำ 128 MB และแนะนำที่ 512 MB (ข้อมูล ณ เดือนสิงหาคม 2026) ซึ่งไม่ใช่ยอดรวมของทั้งเซิร์ฟเวอร์ การมี pool ของ worker จำนวน 10 ตัวถือเป็นภาระหน่วยความจำที่สูงมากสำหรับแผนบริการ 2 GB ดังนั้นผู้ดูแลระบบจึงมักลดค่า pm.max_children ในไฟล์ตั้งค่า PHP-FPM pool ส่งผลให้คำขอต่างๆ ต้องเข้าคิวรอ worker ที่มีอยู่จำกัด อินเทอร์เฟซจึงตอบสนองช้าในขณะที่ดิสก์ไม่ได้ทำงานหนัก

ฐานข้อมูลจะขยายตัวตามจำนวนไฟล์ ไม่ใช่ขนาดของไฟล์ ตาราง file cache หรือ oc_filecache ภายใต้คำนำหน้าตาราง (table prefix) เริ่มต้น จะเก็บข้อมูลหนึ่งแถวต่อหนึ่งไฟล์และหนึ่งโฟลเดอร์ในทุกแหล่งเก็บข้อมูลที่เซิร์ฟเวอร์รู้จัก คลังรูปภาพที่มีไฟล์ขนาดเล็ก 300,000 ไฟล์จะทำให้ตารางนี้มีขนาดใหญ่มาก ในขณะที่ไฟล์วิดีโอขนาด 300 GB ที่มีจำนวนไฟล์เพียง 400 ไฟล์จะถือเป็นตารางขนาดเล็ก การแชร์ การค้นหา และการสแกนไฟล์ล้วนต้องอ่านข้อมูลจากตารางนี้ทั้งสิ้น

sudo mysql nextcloud -e 'SELECT COUNT(*) FROM oc_filecache;'

จำนวนไฟล์ในระดับล้านรายการเป็นคำอธิบายที่ดีกว่าผลการทดสอบความเร็วของดิสก์ว่าเหตุใดรายการไฟล์จึงโหลดช้า หาก instance ของคุณใช้คำนำหน้าตารางอื่นหรือใช้ PostgreSQL ให้ปรับเปลี่ยนคำสั่ง query ตามความเหมาะสม

งานเบื้องหลัง (Background jobs) แย่งทรัพยากรกับอินเทอร์เฟซเว็บ คู่มือของ Nextcloud แนะนำให้ตั้งค่า system cron เพื่อรัน cron.php ทุกๆ 5 นาที การสร้างภาพตัวอย่าง (preview) และการสแกนไฟล์จะทำงานในส่วนนี้ ซึ่งใช้ CPU ตัวเดียวกับที่ให้บริการเบราว์เซอร์ของคุณ

การอัปเกรดเวอร์ชันหลักคือการย้ายฐานข้อมูล (database migration) ระบบจะเข้าสู่โหมดบำรุงรักษา (maintenance mode) และตอบกลับทุกคำขอด้วย Nextcloud is in maintenance mode, please try again later จนกว่าการย้ายข้อมูลจะเสร็จสิ้น บน VPS ขนาดเล็กที่มี oc_filecache ขนาดใหญ่ ช่วงเวลานี้จะนานจนสังเกตเห็นได้ชัดเจน

ตัดสินใจเลือกสิ่งที่ต้องการเก็บไว้ก่อน

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

Syncthing: การซิงค์ไฟล์โดยไม่ต้องใช้แอปพลิเคชันฝั่งเซิร์ฟเวอร์

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

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

sudo systemctl enable --now syncthing@$USER
sudo ss -lntp | grep 8384

บรรทัดที่แสดง 127.0.0.1:8384 หมายความว่าเว็บอินเทอร์เฟซกำลังทำงานและผูกอยู่กับ localhost เท่านั้น ซึ่งเป็นสิ่งที่คุณต้องการเมื่อใช้งานบน VPS สาธารณะ คุณสามารถเข้าถึงได้ผ่าน SSH tunnel ด้วยคำสั่ง ssh -L 8384:127.0.0.1:8384 you@your-vps จากนั้นเปิด http://127.0.0.1:8384 บนแล็ปท็อปของคุณ หากไม่มีการฟังพอร์ต 8384 แสดงว่าบริการเริ่มทำงานไม่สำเร็จ และ journalctl -u syncthing@$USER -n 50 จะระบุสาเหตุที่เกิดขึ้น

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

พื้นที่ดิสก์คือต้นทุนที่แท้จริง ไม่มีการประหยัดพื้นที่ฝั่งเซิร์ฟเวอร์เนื่องจาก Syncthing ไม่ใช่เซิร์ฟเวอร์ โฟลเดอร์ขนาด 200 GB ที่แชร์ระหว่าง VPS และแล็ปท็อปจำเป็นต้องใช้พื้นที่ 200 GB ทั้งสองฝั่ง ซึ่งตรงข้ามกับ Nextcloud ที่เซิร์ฟเวอร์เก็บข้อมูลทั้งหมดไว้และไคลเอนต์เลือกเฉพาะสิ่งที่ต้องการซิงค์ ให้ใช้การเลือกโฟลเดอร์เฉพาะส่วนและโฟลเดอร์ receive only บน VPS หากคุณต้องการให้ VPS ทำหน้าที่เป็นจุดสำรองข้อมูลมากกว่าจะเป็น peer ที่เท่าเทียมกัน

การย้ายข้อมูลคือเหตุผลที่ควรเลือกใช้ คุณสามารถชี้ Syncthing ไปยังโครงสร้างไดเรกทอรีที่คุณมีอยู่แล้วได้ทันที ไม่มีการนำเข้า ไม่มีการอัปโหลด และไม่มีการแปลงรูปแบบไฟล์ เพียงเพิ่มโฟลเดอร์บน VPS และเพิ่มโฟลเดอร์เดียวกันบนแล็ปท็อปโดยใช้ Folder ID เดียวกัน แล้วปล่อยให้ทั้งสองฝั่งซิงค์ข้อมูลเข้าหากัน หากไฟล์เดียวกันมีความแตกต่างกันในตอนที่เริ่มเชื่อมต่อครั้งแรก Syncthing จะเก็บไว้ทั้งสองเวอร์ชันและเปลี่ยนชื่อไฟล์หนึ่งให้เป็น filename.sync-conflict-20260809-142530-ABCD123.txt การพบไฟล์เหล่านี้เป็นเรื่องปกติในการซิงค์ครั้งแรก ไม่ใช่ความล้มเหลวของระบบ

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

Seafile: การซิงค์ที่รวดเร็วด้วยเซิร์ฟเวอร์ที่เบากว่า

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

sudo mkdir -p /opt/seafile
cd /opt/seafile
sudo wget -O .env https://manual.seafile.com/13.0/repo/docker/ce/env
sudo wget https://manual.seafile.com/13.0/repo/docker/ce/seafile-server.yml
sudo wget https://manual.seafile.com/13.0/repo/docker/seadoc.yml
sudo wget https://manual.seafile.com/13.0/repo/docker/caddy.yml

แก้ไข .env ก่อนเริ่มดำเนินการใดๆ ไฟล์นี้จะกำหนดค่า SEAFILE_SERVER_HOSTNAME, INIT_SEAFILE_ADMIN_EMAIL, INIT_SEAFILE_ADMIN_PASSWORD, SEAFILE_MYSQL_DB_PASSWORD และ JWT_PRIVATE_KEY ซึ่งต้องเป็นสตริงสุ่มที่มีความยาวอย่างน้อย 32 ตัวอักษร นอกจากนี้ไฟล์ดังกล่าวยังระบุให้ compose ทราบว่าจะอ่านไฟล์ YAML ที่ดาวน์โหลดมาไฟล์ใดบ้าง เพื่อให้การดาวน์โหลดทั้งสี่ไฟล์ทำงานร่วมกันเป็น stack เดียว

cd /opt/seafile
sudo docker compose up -d
sudo docker compose ps

คอนเทนเนอร์ทุกตัวควรแสดงสถานะว่ากำลังทำงานอยู่ หากคอนเทนเนอร์มีการรีสตาร์ทวนซ้ำ มักเกิดจากค่าที่ขาดหายไปใน .env โดย sudo docker compose logs seafile จะระบุว่าคอนเทนเนอร์ใดที่มีปัญหา

ทรัพยากรระบบ เอกสารของ Seafile ระบุความต้องการขั้นต่ำที่ RAM 2 GB และ CPU 2 คอร์ ที่ความเร็วสูงกว่า 2 GHz ณ เดือนสิงหาคม 2026 ให้ถือว่านี่คือค่าต่ำสุดสำหรับทั้ง stack เนื่องจากในการติดตั้งแบบ Docker จะมีการเริ่ม MariaDB, reverse proxy อย่าง Caddy และโปรแกรมแก้ไข SeaDoc ด้วย หากมีผู้ใช้งานมากกว่าหนึ่งหรือสองคน ควรจัดสรร RAM ให้ 4 GB หรือเลือกตัดคอนเทนเนอร์ที่ไม่จำเป็นออก

ข้อควรระวังในการย้ายข้อมูลคือรูปแบบการจัดเก็บ Seafile ไม่ได้เก็บไฟล์ของคุณในรูปแบบไฟล์ปกติ แต่จะแบ่งไฟล์แต่ละไฟล์ออกเป็นบล็อกภายใต้ /opt/seafile-data และบันทึกโครงสร้างไว้ในฐานข้อมูล คุณไม่สามารถชี้ Seafile ไปยังไดเรกทอรีที่มีอยู่เดิมเพื่อให้แสดงเป็นไลบรารีได้ ดังนั้นการย้ายข้อมูลเข้ามาจึงหมายถึงการอัปโหลดข้อมูลทั้งหมดที่คุณมีใหม่หนึ่งรอบ การออกแบบนี้ยังหมายความว่าคุณไม่สามารถดึงข้อมูลออกมาโดยตรงด้วย cp ได้ การกู้คืนข้อมูลต้องทำผ่านเซิร์ฟเวอร์, การใช้ seaf-fsck เพื่อตรวจสอบความถูกต้องของข้อมูล หรือการ mount แบบอ่านอย่างเดียวผ่าน seaf-fuse

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

rclone config
rclone copy /srv/files seafile:MyLibrary --progress

เอกสารของ rclone ระบุว่าได้ทดสอบกับ Seafile เวอร์ชัน 6.x ถึง 9.x แล้ว ดังนั้นควรทดสอบกับโฟลเดอร์ขนาดเล็กก่อนที่จะเริ่มอัปโหลดข้อมูลขนาดหนึ่งเทราไบต์

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

Object storage พร้อมไคลเอนต์สำหรับซิงค์ข้อมูล

หากเป้าหมายคือการจัดเก็บข้อมูลจำนวนมากในราคาประหยัดและสามารถเข้าถึงได้ผ่านสคริปต์ ให้รัน object store ที่รองรับ S3 และจัดการการซิงค์เป็นเครื่องมือแยกต่างหาก คุณจะได้รับความทนทาน (durability), การทำ versioning และโปรโตคอลที่เครื่องมือสำรองข้อมูลส่วนใหญ่รองรับอยู่แล้ว แต่คุณจะไม่มีระบบบัญชีผู้ใช้ในรูปแบบ file-server หรือตัวจัดการไฟล์ที่ใช้งานได้สะดวก การทำ Self-hosted object storage ด้วย MinIO ครอบคลุมรายละเอียดฝั่งเซิร์ฟเวอร์

rclone copy /srv/files s3remote:mybucket --progress
rclone check /srv/files s3remote:mybucket

rclone check จะเปรียบเทียบข้อมูลทั้งสองฝั่งโดยใช้ขนาดและค่า hash จากนั้นจะแสดงจำนวนไฟล์ที่แตกต่างกัน หากผลลัพธ์ไม่ใช่ศูนย์แสดงว่าการคัดลอกข้อมูลยังไม่สมบูรณ์ ดังนั้นให้รัน copy อีกครั้งก่อนที่จะลบข้อมูลต้นทาง สิ่งที่ควรทราบมีสองประการ: object storage ไม่มีโครงสร้างไดเรกทอรีจริง มีเพียง key prefixes เท่านั้น ดังนั้นโฟลเดอร์ว่างจะไม่ถูกคัดลอกไปด้วย และการเพิ่มค่า --transfers พร้อมกับ S3 chunk size คือสาเหตุที่ทำให้ rclone ใช้หน่วยความจำเพิ่มขึ้น ดังนั้นควรคงค่าเริ่มต้นไว้หากใช้งานบน VPS ขนาด 1 GB

การใช้ WebDAV หรือ SFTP แบบปกติเมื่อคุณต้องการเพียงแค่เข้าถึงไฟล์จากระยะไกล

ทางเลือกที่ประหยัดที่สุดมักจะเป็นการไม่ติดตั้งอะไรเพิ่มเลย หาก VPS ของคุณรัน OpenSSH อยู่แล้ว คุณก็มีเซิร์ฟเวอร์สำหรับเก็บไฟล์ใช้งานได้ทันที SFTP ไม่จำเป็นต้องใช้ daemon เพิ่มเติม ไม่ต้องมีฐานข้อมูล ไม่ต้องใช้ PHP และไม่ต้องคอยอัปเดตซึ่งอาจทำให้ระบบพังในวันหยุดได้

sftp you@your-vps
rclone mount sftpremote: ~/vps --vfs-cache-mode writes

สำหรับไคลเอนต์ที่รองรับโปรโตคอล WebDAV ซึ่งรวมถึงแอปจัดการไฟล์บนโทรศัพท์ส่วนใหญ่ rclone สามารถทำหน้าที่ให้บริการไฟล์ในโครงสร้างเดียวกันได้

sudo apt install apache2-utils
sudo htpasswd -c /etc/rclone/htpasswd you
rclone serve webdav --addr 127.0.0.1:8080 --htpasswd /etc/rclone/htpasswd /srv/files

ให้ผูกบริการไว้กับ 127.0.0.1 และวาง reverse proxy ที่มี TLS (transport layer security) ไว้ด้านหน้า การยืนยันตัวตนแบบ basic authentication ของ WebDAV จะส่งรหัสผ่านไปพร้อมกับทุกคำขอ ดังนั้นการใช้ HTTP แบบปกติในกรณีนี้จึงเท่ากับการส่งรหัสผ่านผ่านเครือข่ายหลายครั้งต่อนาที ต้นทุนในการย้ายระบบเป็นศูนย์เพราะไฟล์ไม่ต้องถูกย้ายไปไหน ข้อเสียคือไม่มีระบบซิงค์และไม่มีสำเนาแบบออฟไลน์ เมื่อการเชื่อมต่อขาดหายไป ไฟล์บนไคลเอนต์ก็จะเข้าถึงไม่ได้จนกว่าการเชื่อมต่อจะกลับมาใช้งานได้อีกครั้ง

สิ่งที่ใช้แทนปฏิทิน รายชื่อผู้ติดต่อ และการแก้ไขเอกสาร

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

sudo apt install radicale
sudo systemctl enable --now radicale
sudo ss -lntp | grep 5232

แพ็กเกจนี้มาพร้อมกับ /usr/lib/systemd/system/radicale.service และมีค่าคอนฟิกเริ่มต้นอยู่ที่ /etc/radicale/config โดยจะรอรับการเชื่อมต่อที่ localhost:5232 เนื่องจาก Radicale ไม่มีอินเทอร์เฟซสำหรับแก้ไขกิจกรรม คุณจึงต้องเชื่อมต่อผ่านแอปพลิเคชันบนโทรศัพท์หรือเดสก์ท็อปเพื่อจัดการข้อมูลเหล่านั้น

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

คงการใช้งาน Nextcloud ไว้หากเงื่อนไขเหล่านี้เป็นจริง

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

สำหรับงานเหล่านี้ยังไม่มีโซลูชันอื่นที่มีน้ำหนักเบากว่าและสามารถทำได้ครบถ้วน การตัดสินใจที่ตรงไปตรงมาที่สุดคือการแก้ไขการติดตั้งเดิมให้ดีขึ้นแทนที่จะเปลี่ยนไปใช้ระบบอื่น อินสแตนซ์ส่วนใหญ่ที่ทำงานช้าเกิดจากการใช้ PHP-FPM pool ค่าเริ่มต้นโดยไม่ได้ตั้งค่า memory cache ซึ่งหน้าภาพรวมผู้ดูแลระบบของ Nextcloud จะแจ้งเตือนหากไม่มีการตั้งค่า cache ไว้ การลดจำนวนไฟล์ที่ระบบต้องติดตามส่งผลดีมากกว่าการปรับแต่งเพียงจุดเดียว เพราะตาราง file cache คือส่วนที่ขยายตัวได้มากที่สุด การติดตั้ง Nextcloud บน VPS ด้วย Docker, TLS และการสำรองข้อมูล ได้แนะนำวิธีการตั้งค่าที่ช่วยหลีกเลี่ยงปัญหาเหล่านี้ส่วนใหญ่ได้

ต้นทุนที่แท้จริงของการย้ายข้อมูล แยกตามตัวเลือก

• Syncthing: ไม่มีการนำเข้าข้อมูล เพียงแค่ชี้ไปยังโครงสร้างไฟล์ที่คุณมีอยู่แล้วทั้งสองฝั่ง แล้วปล่อยให้ระบบซิงค์ข้อมูลเข้าหากัน
• SFTP หรือ WebDAV บนโครงสร้างไฟล์เดิม: ไม่ต้องนำเข้าข้อมูลใดๆ เพราะไม่มีการย้ายไฟล์
• Object storage: ต้องคัดลอกผ่านเครือข่ายหนึ่งรอบเต็ม สามารถทำต่อจากจุดเดิมและเขียนสคริปต์ควบคุมได้ แต่โฟลเดอร์ว่างจะไม่ถูกคัดลอกไปด้วย
• Seafile: ต้องอัปโหลดข้อมูลทั้งหมดเข้าสู่ libraries หนึ่งรอบเต็ม เนื่องจากเซิร์ฟเวอร์จัดเก็บข้อมูลในรูปแบบ blocks แทนที่จะเป็นไฟล์ปกติ

ไม่ว่าคุณจะเลือกวิธีใด ให้คัดลอกข้อมูลที่สะอาดออกมาจาก Nextcloud ก่อนเสมอ ไฟล์ของผู้ใช้จะอยู่ในไดเรกทอรี data ในรูปแบบปกติ โดยแยกเป็นโฟลเดอร์ตามรายชื่อผู้ใช้ ดังนั้น rsync ของโครงสร้างไฟล์นั้นคือแหล่งข้อมูลของคุณ ให้ตั้งค่าอินสแตนซ์เป็น maintenance mode ก่อนเริ่มคัดลอก มิฉะนั้นคุณอาจได้ไฟล์ที่คัดลอกมาในขณะที่ระบบกำลังเขียนข้อมูลอยู่

sudo -u www-data php occ maintenance:mode --on
sudo rsync -a --info=progress2 /path/to/nextcloud/data/ /srv/files/
find /srv/files -type f | wc -l

เปรียบเทียบจำนวนไฟล์ที่นับได้กับ find เดียวกันบนแหล่งข้อมูลต้นทาง หากจำนวนน้อยกว่าปกติ มักหมายความว่าสิทธิ์การเข้าถึง (permissions) ทำให้ rsync ไม่สามารถอ่านไฟล์บางรายการได้ ซึ่งระบบจะแสดงข้อผิดพลาดเหล่านั้นออกมาในระหว่างดำเนินการ

มีกับดักสองประการในการคัดลอกนี้ ประการแรก ไฟล์ที่เข้าถึงผ่านฟีเจอร์ external storage ของ Nextcloud จะไม่อยู่ในไดเรกทอรี data เลย เนื่องจากไฟล์เหล่านั้นถูกเก็บไว้บนระบบภายนอกที่ Nextcloud เชื่อมต่อไว้ ประการที่สอง หากเคยเปิดใช้งานการเข้ารหัสฝั่งเซิร์ฟเวอร์ (server-side encryption) ไฟล์ที่อยู่บนดิสก์จะเป็น ciphertext ดังนั้นต้องรัน occ encryption:decrypt-all ก่อนทำการคัดลอก มิฉะนั้นคุณจะย้ายโฟลเดอร์ที่เต็มไปด้วยข้อมูลที่อ่านไม่ได้ไปแทน ตรวจสอบทั้งสองประเด็นนี้ก่อนที่คุณจะยกเลิกการดำเนินการใดๆ

FAQ

มีทางเลือกอื่นแทน Nextcloud ที่ยังคงโครงสร้างโฟลเดอร์เดิมของฉันไว้หรือไม่?

Syncthing รวมถึงการตั้งค่าผ่าน SFTP หรือ WebDAV แบบปกติทั่วไป Syncthing จะทำดัชนีไดเรกทอรีที่คุณกำหนดและคงชื่อรวมถึงโครงสร้างเดิมไว้ในทุกอุปกรณ์ จึงไม่มีขั้นตอนการนำเข้าหรือการอัปโหลดข้อมูลใหม่ ในขณะที่ Seafile และ object storage จำเป็นต้องผ่านขั้นตอนการอัปโหลดข้อมูลทั้งหมดใหม่ เนื่องจากทั้งสองระบบไม่ได้จัดเก็บข้อมูลของคุณเป็นไฟล์ปกติในโครงสร้างต้นไม้ทั่วไป โดย Seafile จะแบ่งไฟล์ออกเป็นบล็อกย่อยๆ ภายใต้ไดเรกทอรีข้อมูลของมัน ส่วน object storage จะใช้คีย์แทนการใช้ไดเรกทอรี

Seafile สามารถรันบน VPS ขนาด 2 GB ได้หรือไม่?

เอกสารของ Seafile ระบุความต้องการขั้นต่ำไว้ที่ RAM 2 GB และ CPU 2 คอร์ ที่ความเร็วสูงกว่า 2 GHz ณ เดือนสิงหาคม 2026 ให้ถือว่านี่คือค่าต่ำสุดที่ไม่มีพื้นที่เหลือให้ระบบทำงานได้คล่องตัวนัก เนื่องจากในการติดตั้งแบบ Docker จะต้องรัน MariaDB, Caddy และ SeaDoc editor ในคอนเทนเนอร์แยกกัน สำหรับผู้ใช้คนเดียวถือว่าใช้งานได้ แต่สำหรับครอบครัวหรือทีมขนาดเล็ก ควรขยับไปใช้ 4 GB หรือตัดคอนเทนเนอร์ SeaDoc ออกจาก stack เพื่อแลกกับการไม่สามารถแก้ไขเอกสารผ่านเบราว์เซอร์ได้

ทำไมหน้าเว็บอินเทอร์เฟซของ Nextcloud ถึงช้าทั้งที่ความเร็วในการดาวน์โหลดไฟล์ยังคงเร็วอยู่?

เพราะทั้งสองส่วนทำงานต่างกัน การดาวน์โหลดคือการสตรีมไบต์จากดิสก์โดยตรง ในขณะที่การโหลดหน้าเว็บต้องรัน PHP, คิวรีตารางแคชไฟล์ และมักจะต้องรอคิวว่างจาก PHP-FPM worker ให้ตรวจสอบจำนวนแถวใน oc_filecache และตรวจสอบ pm.max_children ในพูล PHP-FPM ของคุณก่อนที่จะโทษระบบจัดเก็บข้อมูล ตารางที่มีข้อมูลหลายล้านแถวและพูลที่มี worker เพียง 5 ตัว จะทำให้เกิดอาการช้าในลักษณะนี้อย่างชัดเจน

ฉันสามารถใช้ Nextcloud สำหรับปฏิทินต่อไป แต่ย้ายเฉพาะไฟล์ออกไปได้หรือไม่?

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