Offre de sauvegarde hébergée restic

Introduction

Après des décennies de solutions de sauvegardes classiques (tar, rsync) hébergées ou non, chiffrées ou non (GPG, openssl), avec plus ou moins de contrôle d'intégrité, de nouvelles solutions sont apparues avec quelques caractéristiques novatrices:

• optimisation de la performance (bénéfice de RAM importante, de CPU multicore)
• fiabilité de bout en bout, ou au moins de la collecte au stockage
• facilité de vérification de l'intégrité des données, avec ou sans comparaison octet par octet, aussi en cas de corruption intentionnelle
• chiffrement systématisé empêchant le serveur de sauvegarde d'accéder lui-même aux données
• inventorisation systématique
• parfois résistance à la perte de média
• mode push plutôt que pull, évitant des risques liés aux droits d'accès du serveur de sauvegarde envers les clients de sauvegarde
• déduplification

Par exemple restic est une implémentation intéressante: disponible dans les packages Debian, offrant plusieurs fonctionnalités utiles, performant même sur système embarqué apu2.

Attention, la déduplification a aussi une conséquence sévère: une corruption d'un pack de données (ci après data-pack) va toucher potentiellement l'ensemble des sauvegardes (snapshots ci après).

C'est aussi pour cela que de la redondance reste intéressante

• plusieurs chemins de sauvegarde
• plusieurs logiciels différents de sauvegarde
• plusieurs médias différents de sauvegarde, y compris non effaçables magnétiquement et/ou à long terme
• plusieurs lieux de stockage

Fiabilité

restic ne peut pas (sauf vérification end-to-end des données, manuelle)

• détecter des corruptions silencieuse du média source non détectées par l'OS
• détecter des corruptions en RAM, CPU ou interface non détectées par l'OS ou le matériel

restic peut

• détecter des corruptions de données pendant le transfert vers le serveur distant
• sur demande du client et avec la clé de chiffrement, vérifier l'intégrité des indexes, snapshots et data packs stockés sur le serveur distant (restic check avec ou sans --read-data pour vérifier/transférer réellement les données sur le client)

le serveur de stockage restic ALPHANET peut

• détecter des corruptions de packs de données stockées sur ses médias (vérification 1x/mois) accidentelle ou intentionnelle
• éventuellement restaurer les data packs perdus de copies (1 copie par semaine automatique en site, plus 6 copies hors site, 1 tourne chaque semaine)
  • il y a également 3 copies hors site en rotation tous les 6 mois (LTO et/ou disques-dur), pour historisation à plus long terme (donc max 1.5 ans d'historique actuellement)

A la restauration

Les problèmes à la restauration peuvent venir de plusieurs causes: il reste utile de vérifier, de temps en temps, qu'une restauration est possible:

• avez-vous les logiciels adéquats? (p.ex.: zstd, openssl, tar)
• avez-vous la clé de chiffrement des sauvegardes? (ALPHANET n'a pas votre clé!)
  • recommandation de l'imprimer et de la stocker hors de chez vous (p.ex. safe bancaire)
    • vous pouvez l'obtenir avec sudo cat /root/scripts/backup-restic/pw
• avez-vous testé une restauration complète?
• les data-packs, snapshots et indexes distants sont-ils lisibles?

Durant l'ensemble du processus

Les causes de non fiabilités peuvent être:

• à la collecte de donnée sur la machine
  • corruption de données temporaire (CPU, RAM, interfaces) ou permanente (média), pas forcément détectée
  • fichiers actifs (changeants) en l'absence d'utilisation d'un snapshot du filesystem (LVM p.ex.)

• à la compression ou au chiffrement (voir corruption de données temporaires ci-dessus)

• durant le transfert

• sur le système de stockage (voir corruption de données temporaires ci-dessus)

• sur le média de stockage

• à la restauration (y.c. transfert) (voir corruption de données temporaires ci-dessus)

Le service hébergé de sauvegarde restic ALPHANET

Conditions

• but non lucratif (association, individus)
• poursuite des buts standards ALPHANET
• volume raisonnable (quelque centaines de Gbytes sur un an)
• vous avez une copie ailleurs de vos données importantes / pas de garantie

Installation

• création d'un compte sur restic-test.alphanet.ch
• au besoin, création d'un compte-relais sur le jump host SSH login-backup.alphanet.ch
• création d'une clé de chiffrement
• installation du client paramétré (Debian GNU/Linux, GUI MATE)
• si volume important, première sauvegarde sur site

Régulièrement

• lancement du client de sauvegarde (p.ex. via script de rappel hedomadaire au login, ou manuellement) -- si vous ne sauvegardez pas régulièrement, vous pouvez être contacté pour le faire (nous avons un script de monitoring)

Une fois par mois

• sur le serveur: contrôle de l'intégrité des packs de données (via les sha256sum), sans nécessiter de clé de chiffrement
• le 15, contrôle de l'intégrité du dépôt (évt. aussi des données elles-mêmes) par le client, car nécessite clé de chiffrement: il faut faire explicitement une sauvegarde le 15.

Une fois tous les 6 mois

• utiliser l'interface de montage et comparez vos données, aussi non récentes
• relecture (--force) de tous les fichiers locaux à demander

Une fois par an

• recommandation de tester la comparaison complète des données.

En cas de corruption de données (hors collecte locale des données)

• il y a plusieurs copies du dépôt entier en site et hors site, vérifiées régulièrement, il est théoriquement possible de restaurer des data packs corrompus plus vieux d'une semaine

Recommandations

• imprimer la clé de chiffrement et la stocker également de manière hors-site de manière sûre (en cas de perte: perte totale des données hébergées)
• procéder à une vérification régulière, de bout en bout, des données, voire une restauration.

-- MarcSCHAEFER - 30 Jan 2026