Sauvegarder Vaultwarden avec restic : chiffré, automatique et testé

Par Michel Vigoureux · Le Coq Numérique · Mis à jour en octobre 2026 · Commandes testées sur Debian 13

Pour sauvegarder Vaultwarden correctement, il faut trois choses : une copie propre de la base SQLite (avec la commande .backup, jamais un simple cp à chaud), un envoi chiffré hors du serveur, et une restauration réellement testée. Ce guide met tout cela en place avec restic et une Storage Box Hetzner en Europe, automatise la sauvegarde chaque nuit avec un timer systemd, et vous prévient sur Telegram si elle échoue.

Il fait suite au guide Installer Vaultwarden sur un VPS européen : on repart exactement du serveur installé dans cet article.

La vidéo

La vidéo est hébergée par YouTube : cliquer charge le lecteur YouTube. Voir la vidéo sur YouTube

La vidéo montre la mise en place et une restauration en direct. Cet article reprend toutes les commandes, les explique, et ajoute ce que la vidéo ne fait pas : la restauration complète sur un serveur neuf, si le vôtre a totalement disparu.

Sommaire

1. Pourquoi sauvegarder (et pourquoi pas sur le même serveur)
2. Ce qu'il faut sauvegarder
3. Le piège de la base SQLite à chaud
4. Pourquoi restic, et pourquoi une Storage Box
5. Étape 1 — Installer les outils
6. Étape 2 — Brancher la Storage Box
7. Étape 3 — Créer le dépôt chiffré et la fiche de survie
8. Étape 4 — Le script de sauvegarde
9. Étape 5 — Automatiser avec un timer systemd
10. Étape 6 — L'alerte Telegram en cas d'échec
11. Étape 7 — Tester la restauration
12. Restaurer sur un serveur neuf
13. Variante : un stockage S3 auto-hébergé (Garage)
14. Dépannage
15. FAQ

Pourquoi sauvegarder (et pourquoi pas sur le même serveur)

Votre coffre Vaultwarden contient tout : mots de passe, codes de double authentification, clés SSH, notes sensibles. S'il tourne sur un serveur que vous administrez, personne d'autre que vous ne le sauvegarde. Un disque qui lâche, une mauvaise commande, un compte d'hébergeur suspendu, et tout disparaît.

La règle de base de toute sauvegarde : une copie rangée sur la même machine que l'original n'est pas une sauvegarde. Si le disque meurt, les deux disparaissent ensemble. Les snapshots de votre hébergeur aident, mais ils restent chez le même fournisseur, dans le même compte.

Ce qu'il faut sauvegarder

D'après le wiki officiel de Vaultwarden, tout l'état du serveur se trouve dans le dossier vw-data. On y ajoute les trois fichiers de configuration créés lors de l'installation.

Plutôt que de lister ces éléments un par un, le script de ce guide sauvegarde tout le dossier vaultwarden, en excluant seulement la base brute et le cache d'icônes. Avantage : si une future version de Vaultwarden ajoute un fichier, il est sauvegardé sans que vous ayez à y penser.

Le piège de la base SQLite à chaud

Vaultwarden écrit dans sa base en permanence, et SQLite garde une partie des écritures récentes dans un fichier à part, db.sqlite3-wal. Si vous copiez db.sqlite3 avec un simple cp pendant que Vaultwarden tourne, vous pouvez obtenir une copie incohérente, voire corrompue, sans aucun message d'erreur. Vous ne le découvrez que le jour de la restauration.

La solution, recommandée par le wiki Vaultwarden : la commande .backup de SQLite. Elle utilise l'API de sauvegarde en ligne de SQLite, qui produit une copie cohérente même pendant que la base est utilisée. On vérifie ensuite l'intégrité de la copie avant de l'envoyer.

Pourquoi restic, et pourquoi une Storage Box

restic

restic est un outil de sauvegarde open source, en un seul programme. Trois propriétés le rendent idéal ici :

• Il chiffre tout sur votre serveur, avant l'envoi. Le stockage ne reçoit que des données illisibles. L'hébergeur de la sauvegarde ne peut rien lire.
• Il déduplique. Il découpe les fichiers en morceaux et n'envoie que les morceaux nouveaux. La sauvegarde de chaque nuit est minuscule, même avec des mois d'historique.
• Il gère des instantanés. Chaque sauvegarde est un « snapshot » daté, restaurable individuellement.

