גיבויים ושדרוגים

מה לגבות, איך לשחזר על מארח חדש, איך לשדרג, ואיך להעביר שרת Mattermost או קהילה בודדת ל-Antimatter.

מה לגבות

ללא מפתח ההצפנה של AI, שרת שחוקר לא יכול לקרוא את מפתחות ה-API של חיבורי המודלים שלו, וכל אחד מהם צריך להקליד שוב. שמרו עותק של המפתח בנפרד מגיבויי המסד הנתונים, כך שגיבוי אחד שנחטף לא יכיל את שניהם. ראו מפתח ההצפנה.

מסד הנתונים והקבצים שייכים זה לזה: גיבו אותם בו-זמנית, ושמרו עותקים מחוץ לשרת. שמות הנפחים מתחילים בשם פרויקט compose, antimatter (docker volume ls מציג אותם).

גיבוי

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

stamp=$(date +%Y%m%d-%H%M%S)
mkdir -p backups
docker compose stop antimatter
# Database
docker compose exec -T postgres pg_dump -U antimatter -d antimatter -Fc \
    > "backups/antimatter-db-$stamp.dump"
# File storage, GIF service and the data directory (the AI key file)
for v in files gifs data; do
    docker run --rm -v "antimatter_$v:/data:ro" -v "$PWD/backups:/backup" \
        alpine tar -czf "/backup/antimatter-$v-$stamp.tar.gz" -C /data .
done
docker compose start antimatter
# Secrets
cp .env "backups/env-$stamp"

אם לא הגדרתם AM_AI_ENCRYPTION_KEY, קובץ המפתח של השרת נמצא בנפח data, שהלולאה למעלה שומרת יחד עם הקבצים. עדיף להכניס את תוכנו ל.env כפי שמסביר מפתח ההצפנה, ולשמור עותק שלו בנפרד מגיבויי המסד הנתונים.

הריצו אותו מ-cron לגיבויים יומיים, והעתיקו את ספריית backups/ למכונה אחרת. שמרו את העותקים של .env באותה מידה של אבטחה כמו השרת: הם מכילים את סיסמאותיו.

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

docker compose run --rm -v "$PWD/backups/files:/backup" bucket \
    "aws --endpoint-url http://files:9000 s3 sync s3://antimatter /backup"

עם ארכיון גרסה, גיבוי המסד הנתונים עם pg_dump -Fc, והדירקטוריות data/ וconfig/ עם הכלים הרגילים שלכם (data/ מכיל את קובץ מפתח ה-AI). עם החבילות, גיבוי המסד הנתונים באותו אופן, ו/etc/antimatter, /var/lib/antimatter, /etc/gifs-server ו/var/lib/gifs-server.

שחזור על מארח חדש

שמו את compose.yaml, את .env ששמרתם ואת הגיבויים בספרייה חדשה, ואז:

stamp=20261016-030000          # the backup to restore
docker compose create           # creates the volumes, starts nothing
docker compose up -d postgres
docker compose exec -T postgres pg_restore -U antimatter -d antimatter --no-owner \
    < "backups/antimatter-db-$stamp.dump"
for v in files gifs data; do
    docker run --rm -v "antimatter_$v:/data" -v "$PWD/backups:/backup" \
        alpine tar -xzf "/backup/antimatter-$v-$stamp.tar.gz" -C /data
done
docker compose up -d

השתמשו באותו .env: האחסון והמסד הנתונים חייבים לשמור על הסיסמאות שהיו להם, וחיבורי המודלים זקוקים לאותו מפתח הצפנה של AI. אם למוזיקה החדד יש כתובת אחרת, עדכנו את SITE_URL (וגם DOMAIN).

בדקו את הגיבויים שלכם על ידי שחזורם על מכונה אחרת מעת לעת.

שדרוג

1. עשו גיבוי.
2. שנו את תג התמונה ב-.env (ANTIMATTER_IMAGE), אם אתם נועלים גרסה, כפי שמומלץ.
3. שכו ואתחלו מחדש:

   docker compose pull
   docker compose up -d
   docker compose logs -f antimatter

בהפעלה, השרת שדרג את תבנית הבסיס הנתונים (עקבו אחר התהליך ביומן; בשרת גדול זה יכול לקחת כמה דקות) והתקין את הגרסאות החדשות יותר של האפליקציות המצורפות מהדמות. בארכיון שחרור: עצרו את השרת, החליפו את כל התוכן מלבד config/, data/, logs/, plugins/ ו-client/plugins/ בתוכן הארכיון החדש, והפעילו שוב. בחבילת .deb או .rpm, התקינו את החבילה החדשה כפי שמתואר בשדרוג חבילה.

