Backups da empresa

Administradores e proprietários da empresa abrem a empresa no aplicativo web e selecionam Backups. Podem solicitar backups, baixar arquivos ZIP e gerenciar chaves de API para o servidor de backup. Esta exportação não está disponível no aplicativo móvel.

Escopo e limites

O backup contém os chats de projeto regulares da empresa, incluindo chats arquivados, com mensagens, reações, cartões de chat e seus anexos enviados associados. Também inclui metadados de projeto e chat, nomes dos participantes e documentos da empresa publicados nesses chats. Administradores e proprietários da empresa podem fazer backup de chats da empresa aos quais não participaram pessoalmente.

Mensagens diretas, notas privadas, serviços visíveis pessoalmente, chats entre empresas e rascunhos pessoais estão excluídos. O conteúdo do Drive da empresa e de links externos fica fora desta exportação de chat. Anexos associados ausentes causam falha na geração. O ZIP é uma exportação de dados; a importação automática de volta para o Skava ainda não está disponível.

Cotas, incrementais e retenção

Cada empresa pode solicitar um backup completo a cada 7 dias e dois backups incrementais a cada 24 horas. Essas janelas móveis começam em cada solicitação. Baixar novamente o mesmo arquivo pronto não consome cota de geração. Tarefas de geração falhas não contam para esses limites.

Cada incremental contém alterações e exclusões desde o último backup totalmente transferido e confirmado por checksum. A cadeia é A + B + C: A é o backup completo, B contém as alterações desde A, e C apenas as alterações subsequentes desde B. Reconstrua o estado aplicando todos os pacotes em ordem. Anexos inalterados referem-se a arquivos já presentes nesta cadeia.

Os downloads permanecem disponíveis por 24 horas após o término da geração. O ZIP é então removido, enquanto o histórico permanece. Mantenha o backup completo e todos os incrementais associados localmente. O estado de comparação permanece utilizável por no máximo 90 dias após o backup completo; um novo backup completo é necessário depois disso. Cada incremental identifica tanto o backup completo quanto seu predecessor direto por ID e SHA-256.

Apenas um pacote totalmente recebido e confirmado se torna o novo predecessor. Um incremental pronto, mas não confirmado, bloqueia outro incremental até ser confirmado ou expirar. Após a expiração de um pacote não confirmado, a próxima tentativa parte do último estado confirmado e inclui as alterações ainda não backupadas. Se uma parte confirmada estiver ausente localmente, baixe-a novamente dentro de sua disponibilidade de 24 horas ou inicie um novo backup completo, sujeito ao limite semanal. Prefira um diretório de backup compartilhado por empresa; clientes independentes devem manter a mesma cadeia completa.

Configurar uma chave de API

Em Chaves de API, insira um nome como “NAS da empresa” e crie a chave. Ela é exibida uma única vez, expira após um ano e pode ser revogada a qualquer momento. Armazene-a no cofre de segredos protegido do seu ambiente de backup. A empresa é a proprietária da chave, que só pode acessar a API de backup dessa empresa. Ela opera de forma independente do login posterior do seu criador.

Envie-a via HTTPS no cabeçalho Authorization: Bearer YOUR_BACKUP_TOKEN. Mantenha as chaves fora de URLs, scripts públicos e logs. Apenas administradores e proprietários da empresa podem criar, listar e revogar chaves.

Python: baixar um backup completo e incrementais

Baixe o cliente Python company_backup.py e coloque-o ao lado do seu script. Ele requer Python 3.10 ou mais recente no Linux ou macOS e usa apenas a biblioteca padrão. Defina SKAVA_BACKUP_TOKEN no ambiente de processo protegido e substitua 42 pelo ID da empresa no endereço do aplicativo 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")

Tarefas agendadas podem invocar o mesmo cliente diretamente:

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

O cliente solicita a geração, consulta o status, faz o streaming do download para o disco, verifica o tamanho, o SHA-256 e o conteúdo do ZIP, e confirma o recebimento. Ele armazena backups completos e incrementais como arquivos separados. Mantenha o arquivo de estado oculto nesse diretório: ele contém as informações de cadeia e retomada. Antes de solicitar outro incremental, o cliente verifica todos os arquivos ZIP anteriores. Após uma interrupção, repita o mesmo comando. Tarefas concorrentes para a mesma empresa no mesmo diretório são evitadas.

Fluxo da API sem conexão persistente

1. Requisição: POST /api/v1/companies/42/backups com {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Para um incremental, defina kind como diff e envie o ID do seu backup completo local como base_id e o ID do último pacote confirmado como parent_id. A resposta fornece job.id. Reutilize o mesmo request_id ao tentar novamente.
2. Consulta: GET /api/v1/companies/42/backups/JOB_ID, aproximadamente a cada dez segundos. A geração ocorre em segundo plano durante queued ou running. Nenhuma conexão permanece aberta entre as requisições.
3. Download: Em ready com available: true, chame GET /api/v1/companies/42/backups/JOB_ID/download. Apenas esta transferência mantém uma conexão aberta. Se for interrompida, baixe o arquivo inteiro novamente.
4. Confirmar recebimento: Verifique job.bytes e job.sha256. Obtenha X-Backup-Download-Id e X-Backup-Receipt dos cabeçalhos da resposta do download. Envie POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm com {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Apenas uma transferência completa com confirmação correspondente conta como bem-sucedida.

GET /api/v1/companies/42/backups retorna o histórico, paginado através de next_offset. Cotas esgotadas ou limites temporários de capacidade retornam HTTP 429 com Retry-After. Os backups são gerados sequencialmente dentro dos limites, para que tarefas simultâneas noturnas não sobrecarrem a aplicação.

Compreender o histórico de downloads

O histórico mostra o tipo completo ou incremental, horário da solicitação, validade, backup completo, predecessor e cada tentativa de download com os bytes transferidos. “Pronto” identifica um arquivo gerado. “Transferido” significa que o servidor enviou todos os bytes. “Checksum confirmado” significa que o cliente verificou e confirmou o recebimento completo. Tentativas interrompidas e falhas permanecem visíveis.

O aplicativo web verifica o recebimento no navegador antes do diálogo de salvamento. Essa confirmação não prova que o arquivo foi armazenado permanentemente no seu computador. Para backups automatizados, o cliente Python grava o arquivo no disco antes de confirmar o recebimento. Os downloads pelo aplicativo web são limitados a 64 MiB; use o cliente Python para arquivos maiores.