Il sait écrire sur un serveur SFTP, sur du stockage S3 et sur bien d'autres destinations. Il est aussi plus simple à prendre en main que borg, son principal concurrent.

La Storage Box Hetzner

Une Storage Box est un espace de stockage en ligne vendu par Hetzner, dans ses centres de données en Allemagne et en Finlande. Elle est séparée de votre serveur : si le serveur disparaît, la Storage Box reste. Elle accepte les connexions SFTP, que restic prend en charge nativement (documentation Hetzner).

La plus petite offre suffit largement pour un coffre de mots de passe ; consultez le prix du jour sur la page Storage Box de Hetzner.

Étape 1 — Installer les outils

sudo -i
apt install -y restic sqlite3
restic version

• restic : l'outil de sauvegarde, depuis les dépôts Debian.
• sqlite3 : le client SQLite, pour la copie propre de la base. L'image Docker de Vaultwarden ne le contient pas, c'est pourquoi on l'installe sur le serveur.
• restic version doit afficher un numéro de version : l'outil est prêt.

Étape 2 — Brancher la Storage Box

Activer l'accès SSH dans la console Hetzner

Après avoir commandé votre Storage Box, ouvrez ses réglages dans la console Hetzner et activez :

• SSH support ;
• External Reachability, indispensable si votre serveur n'est pas dans le réseau interne de Hetzner.

Notez son identifiant (uXXXXX) et son adresse (uXXXXX.your-storagebox.de), ainsi que le mot de passe défini dans la console : il ne servira qu'une fois.

Créer une clé SSH dédiée

La sauvegarde tourne seule la nuit : personne n'est là pour taper une phrase de passe. On crée donc une clé dédiée et sans phrase de passe. C'est acceptable ici parce que cette clé ne donne accès qu'à la Storage Box, et que les données y sont déjà chiffrées par restic. Pour comprendre le principe des clés ED25519, voir notre guide Créer une clé SSH ED25519.

Pour éviter de retaper l'identifiant partout, chargez-le dans deux variables (remplacez uXXXXX par le vôtre) :

cat > /root/tournage.env <<'EOF'
BOX_USER=uXXXXX
BOX_HOST=uXXXXX.your-storagebox.de
EOF
chmod 600 /root/tournage.env
source /root/tournage.env

Puis générez la clé :

ssh-keygen -t ed25519 -f /root/.ssh/storagebox -N "" -C "restic@coffre"

• -f /root/.ssh/storagebox : un fichier à part, pour ne pas mélanger cette clé avec vos autres clés.
• -N "" : pas de phrase de passe.
• -C "restic@coffre" : un commentaire, pour la reconnaître plus tard.

Créer un alias SSH, puis déposer la clé

Un alias regroupe tous les réglages de connexion sous un nom court, storagebox. restic et sftp l'utiliseront ensuite automatiquement.

cat >> /root/.ssh/config <<EOF
Host storagebox
  Hostname $BOX_HOST
  Port 23
  User $BOX_USER
  IdentityFile /root/.ssh/storagebox
  IdentitiesOnly yes
EOF
chmod 600 /root/.ssh/config

Attention au port 23 : c'est le port SSH/SFTP des Storage Box, pas le 22. IdentitiesOnly yes force l'utilisation de cette clé, et d'elle seule.

Déposez ensuite la clé publique sur la Storage Box. La commande demande une seule fois le mot de passe de la Storage Box :

ssh-copy-id -i /root/.ssh/storagebox.pub -s storagebox

L'option -s passe par SFTP, le seul mode que la Storage Box accepte pour cette opération. Si la commande coince, Hetzner propose une alternative :

cat /root/.ssh/storagebox.pub | ssh -p 23 storagebox install-ssh-key

Tester la connexion sans mot de passe

echo ls | sftp -b - storagebox

La commande doit lister le contenu de la Storage Box sans aucune question : ni mot de passe, ni confirmation d'empreinte. C'est exactement ce que fera la sauvegarde de nuit, sans personne pour répondre.

En mode -b, sftp ne pose pas la question de l'empreinte du serveur : il échoue avec Host key verification failed. Dans ce cas, enregistrez l'empreinte une fois pour toutes :

ssh-keyscan -p 23 "$BOX_HOST" >> /root/.ssh/known_hosts

