Что нового

OpenClaw 2026.10.1: именованные локации и шифрованные бэкапы в R2

Как описать локацию для бэкапов через filesystem или Cloudflare R2, инициализировать её и перевести backup create --to на шифрованный offsite.

· 5 мин чтения

Коротко

  • Локация — это именованное место назначения из storage.locations с провайдером, настройками и шифрованием через SecretRef (ссылка на секрет) или парольную фразу.
  • Бэкапы идут через openclaw backup create --to offsite: команда открывает локацию, проверяет отметку, делает архив во временной директории, прогоняет верификацию, загружает объект и удаляет временную копию.
  • Конфиг локации сам не планирует расписание и не переносит существующие архивы.

Сверено с документацией OpenClaw 2026.10.1, 11 октября 2026.

Локальный .tar.gz рядом с Gateway это удобно, пока рядом есть диск. Дальше встают два вопроса: куда складывать копию вне машины и что делать, если диск выпал. В OpenClaw 2026.10.1 для этого ввели storage locations: именованные места назначения с провайдером, настройками и шифрованием. Команда backup create --to offsite грузит проверенный архив туда.

Что конфиг локации делает и чего не делает

Конфигурация локации описывает, куда класть объекты, под каким шифрованием и с какими учётными данными. Сама она не планирует бэкапы и не переносит уже сделанные архивы.

Локация на подключаемом диске

Провайдер filesystem принимает settings: { path: "/absolute/existing/directory" }, только существующий каталог. OpenClaw никогда не создаёт корневой каталог сам. В среде процесса, запускающего CLI или Gateway, задайте OPENCLAW_STORAGE_PASSPHRASE и сохраните её копию в менеджере секретов.

{
  storage: {
    locations: {
      archive: {
        provider: "filesystem",
        settings: { path: "/mnt/archive/openclaw" },
        encryption: {
          passphrase: {
            source: "env",
            provider: "default",
            id: "OPENCLAW_STORAGE_PASSPHRASE",
          },
        },
      },
    },
  },
}

Шифрование использует формат OCSTOR1: scrypt выводит мастер-ключ, аутентифицированный AES-256-GCM шифрует поток с отдельным ключом на каждый объект. Неверная парольная фраза вернёт состояние wrong-key. Имена объектов и маркер инициализации остаются видны провайдеру; шифрование защищает содержимое объектов.

openclaw storage init archive
openclaw storage test archive
openclaw storage list --json

Команда storage init пишет openclaw-storage.json в корень локации. Повторный запуск с теми же настройками и парольной фразой безопасен: маркер не перезаписывается. Команда storage test пишет временный объект .openclaw-probe-<uuid> в корень, читает его через слой шифрования, проверяет байты и удаляет. Если при удалении произошёл сбой, переподключите провайдер перед очисткой оставшихся пробных объектов.

Cloudflare R2 как удалённая локация

Плагин cloudflare подключает провайдер r2 через S3-совместимый API Cloudflare. Бакет создаётся вручную в дашборде, токен через R2 → Account Details → API Tokens → Create Account API token с правами Object Read & Write на этот бакет. Секретный ключ показывается один раз. Переменные R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY и OPENCLAW_STORAGE_PASSPHRASE должны быть в среде CLI и Gateway.

{
  storage: {
    locations: {
      offsite: {
        provider: "r2",
        settings: {
          accountId: "00000000000000000000000000000000",
          bucket: "openclaw-artifacts",
          prefix: "openclaw",
          accessKeyId: {
            source: "env",
            provider: "default",
            id: "R2_ACCESS_KEY_ID",
          },
          secretAccessKey: {
            source: "env",
            provider: "default",
            id: "R2_SECRET_ACCESS_KEY",
          },
        },
        encryption: {
          passphrase: {
            source: "env",
            provider: "default",
            id: "OPENCLAW_STORAGE_PASSPHRASE",
          },
        },
      },
    },
  },
}

Поля accessKeyId и secretAccessKey для R2 принимают только SecretRef: обычные строки отклоняются. Вместо переменных окружения можно использовать другой настроенный провайдер секретов. Шифрование на R2 отдельное: режим none оставит бэкап читаемым для того, у кого есть токен.

openclaw storage init offsite
openclaw storage test offsite
openclaw storage list --json

После init и test создание бэкапа выглядит одинаково для локальной папки и для R2. Команда openclaw backup create --to offsite открывает локацию, проверяет маркер, делает архив во временной директории, прогоняет верификацию, загружает объект и сверяет размер. Временный архив удаляется. Добавьте --output <path>, если нужна локальная копия; она сохраняется как обычный открытый .tar.gz, даже когда шифрование локации включено.

Расписание и совместное использование локации

Сама локация не планирует расписание. Включить периодический запуск можно командой backup enable --to offsite --every 24h --keep-daily 7. С --keep-daily 7 ротация оставляет самый свежий бэкап за каждый из семи последних непустых дней по UTC. Недели и месяцы добавляются флагами --keep-weekly и --keep-monthly.

Несколько установок могут использовать одну локацию через --namespace <name>. Первый запуск пишет owner.json с идентификатором устройства Gateway, именем хоста и временем; другая установка с тем же пространством имён получит отказ бэкапа и запись о неудачной попытке, чтобы случайное совпадение имён хостов не привело к общей ротации. Восстановление остаётся чтением без проверки владельца. Если обе установки продолжают работать параллельно, заведите отдельное пространство имён.

Состояния локации и что с ними делать

Команды storage list и storage test показывают состояние локации. На него и опирайтесь при диагностике.

  • ok: маркер и шифрование в порядке, проба прошла.
  • uninitialized: маркера нет. Если это действительно новое место, выполните openclaw storage init <name>. Пустой mountpoint без подтверждения инициализировать нельзя.
  • wrong-key: неверная парольная фраза или битый SecretRef. Восстановите оригинальную парольную фразу; замена маркера инициализации данные не вернёт.
  • unavailable: переподключите диск или восстановите доступ к бакету. Путь и учётные данные должны быть видны и CLI, и Gateway.
  • error: прочитайте сообщение и исправьте настройки провайдера, права или указанный сбой.

Что проверить при обновлении

  1. Сохраните в надёжном месте OPENCLAW_STORAGE_PASSPHRASE, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY и текущую секцию storage.locations конфига.
  2. Добавьте секцию storage.locations под нужное имя (archive, offsite и т. п.) и убедитесь, что переменные окружения доступны процессу Gateway, а не только вашей оболочке.
  3. Создайте маркер инициализации: openclaw storage init <name> для каждой локации. Повторный init с теми же настройками безопасен.
  4. Прогоните пробный цикл записи, чтения и удаления: openclaw storage test <name> --json. В ответе должно быть state: "ok".
  5. Сделайте пробный удалённый бэкап: openclaw backup create --to offsite, затем openclaw backup list --from offsite и openclaw backup verify --from offsite latest.
  6. Если нужно расписание, включите его после проверки: openclaw backup enable --to offsite --every 24h --keep-daily 7. Старые локальные .tar.gz остаются на месте и никуда не переезжают.