Seafile או Nextcloud: השוואת מערכות לסנכרון קבצים

ההבדל בין Seafile לבין Nextcloud: התשובה הקצרה

ההבדל בין Seafile לבין Nextcloud מסתכם בנקודה אחת: כיצד נשמר קובץ ברגע שהוא מגיע לשרת. Seafile מפצלת כל קובץ לבלוקים ומאחסנת אותם בתוך מאגר אובייקטים שרק Seafile מסוגלת לקרוא, ולכן הסנכרון מהיר והגיבוי הופך למשימה דו-שלבית. Nextcloud כותבת את הקובץ לדיסק כקובץ רגיל, ומתייחסת לסנכרון כאל תכונה אחת מתוך פלטפורמה שמריצה גם יומנים, אנשי קשר, מסמכים וקישורי שיתוף. החליטו על בסיס הבדל זה, שכן כל השאר נגזר ממנו.

נכון לאוגוסט 2026, Seafile נמצאת בסדרת גרסאות 13.0 ו-Nextcloud בסדרת 34. שתי המערכות בשלות, ואף אחת מהן לא עומדת לשנות את מודל האחסון שלה.

כיצד Seafile מאחסן את הקבצים שלך

Seafile ממדל ספרייה (library) באותו אופן שבו git ממדל מאגר (repository). המדריך למנהל מערכת מציג את המודל הפנימי כ-Repo, Commit, FS ו-Block, ומציין שמאגר נקרא לעיתים גם ספרייה. כל קובץ מפוצל לבלוקים באורך משתנה באמצעות טכניקת Content Defined Chunking (או בקיצור CDC, אלגוריתם שבוחר את גבולות הבלוק מתוך הנתונים עצמם), והמדריך מציין שגודל בלוק ממוצע הוא כ-8 MB. הבלוקים נקראים על שם התוכן שלהם, כך ששתי גרסאות של קובץ גדול חולקות כל בלוק שלא השתנה, ושתי ספריות חולקות בלוקים זהים ביניהן.

מסד הנתונים היחסי מחזיק רק כמות קטנה של מטא-דאטה על הספריות. כל השאר, כלומר ה-commits, אובייקטי הספריות והבלוקים, נמצאים תחת ספריית הנתונים. בפריסת ה-Docker המשמשת את סדרות 12 ו-13, מדובר ב-/opt/seafile-data/seafile/seafile-data. הרצת ls שם לא תספק מידע שימושי, כיוון שתראה ספריות מלאות בשמות hash, ולא Invoices/2026/march.pdf.

סנכרון עוקב אחר אותו מודל. הלקוח שואל את השרת מה השתנה, מקבל רשימה של hash של בלוקים, ומושך רק את הבלוקים שעדיין אין ברשותו. זו הסיבה ש-Seafile מתפקד היטב עם ספריות גדולות: כמות הבייטים המועברים פרופורציונלית לבלוקים שהשתנו, ולא לגודל הקובץ המכיל אותם.

כיצד Nextcloud מאחסן את הקבצים שלך

Nextcloud מציב את הקובץ בדיסק במיקום הצפוי. הנתיב data/<username>/files/ משקף את מה שהמשתמש רואה בממשק האינטרנט. טבלת מסד נתונים, oc_filecache, משקפת את אותו עץ קבצים עם גדלים, זמני שינוי ו־etags, ו־Nextcloud מסתמך על הטבלה ולא על הדיסק עצמו.

לקוח שולחן העבודה מתקשר באמצעות פרוטוקול WebDAV (web distributed authoring and versioning) על גבי HTTPS. כל קובץ דורש לפחות בקשה אחת, וזו הסיבה ש־Nextcloud הוסיף API להעלאה מרוכזת: המדריך למפתח מסביר שהעלאת קבצים קטנים רבים איטית מהפוטנציאל שלהם, כיוון שרוחב הפס של הרשת אינו מנוצל במלואו, ולכן קבצים קטנים נארזים יחד. קבצים גדולים עוברים דרך ה־API של חלוקה למקטעים (chunking), כאשר גודל המקטע המוגדר כברירת מחדל בלקוח שולחן העבודה הוא 5 MiB (הערך OWNCLOUD_CHUNK_SIZE מוגדר כברירת מחדל ל-5242880 בתים).