Puis relancez le test.

Étape 3 — Créer le dépôt chiffré et la fiche de survie

Créer le dépôt

Un « dépôt » restic est l'endroit où sont rangées vos sauvegardes, chiffrées. On commence par générer une phrase de passe longue et aléatoire, puis on crée un petit fichier de réglages que le script chargera.

openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-pass

cat > /root/restic.env <<'EOF'
export RESTIC_REPOSITORY=sftp:storagebox:./vaultwarden
export RESTIC_PASSWORD_FILE=/root/.restic-pass
EOF
chmod 600 /root/restic.env

source /root/restic.env
restic init

• openssl rand -base64 32 : 32 octets aléatoires, bien plus solides qu'une phrase inventée.
• RESTIC_REPOSITORY=sftp:storagebox:./vaultwarden : le dépôt est dans le dossier vaultwarden de la Storage Box, joint via l'alias storagebox.
• RESTIC_PASSWORD_FILE : restic lit la phrase de passe dans ce fichier, au lieu de la demander.
• chmod 600 : seul root peut lire ces fichiers.

Sortie attendue, en quelques secondes (l'identifiant varie) :

created restic repository 3f2a9c1e5b at sftp:storagebox:./vaultwarden

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

restic le dit lui-même : sans la phrase de passe, les données sont perdues à jamais.

La fiche de survie : le piège de l'œuf et de la poule

C'est le piège le plus grave, et il n'est pas technique. Si vos accès de restauration ne sont rangés que dans Vaultwarden et que le serveur disparaît, vous ne pouvez plus déchiffrer la sauvegarde qui contient… Vaultwarden.

Préparez donc une fiche de survie, hors du serveur, sur papier et sur un second support. Elle contient trois éléments :

1. l'identifiant et l'adresse de la Storage Box (uXXXXX, uXXXXX.your-storagebox.de) ;
2. la phrase de passe restic (le contenu de /root/.restic-pass) ;
3. l'accès à votre console Hetzner, pour déposer une nouvelle clé SSH depuis un serveur neuf (ou une copie de /root/.ssh/storagebox).

Sans ces trois éléments, un serveur détruit égale un coffre perdu.

Étape 4 — Le script de sauvegarde

Créez le script :

vim /usr/local/sbin/sauvegarde-vaultwarden

Collez-y ce contenu :

#!/usr/bin/env bash
set -euo pipefail
source /root/restic.env

VW=/home/lecoqnumerique/vaultwarden
DUMP=/var/backups/vaultwarden
install -d -m 700 "$DUMP"
trap 'rm -f "$DUMP/db.sqlite3"' EXIT   # ne laisse jamais la copie traîner

# 1. Copie cohérente de la base, puis contrôle d'intégrité
sqlite3 "$VW/vw-data/db.sqlite3" ".backup '$DUMP/db.sqlite3'"
sqlite3 "$DUMP/db.sqlite3" "PRAGMA integrity_check;" | grep -qx ok

# 2. Tout le dossier, sauf la base brute (remplacée par la copie) et le cache d'icônes
restic backup --tag vaultwarden "$VW" "$DUMP/db.sqlite3" \
  --exclude "$VW/vw-data/db.sqlite3*" \
  --exclude "$VW/vw-data/icon_cache"

# 3. Rétention, puis contrôle d'un échantillon
restic forget --tag vaultwarden --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

Le script, ligne par ligne :

• set -euo pipefail : le script s'arrête à la première erreur, y compris au milieu d'une suite de commandes reliées par |. Une sauvegarde à moitié faite échoue donc franchement, ce qui déclenchera l'alerte de l'étape 6.
• install -d -m 700 "$DUMP" : crée le dossier de la copie temporaire, lisible par root seulement.
• trap '…' EXIT : la copie de la base est effacée à la fin du script, quoi qu'il arrive, même en cas d'erreur. Rien ne traîne en clair sur le disque.
• Partie 1 : .backup fait la copie cohérente de la base. PRAGMA integrity_check la vérifie ; il doit répondre exactement ok, sinon grep -qx ok échoue et le script s'arrête avant d'envoyer une copie abîmée.
• Partie 2 : restic backup envoie le dossier vaultwarden entier et la copie propre de la base. Les deux --exclude retirent la base brute (et ses fichiers -wal et -shm), remplacée par la copie, ainsi que le cache d'icônes. --tag vaultwarden étiquette les instantanés, pour les retrouver et les trier.
• Partie 3 : restic forget applique la rétention : 7 sauvegardes quotidiennes, 4 hebdomadaires et 6 mensuelles. Les plus anciennes sont supprimées, et --prune libère la place correspondante. restic check --read-data-subset=5% relit chaque nuit 5 % des données au hasard : en un peu moins de trois semaines, tout le dépôt a été contrôlé.

Rendez le script exécutable, lancez-le une première fois et listez les instantanés :

chmod 700 /usr/local/sbin/sauvegarde-vaultwarden
/usr/local/sbin/sauvegarde-vaultwarden
restic snapshots

Sortie attendue, en 10 à 20 secondes pour un petit coffre (les chiffres varient) :

Files:          12 new,     0 changed,     0 unmodified
Dirs:           10 new,     0 changed,     0 unmodified
Added to the repository: 1.204 MiB (420.312 KiB stored)

processed 12 files, 1.181 MiB in 0:01
snapshot 7a1c3e9b saved

Suivent la ligne Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots, puis no errors were found pour le contrôle. Enfin, restic snapshots affiche votre premier instantané :

ID        Time                 Host    Tags         Paths
----------------------------------------------------------------------------------
7a1c3e9b  2026-10-17 14:02:11  coffre  vaultwarden  /home/lecoqnumerique/vaultwarden
                                                    /var/backups/vaultwarden/db.sqlite3
----------------------------------------------------------------------------------
1 snapshots

Étape 5 — Automatiser avec un timer systemd

Un timer systemd est l'équivalent moderne d'une tâche cron : il lance un service à heure fixe. Il est natif sur Debian, ses exécutions sont journalisées, et il sait rattraper une exécution manquée. Il faut deux fichiers : le service (ce qu'on lance) et le timer (quand on le lance).

cat > /etc/systemd/system/sauvegarde-vaultwarden.service <<'EOF'
[Unit]
Description=Sauvegarde Vaultwarden (restic)
Wants=network-online.target
After=network-online.target
OnFailure=alerte-telegram@%n.service

[Service]
Type=oneshot
ExecStart=/usr/bin/flock -n /run/sauvegarde-vaultwarden.lock /usr/local/sbin/sauvegarde-vaultwarden
TimeoutStartSec=2h
Nice=10
IOSchedulingClass=idle
EOF

cat > /etc/systemd/system/sauvegarde-vaultwarden.timer <<'EOF'
[Unit]
Description=Sauvegarde Vaultwarden chaque nuit

[Timer]
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now sauvegarde-vaultwarden.timer
systemctl list-timers sauvegarde-vaultwarden.timer

Les réglages du service :

• After=network-online.target : la sauvegarde attend que le réseau soit vraiment disponible.
• OnFailure=alerte-telegram@%n.service : si la sauvegarde échoue, systemd lance l'alerte de l'étape suivante, en lui passant le nom du service (%n).
• Type=oneshot : un service qui fait son travail puis s'arrête.
• flock -n : empêche deux sauvegardes de tourner en même temps, par exemple une lancée à la main pendant celle de la nuit. La seconde abandonne immédiatement.
• TimeoutStartSec=2h : coupe une sauvegarde bloquée, sur une connexion SFTP figée par exemple. Elle échoue, et l'alerte part.
• Nice=10 et IOSchedulingClass=idle : la sauvegarde passe après le reste, pour ne pas ralentir le serveur.

Les réglages du timer :

• OnCalendar=*-*-* 03:30 : tous les jours à 3 h 30.
• RandomizedDelaySec=15min : un décalage aléatoire de 0 à 15 minutes, pour éviter que tous les serveurs frappent leur stockage à la même minute.
• Persistent=true : si le serveur était éteint à 3 h 30, la sauvegarde part dès le redémarrage.

Sortie attendue de systemctl list-timers (la colonne LAST reste vide tant que la première exécution n'a pas eu lieu) :

NEXT                         LEFT      LAST PASSED UNIT                         ACTIVATES
Sat 2026-10-18 03:38:12 CEST 13h left  -    -      sauvegarde-vaultwarden.timer sauvegarde-vaultwarden.service

1 timers listed.

Pour consulter le journal d'une sauvegarde passée :

journalctl -u sauvegarde-vaultwarden.service -n 50 --no-pager

Étape 6 — L'alerte Telegram en cas d'échec

Une sauvegarde qui échoue en silence est le vrai danger : on la croit en place, et on découvre le problème le jour où on en a besoin. On ajoute donc une alerte Telegram. Il vous faut le token d'un bot Telegram (créé avec @BotFather) et votre chat_id.

cat > /root/telegram.env <<'EOF'
TELEGRAM_TOKEN=ton_token
TELEGRAM_CHAT_ID=ton_chat_id
EOF
chmod 600 /root/telegram.env

cat > /usr/local/sbin/alerte-telegram <<'EOF'
#!/usr/bin/env bash
UNITE="$1"
LOGS="$(journalctl -u "$UNITE" -n 5 --no-pager -o cat)"
curl -fsS -m 20 "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
  --data-urlencode chat_id="${TELEGRAM_CHAT_ID}" \
  --data-urlencode text="⚠️ $(hostname) : échec de ${UNITE}
${LOGS}" > /dev/null
EOF
chmod 700 /usr/local/sbin/alerte-telegram

cat > /etc/systemd/system/alerte-telegram@.service <<'EOF'
[Unit]
Description=Alerte Telegram pour %i

[Service]
Type=oneshot
EnvironmentFile=/root/telegram.env
ExecStart=/usr/local/sbin/alerte-telegram %i
EOF

systemctl daemon-reload
systemctl start alerte-telegram@test.service   # le message doit arriver sur Telegram

Comment ça marche :

• telegram.env garde le token et le chat_id hors du script, lisibles par root seulement.
• alerte-telegram@.service est un service « modèle » : le @ permet de le lancer pour n'importe quel service, dont le nom arrive dans %i. C'est ce que fait la ligne OnFailure= de l'étape 5.
• Le message contient le nom du serveur, le service en échec et ses 5 dernières lignes de journal : la cause de l'échec arrive directement sur votre téléphone.
• curl -f : si l'envoi échoue, le service d'alerte échoue aussi, et le journal en garde la trace.

Pour tester un vrai échec, renommez temporairement la phrase de passe, lancez la sauvegarde, puis remettez tout en place :

mv /root/.restic-pass /root/.restic-pass.test
systemctl start sauvegarde-vaultwarden.service   # échoue → message Telegram
mv /root/.restic-pass.test /root/.restic-pass

Étape 7 — Tester la restauration

Une sauvegarde jamais restaurée n'est pas une sauvegarde. On simule la catastrophe sur le serveur : on met de côté les données du coffre, puis on les restaure depuis la Storage Box.

source /root/restic.env
restic snapshots --tag vaultwarden
cd /home/lecoqnumerique/vaultwarden
docker compose down
mv vw-data vw-data.avant-restauration      # la « catastrophe »

install -d -m 700 /tmp/restauration        # personne d'autre ne peut y lire
restic restore latest --tag vaultwarden --target /tmp/restauration
R=/tmp/restauration
mkdir vw-data
cp -a "$R"/home/lecoqnumerique/vaultwarden/vw-data/. vw-data/
cp -a "$R"/var/backups/vaultwarden/db.sqlite3 vw-data/db.sqlite3
rm -f vw-data/db.sqlite3-wal vw-data/db.sqlite3-shm
docker compose up -d

Étape par étape :

1. restic snapshots : on vérifie qu'il y a bien un instantané à restaurer.
2. docker compose down : on arrête Vaultwarden et Caddy, pour que rien n'écrive pendant l'opération.
3. mv vw-data vw-data.avant-restauration : la « catastrophe ». On ne supprime rien : en cas de problème, l'original est encore là.
4. restic restore latest : restic télécharge et déchiffre le dernier instantané dans /tmp/restauration, un dossier lisible par root seulement, car il contient des données en clair.
5. Les deux cp -a : restic recrée les chemins complets sous le dossier cible, d'où les home/lecoqnumerique/… et var/backups/…. On copie d'abord le dossier vw-data, puis la copie propre de la base, à sa place. -a conserve les droits et les propriétaires.
6. rm -f … -wal … -shm : le wiki Vaultwarden le recommande. Un fichier -wal périmé à côté d'une copie .backup peut corrompre la base. Ils sont déjà absents grâce aux --exclude du script ; la ligne protège ceux qui restaurent dans un dossier existant.
7. docker compose up -d : on redémarre. La sortie affiche Container vaultwarden Started et Container caddy Started. Comptez 5 à 10 secondes avant que la page de connexion réponde.

Sortie attendue de restic restore :

restoring snapshot 7a1c3e9b of [/home/lecoqnumerique/vaultwarden /var/backups/vaultwarden/db.sqlite3] at 2026-10-17 14:02:11 by root@coffre to /tmp/restauration
Summary: Restored 24 files/dirs (1.181 MiB) in 0:01

Vérifiez dans le navigateur : connectez-vous, contrôlez que vos identifiants sont là et qu'une pièce jointe s'ouvre. C'est la preuve que tout est revenu, pas seulement la base.

Ensuite seulement, faites le ménage :

rm -rf /tmp/restauration                    # contient des données en clair
rm -rf vw-data.avant-restauration           # une fois sûr de vous

Refaites ce test régulièrement, par exemple tous les trois mois.

Restaurer sur un serveur neuf

C'est le scénario que la vidéo ne montre pas : votre serveur a totalement disparu. Vous avez votre fiche de survie, et c'est tout. Voici la procédure complète.

1. Préparer le nouveau serveur

Suivez le guide d'installation de Vaultwarden jusqu'à l'installation de Docker incluse (serveur, clé SSH, utilisateur lecoqnumerique, pare-feu, Docker). Ne réinstallez pas Vaultwarden : la sauvegarde contient déjà votre compose.yaml, votre Caddyfile et votre .env.

Faites pointer votre nom de domaine vers l'adresse IP du nouveau serveur, chez votre registraire. Caddy redemandera un certificat HTTPS au démarrage, à condition que le domaine pointe déjà au bon endroit.

2. Installer les outils et recréer la phrase de passe

sudo -i
apt install -y restic sqlite3
vim /root/.restic-pass        # collez la phrase de passe de votre fiche de survie
chmod 600 /root/.restic-pass

3. Reconnecter la Storage Box

L'ancienne clé SSH a disparu avec le serveur. Créez-en une nouvelle et recréez l'alias, exactement comme à l'étape 2 :

cat > /root/tournage.env <<'EOF'
BOX_USER=uXXXXX
BOX_HOST=uXXXXX.your-storagebox.de
EOF
chmod 600 /root/tournage.env
source /root/tournage.env

ssh-keygen -t ed25519 -f /root/.ssh/storagebox -N "" -C "restic@coffre"

cat >> /root/.ssh/config <<EOF
Host storagebox
  Hostname $BOX_HOST
  Port 23
  User $BOX_USER
  IdentityFile /root/.ssh/storagebox
  IdentitiesOnly yes
EOF
chmod 600 /root/.ssh/config

ssh-keyscan -p 23 "$BOX_HOST" >> /root/.ssh/known_hosts
ssh-copy-id -i /root/.ssh/storagebox.pub -s storagebox
echo ls | sftp -b - storagebox

ssh-copy-id demande le mot de passe de la Storage Box. Si vous ne l'avez plus, redéfinissez-le dans la console Hetzner : c'est pour cela que l'accès à la console figure sur la fiche de survie.

4. Restaurer tout le dossier

cat > /root/restic.env <<'EOF'
export RESTIC_REPOSITORY=sftp:storagebox:./vaultwarden
export RESTIC_PASSWORD_FILE=/root/.restic-pass
EOF
chmod 600 /root/restic.env
source /root/restic.env

restic snapshots --tag vaultwarden
install -d -m 700 /tmp/restauration
restic restore latest --tag vaultwarden --target /tmp/restauration
R=/tmp/restauration

cp -a "$R"/home/lecoqnumerique/vaultwarden /home/lecoqnumerique/
cp -a "$R"/var/backups/vaultwarden/db.sqlite3 /home/lecoqnumerique/vaultwarden/vw-data/db.sqlite3
rm -f /home/lecoqnumerique/vaultwarden/vw-data/db.sqlite3-wal /home/lecoqnumerique/vaultwarden/vw-data/db.sqlite3-shm

Cette fois, on copie tout le dossier vaultwarden : vw-data, mais aussi compose.yaml, Caddyfile et .env. cp -a conserve les propriétaires d'origine : vos fichiers de configuration reviennent à l'utilisateur lecoqnumerique, et vw-data à root.

5. Redémarrer et vérifier

cd /home/lecoqnumerique/vaultwarden
docker compose up -d
docker compose logs -f

Attendez que Caddy ait obtenu son certificat, puis connectez-vous dans le navigateur. Vos identifiants et vos pièces jointes sont là. Les clés rsa_key* étant restaurées, vos appareils restent connectés.

6. Remettre la sauvegarde en place

Les scripts et les fichiers systemd n'étaient pas dans le dossier sauvegardé. Refaites les étapes 4, 5 et 6 de ce guide : le dépôt existe déjà, ne relancez pas restic init. Les nouvelles sauvegardes s'ajoutent à l'historique existant. Enfin, faites le ménage :

rm -rf /tmp/restauration

Variante : un stockage S3 auto-hébergé (Garage)

Si vous hébergez votre propre stockage compatible S3, par exemple avec Garage, restic s'y branche nativement. Seul le fichier restic.env change :

export RESTIC_REPOSITORY=s3:https://s3.ton-garage.fr/vaultwarden
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_DEFAULT_REGION=garage   # la région déclarée dans votre config Garage
export RESTIC_PASSWORD_FILE=/root/.restic-pass

Rien d'autre ne bouge : le script, le timer, l'alerte et la restauration sont identiques. Seule condition : ce stockage doit se trouver sur une autre machine que votre coffre, idéalement dans un autre lieu.

Dépannage

FAQ

Faut-il arrêter Vaultwarden pendant la sauvegarde ?

Non. La commande .backup de SQLite produit une copie cohérente pendant que la base est utilisée : c'est tout son intérêt. Vaultwarden reste disponible pendant toute la sauvegarde. Il ne faut l'arrêter que pour une restauration.

Que se passe-t-il si je perds la phrase de passe restic ?

Vos sauvegardes deviennent définitivement illisibles : il n'existe aucun moyen de les récupérer, ni pour vous, ni pour Hetzner. C'est le prix du chiffrement côté serveur. D'où la fiche de survie, sur papier et sur un second support, jamais uniquement dans Vaultwarden.

Combien de place prend la sauvegarde ?

Très peu. Un coffre personnel ou d'équipe pèse quelques mégaoctets, et restic n'envoie que ce qui a changé. Même avec 7 sauvegardes quotidiennes, 4 hebdomadaires et 6 mensuelles, la plus petite Storage Box reste largement surdimensionnée.

L'export du coffre depuis l'interface remplace-t-il cette sauvegarde ?

Non, il la complète. L'export (au format JSON chiffré, depuis le coffre web) contient vos éléments, mais pas les pièces jointes, les réglages du serveur ni les comptes des autres utilisateurs. Faites-en un de temps en temps et rangez-le hors du serveur : c'est votre troisième copie, dans l'esprit de la règle 3-2-1.

Pourquoi restic plutôt que borg ?

Les deux sont excellents et chiffrent les données. restic est un seul programme, sans dépendance côté stockage, et il parle nativement SFTP et S3 : vous passez de la Storage Box à un stockage S3 en changeant une ligne. Pour un premier système de sauvegarde, il est plus simple à expliquer et à maintenir.

Et si vous préférez déléguer ?

Ce guide vous donne tout pour le faire vous-même. Si vous préférez qu'on mette en place, surveille et teste les sauvegardes de vos serveurs à votre place, sur un hébergement européen, c'est notre offre d'infogérance de VPS Linux. Et pour faire le point sur la dépendance de vos outils aux géants américains, l'Index de souveraineté est gratuit.

À lire aussi

• Installer Vaultwarden sur un VPS européen : le guide complet
• Créer une clé SSH ED25519
• Docker contourne ufw : le piège du pare-feu

Sources

• Wiki Vaultwarden — Backing up your vault
• Documentation Hetzner — accès SSH aux Storage Box
• Tutoriel communautaire Hetzner — restic et Storage Box
• Documentation restic

Michel Vigoureux — fondateur du Coq Numérique, infogérance souveraine et open source à Lyon. Il fait tourner ce qu'il recommande. Codeberg · LinkedIn

Vaultwarden est un serveur open source non officiel, compatible avec les applications Bitwarden. Bitwarden est une marque de Bitwarden Inc. Article non sponsorisé.