Sauvegardes de l'entreprise

Les administrateurs et propriétaires de l'entreprise ouvrent leur société dans l'application web et sélectionnent Sauvegardes. Ils peuvent demander des sauvegardes, télécharger des fichiers ZIP et gérer les clés API de leur serveur de sauvegarde. Cette exportation n'est pas disponible dans l'application mobile.

Portée et limites

La sauvegarde contient les chats de projets réguliers de l'entreprise, y compris les chats archivés, avec leurs messages, réactions, cartes de chat et pièces jointes associées. Elle inclut également les métadonnées des projets et des chats, les noms des participants et les documents d'entreprise publiés dans ces chats. Les administrateurs et propriétaires de l'entreprise peuvent sauvegarder les chats de l'entreprise auxquels ils n'ont pas personnellement adhéré.

Les messages directs, notes privées, services visibles personnellement, chats inter-entreprises et brouillons personnels sont exclus. Le contenu du Drive d'entreprise et des liens externes est en dehors de cette exportation de chat. L'absence de pièces jointes associées entraîne l'échec de la génération. Le ZIP est une exportation de données ; l'importation automatique dans Skava n'est pas encore disponible.

Quotas, incrémentales et rétention

Chaque entreprise peut demander une sauvegarde complète dans les 7 jours et deux sauvegardes incrémentales dans les 24 heures. Ces fenêtres glissantes démarrent à chaque demande. Télécharger à nouveau un fichier prêt ne consomme pas de quota de génération. Les tâches de génération échouées ne comptent pas dans ces limites.

Chaque incrémentale contient les modifications et suppressions depuis la dernière sauvegarde entièrement transférée et confirmée par empreinte. La chaîne est A + B + C : A est la sauvegarde complète, B contient les modifications depuis A, et C uniquement les modifications supplémentaires depuis B. Reconstituez l'état en appliquant chaque paquet dans l'ordre. Les pièces jointes inchangées renvoient vers des fichiers déjà présents dans cette chaîne.

Les téléchargements restent disponibles pendant 24 heures après la fin de la génération. Le ZIP est ensuite supprimé, mais l'historique reste présent. Conservez la sauvegarde complète et toutes les incrémentales associées localement. L'état de comparaison reste utilisable pendant au plus 90 jours après la sauvegarde complète ; une nouvelle sauvegarde complète est requise ensuite. Chaque incrémentale identifie la sauvegarde complète et son prédécesseur direct par ID et SHA-256.

Seul un paquet entièrement reçu et confirmé devient le nouveau prédécesseur. Une incrémentale prête mais non confirmée bloque une autre incrémentale jusqu'à confirmation ou expiration. Après l'expiration d'un paquet non confirmé, la tentative suivante démarre depuis le dernier état confirmé et inclut les modifications non encore sauvegardées. Si une partie confirmée manque localement, téléchargez-la à nouveau dans les 24 heures de disponibilité ou démarrez une nouvelle sauvegarde complète, dans la limite hebdomadaire. Préférez un répertoire de sauvegarde partagé par entreprise ; les clients indépendants doivent conserver la même chaîne complète.

Configurer une clé API

Sous Clés API, saisissez un nom tel que « NAS de l'entreprise » et créez la clé. Elle est affichée une seule fois, expire après un an et peut être révoquée à tout moment. Stockez-la dans le coffre-fort de secrets protégé de votre environnement de sauvegarde. L'entreprise est propriétaire de la clé, qui ne peut accéder qu'à l'API de sauvegarde de cette entreprise. Elle fonctionne indépendamment de la connexion ultérieure de son créateur.

Envoyez-la via HTTPS dans l'en-tête Authorization: Bearer YOUR_BACKUP_TOKEN. Évitez de placer les clés dans les URL, les scripts publics et les journaux. Seuls les administrateurs et propriétaires de l'entreprise peuvent créer, lister et révoquer les clés.

Python : télécharger une sauvegarde complète et les incrémentales

Téléchargez le client Python company_backup.py et placez-le à côté de votre script. Il nécessite Python 3.10 ou une version plus récente sur Linux ou macOS et n'utilise que la bibliothèque standard. Définissez SKAVA_BACKUP_TOKEN dans l'environnement de processus protégé et remplacez 42 par l'identifiant de l'entreprise figurant dans l'adresse de l'application 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")

Les tâches planifiées peuvent appeler le même client directement :

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

Le client demande la génération, interroge l'état, télécharge le flux sur le disque, vérifie la taille, le SHA-256 et le contenu du ZIP, puis confirme la réception. Il stocke les sauvegardes complètes et incrémentielles dans des fichiers distincts. Conservez le fichier d'état caché dans ce répertoire : il contient les informations de chaîne et de reprise. Avant de demander une autre sauvegarde incrémentielle, le client vérifie chaque fichier ZIP précédent. Après une interruption, répétez la même commande. Les tâches simultanées pour la même entreprise dans le même répertoire sont évitées.

Flux API sans connexion persistante

1. Requête : POST /api/v1/companies/42/backups avec {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Pour une sauvegarde incrémentielle, définissez kind sur diff et envoyez l'identifiant de votre sauvegarde complète locale comme base_id et l'identifiant du dernier paquet confirmé comme parent_id. La réponse fournit job.id. Réutilisez le même request_id lors des nouvelles tentatives.
2. Interrogation : GET /api/v1/companies/42/backups/JOB_ID, environ toutes les dix secondes. La génération s'exécute en arrière-plan pendant les états queued ou running. Aucune connexion ne reste ouverte entre les requêtes.
3. Téléchargement : À l'état ready avec available: true, appelez GET /api/v1/companies/42/backups/JOB_ID/download. Seul ce transfert maintient une connexion ouverte. En cas d'interruption, téléchargez à nouveau le fichier complet.
4. Confirmer la réception : Vérifiez job.bytes et job.sha256. Récupérez X-Backup-Download-Id et X-Backup-Receipt depuis les en-têtes de réponse du téléchargement. Envoyez POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm avec {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Seul un transfert complet accompagné d'une confirmation correspondante est considéré comme réussi.

GET /api/v1/companies/42/backups renvoie l'historique, paginé via next_offset. Les quotas épuisés ou les limites de capacité temporaires renvoient HTTP 429 avec Retry-After. Les sauvegardes sont générées séquentiellement dans les limites définies afin que les tâches nocturnes simultanées ne surchargent pas l'application.

Comprendre l'historique des téléchargements

L'historique affiche le type complet ou incrémental, l'heure de la demande, l'expiration, la sauvegarde complète, l'élément précédent et chaque tentative de téléchargement avec les octets transférés. « Ready » identifie un fichier généré. « Transferred » signifie que le serveur a envoyé tous les octets. « Checksum confirmed » signifie que le client a vérifié et confirmé la réception complète. Les tentatives interrompues et échouées restent visibles.

L’application web vérifie la réception dans le navigateur avant d’afficher la boîte de dialogue d’enregistrement. Cette confirmation ne prouve pas que le fichier a ensuite été stocké de manière permanente sur votre ordinateur. Pour les sauvegardes automatisées, le client Python écrit le fichier sur le disque avant de confirmer la réception. Les téléchargements via l’application web sont limités à 64 Mio ; utilisez le client Python pour les archives plus volumineuses.