Add BTRFS snapshots guide, TinyAuth/Pocket ID diagrams, and Backrest restore docs #3
@@ -89,6 +89,10 @@ Confirm the timezone guessed from your country.
|
|||||||
|
|
||||||
*Guided, use entire disk* on the system drive, then *All files in one partition*, which gives you one big `/` plus a swap partition. Separate `/home` or `/var` partitions buy you very little here and mostly guarantee that one fills up while the others sit half empty. Pick LVM only if you already know you want snapshots or to grow volumes later. Your data disks are not touched at this stage, you'll mount them afterwards.
|
*Guided, use entire disk* on the system drive, then *All files in one partition*, which gives you one big `/` plus a swap partition. Separate `/home` or `/var` partitions buy you very little here and mostly guarantee that one fills up while the others sit half empty. Pick LVM only if you already know you want snapshots or to grow volumes later. Your data disks are not touched at this stage, you'll mount them afterwards.
|
||||||
|
|
||||||
|
::warning{to="/serveex/advanced/btrfs-snapshots"}
|
||||||
|
__For advanced users:__ this is the moment to decide, not later. 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. Once this step is done and Debian is installed on ext4, switching to Btrfs isn't possible without wiping the disk and starting over. See **BTRFS snapshots** if you want to set it up, it's not a replacement for real backups either, a snapshot lives on the same disk.
|
||||||
|
::
|
||||||
|
|
||||||
Finish with *Finish partitioning and write changes to disk*, then confirm with *Yes*: this is the point of no return for that disk.
|
Finish with *Finish partitioning and write changes to disk*, then confirm with *Yes*: this is the point of no return for that disk.
|
||||||
|
|
||||||
|
|
||||||
@@ -97,10 +101,6 @@ 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.
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: BTRFS Snapshots
|
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.
|
description: Format Debian's root filesystem with BTRFS and use Snapper to instantly roll back a risky update or config change, as a local complement to Backrest's off-site 3-2-1 backups.
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
@@ -50,118 +50,102 @@ Give the partition the rest of the disk (minus a small EFI partition if you're o
|
|||||||
|
|
||||||
Everything else in the [installer](/serveex/core/installation#install-debian) stays the same.
|
Everything else in the [installer](/serveex/core/installation#install-debian) stays the same.
|
||||||
|
|
||||||
## Taking a snapshot
|
## Installing Snapper
|
||||||
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):
|
Rather than juggling raw `btrfs subvolume` commands by hand, [Snapper](https://github.com/openSUSE/snapper) is a small tool that manages the whole snapshot lifecycle: creating them, storing them tidily, pruning old ones, and automatically bracketing every `apt` operation with a snapshot pair.
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo mkdir -p /.snapshots
|
sudo apt install snapper
|
||||||
sudo btrfs subvolume snapshot -r / /.snapshots/$(date +%F_%H-%M-%S)
|
sudo snapper -c root create-config /
|
||||||
```
|
```
|
||||||
|
|
||||||
- `-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.
|
`create-config` registers a config named `root` for the `/` filesystem, and creates a dedicated `.snapshots` subvolume under it to store every snapshot, locked down to root. No `@`/`@home` subvolume split needed, this works fine on the plain single-subvolume layout the manual partitioning above just created.
|
||||||
- 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`.
|
Turn the config on by editing `/etc/default/snapper`:
|
||||||
|
|
||||||
::tip
|
```properties [/etc/default/snapper]
|
||||||
✨ 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.
|
SNAPPER_CONFIGS="root"
|
||||||
::
|
```
|
||||||
|
|
||||||
## Restoring files from a snapshot
|
Then enable the timers that run Snapper's periodic snapshots and cleanup:
|
||||||
A snapshot is just a folder: everything the filesystem looked like at that instant, browsable like any other directory.
|
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
ls /.snapshots/2026-09-09_18-30-00/etc/ssh/
|
sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
|
||||||
```
|
```
|
||||||
|
|
||||||
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
|
::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.
|
Debian's package also ships an APT hook (`/etc/apt/apt.conf.d/80snapper`) that kicks in the moment a config is listed in `SNAPPER_CONFIGS`: from now on, every `apt install`, `apt upgrade` or `apt full-upgrade` automatically gets a snapshot right before and right after it runs, with zero extra effort on your part.
|
||||||
::
|
::
|
||||||
|
|
||||||
## Managing snapshots
|
## Taking a snapshot
|
||||||
|
For anything outside apt, like editing a systemd unit or a Docker Compose file, take one yourself with a description that will actually mean something later:
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo btrfs subvolume list /
|
sudo snapper create --description "before compose change on swag"
|
||||||
```
|
```
|
||||||
|
|
||||||
Lists every subvolume on the filesystem, snapshots included, each with its own ID. Delete one you no longer need with:
|
List every snapshot with:
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo btrfs subvolume delete /.snapshots/2026-09-09_18-30-00
|
sudo snapper list
|
||||||
```
|
```
|
||||||
|
|
||||||
::caution
|
```console [Output]
|
||||||
|
# | Type | Pre # | Date | Description
|
||||||
|
---+--------+-------+--------------------------+---------------------------------
|
||||||
|
0 | single | | | current
|
||||||
|
1 | single | | Tue 09 Sep 2026 18:30:00 | before compose change on swag
|
||||||
|
2 | pre | | Tue 09 Sep 2026 19:00:01 | apt install unattended-upgrades
|
||||||
|
3 | post | 2 | Tue 09 Sep 2026 19:00:14 | apt install unattended-upgrades
|
||||||
|
```
|
||||||
|
|
||||||
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.
|
## Restoring files from a snapshot
|
||||||
|
Snapper keeps the full state of the filesystem at snapshot time under `/.snapshots/<number>/snapshot`, browsable like any other folder:
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
ls /.snapshots/1/snapshot/etc/ssh/
|
||||||
|
```
|
||||||
|
|
||||||
|
To see exactly what changed between a snapshot and the live system (`0` always means "current") before touching anything:
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo snapper status 1..0
|
||||||
|
```
|
||||||
|
|
||||||
|
That prints every file created, modified or deleted since. To undo those changes automatically:
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo snapper undochange 1..0
|
||||||
|
```
|
||||||
|
|
||||||
|
Or restore a single file by hand, which is often the safer, more surgical choice:
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo cp -a /.snapshots/1/snapshot/etc/ssh/sshd_config /etc/ssh/sshd_config
|
||||||
|
```
|
||||||
|
|
||||||
|
::note
|
||||||
|
|
||||||
|
This covers the vast majority of real homelab accidents: a bad config, a deleted file, a package upgrade that broke one thing. Snapper can also `rollback` the entire root filesystem to an earlier snapshot (it creates a new default subvolume and boots into it on the next restart), for a system in a genuinely bad state rather than just missing one file. It's a more delicate, less common operation, worth testing once on a machine you don't mind rebooting before you actually need it for real. And if the disk itself is the problem, that's exactly the scenario your off-site [Backrest](/serveex/advanced/backrest) backup is for anyway.
|
||||||
::
|
::
|
||||||
|
|
||||||
## Automating snapshots
|
## Managing and pruning snapshots
|
||||||
Rather than remembering to run the command by hand, a small script plus a systemd timer takes one automatically and prunes old ones:
|
Snapshots are cheap, not free: the moment the live filesystem diverges from one, the old blocks it still references stick around. Left unchecked, months of snapshots on a server that changes a lot (container images, logs) can quietly eat real disk space.
|
||||||
|
|
||||||
|
The `snapper-cleanup.timer` enabled above already prunes automatically, based on the config at `/etc/snapper/configs/root`:
|
||||||
|
|
||||||
|
| Setting | Default | What it does |
|
||||||
|
|---------|---------|---------------|
|
||||||
|
| `TIMELINE_LIMIT_HOURLY` / `_DAILY` / `_MONTHLY` / `_YEARLY` | `10` | How many timeline snapshots of each granularity to keep |
|
||||||
|
| `TIMELINE_LIMIT_WEEKLY` | `0` | Off by default |
|
||||||
|
| `NUMBER_LIMIT` | `50` | How many manual (`single`) snapshots to keep |
|
||||||
|
|
||||||
|
Adjust these to taste, then delete one immediately by hand if you need the space back right now:
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo nano /usr/local/bin/btrfs-snapshot.sh
|
sudo snapper delete 1
|
||||||
```
|
```
|
||||||
|
|
||||||
```bash [btrfs-snapshot.sh]
|
Check actual disk usage with `df -h /`: the numbers above only cap how many snapshots exist, not the space a very active server can still burn through between cleanups.
|
||||||
#!/bin/bash
|
|
||||||
set -e
|
|
||||||
mkdir -p /.snapshots
|
|
||||||
btrfs subvolume snapshot -r / "/.snapshots/$(date +%F_%H-%M-%S)"
|
|
||||||
|
|
||||||
# Keep only the 7 most recent snapshots
|
That's it: a rolling, automatic undo button for your server, quietly bracketing every update and pruning itself, running alongside the real backups Backrest is already taking off-site.
|
||||||
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.
|
|
||||||
|
|||||||
@@ -89,6 +89,10 @@ Confirmez le fuseau horaire deviné à partir de votre pays.
|
|||||||
|
|
||||||
*Assisté, utiliser un disque entier* sur le disque système, puis *Tout dans une seule partition*, ce qui vous donne un gros `/` plus une partition de swap. Des partitions `/home` ou `/var` séparées n'apportent pas grand-chose ici et garantissent surtout que l'une se remplit pendant que les autres restent à moitié vides. Ne prenez LVM que si vous savez déjà que vous voulez des snapshots ou agrandir des volumes plus tard. Vos disques de données ne sont pas touchés à ce stade, vous les monterez ensuite.
|
*Assisté, utiliser un disque entier* sur le disque système, puis *Tout dans une seule partition*, ce qui vous donne un gros `/` plus une partition de swap. Des partitions `/home` ou `/var` séparées n'apportent pas grand-chose ici et garantissent surtout que l'une se remplit pendant que les autres restent à moitié vides. Ne prenez LVM que si vous savez déjà que vous voulez des snapshots ou agrandir des volumes plus tard. Vos disques de données ne sont pas touchés à ce stade, vous les monterez ensuite.
|
||||||
|
|
||||||
|
::warning{to="/serveex/advanced/btrfs-snapshots"}
|
||||||
|
__Pour les utilisateurs avancés :__ c'est maintenant qu'il faut décider, pas plus tard. 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. Une fois cette étape passée et Debian installé en ext4, passer à Btrfs n'est plus possible sans effacer le disque et tout recommencer. Voir **Snapshots BTRFS** pour la mise en place, ça ne remplace pas non plus de vraies sauvegardes, un snapshot vit sur le même disque.
|
||||||
|
::
|
||||||
|
|
||||||
Terminez avec *Terminer le partitionnement et appliquer les changements*, puis confirmez avec *Oui* : c'est le point de non-retour pour ce disque.
|
Terminez avec *Terminer le partitionnement et appliquer les changements*, puis confirmez avec *Oui* : c'est le point de non-retour pour ce disque.
|
||||||
|
|
||||||
|
|
||||||
@@ -97,10 +101,6 @@ 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.
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: Snapshots BTRFS
|
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.
|
description: Formater la partition racine de Debian en BTRFS et utiliser Snapper 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.
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
@@ -50,118 +50,102 @@ Donnez à la partition le reste du disque (moins une petite partition EFI si vou
|
|||||||
|
|
||||||
Tout le reste de [l'installeur](/serveex/core/installation#installer-debian) reste identique.
|
Tout le reste de [l'installeur](/serveex/core/installation#installer-debian) reste identique.
|
||||||
|
|
||||||
## Prendre un snapshot
|
## Installer Snapper
|
||||||
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) :
|
Plutôt que de jongler à la main avec des commandes `btrfs subvolume` brutes, [Snapper](https://github.com/openSUSE/snapper) est un petit outil qui gère tout le cycle de vie des snapshots : les créer, les ranger proprement, supprimer les anciens, et encadrer automatiquement chaque opération `apt` d'une paire de snapshots.
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo mkdir -p /.snapshots
|
sudo apt install snapper
|
||||||
sudo btrfs subvolume snapshot -r / /.snapshots/$(date +%F_%H-%M-%S)
|
sudo snapper -c root create-config /
|
||||||
```
|
```
|
||||||
|
|
||||||
- `-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.
|
`create-config` enregistre une configuration nommée `root` pour le système de fichiers `/`, et crée un sous-volume `.snapshots` dédié en dessous pour y stocker chaque snapshot, verrouillé pour root uniquement. Pas besoin de découpage `@`/`@home`, ça fonctionne très bien sur le layout à sous-volume unique que le partitionnement manuel vient de créer.
|
||||||
- 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`.
|
Activez la configuration en éditant `/etc/default/snapper` :
|
||||||
|
|
||||||
::tip
|
```properties [/etc/default/snapper]
|
||||||
✨ 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.
|
SNAPPER_CONFIGS="root"
|
||||||
::
|
```
|
||||||
|
|
||||||
## Restaurer des fichiers depuis un snapshot
|
Puis activez les timers qui exécutent les snapshots périodiques et le nettoyage de Snapper :
|
||||||
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]
|
```bash [Terminal]
|
||||||
ls /.snapshots/2026-09-09_18-30-00/etc/ssh/
|
sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
|
||||||
```
|
```
|
||||||
|
|
||||||
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
|
::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.
|
Le paquet Debian embarque aussi un hook APT (`/etc/apt/apt.conf.d/80snapper`) qui s'active dès qu'une configuration figure dans `SNAPPER_CONFIGS` : à partir de maintenant, chaque `apt install`, `apt upgrade` ou `apt full-upgrade` obtient automatiquement un snapshot juste avant et juste après son exécution, sans aucun effort de votre part.
|
||||||
::
|
::
|
||||||
|
|
||||||
## Gérer les snapshots
|
## Prendre un snapshot
|
||||||
|
Pour tout ce qui sort du cadre d'apt, comme modifier une unité systemd ou un fichier Docker Compose, prenez-en un vous-même avec une description qui voudra vraiment dire quelque chose plus tard :
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo btrfs subvolume list /
|
sudo snapper create --description "avant changement compose sur swag"
|
||||||
```
|
```
|
||||||
|
|
||||||
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 :
|
Listez-les tous avec :
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo btrfs subvolume delete /.snapshots/2026-09-09_18-30-00
|
sudo snapper list
|
||||||
```
|
```
|
||||||
|
|
||||||
::caution
|
```console [Output]
|
||||||
|
# | Type | Pre # | Date | Description
|
||||||
|
---+--------+-------+--------------------------+---------------------------------
|
||||||
|
0 | single | | | current
|
||||||
|
1 | single | | Tue 09 Sep 2026 18:30:00 | avant changement compose sur swag
|
||||||
|
2 | pre | | Tue 09 Sep 2026 19:00:01 | apt install unattended-upgrades
|
||||||
|
3 | post | 2 | Tue 09 Sep 2026 19:00:14 | apt install unattended-upgrades
|
||||||
|
```
|
||||||
|
|
||||||
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.
|
## Restaurer des fichiers depuis un snapshot
|
||||||
|
Snapper conserve l'état complet du système de fichiers au moment du snapshot sous `/.snapshots/<numéro>/snapshot`, consultable comme n'importe quel autre dossier :
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
ls /.snapshots/1/snapshot/etc/ssh/
|
||||||
|
```
|
||||||
|
|
||||||
|
Pour voir exactement ce qui a changé entre un snapshot et le système actuel (`0` désigne toujours "l'état actuel") avant de toucher à quoi que ce soit :
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo snapper status 1..0
|
||||||
|
```
|
||||||
|
|
||||||
|
Ça affiche chaque fichier créé, modifié ou supprimé depuis. Pour annuler ces changements automatiquement :
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo snapper undochange 1..0
|
||||||
|
```
|
||||||
|
|
||||||
|
Ou restaurez un seul fichier à la main, souvent le choix le plus sûr et le plus chirurgical :
|
||||||
|
|
||||||
|
```bash [Terminal]
|
||||||
|
sudo cp -a /.snapshots/1/snapshot/etc/ssh/sshd_config /etc/ssh/sshd_config
|
||||||
|
```
|
||||||
|
|
||||||
|
::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. Snapper peut aussi faire un `rollback` de toute la partition racine vers un snapshot antérieur (il crée un nouveau sous-volume par défaut et démarre dessus au prochain redémarrage), pour un système dans un état vraiment cassé plutôt qu'un simple fichier manquant. C'est une opération plus délicate et bien plus rare, à tester une fois sur une machine où redémarrer ne vous dérange pas, avant d'en avoir vraiment besoin. Et si le disque lui-même est le problème, c'est exactement le scénario pour lequel votre sauvegarde [Backrest](/serveex/advanced/backrest) hors site existe.
|
||||||
::
|
::
|
||||||
|
|
||||||
## Automatiser les snapshots
|
## Gérer et nettoyer 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 :
|
Les snapshots sont bon marché, pas gratuits : dès que le système de fichiers actif diverge d'un snapshot, les anciens blocs qu'il référence toujours restent occupés. Sans surveillance, des mois de snapshots sur un serveur qui change beaucoup (images de conteneurs, logs) peuvent discrètement grignoter de l'espace disque réel.
|
||||||
|
|
||||||
|
Le `snapper-cleanup.timer` activé plus haut nettoie déjà automatiquement, selon la configuration de `/etc/snapper/configs/root` :
|
||||||
|
|
||||||
|
| Réglage | Défaut | Ce que ça fait |
|
||||||
|
|---------|---------|---------------|
|
||||||
|
| `TIMELINE_LIMIT_HOURLY` / `_DAILY` / `_MONTHLY` / `_YEARLY` | `10` | Combien de snapshots de chronologie garder pour chaque granularité |
|
||||||
|
| `TIMELINE_LIMIT_WEEKLY` | `0` | Désactivé par défaut |
|
||||||
|
| `NUMBER_LIMIT` | `50` | Combien de snapshots manuels (`single`) garder |
|
||||||
|
|
||||||
|
Ajustez ça à votre goût, puis supprimez-en un immédiatement à la main si vous avez besoin de la place tout de suite :
|
||||||
|
|
||||||
```bash [Terminal]
|
```bash [Terminal]
|
||||||
sudo nano /usr/local/bin/btrfs-snapshot.sh
|
sudo snapper delete 1
|
||||||
```
|
```
|
||||||
|
|
||||||
```bash [btrfs-snapshot.sh]
|
Vérifiez l'usage disque réel avec `df -h /` : les chiffres ci-dessus ne plafonnent que le nombre de snapshots, pas l'espace qu'un serveur très actif peut encore consommer entre deux nettoyages.
|
||||||
#!/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
|
Et voilà : un bouton annuler automatique et permanent pour votre serveur, qui encadre discrètement chaque mise à jour et se nettoie tout seul, en tournant à côté des vraies sauvegardes que Backrest prend déjà hors site.
|
||||||
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.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user