Aller au contenu
Infrastructure · 4 min de lecture

Restic vers du stockage objet est une vraie stratégie de sauvegarde

L'affirmation Une petite entreprise n'a pas besoin d'un appareil de sauvegarde, d'un contrat de fournisseur ni d'un produit de reprise à six chiffres pour protéger ses données corr...

A Rédigé par Administrator
Restic vers du stockage objet est une vraie stratégie de sauvegarde

L'affirmation

Une petite entreprise n'a pas besoin d'un appareil de sauvegarde, d'un contrat de fournisseur ni d'un produit de reprise à six chiffres pour protéger ses données correctement. Un seul outil à code ouvert écrivant des instantanés chiffrés, dédupliqués et vérifiables vers du stockage objet peu coûteux couvre entièrement le besoin, pour quelques dollars par mois, et il fait la seule chose qui distingue une sauvegarde d'un dossier de fichiers : prouver que la sauvegarde est intacte sans la restaurer.

Ce qu'un vrai outil de sauvegarde doit faire

La barre n'est pas « copie les fichiers quelque part ». Une sauvegarde fiable a quatre propriétés, et un simple rsync vers un second disque en a une :

  • Chiffrée avant de quitter l'hôte, pour que le fournisseur de stockage — et quiconque le compromet — ne détienne que du texte chiffré.
  • Dédupliquée et incrémentale, pour qu'un instantané quotidien d'un jeu de 40 Go coûte l'espace de ce qui a changé, pas 40 Go, et que vous gardiez des mois d'historique à bas prix.
  • À un instant précis, pour restaurer à mardi dernier, pas seulement à la copie la plus récente — ce qui compte énormément quand vous récupérez d'une corruption ou d'un rançongiciel que votre dernière copie a fidèlement répliqué.
  • Vérifiable, pour contrôler à intervalle que la sauvegarde est lisible et cohérente, sans restauration complète.

Toute la configuration

export RESTIC_REPOSITORY=s3:https://s3.ca-central-1.exemple.com/acme-backups
export RESTIC_PASSWORD_FILE=/etc/restic/passphrase

restic init          # une fois

# chaque nuit :
restic backup /srv/app/data /etc --tag nightly
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Cette ligne forget est la politique de conservation en une commande : quatorze instantanés quotidiens, huit hebdomadaires, douze mensuels, et tout ce qui est plus ancien retiré et son espace récupéré. La déduplication fait que ces trente-quatre instantanés conservés d'un jeu qui évolue lentement occupent un petit multiple d'une copie complète, non trente-quatre fois celle-ci.

La vérification qui en fait une stratégie plutôt qu'un espoir

C'est l'étape qui sépare restic d'une tâche planifiée pleine de bonnes intentions :

# bon marche, chaque nuit : integrite structurelle du depot
restic check

# approfondi, chaque semaine : lire et verifier un echantillon des donnees
restic check --read-data-subset=5%

check vérifie que la structure interne du dépôt est cohérente. --read-data-subset va plus loin et télécharge et rehache réellement un pourcentage des vraies données, attrapant la corruption silencieuse du stockage qu'un contrôle structurel manquerait. Un sous-ensemble hebdomadaire de 5 % lit tout le jeu en environ cinq mois sans jamais payer une vérification complète d'un coup.

La règle qui déjoue le rançongiciel

Une sauvegarde que l'hôte compromis peut supprimer n'est pas une sauvegarde contre le rançongiciel, car les rançongiciels modernes cherchent et chiffrent les sauvegardes en premier. La défense, ce sont des identifiants en ajout seul : la clé qu'utilise votre serveur peut écrire de nouveaux instantanés et les lire, mais ne peut rien supprimer. La suppression — l'étape forget --prune — s'exécute depuis un contexte distinct aux identifiants distincts, ou vous utilisez le verrou de rétention du stockage objet pour que les objets soient immuables pendant une fenêtre définie, quelle que soit la clé qui demande.

# cle du serveur : PutObject, GetObject, ListBucket   (pas de DeleteObject)
# verrou d'objet : conserver 30 jours, mode gouvernance ou conformite

Ainsi, un attaquant qui possède entièrement votre serveur peut chiffrer vos données vives mais ne peut pas toucher aux trente jours d'historique du seau, ce qui est exactement la position souhaitée.

La règle 3-2-1, satisfaite honnêtement

Le vieux conseil — trois copies, deux supports, une hors site — est satisfait ici : les données vives, un dépôt restic local pour les restaurations rapides, et le dépôt de stockage objet hors site. Gardez la copie locale pour le cas courant, restaurer un fichier supprimé ce matin, et comptez sur la copie distante pour le cas rare, perdre l'hôte entier. Restaurer 40 Go depuis un disque local, c'est des minutes ; depuis le stockage objet, c'est borné par votre débit de téléchargement, qu'il vaut la peine de mesurer avant d'en avoir besoin.

Ce que cela coûte

Le stockage objet dans une région canadienne se situe autour de quelques cents par gigaoctet par mois ; un jeu de 40 Go avec plusieurs mois d'historique dédupliqué revient donc à quelques dollars mensuels, plus des frais de sortie que vous ne payez qu'à une vraie restauration. Face à la mensualité par serveur d'un produit de sauvegarde géré, la voie à code ouvert est nettement moins chère — et comme vous pouvez lire exactement son fonctionnement, la vérifier vous-même et restaurer sans fournisseur, elle est aussi plus digne de confiance le jour venu. Le coût, c'est que la configuration vous appartient. Pour la plupart des petites entreprises, un après-midi de configuration contre une vraie capacité de reprise est le meilleur marché de cette liste.

#backups #restic #object storage #ransomware

À lire aussi