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: изтегляне на пълно резервно копие и инкрементални данни

Изтеглете Python клиента company_backup.py и го поставете до вашия скрипт. Изисква 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 MiB; използвайте Python клиента за по-големи архиви.