Sauvegarde Restic : créer un dépôt et vérifier la restauration

Une sauvegarde Restic stocke les données des fichiers dans un dépôt chiffré et crée des instantanés que vous pouvez restaurer plus tard. La déduplication permet aux instantanés de partager des données déjà présentes dans le dépôt. Pour commencer, sauvegardez un petit ensemble de fichiers connus, restaurez un instantané précis dans un autre dossier, puis comparez les fichiers restaurés à une référence enregistrée.

Ce guide réalise cet exercice avec un dépôt local. Nous l’avons exécuté avec Restic 0.19.1 sous Windows, sur des fichiers de test comprenant un CSV dans un sous-dossier, un fichier vide et des données binaires. Les deux versions sauvegardées ont été restaurées correctement. Le stockage distant, la cohérence applicative, les permissions et la restauration complète d’un système demandent des tests distincts.

Préparer un exercice de sauvegarde isolé

Installez Restic en suivant les instructions officielles, puis relevez sa version :

restic version

Créez un dossier de travail vide et un sous-dossier nommé source. Placez-y quelques fichiers sans importance, dont un sous-dossier et un fichier vide. Exécutez toutes les commandes ci-dessous depuis le dossier de travail. Les exemples supposent que restic et Python 3 sont accessibles dans votre terminal ; remplacez python par python3 si votre installation utilise ce nom.

Gardez le dépôt, les éléments d’authentification et les fichiers restaurés hors de source. Utilisez un nouveau dossier nommé repository comme destination. Cet exercice sur un même disque permet d’apprendre les commandes ; il ne protège pas contre la perte du disque. Notre guide de sauvegarde cloud aborde le choix des emplacements et des copies indépendantes.

Initialiser le dépôt chiffré

restic --repo ./repository init

Saisissez un mot de passe propre à ce dépôt et conservez-en une copie récupérable dans votre gestionnaire de mots de passe. Le guide de création d’un dépôt explique cette exigence. Perdre l’accès à la clé de chiffrement revient à perdre l’accès à la sauvegarde. Si le mot de passe reste uniquement sur la machine protégée, cette dépendance compromet sa récupération après une panne.

Pour cet exercice, saisissez le mot de passe lorsque Restic le demande. Avant d’utiliser les commandes dans un terminal déjà configuré, examinez les variables RESTIC_* existantes. L’argument explicite du dépôt sélectionne la destination locale, mais d’autres variables peuvent encore modifier l’authentification ou le comportement.

Enregistrer les fichiers attendus avant la sauvegarde

Ne modifiez pas les fichiers source pendant l’enregistrement de la référence et leur sauvegarde. Enregistrez ce script Python 3 sous verify-restic.py dans le dossier de travail, hors de source. Il relève le chemin relatif et l’empreinte SHA-256 de chaque fichier ordinaire, puis compare une arborescence restaurée à cette référence.

import hashlib
import json
import sys
from pathlib import Path

mode, folder, manifest_file = sys.argv[1:]
root = Path(folder)
if mode not in ('record', 'compare') or not root.is_dir():
    raise SystemExit('Use record or compare with an existing directory.')
files = {}
for path in sorted(root.rglob('*')):
    if path.is_symlink():
        raise SystemExit('This example checks regular files, not symlinks.')
    if path.is_file():
        digest = hashlib.sha256()
        with path.open('rb') as stream:
            for block in iter(lambda: stream.read(1024 * 1024), b''):
                digest.update(block)
        files[path.relative_to(root).as_posix()] = digest.hexdigest()
if mode == 'record':
    with open(manifest_file, 'x', encoding='utf-8') as stream:
        json.dump(files, stream, indent=2)
    print('Recorded', len(files), 'files')
else:
    expected = json.loads(Path(manifest_file).read_text(encoding='utf-8'))
    if files != expected:
        raise SystemExit('FAIL: file paths or SHA-256 hashes differ.')
    print('PASS:', len(files), 'files match')

python verify-restic.py record source baseline.json

Le script crée un nouveau fichier baseline.json et refuse d’en écraser un existant. Il vérifie le contenu et les chemins des fichiers, y compris les fichiers manquants ou supplémentaires. Il ne vérifie pas les dossiers vides, les permissions, les propriétaires, les horodatages ni le fonctionnement d’une application.

Simuler la sauvegarde, puis créer un instantané

Exécutez ces commandes une par une. Examinez la simulation et arrêtez-vous si les fichiers sélectionnés ou la destination sont incorrects :

restic --repo ./repository backup source --tag restic-guide --dry-run --verbose=2
restic --repo ./repository backup source --tag restic-guide --force
restic --repo ./repository snapshots

Pour ce petit exercice, --force relit tous les fichiers source. Cette option n’est pas nécessaire à chaque sauvegarde de production. La documentation de sauvegarde décrit la détection normale des changements, la déduplication et les exclusions. Un nouvel instantané peut réutiliser des données existantes ; sa présence ne signifie pas qu’une deuxième copie physique complète a été créée.

