Резервні копії компанії

Адміністратори та власники компанії відкривають свою компанію в веб-додатку і обирають Резервні копії. Вони можуть створювати запити на резервне копіювання, завантажувати 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 без постійного з'єднання

Запит: 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.
Опитування: GET /api/v1/companies/42/backups/JOB_ID, приблизно кожні десять секунд. Генерація відбувається у фоновому режимі, поки статус queued або running. Між запитами з'єднання не залишається відкритим.
Завантаження: Коли статус ready і available: true, викличте GET /api/v1/companies/42/backups/JOB_ID/download. Лише це переміщення тримає з'єднання відкритим. Якщо процес перервався, завантажте весь файл заново.
Підтвердження отримання: Перевірте 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-клієнт.