什么是 Restic Home Backup？

Restic Home Backup 是一款旨在保护 Linux 主目录的综合自动化技能。它利用 restic 的强大功能，为本地磁盘、S3 或 SFTP 等各种后端提供加密、去重和版本化的备份。通过直接与 systemd 集成，该技能确保您的备份生命周期（包括快照、清理和完整性检查）完全自动化且可靠。

作为 Openclaw Skills 生态系统的一部分，它专注于操作安全，确保敏感凭据得到保护，同时为灾难恢复提供清晰的路径。它执行严格的权限标准，并在对系统目录进行更改之前需要显式的用户确认，使其成为维护高完整性备份工作流的基本工具。

下载入口:https://github.com/openclaw/skills/tree/main/skills/moep90/restic-home-backup-safe

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Restic Home Backup 应用场景

• 自动化将主目录每日或每周备份到异地云存储。
• 实施保留策略以管理磁盘空间，同时保留历史快照。
• 设置具有自动化完整性验证的安全加密备份仓库。
• 使用 systemd 定时器和仅 root 访问的凭据文件加强 Linux 系统的备份安全性。

1. 该技能评估备份需求，包括源路径、目标仓库端点和首选保留策略。
2. 它生成确定性的设置产物，包括环境文件和 shell 脚本，并使用仅计划（plan-only）模式以确保安全。
3. 它配置 systemd 服务和定时器单元，以处理自动化备份、清理和检查例程。
4. 验证阶段运行冒烟测试恢复和初始快照，以确保仓库功能正常且可访问。
5. 它生成一份简短的操作手册，用于日常维护和手动恢复过程。

Restic Home Backup 配置指南

要在您的 Openclaw Skills 环境中部署此技能，请确保已安装 restic，然后按照以下步骤操作：

# 引导备份实现（默认为仅计划模式）
./scripts/bootstrap_restic_home.sh --repo /path/to/repo

# 应用系统更改（需显式确认）
./scripts/bootstrap_restic_home.sh --repo /path/to/repo --apply

# 验证 systemd 定时器是否已激活
systemctl list-timers | grep restic

Restic Home Backup 数据架构与分类体系

该技能在以下系统路径中组织备份元数据和配置，以确保安全性和可发现性：

name: restic-home-backup
description: Design, implement, and operate encrypted restic backups for Linux home directories with systemd automation, retention policies, and restore validation. Use when a user asks to back up ~/, set up daily/weekly/monthly backup jobs, harden backup security, or troubleshoot restore/integrity issues.

Restic Home Backup

Define and deliver a production-ready restic backup setup for ~/ with encryption, deduplication, automated scheduling, and restore testing.

Skill contract

• Name: restic-home-backup
• Problem solved: Provide reliable, encrypted, versioned backups of a Linux home directory with operational safety and repeatable recovery.
• Inputs:
  • Backup target type (local disk, sftp, s3, b2, etc.)
  • Repository endpoint/path
  • Secret handling method (env file or password file)
  • Schedule preferences (daily backup, weekly prune, monthly check)
  • Exclude patterns
• Outputs:
  • Installed and initialized restic repository
  • Backup/prune/check scripts
  • systemd service/timer units
  • Validation evidence (snapshots + test restore)
  • Short operator runbook
• Safety boundaries (must never violate):
  • Never print secrets or tokens in chat/log output.
  • Never delete snapshots/repositories without explicit user confirmation.
  • Never weaken permissions on credential files (chmod 600 minimum).
  • Never claim backup success without checking command exit status and snapshot listing.
  • Never apply system changes implicitly: require explicit --apply (or explicit user confirmation) before writing to /etc, /usr/local/bin, or /etc/systemd/system.

Workflow

1) Assess and confirm backup contract

Collect the minimum required values before changes:

• Source path (default /home/)
• Destination repo and transport
• Retention policy (for example: 7d/4w/12m)
• Preferred schedule in local timezone

If any critical value is missing, ask targeted questions.

2) Scaffold backup implementation

Use these resources:

• scripts/bootstrap_restic_home.sh to generate deterministic setup artifacts. It is PLAN-ONLY by default and requires explicit --apply for system changes. Optional flags control timer enablement, repository initialization, and initial backup run.
• references/ops-checklist.md for day-2 operations and troubleshooting.

Create:

• /etc/restic-home.env (root-readable only)
• /usr/local/bin/restic-home-backup.sh
• /usr/local/bin/restic-home-prune.sh
• /usr/local/bin/restic-home-check.sh
• restic-home-backup.service/.timer
• restic-home-prune.service/.timer
• restic-home-check.service/.timer

3) Harden and validate

Run and verify:

1. restic snapshots
2. One immediate backup run
3. One restore smoke test to temporary directory
4. restic check (or scheduled monthly deep check)

Validate failure behavior:

• Wrong password
• Unreachable repository
• Permission denied on env file

Report exact failing command + short corrective action.

4) Package and publish via ClawHub CLI (when requested)

When user requests publication:

1. Validate skill quality and structure.
2. Package skill.
3. Publish with clawhub CLI.
4. Verify install from registry in a clean environment.

Keep publish actions explicit and auditable.

Response style requirements

Use descriptive language with concrete operational detail:

• Name the exact file path, service name, and command.
• State what changed and how to verify it.
• End multi-step tasks with explicit completion status.