גרסאות

שרת Antimatter מדווח על גרסת שורת Mattermost שהוא מבוסס עליה (כיום 12.0.0). השחרורים ב-GitHub, יחד עם הארכיונים והחבילות שלהם, נושאים מספרי גרסה משלהם, בסדרת 0.9.0 במהלך הבטא: antimatter version מציג זאת כמספר בנייה. הדמות נבנית מחדש מהענפים main: antimatter-next כל לילה (תגיות nightly-<YYYYMMDD>), ושתי הדמות בכל שינוי (תגיות sha-<commit>). נעצו אחת מתגיות אלו, שדרגו בכוונה, ושמרו רישום של התגיה הקודמת כדי שתדעו איזו גיבוי תואמת לה.

גרסאות ראשיות של PostgreSQL

קובץ compose משתמש ב-postgres:17-alpine. Antimatter דורש PostgreSQL 15 או חדש יותר. גרסה ראשית חדשה של PostgreSQL לא יכולה לקרוא את תיקיית הנתונים של הגרסה הקודמת: כדי לעבור אליה, בצעו dump של המסד הנתונים, הפעילו את הגרסה החדשה על נפח חדש ושחזרו את ה-dump אליו.

שדרוג ל-0.9.0

ההפעלה הראשונה של גרסה 0.9.0 (או של דמות שנבנתה מ-17 באוקטובר 2026 ואילך) מבצעת כמה שינויים חד-פעמיים בנתונים. כל שינוי מתבצע פעם אחת, ונרשם בבסיס הנתונים. השינויים מעבירים את מה שנשאר ברירת-הברך הישנה לרירת-הברך החדשה, ומשאירים כפי שהם את מה שבחר מנהל. עקבו אחריהם ביומן.

שירותי אפליקציית Agents

השדרוג מועתק כל שירות AI של אפליקציית Agents ל חיבור מודל ברמת השרת, משותף לכל הקהילות וזמין לכולם מלבד אורחים (יש להפעיל גם אורחים כדי לאפשר זאת). המפתחות מוצפנים בדרך, ולכן השרת זקוק למפתח הצפנת AI שלו: בקלאסטר שבו הקבצים נשמרים ב-S3, יש להגדיר תחילה את AM_AI_ENCRYPTION_KEY, אחרת ההעתקה תמתין להפעלה הבאה. לאחר מכן יש לבדוק בקונסולת מערכת › AI › חיבורי מודל:

• כל חיבור שומר את המזהה של השירות שלו, כך שהסוכנים של האפליקציה וגם הגדרת תרגום אוטומטי לשירות Agents עדיין מוצאים אותו.
• שירותי OpenAI, OpenAI-совместимые, Anthropic, Mistral, Cohere ו-Gemini הופכים לחיבורים לנקודת הקצה OpenAI-совместимая (או Anthropic) שלהם. שירות Azure הופך לחיבור לנקודת הקצה OpenAI-совместимая של המשאב: יש לבדוק זאת.
• שירותי AWS Bedrock, Google Vertex AI ו-Cohere North, וסוגים לא ידועים, מסומנים כדורשים תשומת לב, עם הסיבה. האסימונים הענניים שלהם אינם מועתקים: יש להפנות אותם לנקודת הקצה OpenAI-совместимая של הספק או לשער כמו LiteLLM, ולאחר מכן לשמור.
• שירות ה-Embedding הופך למודל Embeddings של החיבור עם הכתובת והמפתח זהים, או לחיבור עצמאי. שירות התמלול מקבל את המודל whisper-1.
• כאשר לרישום מחדש ולסיכומים אין עדיין חיבור, הם מקבלים את השירות והמודל של הסוכן המוגדר כברירת מחדל באפליקציה.

ההגדרות והנתונים של אפליקציית Agents נשארים כפי שהיו: הסוכנים שלה ממשיכים להשתמש בשירותים שלה.

שינויים אחרים ברברירת המחדל

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

מעבר מ-Mattermost

Antimatter משתמש בתבנית מסד הנתונים של Mattermost ומוסיף לו שדות משלו, ולכן הוא יכול לקחת על עצמו את מסד הנתונים PostgreSQL והקבצים של שרת Mattermost. נסו זאת תחילה על העתק:

