openclaw-sync_skill

Overview

This skill provides real-time file synchronization for OpenClaw using inotify to detect file changes and rclone to upload to cloud object storage. It automatically persistently backs up memory, configuration, and skill files to providers such as Qiniu (Kodo), Tencent COS, or Alibaba OSS. It supports running as a systemd service for continuous background syncing or via simple shell scripts for manual control.

How this skill works

The agent watches configured file paths with inotify and triggers sync jobs when files change. Sync operations use rclone to transfer selected files and directories to a configured cloud bucket. You can run a monitoring script for ad-hoc use or install the provided systemd unit to run the monitor as a persistent service. Configuration is managed through rclone.conf and a backup.json list of sync targets.

When to use it

• You need persistent off-host backups of OpenClaw memory and configs.
• You want automatic, low-latency syncing on file changes rather than scheduled batch backups.
• You operate multiple OpenClaw instances that should share a single cloud bucket.
• You require simple tools that integrate with systemd for reliable background operation.
• You need quick recovery options and cloud-based restore workflows.

Best practices

• Use rclone and test rclone.conf with the provided test script before enabling automated syncs.
• Keep the sync-list minimal and explicit (data/sync-list.txt) to avoid uploading unnecessary files.
• Run the monitor as a systemd service for reliability and automatic restarts.
• Limit permissions of the cloud credentials to only the target bucket and operations required for backup and restore.
• Regularly run restore.sh in a staging environment to validate backups and recovery steps.

Example use cases

• Automatic persistence of conversational memory files (MEMORY.md, memory/), identity and user profile files.
• Continuous backup of OpenClaw configuration and skill config files (AGENTS.md, tools, skills/*/config.json).
• Multi-instance deployments where several servers write to separate prefixes in one cloud bucket for centralized storage.
• Quick disaster recovery: use restore.sh to fetch the latest synced state to a replacement instance or development sandbox.
• Operational monitoring: use journalctl and systemctl to track service health and sync activity.