📦 Спецификация формата резервного копирования Monica WebDAV

Аннотация

Настоящая спецификация определяет структуру архива, базовые форматы данных и протоколы шифрования, используемые локальным хранилищем Monica во время автоматического резервного копирования WebDAV и передачи данных. Разработанный фреймворк обеспечивает надежные возможности кроссплатформенного парсинга наряду с бескомпромиссным уровнем конфиденциальности и безопасности.

---

1. Обзор

Механизм резервного копирования WebDAV в Monica упаковывает основные данные пользователя в стандартный ZIP-архив (имеет расширение .zip без шифрования и .enc.zip при включении высокопрочного шифрования резервных копий).

Вместо традиционных избыточных прямых двоичных экспортов баз данных, архив резервной копии использует слабосвязанную архитектуру, состоящую из основных данных .json, сводных таблиц .csv и медиаресурсов (изображений). Это гарантирует упрощенный аудит данных и высокоточную логику восстановления на любых платформах в будущем.

---

2. Структура каталогов архивного пакета

Дерево структуры стандартного ZIP-архива резервной копии после распаковки выглядит следующим образом:

/ (Корневой каталог)
├── passwords/                  # Записи паролей (высокосвязное раздельное хранение)
│   ├── password_1_1700000.json
│   └── password_2_1700001.json
├── notes/                      # Защищенные заметки
│   └── note_1_1700005.json
├── cards/                      # Кошелек банковских карт
│   └── card_1_1700010.json
├── otp/                        # Сиды аутентификатора 2FA
│   └── otp_1_1700015.json
├── images/                     # Зашифрованные бинарные медиавложения
│   ├── attachment_blob_a.bin
│   └── attachment_blob_b.bin
├── summary.csv                 # Таблица быстрого индекса (для генерации превью списков)
└── metadata.json               # Метаданные архива (версия приложения, штамп времени, соль)

---

3. Спецификация схемы основных полей данных (JSON)

Каждая сущность внутри каталогов сериализуется в строго типизированный документ JSON. Ниже приведен пример схемы для объекта пароля (passwords/password_*.json):

{
  "id": 1700000,
  "title": "GitHub Account",
  "username": "mrmiaomrzh",
  "password": "EncryptedBase64String...",
  "websiteUrl": "[https://github.com](https://github.com)",
  "notes": "Личный аккаунт разработчика",
  "ssoRefEntryId": 1700002,
  "categoryId": 12,
  "totpSecretId": 1700015,
  "lastModifiedTime": 1776289200000,
  "isPinned": true
}

Описание критических полей связей:

• ssoRefEntryId: Внешний ключ связи (ID ссылки стороннего входа), указывающий на другую запись учетных данных для реализации механики сквозной авторизации.
• totpSecretId: Идентификатор ассоциации с объектом в каталоге otp/ для синхронного вывода кодов 2FA на карточке пароля.

---

4. Криптографический слой двоичного потока MONICA_ENC_V1

Когда пользователь активирует сквозное шифрование резервных копий, ZIP-архив перед передачей по сети обрабатывается специализированным криптографическим модулем:

1. Алгоритм шифрования: Используется режим AES-256-GCM (Advanced Encryption Standard в режиме Галуа/счетчика) с аутентификацией данных, что предотвращает не только чтение, но и любые попытки незаметного изменения бит файла на облачном сервере.
2. Дизайн заголовка (Header): В начало бинарного файла резервной копии принудительно внедряется блок заголовка со следующей сигнатурой структуры:

• MONICA_ENC_V1 (Магические байты — маркер версии генерации формата).
• Высокоэнтропийная случайная соль (Salt, 16 байт) для PBKDF2.
• Случайный вектор инициализации (IV, 12 байт).

---

5. Логика восстановления на устройствах и разрешения конфликтов идентификаторов

Во время фазы импорта или восстановления данных из облака клиентская среда выполнения строго выполняет следующий конвейер жизненного цикла:

1. Дешифрование и валидация: Считывание заголовка .enc.zip ➔ Проверка целостности магических байтов ➔ Дешифрование потока через ключи, деривированные из пароля бэкапа ➔ Распаковка файлов в изолированную виртуальную песочницу в оперативной памяти.
2. Разрешение конфликтов ID:

• Если обнаруживается, что id извлекаемой JSON-записи уже существует в активной локальной базе данных устройства, движок блокирует прямую перезапись (предотвращая потерю более новых локальных данных).
• Активируется резервный маршрут: для входящей записи динамически выделяется новый уникальный физический идентификатор Long ID, после чего она безопасно сохраняется в виде новой сущности.

3. Реструктуризация графа связей (Ремонт маппинга ID):

• Рантайм компилирует временную карту соответствий вида Old ID ➔ New ID.
• Система автоматически сканирует и перезаписывает параметры ssoRefEntryId, индикаторы парных аккаунтов и привязки TOTP, сохраняя логическую целостность графа данных без разрыва реляционных связей.

4. Релокация медиаактивов:

• Обрабатываются все бинарные записи внутри дерева директории images/.
• Фотоснимки и документы безопасно мигрируют во внутреннюю изолированную файловую систему хост-приложения (context.filesDir), а соответствующие внутренние пути путей обновляются в активной базе данных заметок