bubbles-backup-bcdr-doctrine

Defines backup tiers, RTO/RPO targets, and restore-drill cadence for BCDR planning.

1|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-backup-bcdr-doctrine-pkirsanov
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bubbles-backup-bcdr-doctrine
Source: https://github.com/pkirsanov/bubbles/tree/main/skills/bubbles-backup-bcdr-doctrine
Command: npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-backup-bcdr-doctrine-pkirsanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams running self-hosted products often lack a consistent backup and disaster recovery doctrine, leading to unclear recovery objectives, untested backups, and offsite strategies that require code changes when infrastructure evolves. ## Core Features & Use Cases - Four-Tier Backup Model: Defines T1 ZFS snapshots, T2 host-local restic, T3 removable USB, and T4 cloud offsite, all encapsulated behind a single OFFSITE_BACKEND environment variable. - RTO/RPO and Drill Cadence: Specifies how to declare per-product recovery objectives in a BCDR plan and enforce weekly restore-tests, quarterly BCDR drills, and compliance sweeps. - Gate Enforcement: Documents gates G112-G116 that block release-train promotion without backup evidence, successful restore tests, and offsite backends for production trains. - Use Case: When adding a new product to a single-host RAID server, use this doctrine to configure daily T1+T2 backups with WARN-level offsite gates, then flip to blocking enforcement when USB drives or cloud storage arrive. ## Quick Start Ask the agent to define a backup and BCDR strategy for a new product using the four-tier model and OFFSITE_BACKEND contract.

Frequently Asked Questions about bubbles-backup-bcdr-doctrine

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up an offsite backup strategy for a self-hosted product?▼

Use the four-tier model: T1 ZFS snapshots and T2 host-local restic run daily, T3 uses a rotated USB drive, and T4 uses cloud storage via restic to B2, R2, Wasabi, or S3. Set the OFFSITE_BACKEND environment variable in the product's params.yaml to select the active tier.

What is the difference between RTO and RPO in a BCDR plan?▼

RTO is the maximum time from declaring an incident until the product is back online, measured from drill ledger timestamps. RPO is the maximum tolerable data loss in time, determined by backup cadence, so daily backups imply a 24-hour RPO ceiling.

How do I switch backup backends without changing product code?▼

Change the OFFSITE_BACKEND environment variable, for example from local-only to restic_usb:/mnt/usb-backup-1 or restic_b2:bucket=mybucket, then re-run the adapter apply script. The engine parses the prefix and dispatches to the correct restic backend.

Why is a completed backup not enough evidence for release promotion?▼

Backup completion does not prove restorability, so gate G113 requires a successful restore-test within the cadence before promotion. Restore-tests run in an isolated ephemeral namespace and must exit cleanly to count as evidence.

When does local-only backup block production releases?▼

Gate G116 only warns when offsite_required is false, which is the default for single-host setups without offsite storage. Setting offsite_required to true in release-trains.yaml makes local-only backends block promotion of production trains.