---
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.