Bedrijfsbackups

Bedrijfsbeheerders en eigenaren openen hun bedrijf in de webapp en selecteren Backups. Ze kunnen backups aanvragen, ZIP-bestanden downloaden en API-sleutels voor hun back-upserver beheren. Deze export is niet beschikbaar in de mobiele app.

Reikwijdte en beperkingen

De back-up bevat de gewone projectchats van het bedrijf, inclusief gearchiveerde chats, met berichten, reacties, chatkaarten en de bijbehorende geüploade bijlagen. Ook worden project- en chatmetadata, namen van deelnemers en gepubliceerde bedrijfsdocumenten in die chats opgenomen. Bedrijfsbeheerders en eigenaren kunnen bedrijfchats back-uppen waaraan ze zelf niet hebben deelgenomen.

Directe berichten, privénotities, persoonlijk zichtbare diensten, chats tussen bedrijven en persoonlijke concepten zijn uitgesloten. Inhoud van Company Drive en externe links valt buiten deze chatexport. Ontbrekende bijbehorende bijlagen zorgen ervoor dat de generatie mislukt. De ZIP is een data-export; automatische import terug in Skava is nog niet beschikbaar.

Quotas, incrementals en retentie

Elk bedrijf kan één volledige back-up binnen 7 dagen en twee incrementele back-ups binnen 24 uur aanvragen. Deze rollende periodes starten bij elke aanvraag. Het opnieuw downloaden van hetzelfde gereedstaande bestand verbruikt geen generatiequota. Mislukte generatiejobs tellen niet mee voor deze limieten.

Elke incrementele back-up bevat wijzigingen en verwijderingen sinds de laatste volledig overgedragen en met checksum bevestigde back-up. De keten is A + B + C: A is de volledige back-up, B bevat wijzigingen sinds A en C alleen verdere wijzigingen sinds B. Herstel de staat door alle pakketten in volgorde toe te passen. Onveranderde bijlagen verwijzen naar bestanden die al in deze keten aanwezig zijn.

Downloads blijven 24 uur na het voltooien van de generatie beschikbaar. Daarna wordt het ZIP-bestand verwijderd, maar blijft de geschiedenis behouden. Bewaar de volledige back-up en elke bijbehorende incrementele back-up lokaal. De vergelijkingsstatus blijft maximaal 90 dagen na de volledige back-up bruikbaar; daarna is een nieuwe volledige back-up vereist. Elke incrementele back-up identificeert zowel de volledige back-up als de directe voorganger via ID en SHA-256.

Pas een volledig ontvangen en bevestigd pakket wordt de nieuwe voorganger. Een klaarstaand, niet-bevestigd incrementeel pakket blokkeert een ander incrementeel pakket tot het bevestigd of verlopen is. Nadat een niet-bevestigd pakket is verlopen, begint de volgende poging bij de laatste bevestigde staat en omvat de wijzigingen die nog niet zijn gereserveerd. Als een bevestigd deel lokaal ontbreekt, download het opnieuw binnen de beschikbaarheidsperiode van 24 uur of start een nieuwe volledige back-up, onder voorbehoud van de weeklimiet. Gebruik bij voorkeur één gedeelde back-upmap per bedrijf; onafhankelijke cliënten moeten dezelfde volledige keten behouden.

Een API-sleutel instellen

Voer onder API-sleutels een naam in, zoals “Bedrijfs-NAS”, en maak de sleutel aan. Deze wordt één keer weergegeven, verloopt na één jaar en kan op elk moment worden ingetrokken. Bewaar de sleutel in de beveiligde geheime opslag van uw backumgeving. Het bedrijf is eigenaar van de sleutel, die alleen toegang heeft tot de back-up-API van dat bedrijf. De sleutel werkt onafhankelijk van de latere inloggegevens van de maker.

Verstuur de sleutel via HTTPS in de Authorization: Bearer YOUR_BACKUP_TOKEN-header. Houd sleutels uit URL’s, openbare scripts en logs. Alleen bedrijfsbeheerders en eigenaren kunnen sleutels aanmaken, weergeven en intrekken.

Python: een volledige back-up en incrementals downloaden

Download de Python-client company_backup.py en plaats deze naast uw script. Het vereist Python 3.10 of nieuwer op Linux of macOS en gebruikt alleen de standaardbibliotheek. Stel SKAVA_BACKUP_TOKEN in in de beveiligde procesomgeving en vervang 42 door het bedrijfs-ID uit het adres van de webapp.

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

Geplande taken kunnen dezelfde client direct aanroepen:

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

De client vraagt generatie aan, controleert de status, streamt de download naar schijf, controleert de grootte, SHA-256 en de ZIP-inhoud en bevestigt ontvangst. Volledige en incrementele back-ups worden opgeslagen als aparte bestanden. Houd het verborgen statusbestand in die map: het bevat de keten en hervattingsinformatie. Voordat een nieuwe incrementele back-up wordt aangevraagd, controleert de client elk eerdere ZIP-bestand. Na een onderbreking voert u hetzelfde commando opnieuw uit. Gelijktijdige taken voor hetzelfde bedrijf in dezelfde map worden voorkomen.

API-flow zonder persistente verbinding

1. Aanvraag: POST /api/v1/companies/42/backups met {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Voor een incrementele back-up stelt u kind in op diff en stuurt u uw lokale volledige back-up-ID als base_id en de laatste bevestigde pakket-ID als parent_id. Het antwoord bevat job.id. Gebruik dezelfde request_id bij een nieuwe poging.
2. Statuscontrole: GET /api/v1/companies/42/backups/JOB_ID, ongeveer elke tien seconden. De generatie verloopt in de achtergrond tijdens queued of running. Tussen de aanvragen blijft geen verbinding open.
3. Download: Bij ready met available: true, roep je GET /api/v1/companies/42/backups/JOB_ID/download aan. Alleen deze overdraging houdt een verbinding open. Wordt deze onderbroken, download dan het volledige bestand opnieuw.
4. Ontvangst bevestigen: Controleer job.bytes en job.sha256. Neem X-Backup-Download-Id en X-Backup-Receipt uit de response-headers van de download. Stuur POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm met {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Alleen een volledige overdraging met een overeenkomstige bevestiging telt als geslaagd.

GET /api/v1/companies/42/backups geeft de geschiedenis terug, gepagineerd via next_offset. Uitgeputte quota of tijdelijke capaciteitslimieten geven HTTP 429 met Retry-After. Backups worden binnen de limieten sequentieel gegenereerd, zodat gelijktijdige nachtelijke taken de applicatie niet overbelasten.

Downloadgeschiedenis begrijpen

De geschiedenis toont het type (volledig of incrementeel), de aanvraagtijd, de vervaldatum, de volledige backup, de voorganger en elke downloadpoging met het aantal overgedragen bytes. “Ready” identificeert een gegenereerd bestand. “Transferred” betekent dat de server alle bytes heeft verzonden. “Checksum confirmed” betekent dat de client de volledige ontvangst heeft geverifieerd en bevestigd. Onderbroken en mislukte pogingen blijven zichtbaar.

De webapp bevestigt de ontvangst in de browser voordat het bewaarvenster verschijnt. Die bevestiging garandeert niet dat het bestand daarna permanent op uw computer is opgeslagen. Voor geautomatiseerde back-ups schrijft de Python-client het bestand naar de schijf voordat de ontvangst wordt bevestigd. Downloads via de webapp zijn beperkt tot 64 MiB; gebruik de Python-client voor grotere archieven.