Copii de rezervă și actualizări
Ce trebuie copiat de rezervă, cum se restaurează pe un gazdă nou, cum se actualizează și cum se mută un server Mattermost sau o singură comunitate către Antimatter.
Ce trebuie copiat de rezervă
| Ce | Cu fișierul de compunere al site-ului | Cu un arhivă de versiune | Cu pachetul .deb sau .rpm |
|---|---|---|---|
| Baza de date: mesaje, utilizatori, comunități, canale și, cu fișierul de compunere al site-ului, configurația | volumul antimatter_postgres, prin pg_dump | baza de date PostgreSQL | baza de date PostgreSQL |
| Fișierele încărcate, imaginile și aplicațiile instalate | volumul antimatter_files (stocarea S3) | FileSettings.Directory, implicit ./data/ | /var/lib/antimatter |
| Fișierul de configurație | (în baza de date) | config/config.json | /etc/antimatter/config/config.json |
| GIF-uri și stickere | volumul antimatter_gifs | directorul de date al serviciului GIF | /var/lib/gifs-server |
| Secrete | .env (și compose.override.yaml) | fișierul de mediu | /etc/antimatter/antimatter.env, /etc/gifs-server |
| Cheia de criptare AI, care criptează cheile conexiunilor cu modelele | AM_AI_ENCRYPTION_KEY în .env (recomandat) sau fișierul ai-encryption.key în volumul antimatter_data | AM_AI_ENCRYPTION_KEY sau data/ai-encryption.key | AM_AI_ENCRYPTION_KEY în antimatter.env sau /var/lib/antimatter/data/ai-encryption.key |
Fără cheia de criptare AI, un server restaurat nu poate citi cheile API ale conexiunilor cu modelele, iar fiecare trebuie introdusă din nou. Păstrați o copie a cheii separat de copiile de rezervă ale bazei de date, astfel încât o copie furată să nu conțină ambele. Consultați Cheia de criptare.
Baza de date și fișierele aparțin împreună: copiați-le de rezervă în același timp și păstrați copii în afara serverului. Numele volumelor încep cu numele proiectului de compunere, antimatter (docker volume ls le listează).
Copie de rezervă
Din directorul compose.yaml. Oprirea Antimatter înainte oferă o copie complet coerentă; o copie de rezervă făcută în timpul rulării este de obicei în regulă, dar fișierele încărcate în timpul copierii de rezervă pot lipsi din ea.
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"
Dacă nu ați configurat AM_AI_ENCRYPTION_KEY, fișierul cu cheia serverului se află în volumul data, pe care bucla de mai sus îl salvează împreună cu fișierele. Mai bine, puneți conținutul acestuia în .env, așa cum explică Cheia de criptare, și păstrați o copie separat de copiile de rezervă ale bazei de date.
Rulați-o din cron pentru copii de rezervă zilnice și copiați directorul backups/ pe o altă mașină. Păstrați copiile .env la fel de în siguranță ca serverul: ele conțin parolele acestuia.
Pentru a copia fișierele încărcate obiect cu obiect (de exemplu, către alt stocare S3), utilizați instrumentul de linie de comandă AWS al serviciului bucket:
docker compose run --rm -v "$PWD/backups/files:/backup" bucket \
"aws --endpoint-url http://files:9000 s3 sync s3://antimatter /backup"
Cu un arhivă de versiune, faceți o copie de rezervă a bazei de date cu pg_dump -Fc, iar directoarele data/ și config/ cu instrumentele obișnuite (data/ conține fișierul cu cheia AI). Cu pachetele, faceți o copie de rezervă a bazei de date în același mod, precum și a /etc/antimatter, /var/lib/antimatter, /etc/gifs-server și /var/lib/gifs-server.
Restaurare pe o gazdă nouă
Puneți compose.yaml, .env salvat și copiile de rezervă într-un director nou, apoi:
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
Folosiți același .env: stocarea și baza de date trebuie să își păstreze parolele, iar conexiunile cu modelele au nevoie de aceeași cheie de criptare AI. Dacă gazda nouă are o altă adresă, actualizați SITE_URL (și DOMAIN).
Testați-vă copiile de rezervă resturându-le pe o altă mașină de la timp la timp.
Actualizare
data: fișierul cu cheia AI se afla în container. Înainte de a folosi noul compose.yaml și dacă .env nu conține AM_AI_ENCRYPTION_KEY, salvați cheia creată de server: echo "AM_AI_ENCRYPTION_KEY=$(docker compose exec -T antimatter cat /antimatter/data/ai-encryption.key)" >> .env. Dacă comanda nu găsește niciun fișier, nici o conexiune cu un model nu a salvat încă o cheie.- Faceți o copie de rezervă.
- Schimbați eticheta imaginii în
.env(ANTIMATTER_IMAGE), dacă o fixați, așa cum se recomandă. - Trageți și reporniți:
docker compose pull docker compose up -d docker compose logs -f antimatter
La pornire, serverul actualizează schema bazei de date (puteți urmări progresul în jurnal; pe un server mare, procesul poate dura câteva minute) și instalează versiunile mai noi ale aplicațiilor incluse în imagine. În cazul unui arhivă de versiune: opriți serverul, înlocuiți tot conținutul, cu excepția directorilor config/, data/, logs/, plugins/ și client/plugins/, cu cel al arhivei noi, apoi porniți serverul din nou. În cazul unui pachet .deb sau .rpm, instalați pachetul nou, așa cum este explicat în Actualizarea unui pachet.
antimatter-next înapoi la antimatter.Versiuni
Serverul Antimatter raportează versiunea liniei Mattermost pe care se bazează (în prezent 12.0.0). Versiunile publicate pe GitHub, împreună cu arhivele și pachetele lor, au propriile numere de versiune, din seria 0.9.0 în timpul beta: comanda antimatter version o afișează ca Versiunea. Imaginile sunt reconstruite din ramurile main: antimatter-next în fiecare noapte (etichete nightly-<YYYYMMDD>) și ambele imagini la fiecare modificare (etichete sha-<commit>). Fixați una dintre aceste etichete, actualizați intenționat și notați eticheta anterioară, astfel încât să știți cu ce copie de rezervă corespunde.
Versiuni majore PostgreSQL
Fișierul de compunere folosește postgres:17-alpine. Antimatter necesită PostgreSQL 15 sau o versiune mai nouă. O versiune majoră nouă a PostgreSQL nu poate citi directorul de date al versiunii anterioare: pentru a trece la ea, exportați baza de date, porniți versiunea nouă pe un volum nou și restaurați exportul în ea.
Actualizarea la 0.9.0
Prima pornire a versiunii 0.9.0 (sau a unei imagini construite din 17 octombrie 2026 încoace) introduce câteva modificări ocazionale în date. Fiecare se execută o singură dată și este înregistrată în baza de date. Ele aduc la valoarea nouă implicită ceea ce a rămas la o valoare implicită veche, lăsând intacte opțiunile alese de un administrator. Urmăriți-le în jurnal.
AM_TEAMSETTINGS_DEFAULTCOMMUNITYKIND=workplace. Actualizarea atribuie fiecărei comunități tipul configurat în acel moment, iar apelurile sunt dezactivate implicit în canalele comunităților de tip Comunitate. Consultați Mediu de lucru sau comunitate.| Ce | Modificarea |
|---|---|
| Tipuri de comunitate | Fiecare comunitate primește un tip, Comunitate sau Mediu de lucru: valoarea Tipul comunităților noi (TeamSettings.DefaultCommunityKind) la prima pornire. Un tip deja configurat este păstrat. Administratorii de comunitate pot modifica ulterior tipul comunității lor, în Setările echipei › Canale › Tipul comunității. |
| Cine arhivează canalele | Membrii canalelor nu mai arhivează canalele în care se află: administratorii comunităților fac acest lucru. Într-un mediu de lucru, administratorii canalului (cel care l-a creat și persoanele pe care le-a promovat la administratori) îl arhivează, de asemenea. Această modificare afectează rolurile din schema de sistem; schemele de permisiuni create de un administrator de sistem pentru anumite comunități rămân neschimbate. |
| Rolul Moderators din presetările de aspect | Rolul Moderators pe care comunitățile l-au primit dintr-o presetare de aspect primește Elimină persoane, funcție necesară pentru a exclude și a elimina persoanele. Se modifică doar rolurile care rămân exact cum le-a creat presetarea; un rol editat de cineva este lăsat neschimbat. |
| Rolurile cu Administrator | Un rol de comunitate cu comutatorul Administrator activat deține acum tot ce pot face administratorii comunității, așa cum indică comutatorul, nu doar setările comunității. |
| Limita de membri | Număr maxim de membri per comunitate (TeamSettings.MaxUsersPerTeam) trece de la 50, valoarea implicită anterioară, la 0 (fără limită). Orice altă valoare este păstrată, la fel și o limită setată cu AM_TEAMSETTINGS_MAXUSERSPERTEAM. |
| Conexiuni la modele | Administratorii de sistem obțin gestionarea conexiunilor de modele, iar administratorii de comunitate (și rolurile cu Administrator) obțin gestionarea celor ale propriei comunități. Serviciile AI ale aplicației Agents devin conexiuni de modele la nivel de server, vezi mai jos. |
| Town Square devine General | Canalul implicit al fiecărei comunități este redenumit de la town-square (Town Square) la general (General). Păstrează ID-ul, membrii, mesajele și setările, precum și numele de afișare ales de administratori. Linkurile vechi și căutările după town-square conduc tot la acesta. O comunitate care are deja un canal numit general, chiar și arhivat, își păstrează town-square ca canal implicit, la fel și o comunitate al cărei town-square este arhivat: jurnalul îi numește, iar administratorii lor pot redenumi canalele. |
| Favorite | Categoria de bară laterală Favorites a tuturor este redenumită Favourites, așa cum indică acum interfața. Categoriile create de utilizatori cu acest nume rămân neschimbate. |
Serviciile aplicației Agents
Actualizarea copiază fiecare serviciu AI al aplicației Agents într-o conexiune la model la nivel de server, partajată cu fiecare comunitate și utilizabilă de toți, cu excepția oaspeților (activați Și oaspeții pentru a le permite acest lucru). Cheile sunt criptate în timpul copierii, astfel încât serverul are nevoie de cheia sa de criptare AI: pe un cluster ale cărui fișiere se află în S3, configurați mai întâi AM_AI_ENCRYPTION_KEY, altfel copierea așteaptă următoarea pornire. Apoi verificați Consola de sistem › AI › Conexiuni la modele:
- Fiecare conexiune păstrează ID-ul serviciului sursă, astfel încât agenții aplicației și un set de traducere automată configurat pentru un serviciu Agents îl pot găsi în continuare.
- Serviciile OpenAI, compatibile cu OpenAI, Anthropic, Mistral, Cohere și Gemini devin conexiuni la punctul lor de acces compatibil cu OpenAI (sau Anthropic). Un serviciu Azure devine o conexiune la punctul de acces compatibil cu OpenAI al resursei: testați-l.
- Serviciile AWS Bedrock, Google Vertex AI și Cohere North, precum și tipurile necunoscute, sunt marcate cu Necesită atenție, împreună cu motivul. Credentialele lor cloud nu sunt copiate: configurați-le către punctul de acces compatibil cu OpenAI al furnizorului sau către un gateway precum LiteLLM, apoi salvați.
- Serviciul de embedding devine modelul Embeddings al conexiunii cu aceeași adresă și cheie, sau o conexiune separată. Serviciul de transcriere primește modelul
whisper-1. - Când rescrierea și rezumatele nu au încă o conexiune, primesc serviciul și modelul agentului implicit al aplicației.
Setările și datele proprii ale aplicației Agents rămân neschimbate: agenții ei continuă să utilizeze serviciile ei.
Alte modificări ale valorilor implicite
- Apeluri: Mod de test este dezactivat, iar Activează video este activat implicit. O alegere salvată în configurație este păstrată. Apelurile urmează, de asemenea, tipul comunității (a se vedea Apeluri și voce).
- Fixarea mesajelor pe prima pagină este disponibilă administratorilor canalului, administratorilor și moderatorilor comunității (cu Gestionează mesajele); membrii unui mesaj direct sau de grup pot face acest lucru în continuare.
- Canalele arhivate pot primi noi membri, care își pot citi istoricul. Nimeni nu poate posta, reacționa sau modifica nimic în ele.
Trecerea de la Mattermost
Antimatter utilizează schema bazei de date a Mattermost și adaugă tabele proprii, astfel încât poate prelua baza de date PostgreSQL și fișierele unui server Mattermost. Încercați mai întâi pe o copie:
- Creați o copie de siguranță a bazei de date Mattermost, a stocării de fișiere (
data/sau coș S3) și a fișieruluiconfig.json, apoi opriți Mattermost. - Restaurați baza de date în PostgreSQL-ul Antimatter, sau indicați Antimatter o copie a acesteia (
AM_SQLSETTINGS_DATASOURCE). - Copiați fișierele în stocarea Antimatter, păstrând căile lor: în coșul
antimattercu un instrument S3, sau îndata/cu o arhivă de versiune. - Reutilizați configurația: copiați
config.json, sau mutați-l în baza de date cuamctl --local config migrate(a se vedea Configurație). Variabilele de mediuMM_funcționează în continuare; redenumiți-le înAM_când este convenabil. - Pornește Antimatter și urmărește jurnalul în timp ce actualizează baza de date. Apoi verifică Consola de sistem › Plugin-uri › Gestionare. Antimatter își instalează propriile versiuni de Calls, Playbooks, Kanban (Panouri), Agents și integrări atunci când acestea sunt mai noi decât versiunea instalată. Dacă Mattermost avea o versiune mai nouă a uneia dintre ele, elimină acea aplicație și repornește Antimatter, astfel încât să fie instalată versiunea proprie.
- Reconfigurează notificările push, folosind propriul tău proxy push: Antimatter nu trimite niciodată notificări către serviciile push ale Mattermost, fie de test, fie găzduite, care livrează notificări doar către aplicațiile proprii ale Mattermost. Până când nu modifici Server Push de notificare, serverul nu trimite nicio notificare push (a se vedea Notificări push).
Antimatter nu contactează niciun serviciu operat de Mattermost, Inc. (vezi Conexiuni către servicii externe), chiar dacă configurația ta mai menționează unul:
- serverul de notificări push de la Mattermost este păstrat în setări, dar nu este niciodată utilizat;
- adresele Mattermost pentru piața de aplicații (Adresa URL a pieței) și pentru notificările de produs sunt șterse;
- linkurile de descărcare a aplicației care erau valorile implicite Mattermost (Antimatter Apps Download Page Link, Descărcați aplicația Android App Link și adresa de descărcare pentru aplicația iOS) sunt înlocuite cu paginile de descărcare ale aplicațiilor Antimatter de pe GitHub; linkurile pe care le configurați singuri sunt păstrate;
- aplicația Calls utilizează serverul STUN public al Cloudflare în loc de cel al Mattermost, fără a modifica setarea salvată (vezi Calls);
- verificarea actualizărilor de securitate și raportarea erorilor au fost eliminate, la fel și setările lor din Consola de sistem (Activează alerte de securitate, Activează diagnosticarea și raportarea erorilor) și pagina Observații.
Socket-ul pentru modul local este acum /var/tmp/antimatter_local.socket; amctl încearcă și vechiul /var/tmp/mattermost_local.socket. Mattermost suportă doar PostgreSQL în versiunile recente, la fel și Antimatter: mută mai întâi o bază de date MySQL către PostgreSQL. A reveni la Mattermost după ce Antimatter a actualizat baza de date înseamnă a restaura copia de rezervă a Mattermost.
Export și import de date
Formatul de export în masă mută datele între servere: întregul server, unele comunități sau unele canale, cu atașamente, fotografii de profil și emoji personalizate, dacă dorești.
# 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
Monitorizați joburile cu amctl export job list și amctl import job list. Pentru o exportare sau importare de comunitate sau canal, este necesar --imported-users: active dacă persoanele se mută pe acest server, inactive dacă se importă într-un server unde acestea au deja conturi, astfel încât conturile create din potriviri incerte să rămână inactive până când un administrator le verifică. --destination-team-name importă într-o comunitate existentă. Exportările și importările sunt păstrate pe stocarea serverului (ExportSettings.Directory, ImportSettings.Directory) timp de 30 de zile, în mod implicit.
Pe serverul propriu-zis, antimatter export bulk și antimatter import bulk --apply fac același lucru din fișiere, fără a folosi API-ul.