first version of the knowledge base :)

2026-03-14 11:41:54 +01:00
commit 27965301ad
47 changed files with 4356 additions and 0 deletions
--- a/Guides/self-hosting/backup-strategies.md
+++ b/Guides/self-hosting/backup-strategies.md
@@ -0,0 +1,121 @@
+---
+title: Backup Strategies
+description: Practical backup strategy guidance for self-hosted services, containers, and virtualized homelabs
+tags:
+  - backup
+  - self-hosting
+  - operations
+category: self-hosting
+created: 2026-03-14
+updated: 2026-03-14
+---
+
+# Backup Strategies
+
+## Introduction
+
+Backups protect against deletion, corruption, hardware failure, ransomware, and operational mistakes. In self-hosted environments, a backup strategy should cover both data and the information needed to restore services correctly.
+
+## Purpose
+
+This guide covers:
+
+- What to back up
+- How often to back it up
+- Where to store copies
+- How to validate restore readiness
+
+## Architecture Overview
+
+A good strategy includes:
+
+- Primary data backups
+- Configuration and infrastructure backups
+- Off-site or offline copies
+- Restore testing
+
+The 3-2-1 rule is a strong baseline:
+
+- 3 copies of data
+- 2 different media or storage systems
+- 1 copy off-site
+
+For higher assurance, also consider an immutable or offline copy and zero-error verification.
+
+## Step-by-Step Guide
+
+### 1. Inventory what matters
+
+Back up:
+
+- Databases
+- Application data directories
+- Compose files and infrastructure code
+- DNS, reverse proxy, and secrets configuration
+- Hypervisor or VM backup metadata
+
+### 2. Choose backup tools by workload
+
+- File-level backups: restic, Borg, rsync-based workflows
+- VM backups: hypervisor-integrated backup jobs
+- Database-aware backups: logical dumps or physical backup tools where needed
+
+### 3. Schedule and retain intelligently
+
+Use a retention policy that matches recovery needs. Short retention for frequent snapshots and longer retention for off-site backups is common.
+
+### 4. Test restores
+
+Backups are incomplete until you can restore and start the service successfully.
+
+## Configuration Example
+
+Restic backup example:
+
+```bash
+export RESTIC_REPOSITORY=/backup/restic
+export RESTIC_PASSWORD_FILE=/run/secrets/restic_password
+
+restic backup /srv/app-data /srv/compose
+restic snapshots
+```
+
+Example restore check:
+
+```bash
+restic restore latest --target /tmp/restore-check
+```
+
+## Troubleshooting Tips
+
+### Backups exist but restores are incomplete
+
+- Confirm databases were backed up consistently, not mid-write without support
+- Verify application config and secret material were included
+- Check permissions and ownership in the restored data
+
+### Repository size grows too quickly
+
+- Review retention rules and pruning behavior
+- Exclude caches, transient files, and rebuildable artifacts
+- Split hot data from archival data if retention needs differ
+
+### Backups run but nobody notices failures
+
+- Alert on backup freshness and last successful run
+- Record the restore procedure for each critical service
+- Test restores on a schedule, not only after incidents
+
+## Best Practices
+
+- Back up both data and the configuration needed to use it
+- Keep at least one copy outside the main failure domain
+- Prefer encrypted backup repositories for off-site storage
+- Automate backup jobs and monitor their success
+- Practice restores for your most important services first
+
+## References
+
+- [restic documentation](https://restic.readthedocs.io/en/latest/)
+- [BorgBackup documentation](https://borgbackup.readthedocs.io/en/stable/)
+- [Proxmox VE Backup and Restore](https://pve.proxmox.com/pve-docs/chapter-vzdump.html)