Que se passe-t-il si je perds le mot de passe restic ?

Les sauvegardes sont perdues pour de bon. restic chiffre tout côté client et il n'existe aucune clé de récupération. Rangez le mot de passe dans un gestionnaire de mots de passe, pas seulement sur le serveur que vous sauvegardez.

Où placer le dépôt ?

N'importe où sauf sur le serveur lui-même : stockage objet compatible S3, autre VPS en SFTP ou machine chez vous. Une sauvegarde sur le même disque meurt avec ce disque.

Comment sauvegarder une base de données avec restic ?

Faites d'abord un dump et sauvegardez ce dump — pour PostgreSQL 'pg_dump -Fc', pour MySQL 'mysqldump --single-transaction'. Copier les fichiers d'une base en marche peut donner une sauvegarde qui ne démarre pas.

Combien de place prennent les sauvegardes ?

Moins qu'on ne croit. restic découpe les fichiers en morceaux et stocke chaque morceau une seule fois, donc les instantanés quotidiens d'un serveur qui change peu n'ajoutent que les modifications.

Ai-je encore besoin des Managed Backups ?

Ils résolvent des problèmes différents. Les Managed Backups offrent des points de restauration quotidiens du serveur entier, à rétablir depuis l'espace client. restic offre des copies au niveau fichier, hors site, que vous contrôlez. Beaucoup utilisent les deux.

Sauvegarder un VPS avec restic (chiffré et hors site)

Des sauvegardes de VPS chiffrées et dédupliquées avec restic : dépôt sur stockage compatible S3 ou autre serveur, timer systemd, règles de rétention et vrai test de restauration.

Tout le monde a des sauvegardes jusqu'au jour où il essaie d'en restaurer une. Le dossier est vide, la tâche cron est morte en mars, ou l'archive est sur le disque qui vient justement de lâcher. restic règle presque tout ça : il chiffre de votre côté, stocke chaque morceau de données une seule fois, et restaurer un seul fichier devient aussi simple que sauvegarder tout le serveur.

Voici une configuration à laquelle nous ferions confiance, sous Ubuntu ou Debian.

1. Installer restic

apt update && apt install -y restic
restic self-update

Les paquets de la distribution ont du retard ; self-update récupère la version actuelle.

2. Choisir l'emplacement du dépôt

Le dépôt ne doit pas se trouver sur le serveur que vous protégez. Deux choix courants :

Un autre serveur en SFTP : sftp:backup@203.0.113.20:/srv/restic/web1
Un stockage objet compatible S3 : s3:https://s3.example.com/my-bucket/web1

3. Enregistrer les identifiants

Gardez tout dans un fichier lisible par root uniquement, pour que le timer et votre shell utilisent les mêmes réglages :

cat > /root/.restic-env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-bucket/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="your-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret"
EOF
openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-env /root/.restic-pass

Copiez maintenant le contenu de /root/.restic-pass dans votre gestionnaire de mots de passe. Sans lui, personne ne peut déchiffrer les sauvegardes — vous non plus.

4. Initialiser et lancer la première sauvegarde

source /root/.restic-env
restic init
restic backup /etc /home /root /srv /var/www \
  --exclude-caches --exclude '/root/.cache'
restic snapshots

Adaptez les chemins à l'endroit où vivent vraiment vos données. Les volumes Docker sont dans /var/lib/docker/volumes ; les données applicatives souvent dans /srv ou /opt.

5. Bases de données : dump d'abord, sauvegarde ensuite

Ne sauvegardez pas les fichiers bruts d'une base en marche. Faites un dump juste avant la sauvegarde :

mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc mydb > /var/backups/db/mydb.dump

Ajoutez /var/backups/db aux chemins sauvegardés. Notre guide PostgreSQL détaille les dumps.

6. Planifier avec systemd

Ici, un timer vaut mieux que cron : il journalise et rattrape l'exécution manquée si le serveur était éteint.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic backup

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source /root/.restic-env && restic backup /etc /home /root /srv /var/www /var/backups/db --exclude-caches && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

forget --prune garde 7 instantanés quotidiens, 4 hebdomadaires et 6 mensuels et supprime le reste. Si vous avez une étape de dump, mettez-la dans une ligne ExecStartPre=.

7. Restaurer vraiment quelque chose

C'est l'étape qui transforme « on a des sauvegardes » en fait. Récupérez un répertoire dans un dossier temporaire et regardez-le :

source /root/.restic-env
restic restore latest --target /tmp/restore-test --include /etc/nginx
ls -la /tmp/restore-test/etc/nginx
restic check

Faites-le maintenant, puis tous les quelques mois. restic check vérifie la structure du dépôt ; la restauration prouve que les données sont bien là.

restic et Managed Backups

Ils ne se concurrencent pas. Les Managed Backups créent chaque jour un point de restauration de tout le serveur, à rétablir depuis l'espace client — la réparation rapide après une mise à jour ratée. Ils coûtent $2 par mois et sont inclus gratuitement avec toute offre annuelle. restic vous donne des copies au niveau fichier dans un stockage que vous contrôlez, ce qui compte quand le problème est un fichier supprimé mardi dernier ou quand vous voulez une copie totalement hors de notre infrastructure.

Si vous stockez des données sensibles, associez-le au chiffrement complet du disque, ou regardez le cas d'usage stockage chiffré pour héberger votre propre cible de sauvegarde. Une offre Micro suffit à la plupart des petits serveurs avec leurs tâches de sauvegarde.