Document Backrest restore and fix the Paths field autocomplete claim

content/en/3.serveex/91.advanced/3.backrest.md

@@ -87,7 +87,7 @@ services:
 
 The `/srv/docker`, `/etc` and `/home` lines above cover what's actually worth an off-site backup on a homelab server, per [folders and partitions](/general/linux/filesystem): `/srv/docker` holds every stack's config and data (databases, uploaded files, Vaultwarden's vault, Pocket ID's users, and so on), `/etc` holds your system configuration (the SSH hardening from the [installation guide](/serveex/core/installation#close-the-door-behind-you), your SWAG `.subdomain.conf` files, systemd units), and `/home` holds your own scripts and notes. All three are mounted read-only, a backup tool has no business writing to what it's backing up.
 
-What's usually **not** worth it: a big media library or a torrent download folder sitting on a separate data disk. It's often huge, replaceable, and rarely worth paying for cloud storage or SSH bandwidth to protect. Mount it too if you disagree, `/media:/userdata/media:ro` for instance, just think about the size first.
+What's usually **not** worth it: a big media library or a torrent download folder sitting on a separate data disk. It's often huge, replaceable, and rarely worth paying for cloud storage or SSH bandwidth to protect.
 
 ::tip{icon=""}
 ✨ __Tip:__ Add the Watchtower label to automate updates
@@ -231,7 +231,7 @@ Back in Backrest, go to **Add Plan**. This form covers what to back up and when,
 
 - **Plan Name**: same rule as the repo name, pick something clear, you can't change it later.
 - **Repository**: the one you just created above.
-- **Paths**: click **Add** to add a row, then type in the container-side path for whatever you mounted above, there's no folder browser, just a plain text field. `/userdata/docker` for your stacks, `/userdata/etc` for your system config, `/userdata/home` for your own files. Click **Add** again for each additional folder, the small `-` button removes a row you don't need.
+- **Paths**: click **Add** to add a row, then type in the container-side path for whatever you mounted above, it's a plain text field, but it autocompletes real paths from the container's filesystem as you type, handy to confirm a mount actually landed where you think. `/userdata/docker` for your stacks, `/userdata/etc` for your system config, `/userdata/home` for your own files. Click **Add** again for each additional folder, the small `-` button removes a row you don't need.
 - **Excludes** and **Excludes (Case Insensitive)**: patterns to skip within those paths, handy for cache folders or anything genuinely disposable that would otherwise bloat every snapshot for no reason.
 - **Schedule Type**: same three choices as the repository's own schedules above, `Disabled`, an `Interval`, or a `Cron Expression`. A nightly cron like `0 3 * * *` (every day at 3 AM) is a reasonable default for a homelab.
 - **Retention Policy**: how many snapshots to keep, and for how long. **By Time Period** lets you say "keep 7 daily, 4 weekly, 6 monthly" independently, which gives you plenty of restore points spread over time without the repository growing forever, since restic deduplicates unchanged data between snapshots anyway. **By Count** instead just keeps the last N snapshots regardless of age. **Latest (Count)** on top of either mode guarantees a minimum number of recent snapshots always survive, whatever the rest of the policy says.
@@ -243,4 +243,11 @@ That retention policy is your real defense against ransomware, by the way: if so
 ✨ __Going further:__ if some of what you're backing up includes a live database, stopping its container for the few seconds a backup takes is safer than backing it up while it's being written to. See **Backrest Docker Stop** for a script that does exactly that, triggered automatically by Backrest itself.
 ::
 
+## Restoring a backup
+A backup you've never tried restoring is a guess, not a plan, so it's worth doing once before you actually need it. Open the plan, click into a snapshot, expand **Snapshot Browser** down to whatever you need, then click the **...** menu next to it and pick **Restore to path**.
+
+Leave the path field empty and Backrest streams it straight to your browser's downloads instead, the simplest option for grabbing a single file. Type a path and Backrest writes the restored data inside the container at that location instead, and it pre-fills a scratch folder like `/userdata-backrest-restore-<snapshot id>`, deliberately not your original mount.
+
+That default isn't an accident: `/srv/docker`, `/etc` and `/home` are mounted `:ro`, so restic can't write back into them, restoring straight into `/userdata/docker` fails with a read-only filesystem error. Restore to that suggested scratch path (or download instead), check what you got, then copy the files into their real place yourself with `sudo cp -a`, from the host, outside of Backrest entirely. It's one extra step, but it also means a restore can never silently clobber live data by accident, exactly the caution you want mid-incident.
+
 And that's it, you now have an actual backup strategy instead of a folder called `backup_final_v2_REAL`.

content/fr/3.serveex/91.advanced/3.backrest.md

@@ -87,7 +87,7 @@ services:
 
 Les lignes `/srv/docker`, `/etc` et `/home` ci-dessus couvrent ce qui vaut réellement la peine d'être sauvegardé hors site sur un serveur homelab, selon [dossiers et partitions](/general/linux/filesystem) : `/srv/docker` contient la config et les données de chaque stack (bases de données, fichiers uploadés, le coffre de Vaultwarden, les utilisateurs de Pocket ID, etc.), `/etc` contient votre configuration système (le durcissement SSH du [guide d'installation](/serveex/core/installation#refermer-la-porte-derrière-vous), vos fichiers `.subdomain.conf` de SWAG, les unités systemd), et `/home` contient vos propres scripts et notes. Les trois sont montées en lecture seule, un outil de sauvegarde n'a aucune raison d'écrire dans ce qu'il sauvegarde.
 
-Ce qui ne vaut généralement **pas** le coup : une grosse bibliothèque média ou un dossier de téléchargement torrent sur un disque de données séparé. C'est souvent énorme, remplaçable, et rarement justifié de payer du stockage cloud ou de la bande passante SSH pour le protéger. Montez-le aussi si vous n'êtes pas d'accord, `/media:/userdata/media:ro` par exemple, réfléchissez juste à la taille avant.
+Ce qui ne vaut généralement **pas** le coup : une grosse bibliothèque média ou un dossier de téléchargement torrent sur un disque de données séparé. C'est souvent énorme, remplaçable, et rarement justifié de payer du stockage cloud ou de la bande passante SSH pour le protéger.
 
 ::tip{icon=""}
 ✨ __Astuce :__ ajoutez le label Watchtower pour automatiser les mises à jour
@@ -231,7 +231,7 @@ Retour dans Backrest, allez dans **Add Plan**. Ce formulaire couvre quoi sauvega
 
 - **Plan Name** : même règle que le nom du dépôt, choisissez quelque chose de clair, impossible à changer ensuite.
 - **Repository** : celui que vous venez de créer plus haut.
-- **Paths** : cliquez sur **Add** pour ajouter une ligne, puis tapez le chemin côté conteneur de ce que vous avez monté plus haut, il n'y a pas d'explorateur de fichiers, juste un champ texte. `/userdata/docker` pour vos stacks, `/userdata/etc` pour votre config système, `/userdata/home` pour vos propres fichiers. Cliquez à nouveau sur **Add** pour chaque dossier supplémentaire, le petit bouton `-` retire une ligne dont vous n'avez plus besoin.
+- **Paths** : cliquez sur **Add** pour ajouter une ligne, puis tapez le chemin côté conteneur de ce que vous avez monté plus haut, c'est un champ texte, mais il autocomplète les vrais chemins du système de fichiers du conteneur au fur et à mesure, pratique pour confirmer qu'un montage a bien atterri là où vous pensez. `/userdata/docker` pour vos stacks, `/userdata/etc` pour votre config système, `/userdata/home` pour vos propres fichiers. Cliquez à nouveau sur **Add** pour chaque dossier supplémentaire, le petit bouton `-` retire une ligne dont vous n'avez plus besoin.
 - **Excludes** et **Excludes (Case Insensitive)** : des motifs à ignorer au sein de ces chemins, pratique pour les dossiers de cache ou tout ce qui est vraiment jetable et qui gonflerait chaque instantané pour rien.
 - **Schedule Type** : les trois mêmes choix que les plannings du dépôt ci-dessus, `Disabled`, un `Interval`, ou une `Cron Expression`. Un cron nocturne du type `0 3 * * *` (tous les jours à 3h du matin) est un défaut raisonnable pour un homelab.
 - **Retention Policy** : combien d'instantanés conserver, et pendant combien de temps. **By Time Period** vous permet de dire "garder 7 quotidiens, 4 hebdomadaires, 6 mensuels" indépendamment, ce qui vous donne largement assez de points de restauration étalés dans le temps sans que le dépôt grossisse indéfiniment, puisque restic déduplique de toute façon les données inchangées entre les instantanés. **By Count** conserve à la place simplement les N derniers instantanés, quel que soit leur âge. **Latest (Count)** en plus de l'un ou l'autre mode garantit qu'un nombre minimum d'instantanés récents survit toujours, quoi que dise le reste de la politique.
@@ -243,4 +243,11 @@ Cette politique de rétention est d'ailleurs votre vraie défense contre les ran
 ✨ __Pour aller plus loin :__ si ce que vous sauvegardez inclut une base de données en cours d'exécution, arrêter son conteneur le temps des quelques secondes que prend la sauvegarde est plus sûr que de la sauvegarder pendant qu'elle écrit. Voir **Backrest Docker Stop** pour un script qui fait exactement ça, déclenché automatiquement par Backrest lui-même.
 ::
 
+## Restaurer une sauvegarde
+Une sauvegarde qu'on n'a jamais essayé de restaurer est un pari, pas un plan, ça vaut le coup de le faire une fois avant d'en avoir vraiment besoin. Ouvrez le plan, cliquez sur un instantané, dépliez **Snapshot Browser** jusqu'à ce dont vous avez besoin, puis cliquez sur le menu **...** à côté et choisissez **Restore to path**.
+
+Laissez le champ de chemin vide et Backrest l'envoie directement vers les téléchargements de votre navigateur, l'option la plus simple pour récupérer un seul fichier. Tapez un chemin et Backrest écrit plutôt les données restaurées dans le conteneur à cet endroit, et il pré-remplit un dossier temporaire du type `/userdata-backrest-restore-<id du snapshot>`, volontairement pas votre montage d'origine.
+
+Ce choix par défaut n'est pas un hasard : `/srv/docker`, `/etc` et `/home` sont montés en `:ro`, donc restic ne peut pas y réécrire, restaurer directement dans `/userdata/docker` échoue avec une erreur de système de fichiers en lecture seule. Restaurez vers ce dossier temporaire suggéré (ou téléchargez à la place), vérifiez ce que vous avez récupéré, puis recopiez les fichiers à leur vraie place vous-même avec `sudo cp -a`, depuis l'hôte, en dehors de Backrest. Une étape de plus, mais ça garantit aussi qu'une restauration ne peut jamais écraser silencieusement des données en cours d'utilisation, exactement la prudence qu'on veut en plein incident.
+
 Et voilà, vous avez maintenant une vraie stratégie de sauvegarde plutôt qu'un dossier appelé `sauvegarde_finale_v2_LAVRAIE`.