docs: Update docs for the correctness (#13)

2026-04-15 00:48:06 +03:00
1 parent 8dba55272c
commit 51a783f93a
@@ -0,0 +1,71 @@
+---
+title: Модель многоуровневого хранения
+description: Стандартизированная таксономия хранения данных сервисов.
+weight: 15
+---
+
+Фреймворк навязывает стандартизированную таксономию хранения. Это гарантирует, что каждый сервис имеет предсказуемое местоположение для своих данных, что упрощает стратегии резервного копирования и распределение оборудования.
+
+## Таксономия хранения {#taxonomy}
+
+Данные разделены на три логических [Уровня (Tiers)](/root/glossary#tier) на основе их требований к производительности, жизненного цикла и важности.
+
+### Уровень 1 (Tier 1): Конфигурации и Кэш
+
+**Путь:** `${ROOT_NODE_DIR}/@tier1`
+
+- **Содержимое**: Конфигурационные файлы, небольшие базы данных SQLite, SSL-сертификаты, кэш приложений.
+- **Характеристики**: Чрезвычайно высокая ценность, объем от низкого до среднего, требует минимальных задержек (latency).
+- **Оборудование**: Высокоскоростные SSD-накопители, обычно общие с операционной системой.
+
+### Уровень 2 (Tier 2): Данные приложений
+
+**Путь:** `${ROOT_NODE_DIR}/@tier2`
+
+- **Содержимое**: Пользовательские загрузки, большие базы данных, постоянное состояние приложений.
+- **Характеристики**: Высокая ценность, объем от среднего до высокого, требует высокой надежности.
+- **Оборудование**: Надежные HDD-кластеры, RAID-массивы или выделенные хранилища.
+
+### Уровень 3 (Tier 3): Временные файлы и объемные медиа
+
+**Путь:** `${ROOT_NODE_DIR}/@tier3`
+
+- **Содержимое**: Логи, временные файлы, объемные медиа (фильмы, музыка) и другие некритичные большие данные.
+- **Характеристики**: Низкая ценность, очень высокий объем.
+- **Оборудование**: HDD большой емкости, оптимизированные для непрерывной последовательной записи/чтения (например, WD Purple). Обратите внимание, что Tier 3 **слишком медленный для кэша**.
+
+## Стратегия резервного копирования {#backup}
+
+Общие модули не навязывают конкретную стратегию резервного копирования и не предоставляют реализацию по умолчанию, обеспечивая полную гибкость на уровне узла. Ожидается, что операторы сами реализуют логику резервного копирования.
+
+### Пример: Резервное копирование с помощью Restic
+
+Распространенной лучшей практикой является использование **Restic** для резервного копирования. Например, вы можете создать файл compose узла оператора для запуска Restic:
+
+```yaml filename="operator-compose.yml"
+services:
+  restic:
+    image: restic/restic:0.18.1
+    container_name: operator-restic
+    volumes:
+      - ./@tier2/{project}/{service}/{data}:/data/@tier2/{project}/{service}/{data}:ro
+      - ./@tier1/{project}/{service}/{data}:/data/@tier1/{project}/{service}/{data}:ro
+      - ./@tier1/.operator/restic/cache:/var/restic-cache
+    environment:
+      RESTIC_REPOSITORY: "s3:example.com/bucket"
+      RESTIC_PASSWORD: ${RESTIC_PASSWORD}
+      # ... учетные данные AWS/S3
+    network_mode: "host"
+    entrypoint: [ "restic" ]
+    user: "0:0"
+```
+
+### Реализация стратегии
+
+Операторы могут реализовать свою стратегию, определив локальный Action в `.operator/local/scripts/actions/sync/tiers`. Диспетчер `root` затем сможет выполнить этот скрипт для запуска резервного копирования, позволяя детально контролировать способ сохранения данных.
+
+## Обоснование {#justification}
+
+1. **Оптимизация оборудования**: Сопоставляя уровни с конкретным оборудованием (SSD для Tier 1, RAID для Tier 2, Purples для Tier 3), мы оптимизируем как производительность, так и стоимость.
+2. **Выборочное резервное копирование**: Отделение временных логов и объемных медиа (Tier 3) от критических конфигураций (Tier 1) предотвращает трату дорогостоящего места в хранилище резервных копий.
+3. **Архитектурная ясность**: Любой оператор может проинспектировать директорию [Узла (Node)](/root/glossary#node) и сразу понять требования к хранению и приоритет его содержимого.