Skava Skava / Wiki

Резервные копии компании

Администраторы и владельцы компании открывают её в веб-приложении и выбирают пункт Резервные копии. Они могут запрашивать резервные копии, скачивать файлы ZIP и управлять API-ключами для своего сервера резервного копирования. Этот экспорт недоступен в мобильном приложении.

Охват и ограничения

Резервная копия включает обычные чаты проектов компании, в том числе архивированные, с сообщениями, реакциями, карточками чатов и связанными с ними загруженными вложениями. Также в неё входят метаданные проектов и чатов, имена участников и опубликованные документы компании в этих чатах. Администраторы и владельцы компании могут создавать резервные копии корпоративных чатов, к которым они лично не присоединились.

Личные сообщения, приватные заметки, услуги, видимые только лично, чаты между компаниями и личные черновики исключаются. Содержимое Company Drive и внешних ссылок не входит в этот экспорт чатов. Отсутствие связанных вложений приводит к сбою генерации. ZIP-файл представляет собой экспорт данных; автоматический импорт обратно в Skava пока недоступен.

Квоты, инкрементальные резервные копии и срок хранения

Каждая компания может запросить одну полную резервную копию в течение 7 дней и две инкрементальные резервные копии в течение 24 часов. Эти скользящие окна отсчитываются с момента каждого запроса. Повторное скачивание уже готового файла не расходует квоту на генерацию. Неудачные задания по генерации не учитываются в этих лимитах.

Каждая инкрементальная копия содержит изменения и удаления, произошедшие с момента последней полностью переданной и подтверждённой контрольной суммой резервной копии. Цепочка выглядит как A + B + C: A это полная копия, B содержит изменения с момента A, а C только дальнейшие изменения с момента B. Чтобы восстановить состояние, примените все пакеты по порядку. Невизменённые вложения ссылаются на файлы, уже присутствующие в этой цепочке.

Скачивание доступно в течение 24 часов после завершения генерации. Затем ZIP-архив удаляется, а история сохраняется. Храните полную резервную копию и все связанные с ней инкрементальные копии локально. Состояние сравнения остаётся пригодным для использования не более 90 дней после полной копии; после этого требуется новая полная резервная копия. Каждая инкрементальная копия идентифицирует как полную копию, так и её непосредственного предшественника по ID и SHA-256.

Новым предшественником становится только полностью полученный и подтверждённый пакет. Готовый, но неподтверждённый инкрементальный пакет блокирует создание другого инкрементального пакета до подтверждения или истечения срока. После истечения срока действия неподтверждённого пакета следующая попытка начинается с последнего подтверждённого состояния и включает изменения, которые ещё не были сохранены. Если подтверждённая часть отсутствует локально, скачайте её повторно в течение 24-часового окна доступности или запустите новую полную резервную копию в рамках недельного лимита. Рекомендуется использовать одну общую директорию для резервных копий на компанию; независимые клиенты должны хранить одну и ту же полную цепочку.

Настройка ключа API

В разделе Ключи API введите название, например «Компания NAS», и создайте ключ. Он отображается один раз, действует один год и может быть отозван в любой момент. Сохраните его в защищенном хранилище секретов вашей среды резервного копирования. Ключ принадлежит компании и предоставляет доступ только к API резервных копий этой компании. Он работает независимо от последующего входа создателя.

Передавайте его по HTTPS в заголовке Authorization: Bearer YOUR_BACKUP_TOKEN. Не храните ключи в URL, публичных скриптах и логах. Создавать, просматривать список и отзывать ключи могут только администраторы и владельцы компании.

Веб-приложение: API-ключ с датой истечения срока действия и возможностью отзыва
Управление ключами в веб-приложении: имя, срок действия и отзыв для каждой программы резервного копирования.

Python: загрузка полной резервной копии и инкрементальных обновлений

Скачайте клиент company_backup.py на Python и разместите его рядом со своим скриптом. Требуется Python 3.10 или новее на Linux или macOS, используются только стандартные библиотеки. Установите SKAVA_BACKUP_TOKEN в защищенной среде процесса и замените 42 на ID компании из адреса веб-приложения.

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

Планировщик задач может вызывать тот же клиент напрямую:

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

Клиент запрашивает создание резервной копии, опрашивает статус, записывает поток загрузки на диск, проверяет размер, SHA-256 и содержимое ZIP, подтверждает получение. Полные и инкрементальные резервные копии сохраняются как отдельные файлы. Сохраняйте скрытый файл состояния в этой директории: в нём хранятся данные о цепочке и информации для возобновления. Перед запросом новой инкрементальной копии клиент проверяет все предыдущие файлы ZIP. После прерывания повторите ту же команду. Одновременные задачи для одной компании в одной директории предотвращаются.

Поток API без постоянного соединения

  1. Запрос: POST /api/v1/companies/42/backups с телом {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Для инкрементальной копии установите kind в diff, передайте локальный ID полной резервной копии как base_id и ID последнего подтверждённого пакета как parent_id. В ответе возвращается job.id. При повторной попытке используйте тот же request_id.
  2. Опрос: GET /api/v1/companies/42/backups/JOB_ID, примерно каждые десять секунд. Генерация выполняется в фоне во время статусов queued или running. Соединение между запросами не остаётся открытым.
  3. Загрузка: при статусе ready и значении available: true выполните запрос GET /api/v1/companies/42/backups/JOB_ID/download. Только этот процесс поддерживает открытое соединение. При прерывании загрузите файл заново целиком.
  4. Подтверждение получения: проверьте значения job.bytes и job.sha256. Извлеките заголовки X-Backup-Download-Id и X-Backup-Receipt из ответа на запрос загрузки. Отправьте запрос POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm с телом {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Операция считается успешной только при полной передаче данных и совпадающем подтверждении.

Запрос GET /api/v1/companies/42/backups возвращает историю с пагинацией через next_offset. При исчерпании квоты или временных ограничениях емкости возвращается код HTTP 429 с заголовком Retry-After. Резервные копии создаются последовательно в пределах лимитов, поэтому одновременные ночные задачи не перегружают приложение.

Понимание истории загрузок

В истории отображаются тип (полный или инкрементальный), время запроса, срок действия, полный бэкап, предыдущая версия и каждая попытка загрузки с указанием переданных байтов. Статус «Готово» означает, что файл сгенерирован. Статус «Передано» означает, что сервер отправил все байты. Статус «Контрольная сумма подтверждена» означает, что клиент проверил данные и подтвердил полное получение. Прерванные и неудачные попытки остаются видимыми.

Веб-приложение: инкрементальное резервное копирование с предшественником, сроком истечения загрузки и подтвержденной контрольной суммой
История загрузок показывает цепочку резервных копий, 24-часовое окно и подтвержденное получение всех данных.

Веб-приложение подтверждает получение данных в браузере перед открытием диалога сохранения. Это подтверждение не гарантирует, что файл был впоследствии сохранен на вашем компьютере. Для автоматического резервного копирования Python-клиент записывает файл на диск до подтверждения получения. Загрузки через веб-приложение ограничены размером 64 МБ; для архивов большего размера используйте Python-клиент.