Firma-backups

Firmaadministratorer og ejere åbner deres firma i webappen og vælger Backups. De kan anmode om backups, downloade ZIP-filer og administrere API-nøgler til deres backupserver. Denne eksport er ikke tilgængelig i mobilappen.

Omfang og begrænsninger

Backuppen indeholder firmas almindelige projektchats, herunder arkiverede chats, med beskeder, reaktioner, chatkort og deres tilknyttede uploadede vedhæftede filer. Den indeholder også projekt- og chatmetadata, deltageres navne og publicerede firmadokumenter i disse chats. Firmaadministratorer og ejere kan backe op firma-chats, de ikke personligt har deltaget i.

Direktemeldinger, private noter, personligt synlige ydelser, tværgående firma-chats og personlige udkast er udelukket. Firma Drive og indhold i eksterne links ligger uden for denne chat-eksport. Manglende tilknyttede vedhæftede filer får genereringen til at fejle. ZIP-filen er en dataeksport. Automatisk import tilbage til Skava er endnu ikke tilgængelig.

Kvoter, inkrementer og opbevaring

Hvert firma kan anmode om én fuld backup inden for 7 dage og to inkrementelle backups inden for 24 timer. Disse rullende vinduer starter ved hver anmodning. At hente den samme færdige fil igen forbruger ikke kvoten for generering. Mislykkede genereringsjobs tæller ikke mod disse grænser.

Hvert inkrement indeholder ændringer og sletninger siden den seneste fuldt overførte og checksum-bekræftede backup. Kæden er A + B + C: A er den fulde backup, B indeholder ændringer siden A, og C kun yderligere ændringer siden B. Genopret tilstanden ved at anvende hver pakke i rækkefølge. Uændvedvedede vedhæftede filer henviser til filer, der allerede er til stede i denne kæde.

Downloads er tilgængelige i 24 timer efter, at genereringen er færdig. ZIP-filen fjernes derefter, mens historikken bevares. Gem den fulde backup og alle tilknyttede inkrementer lokalt. Sammenligningstilstanden kan bruges i op til 90 dage efter den fulde backup; en ny fuld backup er nødvendig derefter. Hvert inkrement identificerer både den fulde backup og dens direkte forgænger ved ID og SHA-256.

Kun en fuldt modtaget og bekræftet pakke bliver til den nye forgænger. Et færdigt, ubekræftet inkrement blokerer for et andet inkrement, indtil det er bekræftet eller udløbet. Når et ubekræftet pakke udløber, starter det næste forsøg fra den seneste bekræftede tilstand og inkluderer de ændringer, der endnu ikke er backup'et. Hvis en bekræftet del mangler lokalt, skal den hentes igen inden for dens 24 timers tilgængelighed, eller så skal en ny fuld backup startes underlagt den ugentlige grænse. Foretræk én fælles backup-mappe pr. firma; uafhængige klienter skal opretholde den samme komplette kæde.

Opret en API-nøgle

Under API-nøgler indtaster du et navn som f.eks. "Firma NAS" og opretter nøglen. Den vises kun én gang, udløber efter ét år og kan til enhver tid tilbagekaldes. Gem den i dit backupmiljøets beskyttede hemmelighedsbevaring. Firmaet ejer nøglen, som kun kan tilgå firmaets backup-API. Den fungerer uafhængigt af opretters senere login.

Send den over HTTPS i Authorization: Bearer YOUR_BACKUP_TOKEN-headeren. Hold nøgler ude af URL'er, offentlige scripts og logs. Kun firmaadministratorer og ejere kan oprette, liste og tilbagekalde nøgler.

Python: download en fuld backup og inkrementer

Download company_backup.py Python-klienten og placer den ved siden af dit script. Det kræver Python 3.10 eller nyere på Linux eller macOS og bruger kun standardbiblioteket. Sæt SKAVA_BACKUP_TOKEN i den beskyttede procesmiljø og erstat 42 med firma-ID'en fra webapp-adressen.

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")

Planlagte jobs kan kalde den samme klient direkte:

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

Klienten anmoder om generering, poller status, streamer downloaden til disken, tjekker størrelse, SHA-256 og ZIP-indhold og bekræfter modtagelse. Den gemmer fulde og inkrementelle backups som separate filer. Bevar den skjulte statusfil i den mappe: den indeholder kæde- og genoptagelsesoplysninger. Før en ny inkrementel anmodning verificerer klienten alle tidligere ZIP-filer. Efter en afbrydelse gentager du samme kommando. Samtidige jobs for samme virksomhed i samme mappe forhindres.

API-flow uden en vedvarende forbindelse

1. Anmodning: POST /api/v1/companies/42/backups med {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. For en inkrementel backup sætter du kind til diff og sender din lokale fulde backup-ID som base_id og den seneste bekræftede pakke-ID som parent_id. Svarbeskeden indeholder job.id. Genbrug samme request_id ved genforsøg.
2. Polling: GET /api/v1/companies/42/backups/JOB_ID, cirka hver tiende sekund. Genereringen kører i baggrunden under queued eller running. Ingen forbindelse holdes åben mellem anmodninger.
3. Download: Ved ready med available: true, kald GET /api/v1/companies/42/backups/JOB_ID/download. Kun denne overførsel holder en forbindelse åben. Hvis den afbrydes, downloades hele filen igen.
4. Bekræft modtagelse: Tjek job.bytes og job.sha256. Tag X-Backup-Download-Id og X-Backup-Receipt fra downloadresponsens headers. Send POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm med {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Kun en fuldstændig overførsel med en matchende bekræftelse tæller som vellykket.

GET /api/v1/companies/42/backups returnerer historik, pagineret via next_offset. Udtømte kvoter eller midlertidige kapacitetsgrænser returnerer HTTP 429 med Retry-After. Backups genereres sekventielt inden for grænserne, så samtidige natjobs ikke overbelaster applikationen.

Forstå downloadhistorik

Historikken viser fuldt eller inkrementelt type, anmodningstid, udløb, fuld backup, forgænger og hver downloadforsøg med overførte bytes. "Ready" identificerer en genereret fil. "Transferred" betyder, at serveren sendte alle bytes. "Checksum confirmed" betyder, at klienten verificerede og bekræftede fuld modtagelse. Afbrudte og fejlede forsøg forbliver synlige.

Webappen bekræfter modtagelsen i browseren, før gem-dialogen vises. Denne bekræftelse beviser ikke, at filen derefter blev gemt permanent på din computer. Til automatiske sikkerhedskopier skriver Python-klienten filen til disken, før den bekræfter modtagelsen. Downloads i webappen er begrænset til 64 MiB. Brug Python-klienten til større arkiver.