היתרון באחסון קבצים ישירות על הדיסק הוא שכל כלי עבודה קיים יכול לקרוא את הנתונים שלך. החיסרון הוא ש־Nextcloud אינו מזהה שינויים שבוצעו "מאחורי הגב" שלו. אם תעתיק קבצים ישירות לתוך תיקיית הנתונים, הם יישארו בלתי נראים בממשק האינטרנט עד שתבצע סריקה:

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

מדריך הניהול מציין בדיוק את המקרים הללו לצורך סריקה מחדש: לאחר העתקת קבצים ישירות לתיקיית הנתונים, לאחר הגירה (migration), וכאשר בודקים חוסר עקביות במטמון הקבצים.

איזה פתרון מסנכרן ספרייה גדולה מהר יותר?

Seafile, בשני המקרים שבהם הביצועים נפגעים: עשרות אלפי קבצים קטנים, ועריכות חוזרות ונשנות בקבצים גדולים. המנגנון מבוסס על deduplication ברמת הבלוק, כך שקובץ 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 דורש "לפחות 2GB RAM ומעבד בעל 2 ליבות (מעל 2GHz)". התיעוד של Nextcloud מפרט זיכרון לפי תהליך PHP: מינימום של 128MB ומומלץ 512MB לכל תהליך, אותם יש להכפיל במספר ה-workers לפני הוספת מסד הנתונים, ה-cache ויצירת התצוגות המקדימות. להלן נקודות ההתחלה שבהן הייתי משתמש עבור צוות קטן. אלו נקודות מוצא, לא מדידות מדויקות.

