Copii de rezervă ale companiei

Adminii și proprietarii companiei își deschid compania în aplicația web și selectează Copii de rezervă. Pot solicita copii de rezervă, descărca fișiere ZIP și gestiona cheile API pentru serverul de rezervă. Această exportare nu este disponibilă în aplicația mobilă.

Domeniu și limite

Copia de rezervă conține conversațiile de proiect obișnuite ale companiei, inclusiv cele arhivate, cu mesaje, reacții, carduri de chat și atașamentele încărcate asociate. Include, de asemenea, metadatele proiectelor și ale chaturilor, numele participanților și documentele companiei publicate în acele chaturi. Adminii și proprietarii companiei pot face copii de rezervă ale chaturilor companiei la care nu s-au alăturat personal.

Mesajele directe, notele private, serviciile vizibile personal, chaturile între companii și schițele personale sunt excluse. Conținutul din Drive-ul companiei și al legăturilor externe se află în afara acestei exportări de chat. Atașamentele asociate lipsă duc la eșecul generării. Fișierul ZIP este o exportare de date; importul automat înapoi în Skava nu este încă disponibil.

Cote, incrementale și retenție

Fiecare companie poate solicita o singură copie de rezervă completă în 7 zile și două copii de rezervă incrementale în 24 de ore. Aceste ferestre glisante pornesc la fiecare solicitare. Descărcarea din nou a aceluiași fișier gata pregătit nu consumă cota de generare. Joburile de generare eșuate nu se iau în calcul la aceste limite.

Fiecare incremental conține modificările și ștergerile de la ultima copie de rezervă transferată integral și confirmată prin sumă de control. Lanțul este A + B + C: A este copia de rezervă completă, B conține modificările de la A, iar C doar modificările ulterioare de la B. Reconstruiți starea aplicând fiecare pachet în ordine. Atașamentele nemodificate se referă la fișierele deja prezente în acest lanț.

Descărcările rămân disponibile timp de 24 de ore după finalizarea generării. Apoi, arhiva ZIP este eliminată, iar istoricul rămâne. Păstrați local copia de rezervă completă și toate incrementalele asociate. Starea de comparație rămâne utilizabilă cel mult 90 de zile după copia de rezervă completă; ulterior este necesară o nouă copie de rezervă completă. Fiecare incremental identifică atât copia de rezervă completă, cât și predecesorul direct prin ID și SHA-256.

Doar un pachet recepționat integral și confirmat devine noul predecesor. Un incremental gata, dar neconfirmat, blochează altul până la confirmare sau expirare. După expirarea unui pachet neconfirmat, următoarea încercare pornește de la ultima stare confirmată și include modificările nebackup-uite încă. Dacă o parte confirmată lipsește local, descărcați-o din nou în termenul de disponibilitate de 24 de ore sau inițiați o nouă copie de rezervă completă, sub rezerva limitării săptămânale. Preferați un singur director de backup partajat per companie; clienții independenți trebuie să păstreze același lanț complet.

Configurați o cheie API

În secțiunea chei API, introduceți un nume, de exemplu „NAS companie”, și creați cheia. Aceasta este afișată o singură dată, expiră după un an și poate fi revocată oricând. Stocați-o în depozitul de secrete protejat al mediului de backup. Cheia aparține companiei și poate accesa doar API-ul de backup al acelei companii. Funcționează independent de autentificările ulterioare ale creatorului.

Trimiteți-o prin HTTPS în antetul Authorization: Bearer YOUR_BACKUP_TOKEN. Păstrați cheile departe de URL-uri, scripturi publice și jurnale. Doar administratorii și proprietarii companiei pot crea, lista și revoca cheile.

Python: descărcați un backup complet și incrementale

Descărcați clientul Python company_backup.py și plasați-l lângă scriptul dumneavoastră. Necesită Python 3.10 sau o versiune mai nouă pe Linux sau macOS și utilizează doar biblioteca standard. Setează SKAVA_BACKUP_TOKEN în mediul de proces protejat și înlocuiește 42 cu ID-ul companiei din adresa aplicației web.

import os
from company_backup import BackupClient

client = BackupClient("https://chat.skava.io", 42,
                      os.environ["SKAVA_BACKUP_TOKEN"])
full = client.backup("full", "backups")  # once every 7 days
# Later, up to twice in a rolling 24-hour window:
diff = client.backup("diff", "backups")

Joburile programate pot invoca direct același client:

python3 company_backup.py --company 42 --kind full --directory backups
python3 company_backup.py --company 42 --kind diff --directory backups

Clientul solicită generarea, verifică starea, descarcă fluxul pe disc, verifică dimensiunea, SHA-256 și conținutul ZIP, și confirmă primirea. Păstrează fișierele complete și incrementale separate. Păstrează fișierul de stare ascuns în acel director: el conține informațiile despre lanț și reluare. Înainte de a solicita un alt increment, clientul verifică fiecare fișier ZIP anterior. După o întrerupere, repetați aceeași comandă. Joburile concurente pentru aceeași companie în același director sunt prevenite.

Fluxul API fără conexiune persistentă

1. Solicitare: POST /api/v1/companies/42/backups cu {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Pentru un increment, setați kind la diff și trimiteți ID-ul local al backup-ului complet ca base_id și ID-ul ultimului pachet confirmat ca parent_id. Răspunsul furnizează job.id. Reutilizați același request_id la reîncercare.
2. Verificare: GET /api/v1/companies/42/backups/JOB_ID, la aproximativ zece secunde. Generarea rulează în fundal în timpul queued sau running. Nicio conexiune nu rămâne deschisă între solicitări.
3. Descărcare: La ready cu available: true, apelează GET /api/v1/companies/42/backups/JOB_ID/download. Doar această transferare menține o conexiune deschisă. Dacă este întreruptă, descarcă din nou fișierul complet.
4. Confirmare primire: Verifică job.bytes și job.sha256. Ia X-Backup-Download-Id și X-Backup-Receipt din anteturile răspunsului de descărcare. Trimite POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm cu {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Doar o transferare completă cu o confirmare corespunzătoare este considerată reușită.

GET /api/v1/companies/42/backups returnează istoricul, paginat prin next_offset. Cotele epuizate sau limitele temporare de capacitate returnează HTTP 429 cu Retry-After. Copiile de rezervă sunt generate secvențial în limitele stabilite, astfel încât joburile simultane de noapte să nu suprasarcină aplicația.

Înțelegerea istoricului de descărcări

Istoricul afișează tipul complet sau incremental, ora solicitării, expirarea, copia de rezervă completă, predecesorul și fiecare încercare de descărcare cu octeții transferați. „Ready” identifică un fișier generat. „Transferred” înseamnă că serverul a trimis toți octeții. „Checksum confirmed” înseamnă că clientul a verificat și a confirmat primirea completă. Încercările întrerupte și eșuate rămân vizibile.

Aplicația web verifică primirea în browser înainte de dialogul de salvare. Această confirmare nu dovedește că fișierul a fost stocat ulterior permanent pe computerul dumneavoastră. Pentru copii de rezervă automate, clientul Python scrie fișierul pe disc înainte de a confirma primirea. Descărcările din aplicația web sunt limitate la 64 MiB; folosiți clientul Python pentru arhive mai mari.