Vérifiez le code de sortie et les éventuelles erreurs avant de continuer. Dans la référence des codes de sortie, le code 3 de la commande de sauvegarde indique que certaines données source n’ont pas pu être lues. Traitez-le comme une sauvegarde incomplète à examiner, même si un instantané a été enregistré. Un code non nul inconnu indique également un échec.

Copiez l’identifiant voulu depuis le résultat de la sauvegarde réussie ou la liste des instantanés. Remplacez SNAPSHOT_ID par cette valeur dans les exemples suivants. Examinez son contenu :

restic --repo ./repository ls SNAPSHOT_ID

Avec le chemin source relatif utilisé ici, l’arborescence contient /source. Vérifiez la liste réelle avant la restauration. Un chemin source absolu produit une autre arborescence ; ne supposez donc pas que tous les dépôts utilisent ce chemin.

Vérifier le dépôt et restaurer dans un nouveau dossier

restic --repo ./repository check --read-data

Les contrôles du dépôt distinguent la vérification de sa structure de la lecture des données stockées. --read-data lit aussi tous les paquets de données. Pour un grand dépôt distant, prévoyez le temps, la bande passante et les éventuels frais de récupération.

Choisissez une destination de restauration qui n’existe pas encore. Ici, il s’agit de restore-check, à côté de source. Simulez d’abord la restauration, puis lancez-la après avoir vérifié la destination :

restic --repo ./repository restore "SNAPSHOT_ID:/source" --target ./restore-check --dry-run --verbose=2
restic --repo ./repository restore "SNAPSHOT_ID:/source" --target ./restore-check --verify

Le suffixe :/source sélectionne le contenu de ce sous-dossier : les fichiers sont donc restaurés directement dans restore-check. --verify vérifie leur contenu après restauration. Une restauration ordinaire peut écraser des fichiers existants ; une nouvelle destination sépare cet exercice des données de travail. Le guide de restauration décrit la sélection des sous-dossiers et les options d’écrasement.

Utilisez un identifiant explicite dans votre compte rendu de restauration. latest est pratique, mais peut désigner un autre instantané après une nouvelle sauvegarde. Le filtre de sélection --path est également distinct du choix du sous-dossier à restaurer.

Comparer les fichiers restaurés à la référence

python verify-restic.py compare restore-check baseline.json

Si la comparaison réussit, le script affiche PASS et le nombre de fichiers. Sinon, il se termine avec une erreur. Si la source a changé depuis la sauvegarde, utilisez la référence enregistrée pour cet instantané, pas le dossier source actuel.

Dans notre test local, le premier instantané contenait cinq fichiers. Nous avons modifié un fichier et en avons ajouté un autre avant de créer le deuxième instantané. Leur restauration dans deux destinations distinctes a produit les manifestes attendus de cinq et six fichiers. Le contrôle des données et la vérification de restauration Restic ont réussi, tout comme les comparaisons SHA-256 indépendantes avec les deux références. L’ancien instantané conservait le contenu initial du fichier modifié.

Ces résultats concernent des fichiers ordinaires sur un système de fichiers Windows local. Ils ne démontrent pas la compatibilité d’un stockage distant, la restitution des permissions ni le bon fonctionnement d’une application. Complétez l’exercice avec les contrôles propres à votre usage ; notre guide des tests de restauration explique comment définir un test utile.

Simuler la rétention avant de supprimer des points de restauration

Dans ce dépôt jetable, examinez une règle qui conserve le dernier instantané de chaque groupe correspondant :

restic --repo ./repository forget --tag restic-guide --keep-last 1 --dry-run

Il s’agit d’une simulation, pas d’une politique de rétention recommandée pour la production. Avec un seul instantané, aucun ancien instantané n’est à supprimer. Notre test avec deux instantanés a confirmé que la simulation les laissait tous deux disponibles.

La documentation de rétention distingue forget, qui supprime des références d’instantanés, de prune, qui supprime les données sans référence. Par défaut, les groupes reposent sur l’hôte et les chemins source ; examinez-les, ainsi que la portée du tag, avant d’autoriser une suppression réelle. Conservez assez de points pour vos besoins de récupération et testez les restaurations avant de modifier la rétention.

Passer de l’exercice à une sauvegarde automatisée

Une sauvegarde de production demande une source stable, des secrets protégés, un signalement des échecs, une politique de rétention et des tests réguliers de restauration. Pour une exécution sans intervention, Restic accepte un fichier de mot de passe ou une commande qui le fournit. Restreignez l’accès à ce mécanisme, gardez-le hors de l’arborescence sauvegardée et documentez la récupération du secret par une personne autorisée après une panne.

Une copie des fichiers d’une base en cours d’exécution ne prouve pas la cohérence de sa sauvegarde. Utilisez d’abord une méthode prise en charge par la base, puis protégez le résultat. Notre guide de sauvegarde et restauration PostgreSQL décrit cette démarche.

Pour passer au stockage distant, répétez l’initialisation, la sauvegarde, les contrôles d’intégrité et la restauration avec le point d’accès et l’identité prévus pour la récupération. Vérifiez les permissions, la connectivité, les interactions avec la rétention et les coûts du stockage retenu. Ce test local ne démontre la compatibilité d’aucun service Hivenet avec Restic.