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ă

CeCu fișierul de compunere al site-uluiCu un arhivă de versiuneCu pachetul .deb sau .rpm
Baza de date: mesaje, utilizatori, comunități, canale și, cu fișierul de compunere al site-ului, configurațiavolumul antimatter_postgres, prin pg_dumpbaza de date PostgreSQLbaza de date PostgreSQL
Fișierele încărcate, imaginile și aplicațiile instalatevolumul 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 stickerevolumul antimatter_gifsdirectorul 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 modeleleAM_AI_ENCRYPTION_KEY în .env (recomandat) sau fișierul ai-encryption.key în volumul antimatter_dataAM_AI_ENCRYPTION_KEY sau data/ai-encryption.keyAM_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

Fișierele Compose descărcate înainte de 17 octombrie 2026 nu aveau un volum 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.
  1. Faceți o copie de rezervă.
  2. Schimbați eticheta imaginii în .env (ANTIMATTER_IMAGE), dacă o fixați, așa cum se recomandă.
  3. 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.

Actualizările se fac doar în sensul versiunilor mai noi. Odată ce un server mai nou a actualizat baza de date, o versiune mai veche nu o mai poate utiliza: pentru a reveni la versiunea anterioară, restaurați copia de siguranță realizată înainte de actualizare. Aceeași regulă se aplică și la trecerea de la 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.

Dacă Antimatter este destinat unei companii sau unei organizații, setați Tipul comunităților noi la Mediu de lucru înainte de actualizare: 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.
CeModificarea
Tipuri de comunitateFiecare 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ă canaleleMembrii 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 aspectRolul 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 AdministratorUn 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 membriNumă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 modeleAdministratorii 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 GeneralCanalul 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.
FavoriteCategoria 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:

  1. Creați o copie de siguranță a bazei de date Mattermost, a stocării de fișiere (data/ sau coș S3) și a fișierului config.json, apoi opriți Mattermost.
  2. Restaurați baza de date în PostgreSQL-ul Antimatter, sau indicați Antimatter o copie a acesteia (AM_SQLSETTINGS_DATASOURCE).
  3. Copiați fișierele în stocarea Antimatter, păstrând căile lor: în coșul antimatter cu un instrument S3, sau în data/ cu o arhivă de versiune.
  4. Reutilizați configurația: copiați config.json, sau mutați-l în baza de date cu amctl --local config migrate (a se vedea Configurație). Variabilele de mediu MM_ funcționează în continuare; redenumiți-le în AM_ când este convenabil.
  5. 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.
  6. 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.