1. בצעו גיבוי של מסד הנתונים של Mattermost, של אחסון הקבצים שלו (data/ או סל S3) ושל config.json, ואז עצרו את Mattermost.
2. שחזרו את מסד הנתונים אל PostgreSQL של Antimatter, או ציינו ל-Antimatter העתק שלו (AM_SQLSETTINGS_DATASOURCE).
3. העתיקו את הקבצים לאחסון של Antimatter, תוך שמירת הנתיבים שלהם: לסל antimatter באמצעות כלי S3, או ל-data/ באמצעות ארכיון שחרור.
4. שבו ונצלו את ההגדרות שלכם: העתיקו את config.json, או העבירו אותו אל המסד הנתונים באמצעות amctl --local config migrate (ראו הגדרות). משתני הסביבה MM_ שלכם ממשיכים לפעול; שנו את שמם ל-AM_ כשיהיה לכם נוח.
5. יש להפעיל את Antimatter ולעקוב אחר היומן בזמן שהשדרוג מתבצע במסד הנתונים. לאחר מכן יש לבדוק בקונסולת מערכת › תוספים › ניהול פלאגינים. Antimatter מתקינה את הבנייה שלה של Calls, Playbooks, Kanban (לוחות), Agents והאינטגרציות כאשר הן חדשות מהגרסה המותקנת. אם Mattermost היה בעל גרסה חדשה יותר של אחד מהם, יש להסיר את האפליקציה ולאתחל את Antimatter, כך שהבנייה שלה תותקן.
6. הגדרו שוב התראות Push באמצעות פרוקסי Push משלכם: Antimatter nie שולח התראות לשירותי ה-Push של Mattermost, בין אם בסביבת בדיקות ובין אם מנוהלים, שמשלמים התראות רק לאפליקציות של Mattermost עצמו. עד שתשנו את שרת התראות Push, השרת לא שולח התראות Push (ראו התראות Push).

Antimatter אינה מתקשרת עם שום שירות שמופעל על ידי Mattermost, Inc. (ראו חיבורים לשירותים חיצוניים), גם אם ההגדרות שלכם עדיין מציינות שירות כזה:

• שרת התראות דחיפה של Mattermost נשמר בהגדרות, אך אינו נעשה שימוש בו;
• כתובות Mattermost עבור שוק התוספים (כתובת (URL) של שוק התוספים) ועבור הודעות על המוצר נמחקות;
• קישורי ההורדה שהיו ברירת המחדל של Mattermost (קישור לעמוד ההורדה של אפליקציות Antimatter, קישור להורדת אפליקציית Android ו-קישור להורדת אפליקציית iOS) מוחלפים בעמודי ההורדה של אפליקציות Antimatter ב-GitHub; קישורים שהגדרתם בעצמכם נשמרים;
• אפליקציית השיחות (Calls) משתמשת בשרת STUN הציבורי של Cloudflare במקום בשרת של Mattermost, ללא שינוי בהגדרה השמורה (ראו שיחות);
• בדיקת עדכוני האבטחה ודיווח השגיאות הוסרו, ויחד איתן גם הגדרות קונסולת המערכת שלהם (הפעלת התראות אבטחה, הפעלת אבחון ודיווח שגיאות) ועמוד הודעות מערכת.

גרב (Socket) של מצב מקומי הוא כעת /var/tmp/antimatter_local.socket; amctl מנסה גם את /var/tmp/mattermost_local.socket הישן. Mattermost תומך רק ב-PostgreSQL בגרסאות האחרונות, וכך גם Antimatter: יש להעביר תחילה בסיס נתונים MySQL ל-PostgreSQL. חזרה ל-Mattermost לאחר ש-Antimatter שגררה את בסיס הנתונים דורשת שחזור גיבוי של Mattermost.

ייצוא וייבוא נתונים

פורמט הייצוא המוני מאפשר העברת נתונים בין שרתים: השרת כולו, קהילות מסוימות או ערוצים מסוימים, כולל קבצים מצורפים, תמונות פרופיל ואמוג'י מותאמים אישית, אם רוצים.

# on the source server
amctl export create --team-name design --include-profile-pictures
amctl export list
amctl export download <export file> design.zip
# on the destination server
amctl import upload design.zip
amctl import list available
amctl import process <uploaded file> --imported-users active

עקבו אחר המשימות באמצעות amctl export job list ו-amctl import job list. עבור ייצוא של קהילה או ערוץ, --imported-users הוא חובה: active כאשר האנשים עוברים לשרת זה, ו-inactive כאשר מייבאים לשרת שבו להם כבר יש חשבונות, כך שהחשבונות שנוצרו מתאימות לא ודאיות יישארו כלא פעילים עד שמנהל יבדוק אותם. --destination-team-name מייבא לקהילה קיימת. ייצואים וייבואים נשמרים באחסון של השרת (ExportSettings.Directory, ImportSettings.Directory) למשך 30 ימים כברירת מחדל.

על השרת עצמו, antimatter export bulk ו-antimatter import bulk --apply מבצעים את אותן פעולות מקבצים, ללא שימוש ב-API.