[
  {
    "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 עם 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, חשבון ה-admin הראשוני, ו-JWT_PRIVATE_KEY. המדריך דורש מחרוזת אקראית באורך של לא פחות מ-32 תווים עבור מפתח זה, והוא נקרא בהפעלה הראשונה, לכן צרו אותו לפני העלאת ה-stack:

openssl rand -base64 40
docker compose up -d

ההפעלה הראשונה יוצרת את שלושת מסדי הנתונים ואת משתמש ה-admin. ההחלטות המקבילות עבור 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 אינה מומלצת עוד ב-image של 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. שחזרו את שני החלקים מאותה נקודת זמן. אם ספריית הנתונים חדשה יותר ממסד הנתונים, משתמשים יראו קבצים שמטמון הקבצים אינו מכיר, ו-occ files:scan --all יתקן זאת. אם מסד הנתונים חדש יותר, שורות במטמון יצביעו על קבצים שכבר אינם קיימים, ו-occ files:cleanup יסיר רשומות מטמון שאין להן רשומה תואמת בטבלת האחסון.

בכל מקרה, אתם זקוקים לתוכנית גיבוי שמתמודדת עם קבצים קטנים רבים ושומרת היסטוריה, וזה מה ש-restic ו-BorgBackup עושים בצורה שונה.

לקוחות לשולחן העבודה ולמכשירים ניידים

Seafile מפיצה שתי תוכנות לשולחן העבודה. לקוח הסנכרון שומר עותק מקומי של הספריות שתבחרו. לקוח ה-Drive‏ (SeaDrive) מעגן את הספריות שלכם ככונן וירטואלי ומוריד קבצים בעת גישה אליהם: ב-Windows הוא משתמש ב-API של קבצי ענן מבית Microsoft, ב-macOS גרסה 3.0 היא תוסף ל-Finder, וב-Linux הוא מופץ כ-AppImage החל מגרסה 3.0.12 ומעוגן ב-~/SeaDrive. ספריות מוצפנות עובדות בכל שלוש פלטפורמות שולחן העבודה. האפליקציות לנייד נועדו לגישה לקבצים, וזהו כל תפקידן.

לקוח שולחן העבודה של Nextcloud מציע גם הוא קבצים וירטואליים, והאפליקציות לנייד שלו כוללות את שאר הפלטפורמה, כך שיומן, אנשי קשר, Talk ופתקים זמינים לצד הגישה לקבצים. אם המשתמשים שלכם מסתמכים על טלפונים וזקוקים ליותר מאשר רק קבצים, מדובר בהבדל משמעותי בשימוש היומיומי.

פרט אחד ב-Seafile דורש תכנון מראש: הספרייה היא יחידת השיתוף, הסנכרון, ההרשאות וההצפנה. החליטו על מבנה הספריות שלכם לפני שתטעינו 500 GB לתוך ספרייה בודדת, כיוון שהעברה בין ספריות היא פעולת העתקה ומחיקה, לא שינוי שם, ולכן היסטוריית הקבצים אינה עוברת יחד איתם.

הצפנה: מה מוגן בפועל בכל מקרה

ספריות מוצפנות ב-Seafile מבוססות על הצפנת צד-לקוח (client side). הסיסמה לעולם אינה נשמרת בשרת. אסימון (token) ייחודי שנגזר מהסיסמה וממזהה הספרייה נשמר לצד הספרייה, כדי לאפשר ללקוח לאמת את הסיסמה לפני ביצוע הסנכרון. מפתח הקובץ מוצפן באמצעות מפתח ו-IV (וקטור אתחול) הנגזרים מהסיסמה שלכם בשיטת AES 256/CBC, ונתוני הקובץ עצמם מוצפנים באמצעות מפתח קובץ זה.

קראו את המגבלות המתועדות, שכן משתמשים רבים מחמיצים אותן. ספרייה מוצפנת מצפינה את תוכן הקבצים בלבד. שמות תיקיות וקבצים אינם מוצפנים, וכך גם גדלי קבצים או היסטוריית העריכה. עיון בספרייה מוצפנת דרך דפדפן אינו מקצה-לקצה (end to end): אתם מזינים את הסיסמה, השרת משתמש בה כדי לפענח את מפתח הקובץ, והוא שומר את הסיסמה בזיכרון למשך שעה אחת. המדריך מציין במפורש שספרייה מוצפנת אינה מבטיחה שלמות נתונים, שכן מנהל השרת יכול לשנות חלק מתוכן הקובץ והלקוח לא יוכל לזהות זאת.

ל-Nextcloud יש שתי תכונות עם שמות דומים באופן מבלבל. הצפנת צד-שרת (server side encryption) מצפינה קבצים במצב מנוחה (at rest), אך שומרת את המפתחות על אותו שרת; לכן, היא מגנה על נתונים המאוחסנים באחסון חיצוני הרבה יותר מאשר היא מגנה עליכם מפני גורם בעל הרשאות root על השרת. אפליקציית ההצפנה מקצה-לקצה (end to end encryption) מצפינה תיקיות נבחרות בצד הלקוח, ומתוקף התכנון, השרת אינו יכול לקרוא אותן. כתוצאה מכך, ממשק האינטרנט, החיפוש בצד השרת והתצוגות המקדימות אינם יכולים לראות את תוכן התיקיות הללו.

ההצפנה של אף אחד מהמוצרים הללו אינה מהווה תחליף לגיבוי מוצפן. הצפינו את הגיבוי בנפרד.

יומנים, אנשי קשר, משרד ופלטפורמת היישומים

ציר זה אינו סגור. Nextcloud כוללת בליבה CalDAV (יומן מבוסס WebDAV) ו-CardDAV (אנשי קשר מבוססי WebDAV), משלבת את Collabora או OnlyOffice עבור מסמכים, ומציעה חנות יישומים לכל השאר. Seafile 13 כוללת את SeaDoc עבור מסמכי עבודה משותפים ודפי wiki, ועוצרת שם. אין בה יומן או פנקס כתובות.

לפלטפורמה יש מחיר, והמחיר הוא שדרוגים. כל יישום שמותקן הוא רכיב נוסף שעלול לחסום שדרוג של Nextcloud או להשתבש לאחריו; ככל שהמשתמשים שלכם תלויים ביותר רכיבים, כך חלון השדרוג שלכם הופך לרגיש יותר. ב-Seafile יש פחות רכיבים שעלולים להישבר כי היא עושה פחות. שימו לב גם ש-Seafile Professional, ולא ה-Community Edition, היא זו שמוסיפה חיפוש טקסט מלא בתוך מסמכים והרשאות ברמת תיקייה תחת רישיון בתשלום, לכן ודאו שהתכונה שעליה אתם מסתמכים אכן קיימת במהדורה שאתם מתכננים להריץ.

דפוסי הכשל המוכרים של כל שירות

Seafile נכשל כאשר קיים חוסר התאמה בין מסד הנתונים לבין ה-object store. במצב זה, ספרייה לא תיפתח או שקבצים ייעלמו, והפקודה seaf-fsck.sh תציג את הבלוק החסר. אין עץ קבצים שניתן לתקן ידנית, לכן השחזור מחייב שימוש ב-database dump וב-object store, תוך הקפדה על סדר שחזור נכון. בצעו בדיקת שחזור פעם אחת על שרת VPS פנוי, שכן גיבוי שלא שוחזר מעולם הוא בגדר ניחוש בלבד.

Nextcloud נכשל כאשר קיים חוסר התאמה בין ה-file cache לבין הדיסק, לרוב בגלל כתיבה ישירה לתיקיית הנתונים ללא עדכון של Nextcloud. במצב זה, יופיע קובץ בדיסק שאינו מופיע בממשק האינטרנט, או שגודל תיקייה יוצג באופן שגוי; הפקודה occ files:scan היא הפתרון לכך. שתי נקודות תורפה נוספות הן מהירות הפרוטוקול בעבודה עם מספר רב של קבצים קטנים, דבר ששום עוצמת מעבד לא תפתור, וצריכת הזיכרון של PHP: יצירת תצוגה מקדימה (previews) עבור תמונות וסרטונים גדולים גורמת בדרך כלל לקפיצות בשימוש בזיכרון, לכן הקצו 512 MB לכל תהליך ובצעו את יצירת התצוגות המקדימות כ-scheduled job ולא בזמן אמת במהלך בקשות משתמש.

אף אחד מהם: 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, כדי שלקבצים שהוא כותב יהיו הרשאות בעלות תקינות:

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

ממשק האינטרנט מאזין כברירת מחדל ל-127.0.0.1:8384, לכן הוא אינו נגיש מהאינטרנט, וזו ברירת המחדל הנכונה. גש אליו דרך מנהרת SSH מהמחשב הנייד שלך:

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

לאחר מכן פתח את http://127.0.0.1:8384 במחשב הנייד. Syncthing עצמו משתמש בפורט 22000 מעל TCP ו-QUIC, וגילוי מקומי משתמש ב-UDP 21027, שאינו פועל מעבר לאינטרנט. ב-VPS, פתח את 22000 והשאר את הממשק סגור:

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

מה שאתה מוותר עליו הוא כל תכונות השרת: אין קישורי שיתוף לאנשים שאינם מריצים את Syncthing, אין דפדפן קבצים מבוסס אינטרנט, אין חשבונות משתמש, ואין סל מחזור בצד השרת אלא אם תפעיל גרסאות קבצים (file versioning) לכל תיקייה. ההפתעה הקלאסית היא קובץ הקונפליקט. אם תערוך קובץ אחד בשני התקנים בזמן שהם אינם יכולים לראות זה את זה, תקבל קובץ תאום בשם כמו notes.sync-conflict-20260806-142233-ABCD1EF.md. שום דבר לא מתריע על כך, לכן חפש sync-conflict מדי פעם.

אם מה שאתה מחפש אינו תיקייה מסונכרנת אלא דלי (bucket) שיישומים כותבים אליו, מדובר בכלי שונה לחלוטין: עיין ב-אחסון אובייקטים תואם S3 באירוח עצמי. לתחום הרחב יותר, סקירת החלופות ל-Dropbox באירוח עצמי מכסה את מה שלא נכנס להשוואה זו.

כללי ההחלטה

1. בחרו ב-Seafile אם המשימה היא סנכרון לפי נפח: קבצים רבים, קבצים גדולים, מספר התקנים, ואתם מקבלים את העובדה שמאגר הנתונים ניתן לקריאה על ידי Seafile בלבד.
2. בחרו ב-Nextcloud אם המשימה היא פלטפורמה: יומנים, אנשי קשר, מסמכים וקישורי שיתוף, עם קבצים גלויים על הדיסק שכל כלי גיבוי יכול לקרוא.
3. בחרו ב-Syncthing אם המשימה היא תיקייה משוכפלת ותו לא.

בחרו בתבונה כעת, שכן מעבר בין Seafile ל-Nextcloud הוא ה-lock in האמיתי. אין כלי המרה. עליכם לסנכרן את כל התוכן ללקוח, להעלות אותו לשרת האחר, ולשלם ברוחב פס ובזמן, בעוד היסטוריית הגרסאות וקישורי השיתוף נשארים מאחור. תכנון הבחירה של היום לשלוש השנים הבאות זול יותר מאשר החלפת המערכת בשנה השנייה.

FAQ

האם Seafile מהירה יותר מ-Nextcloud בסנכרון ספריות גדולות?

כן, בשני המקרים שבהם הביצועים בדרך כלל נפגעים, וזאת מסיבה שניתן לאמת. Seafile מפצלת קבצים לבלוקים בגודל ממוצע של 8 MB ומעבירה רק את הבלוקים שהשתנו, כך שעריכה בתוך קובץ גדול גוררת העברה של בלוקים בודדים בלבד. יחידת ההעברה של Nextcloud היא הקובץ כולו, לכן אותה עריכה מחייבת העלאה מחדש של הקובץ כולו. בנוסף, כל קובץ קטן דורש לפחות בקשת WebDAV אחת, וזו הסיבה ש־API העלאת ה-bulk שלה אורז קבצים קטנים יחד. בצעו מדידת זמנים על ה-VPS שלכם לפני שתחליטו, כיוון שה-CPU, הדיסק ורוחב הפס שלכם משפיעים על הביצועים לא פחות מהפרוטוקול עצמו.

האם ניתן לגבות את Seafile באמצעות הרצת rsync על תיקיית הנתונים?

רק בשילוב עם מסדי הנתונים, ובסדר המתועד. המדריך של Seafile מורה לגבות תחילה את ה-SQL ולאחר מכן את תיקיית הנתונים, כיוון שכך כל רשומה במסד הנתונים מפנה לאובייקט שקיים בגיבוי. הפקודה rsync -az /opt/seafile-data/seafile /backup/data/ מעתיקה את conf, seafile-data ו-seahub-data, אך כשלעצמה היא אינה ניתנת לשחזור, כיוון שמאגר האובייקטים אינו מכיל עץ קבצים קריא ומסד הנתונים משמש כאינדקס שלו. לאחר שחזור שני החלקים, הריצו את seaf-fsck.sh וקראו את הפלט לפני שתסתמכו על התוצאה.

האם אני צריך את Nextcloud אם אני רוצה רק סנכרון קבצים?

לא. Nextcloud היא פלטפורמה, והיומן, אנשי הקשר וחנות האפליקציות צורכים זיכרון ומחייבים תחזוקת שדרוגים בין אם אתם משתמשים בהם ובין אם לא. עבור סנכרון קבצים פשוט, Seafile היא מוצר קל יותר עם פרוטוקול מהיר יותר, ו-Syncthing קלה עוד יותר כיוון שאין לה צד שרת להרצה. בחרו ב-Nextcloud כאשר אתם זקוקים ליישומים הנוספים, ולא כברירת מחדל.

האם ספרייה מוצפנת ב-Seafile מסתירה את שמות הקבצים שלי?

לא. ספרייה מוצפנת מצפינה את תוכן הקבצים בצד הלקוח והסיסמה לעולם אינה מגיעה לשרת, אך שמות התיקיות, שמות הקבצים, גדלי הקבצים והיסטוריית העריכות נשארים גלויים בשרת. פתיחת ספרייה מוצפנת בממשק האינטרנט גם שולחת את הסיסמה לשרת, שמפענח את מפתח הקובץ ושומר את הסיסמה בזיכרון למשך שעה אחת. אם השמות עצמם רגישים, הרחיקו ספרייה זו מממשק האינטרנט ובצעו הצפנה בשכבה אחרת.

כמה RAM כדאי להקצות ל-Seafile או ל-Nextcloud ב-VPS?

התחילו ב-4 GB עם 2 ליבות עבור כל אחת מהן עם מספר משתמשים מצומצם, ולאחר מכן עקבו אחר צריכת הזיכרון בזמן יצירת תצוגות מקדימות וביצוע חיפושים. התיעוד של Seafile קובע רף מינימלי של 2 GB RAM ומעבד בעל 2 ליבות בתדר של מעל 2 GHz. Nextcloud ממליצה על 512 MB לכל תהליך PHP, כמות שיש להכפיל במספר ה-workers לפני הוספת מסד הנתונים וה-cache. התוכנה Syncthing רצה בנוחות ב-1 GB.