Add BTRFS snapshots guide, TinyAuth/Pocket ID diagrams, and Backrest restore docs #3

Merged
Djeex merged 9 commits from wip into main 2026-09-09 14:26:09 +02:00
6 changed files with 350 additions and 0 deletions
Showing only changes of commit a59966006b - Show all commits
+4
View File
@@ -319,6 +319,10 @@ Install and deploy Arcane
::card{icon="i-lucide-database-backup" title="3-2-1 Backups" to="/serveex/advanced/backrest"} ::card{icon="i-lucide-database-backup" title="3-2-1 Backups" to="/serveex/advanced/backrest"}
Install and deploy Backrest Install and deploy Backrest
:: ::
::card{icon="i-lucide-rotate-ccw" title="Instant Rollback" to="/serveex/advanced/btrfs-snapshots"}
Set up BTRFS snapshots
::
:: ::
## Coming Soon ## Coming Soon
@@ -97,6 +97,10 @@ Finish with *Finish partitioning and write changes to disk*, then confirm with *
__Tip:__ what actually lives on that one partition, and why `/srv/docker` is where this guide puts every stack, is covered in **folders and partitions**. __Tip:__ what actually lives on that one partition, and why `/srv/docker` is where this guide puts every stack, is covered in **folders and partitions**.
:: ::
::tip{icon="" to="/serveex/advanced/btrfs-snapshots"}
__For advanced users:__ picking *Manual* here instead of *Guided* lets you format the root partition as Btrfs instead of ext4, unlocking instant, near-free snapshots you can roll back to before a risky update or config change. It's not a replacement for real backups, a snapshot lives on the same disk, see **BTRFS snapshots** if you want to set it up.
::
#### Mirror and surveys #### Mirror and surveys
Answer *No* to *Scan another installation medium?*, everything else comes from the network. For the mirror, pick any one in your country, or `deb.debian.org` which routes to a nearby one automatically, and leave the HTTP proxy field empty unless you actually have one. The popularity contest (anonymous package statistics) is yes or no, no consequence either way. Answer *No* to *Scan another installation medium?*, everything else comes from the network. For the mirror, pick any one in your country, or `deb.debian.org` which routes to a nearby one automatically, and leave the HTTP proxy field empty unless you actually have one. The popularity contest (anonymous package statistics) is yes or no, no consequence either way.
@@ -0,0 +1,167 @@
---
title: BTRFS Snapshots
description: Format Debian's root filesystem with BTRFS and use snapshots to instantly roll back a risky update or config change, as a local complement to Backrest's off-site 3-2-1 backups.
---
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
[BTRFS](https://btrfs.readthedocs.io/) is a Linux filesystem with one killer feature for a homelab: **snapshots**. A snapshot freezes the exact state of a filesystem in an instant, at essentially zero cost, without copying a single byte of data upfront. Break something ten minutes after an `apt full-upgrade`, or overwrite the wrong `.env` file, and you can go back to exactly how things were before, without touching a backup at all.
This is not what [Backrest and the 3-2-1 rule](/serveex/advanced/backrest) are for, so it's worth being precise about the difference before setting anything up.
## Snapshots are not backups
A snapshot lives on the exact same disk as the data it protects. It's instant, needs no network, and it's perfect for undoing a mistake you just made, but it does nothing at all the day that disk itself dies, gets stolen, or your server burns down. That's what a real [3-2-1 backup](/serveex/advanced/backrest) is for: a copy on different media, ideally off-site.
Think of it this way:
- **Snapshot** = an undo button. Instant, local, cheap, only useful while the disk is alive.
- **Backup** = insurance. Slower, off-site, the only thing that survives the disk itself failing.
Keep both. Snapshots make you fearless about updates and experiments, backups make sure a dead drive stays an inconvenience instead of a catastrophe.
::note{to="/serveex/core/installation#partitioning"}
This guide assumes the root partition was formatted with Btrfs during [Debian's installation](/serveex/core/installation#partitioning). Btrfs can't be safely bolted onto an existing ext4 root after the fact, so this is a choice you make once, at install time.
::
## Formatting the root partition with BTRFS
Debian's *Guided* partitioning only ever offers ext4. To get Btrfs, pick *Manual* partitioning instead, at the same step [the main install guide](/serveex/core/installation#partitioning) describes:
::steps{level="3"}
### Select Manual partitioning
At the partitioning method screen, choose *Manual* instead of *Guided - use entire disk*.
### Create a partition table
Select the disk, confirm creating a new empty partition table, then select the resulting *FREE SPACE* and choose *Create a new partition*.
### Set the partition size and type
Give the partition the rest of the disk (minus a small EFI partition if you're on UEFI, handled the same way as a Guided install), and set *Use as* to __Btrfs journaling file system__, with the mount point `/`.
### Finish partitioning
*Finish partitioning and write changes to disk*, then confirm with *Yes*.
### Done!
::
Everything else in the [installer](/serveex/core/installation#install-debian) stays the same.
## Taking a snapshot
A snapshot is created with a single command, and completes instantly no matter how much data is on the disk, since Btrfs only starts copying blocks the moment something actually changes (copy-on-write):
```bash [Terminal]
sudo mkdir -p /.snapshots
sudo btrfs subvolume snapshot -r / /.snapshots/$(date +%F_%H-%M-%S)
```
- `-r` makes it **read-only**, which is what you want for a safety net: nothing, including you by accident, can modify a snapshot after the fact.
- Storing snapshots under `/.snapshots` keeps them out of the way, and Btrfs is smart enough not to recurse into a subvolume the next time you snapshot `/` itself, so snapshots never end up containing older snapshots.
Take the habit of running this before anything that could go wrong: `sudo apt full-upgrade`, editing a systemd unit, or a Docker Compose change that touches something outside `/srv/docker`.
::tip
✨ Give the snapshot a name that means something instead of just a timestamp, for example `/.snapshots/before-upgrade-2026-09-09`, so you know why it's there when you find it three weeks later.
::
## Restoring files from a snapshot
A snapshot is just a folder: everything the filesystem looked like at that instant, browsable like any other directory.
```bash [Terminal]
ls /.snapshots/2026-09-09_18-30-00/etc/ssh/
```
To undo a mistake, copy the file (or folder) back from the snapshot over the current one:
```bash [Terminal]
sudo cp -a /.snapshots/2026-09-09_18-30-00/etc/ssh/sshd_config /etc/ssh/sshd_config
```
`-a` preserves permissions and ownership, which matters for anything under `/etc`.
::note
This covers the vast majority of real homelab accidents: a bad config, a deleted file, a package upgrade that broke one thing. Rolling back the __entire__ root filesystem (for a system that no longer boots at all) is also possible, by renaming subvolumes from a live USB, but it's a more delicate, less common operation. The [Btrfs documentation](https://btrfs.readthedocs.io/en/latest/Subvolumes.html) covers it if you ever need it, and honestly, if it comes to that, this is exactly the scenario your off-site [Backrest](/serveex/advanced/backrest) backup is for anyway.
::
## Managing snapshots
```bash [Terminal]
sudo btrfs subvolume list /
```
Lists every subvolume on the filesystem, snapshots included, each with its own ID. Delete one you no longer need with:
```bash [Terminal]
sudo btrfs subvolume delete /.snapshots/2026-09-09_18-30-00
```
::caution
Snapshots are cheap, not free: the moment the live filesystem diverges from a snapshot, the old blocks stick around for as long as the snapshot references them. A pile of old snapshots on a server that changes a lot (container images, logs) can quietly eat real disk space. Check with `df -h /` and prune what you don't need anymore.
::
## Automating snapshots
Rather than remembering to run the command by hand, a small script plus a systemd timer takes one automatically and prunes old ones:
```bash [Terminal]
sudo nano /usr/local/bin/btrfs-snapshot.sh
```
```bash [btrfs-snapshot.sh]
#!/bin/bash
set -e
mkdir -p /.snapshots
btrfs subvolume snapshot -r / "/.snapshots/$(date +%F_%H-%M-%S)"
# Keep only the 7 most recent snapshots
cd /.snapshots
ls -1 | sort | head -n -7 | while read -r old; do
btrfs subvolume delete "$old"
done
```
```bash [Terminal]
sudo chmod +x /usr/local/bin/btrfs-snapshot.sh
```
```bash [Terminal]
sudo nano /etc/systemd/system/btrfs-snapshot.service
```
```ini [btrfs-snapshot.service]
[Unit]
Description=Take a Btrfs root snapshot
[Service]
Type=oneshot
ExecStart=/usr/local/bin/btrfs-snapshot.sh
```
```bash [Terminal]
sudo nano /etc/systemd/system/btrfs-snapshot.timer
```
```ini [btrfs-snapshot.timer]
[Unit]
Description=Daily Btrfs root snapshot
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
```
```bash [Terminal]
sudo systemctl daemon-reload
sudo systemctl enable --now btrfs-snapshot.timer
```
Check it's scheduled with `systemctl list-timers`, and trigger one right away to test it with `sudo systemctl start btrfs-snapshot.service`.
That's it: a rolling, automatic undo button for your server, running quietly alongside the real backups Backrest is already taking off-site.
+4
View File
@@ -319,6 +319,10 @@ Installer et déployer Arcane
::card{icon="i-lucide-database-backup" title="Sauvegardes en 3-2-1" to="/serveex/advanced/backrest"} ::card{icon="i-lucide-database-backup" title="Sauvegardes en 3-2-1" to="/serveex/advanced/backrest"}
Installer et déployer Backrest Installer et déployer Backrest
:: ::
::card{icon="i-lucide-rotate-ccw" title="Retour en arrière instantané" to="/serveex/advanced/btrfs-snapshots"}
Mettre en place les snapshots BTRFS
::
:: ::
## Bientôt ## Bientôt
@@ -97,6 +97,10 @@ Terminez avec *Terminer le partitionnement et appliquer les changements*, puis c
__Astuce :__ ce qui vit réellement sur cette unique partition, et pourquoi `/srv/docker` est l'endroit où ce guide place chaque stack, est traité dans **dossiers et partitions**. __Astuce :__ ce qui vit réellement sur cette unique partition, et pourquoi `/srv/docker` est l'endroit où ce guide place chaque stack, est traité dans **dossiers et partitions**.
:: ::
::tip{icon="" to="/serveex/advanced/btrfs-snapshots"}
__Pour les utilisateurs avancés :__ choisir *Manuel* ici plutôt qu'*Assisté* permet de formater la partition racine en Btrfs plutôt qu'en ext4, ce qui débloque des snapshots instantanés et quasi gratuits vers lesquels revenir avant une mise à jour risquée ou un changement de config. Ça ne remplace pas de vraies sauvegardes, un snapshot vit sur le même disque, voir **Snapshots BTRFS** pour la mise en place.
::
#### Miroir et sondages #### Miroir et sondages
Répondez *Non* à *Faut-il analyser un autre média d'installation ?*, tout le reste vient du réseau. Pour le miroir, prenez-en un dans votre pays, ou `deb.debian.org` qui route automatiquement vers un miroir proche, et laissez le champ du proxy HTTP vide sauf si vous en avez réellement un. Le concours de popularité (statistiques anonymes sur les paquets) est oui ou non, sans conséquence. Répondez *Non* à *Faut-il analyser un autre média d'installation ?*, tout le reste vient du réseau. Pour le miroir, prenez-en un dans votre pays, ou `deb.debian.org` qui route automatiquement vers un miroir proche, et laissez le champ du proxy HTTP vide sauf si vous en avez réellement un. Le concours de popularité (statistiques anonymes sur les paquets) est oui ou non, sans conséquence.
@@ -0,0 +1,167 @@
---
title: Snapshots BTRFS
description: Formater la partition racine de Debian en BTRFS et utiliser les snapshots pour annuler instantanément une mise à jour ratée ou un mauvais changement de config, en complément local des sauvegardes 3-2-1 hors site de Backrest.
---
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
[BTRFS](https://btrfs.readthedocs.io/) est un système de fichiers Linux avec une fonctionnalité redoutable pour un homelab : les **snapshots**. Un snapshot fige l'état exact d'un système de fichiers en un instant, à coût quasi nul, sans copier le moindre octet de données au départ. Cassez quelque chose dix minutes après un `apt full-upgrade`, ou écrasez le mauvais fichier `.env`, et vous pouvez revenir exactement à l'état d'avant, sans toucher à une sauvegarde.
Ce n'est pas le rôle de [Backrest et de la règle 3-2-1](/serveex/advanced/backrest), donc autant être précis sur la différence avant de mettre quoi que ce soit en place.
## Un snapshot n'est pas une sauvegarde
Un snapshot vit sur le même disque que les données qu'il protège. Il est instantané, ne demande aucun réseau, et il est parfait pour annuler une bêtise que vous venez de faire, mais il ne sert strictement à rien le jour où ce disque lâche, se fait voler, ou où votre serveur part en fumée. C'est le rôle d'une vraie [sauvegarde 3-2-1](/serveex/advanced/backrest) : une copie sur un support différent, idéalement hors site.
Voyez ça comme ça :
- **Snapshot** = un bouton annuler. Instantané, local, gratuit, utile seulement tant que le disque est vivant.
- **Sauvegarde** = une assurance. Plus lente, hors site, la seule chose qui survit à la mort du disque lui-même.
Gardez les deux. Les snapshots vous rendent serein face aux mises à jour et aux expérimentations, les sauvegardes garantissent qu'un disque mort reste un désagrément plutôt qu'une catastrophe.
::note{to="/serveex/core/installation#partitionnement"}
Ce guide suppose que la partition racine a été formatée en Btrfs pendant [l'installation de Debian](/serveex/core/installation#partitionnement). Btrfs ne peut pas être ajouté proprement à un `/` déjà en ext4 après coup, c'est donc un choix à faire une seule fois, à l'installation.
::
## Formater la partition racine en BTRFS
Le partitionnement *Assisté* de Debian ne propose que de l'ext4. Pour obtenir du Btrfs, choisissez plutôt le partitionnement *Manuel*, à la même étape que décrit [le guide d'installation principal](/serveex/core/installation#partitionnement) :
::steps{level="3"}
### Sélectionner le partitionnement manuel
Sur l'écran de méthode de partitionnement, choisissez *Manuel* plutôt que *Assisté, utiliser un disque entier*.
### Créer une table de partitions
Sélectionnez le disque, confirmez la création d'une nouvelle table de partitions vide, puis sélectionnez l'*ESPACE LIBRE* obtenu et choisissez *Créer une nouvelle partition*.
### Définir la taille et le type de la partition
Donnez à la partition le reste du disque (moins une petite partition EFI si vous êtes en UEFI, gérée comme dans une installation Assistée), et réglez *Utiliser comme* sur __Système de fichiers journalisé Btrfs__, avec comme point de montage `/`.
### Terminer le partitionnement
*Terminer le partitionnement et appliquer les changements*, puis confirmez avec *Oui*.
### Terminé !
::
Tout le reste de [l'installeur](/serveex/core/installation#installer-debian) reste identique.
## Prendre un snapshot
Un snapshot se crée avec une seule commande, et se termine instantanément quelle que soit la quantité de données sur le disque, puisque Btrfs ne commence à copier des blocs qu'au moment où quelque chose change réellement (copy-on-write) :
```bash [Terminal]
sudo mkdir -p /.snapshots
sudo btrfs subvolume snapshot -r / /.snapshots/$(date +%F_%H-%M-%S)
```
- `-r` le rend **en lecture seule**, ce qui est ce qu'on veut pour un filet de sécurité : rien, pas même vous par erreur, ne peut modifier un snapshot après coup.
- Stocker les snapshots sous `/.snapshots` les garde hors du chemin, et Btrfs est assez malin pour ne pas descendre dans un sous-volume la prochaine fois que vous snapshotez `/` lui-même, donc les snapshots ne finissent jamais par contenir d'anciens snapshots.
Prenez l'habitude de lancer ça avant tout ce qui pourrait mal tourner : un `sudo apt full-upgrade`, la modification d'une unité systemd, ou un changement Docker Compose qui touche à autre chose que `/srv/docker`.
::tip
✨ Donnez au snapshot un nom qui veut dire quelque chose plutôt qu'un simple horodatage, par exemple `/.snapshots/avant-upgrade-2026-09-09`, pour savoir pourquoi il est là quand vous le retrouverez trois semaines plus tard.
::
## Restaurer des fichiers depuis un snapshot
Un snapshot n'est qu'un dossier : tout ce à quoi ressemblait le système de fichiers à cet instant, consultable comme n'importe quel autre répertoire.
```bash [Terminal]
ls /.snapshots/2026-09-09_18-30-00/etc/ssh/
```
Pour annuler une bêtise, recopiez le fichier (ou le dossier) depuis le snapshot par-dessus le fichier actuel :
```bash [Terminal]
sudo cp -a /.snapshots/2026-09-09_18-30-00/etc/ssh/sshd_config /etc/ssh/sshd_config
```
`-a` préserve les permissions et le propriétaire, ce qui compte pour tout ce qui se trouve sous `/etc`.
::note
Ça couvre l'immense majorité des vrais accidents de homelab : une mauvaise config, un fichier supprimé, une mise à jour de paquet qui a cassé un truc. Revenir en arrière sur __l'intégralité__ de la partition racine (pour un système qui ne démarre plus du tout) est aussi possible, en renommant des sous-volumes depuis une clé USB live, mais c'est une opération plus délicate et bien plus rare. La [documentation Btrfs](https://btrfs.readthedocs.io/en/latest/Subvolumes.html) couvre ce cas si vous en avez un jour besoin, et honnêtement, si on en arrive là, c'est exactement le scénario pour lequel votre sauvegarde [Backrest](/serveex/advanced/backrest) hors site existe.
::
## Gérer les snapshots
```bash [Terminal]
sudo btrfs subvolume list /
```
Liste tous les sous-volumes du système de fichiers, snapshots compris, chacun avec son propre ID. Supprimez-en un dont vous n'avez plus besoin avec :
```bash [Terminal]
sudo btrfs subvolume delete /.snapshots/2026-09-09_18-30-00
```
::caution
Les snapshots sont bon marché, pas gratuits : dès que le système de fichiers actif diverge d'un snapshot, les anciens blocs restent occupés tant que le snapshot les référence. Un tas de vieux snapshots sur un serveur qui change beaucoup (images de conteneurs, logs) peut discrètement grignoter de l'espace disque réel. Vérifiez avec `df -h /` et supprimez ce dont vous n'avez plus besoin.
::
## Automatiser les snapshots
Plutôt que de penser à lancer la commande à la main, un petit script associé à un timer systemd en prend un automatiquement et supprime les anciens :
```bash [Terminal]
sudo nano /usr/local/bin/btrfs-snapshot.sh
```
```bash [btrfs-snapshot.sh]
#!/bin/bash
set -e
mkdir -p /.snapshots
btrfs subvolume snapshot -r / "/.snapshots/$(date +%F_%H-%M-%S)"
# Ne garde que les 7 snapshots les plus récents
cd /.snapshots
ls -1 | sort | head -n -7 | while read -r old; do
btrfs subvolume delete "$old"
done
```
```bash [Terminal]
sudo chmod +x /usr/local/bin/btrfs-snapshot.sh
```
```bash [Terminal]
sudo nano /etc/systemd/system/btrfs-snapshot.service
```
```ini [btrfs-snapshot.service]
[Unit]
Description=Take a Btrfs root snapshot
[Service]
Type=oneshot
ExecStart=/usr/local/bin/btrfs-snapshot.sh
```
```bash [Terminal]
sudo nano /etc/systemd/system/btrfs-snapshot.timer
```
```ini [btrfs-snapshot.timer]
[Unit]
Description=Daily Btrfs root snapshot
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
```
```bash [Terminal]
sudo systemctl daemon-reload
sudo systemctl enable --now btrfs-snapshot.timer
```
Vérifiez qu'il est bien planifié avec `systemctl list-timers`, et déclenchez-en un tout de suite pour tester avec `sudo systemctl start btrfs-snapshot.service`.
Et voilà : un bouton annuler automatique et permanent pour votre serveur, qui tourne tranquillement à côté des vraies sauvegardes que Backrest prend déjà hors site.