mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5
c55f508e05
The cosmos generator linked a consumer to its provider only through an '<role>' in group_names reference or an explicit provides: name. A hard dependency has neither -- pinning the provider on unconditionally is exactly what removes the Jinja reference the generator was reading -- so web-svc-asset's bond to web-svc-file vanished from the diagram the moment it became binding. Match a service key against the provider's own primary key from the registry, in both directions. Services the role turns off drew a solid 1:1 edge, claiming a mandatory relationship for something that carries nothing at deploy time. They now render as a red 0..0 edge; edge merging gained a real precedence so a provider consumed through two keys stays live when only one is off. Named colour, not hex: a '#' opens an entity code in the mermaid lexer and turns the whole diagram into a parse error on GitHub. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
105 lines
4.1 KiB
Markdown
105 lines
4.1 KiB
Markdown
# Cleanup Failed Backups
|
|
|
|
## Description
|
|
|
|
This role installs and runs the **cleanback** tool to automatically detect and remove **failed Docker backups**.
|
|
|
|
The cleanup process scans backup directories located under the configurable path
|
|
**DIR_BACKUPS** (for example `/Backups`)
|
|
and removes only those backups that are detected as invalid, while keeping recent backups safe.
|
|
|
|
To avoid accidental data loss, the role **keeps the most recent backups by default** and runs fully unattended via a scheduled system service.
|
|
|
|
## Overview
|
|
|
|
This role cleans up failed Docker backups by configuring a systemd service and timer to execute the cleanup operations periodically.
|
|
|
|
## Cosmos
|
|
|
|
The diagram places Cleanup Failed Backups in the Infinito.Nexus cosmos: the components it deploys (capabilities), the central services it consumes (dependencies), and its outward reach (federation and bridged external networks).
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
subgraph role [sys-ctl-cln-faild-bkps 💻]
|
|
svc_faild_bkps["faild-bkps"]
|
|
end
|
|
subgraph dependents [Dependents]
|
|
dpt_svc_bkp_nfs_2_local["svc-bkp-nfs-2-local 💻 ⚙️"]
|
|
dpt_svc_bkp_remote_2_local["svc-bkp-remote-2-local 💻 ⚙️"]
|
|
dpt_svc_bkp_secrets_2_local["svc-bkp-secrets-2-local 💻 ⚙️"]
|
|
dpt_svc_bkp_volume_2_local["svc-bkp-volume-2-local 💻 ⚙️"]
|
|
end
|
|
svc_faild_bkps -- "1:1" --> dpt_svc_bkp_nfs_2_local
|
|
svc_faild_bkps -- "1:1" --> dpt_svc_bkp_remote_2_local
|
|
svc_faild_bkps -- "1:1" --> dpt_svc_bkp_secrets_2_local
|
|
svc_faild_bkps -- "1:1" --> dpt_svc_bkp_volume_2_local
|
|
```
|
|
|
|
Solid `1:1` edges are fixed relationships; dashed `0..1` edges are conditional (enabled only in matching deployments); red `0..0` edges are turned off in this role. Node markers show the role's deploy modes (💻 host, 🐳 compose, 🐝 swarm); ❌ marks a service that is explicitly turned off, and ⚙️ an Ansible role dependency declared in `meta/main.yml`.
|
|
|
|
## Features
|
|
|
|
- **Automated provisioning:** Configured by Ansible without manual steps.
|
|
|
|
## What this role does
|
|
|
|
- Installs the *cleanback* cleanup tool
|
|
- Runs regular, automated cleanup jobs via systemd
|
|
- Removes failed backups only
|
|
- Preserves the newest backups automatically
|
|
- Designed for non-interactive, production-safe operation
|
|
|
|
## Keeping recent backups safe
|
|
|
|
By default, the role keeps the **last three backup sets** and does not touch them during cleanup runs.
|
|
|
|
This behavior is controlled via:
|
|
|
|
- **CLEANUP_FAILED_BACKUPS_FORCE_KEEP**
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
CLEANUP_FAILED_BACKUPS_FORCE_KEEP: 3
|
|
```
|
|
|
|
This means:
|
|
|
|
- For each `backup-docker-to-local` directory, the newest 3 timestamp subdirectories are skipped
|
|
- Older backup subdirectories are validated and cleaned if they are invalid
|
|
|
|
The value can be adjusted or overridden via inventory, group vars, or host vars if needed.
|
|
|
|
## Failure handling
|
|
|
|
If a backup validation fails due to infrastructure problems (for example timeouts
|
|
or a missing validation tool), the cleanup service exits with a non-zero status.
|
|
This allows systemd OnFailure handlers or monitoring systems to react accordingly.
|
|
|
|
Invalid backups are removed automatically, but infrastructure-related issues
|
|
never trigger automatic deletion.
|
|
|
|
## cleanback tool
|
|
|
|
The cleanup logic itself is provided by the **cleanback** project:
|
|
|
|
[cleanup-failed-backups](https://github.com/kevinveenbirkenbach/cleanup-failed-backups)
|
|
|
|
This role focuses on **safe automation and scheduling**, while the linked project contains the actual cleanup implementation.
|
|
|
|
## Typical use case
|
|
|
|
This role is intended for servers that create regular Docker backups and need a reliable way to:
|
|
|
|
- Keep storage usage under control
|
|
- Automatically remove broken or incomplete backups
|
|
- Ensure recent backups are never touched
|
|
|
|
No manual interaction is required once the role is deployed.
|
|
|
|
## Credits
|
|
|
|
Implemented by **[Kevin Veen-Birkenbach](https://www.veen.world)**.
|
|
Part of the [Infinito.Nexus Project](https://s.infinito.nexus/code) and maintained by [Kevin Veen-Birkenbach](https://www.veen.world).
|
|
Licensed under the [Infinito.Nexus Community License (Non-Commercial)](https://s.infinito.nexus/license).
|