---
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) и сразу понять требования к хранению и приоритет его содержимого.