Sauvegarder le conteneur ou ses fichiers ? Décidez selon la forme de la restauration

Vous pouvez sauvegarder un conteneur chiffré comme un seul objet, ou le monter et sauvegarder les fichiers qu'il contient. Les deux traversent le VPN sans difficulté, et c'est là que la ressemblance s'arrête. Ils restaurent des choses différentes, dépendent de clés différentes, coûtent des quantités de stockage différentes et échouent de manières différentes quand quelqu'un a besoin de récupérer les données. Choisissez d'abord l'objet de restauration, puis le transport, puis le chiffrement de la copie stockée. La liste ci-dessous suit cet ordre, car presque tout désaccord sur les sauvegardes est en réalité un désaccord sur laquelle de ces trois décisions a été prise en premier.

Deux objets, deux formes de restauration

Une sauvegarde image restaure un conteneur : vous récupérez le volume chiffré et avez encore besoin de son matériel de restauration pour l'ouvrir. Une sauvegarde au niveau des fichiers restaure des fichiers et des arborescences, et le chiffrement qui les protège est une propriété du dépôt de sauvegarde et non du conteneur d'origine. Une simple copie dans un dossier distant est un troisième cas, et elle hérite de la protection que ce dossier possède par hasard.

La ligne du milieu est celle que les gens lisent mal. Elle peut être une conception parfaitement valable : le programme de sauvegarde lit du texte en clair en local et écrit un dépôt chiffré et authentifié. Sa sécurité repose alors sur ce programme et ses identifiants, pas sur le mot de passe du conteneur d'origine, et les deux ne doivent pas être décrits comme s'il s'agissait du même contrôle.

Vérification 1 : que doit reconstruire la restauration ?

Posez la question sous forme de restauration, pas de sauvegarde. Si l'exigence est « remettre ce service en route sur un autre hôte », une image avec son matériel de restauration est une réponse cohérente. Si l'exigence est « récupérer le tableur financier de mars », restaurer une image de plusieurs gigaoctets pour en extraire un seul fichier est une façon coûteuse de répondre. Les deux sont des restaurations légitimes et ce ne sont pas des budgets interchangeables. Un plan qui n'en nomme qu'une sera tôt ou tard mis à l'épreuve par l'autre.

Écrivez la cible de restauration dans le plan : volume entier, arborescence ou fichiers individuels. Notez ensuite quelles métadonnées doivent voyager avec eux, car la propriété, les permissions, les attributs étendus et les horodatages font partie d'une restauration au niveau des fichiers et sont souvent perdus dans les flux de travail basés sur la copie qui semblaient suffisants lors des tests.

Décidez aussi qui effectue la restauration. Un dépôt au niveau des fichiers que tout opérateur peut monter est un modèle d'accès différent d'une image qui exige la présence du détenteur de la clé, et aucun n'est automatiquement meilleur. L'important est que le choix soit délibéré et écrit.

Vérification 2 : qu'est-ce qui protège la copie stockée ?

Le VPN protège un segment de transport. Il ne dit rien de la copie stockée une fois le transfert terminé, et « c'est passé par le tunnel » n'est pas une affirmation sur la capacité de l'opérateur de sauvegarde à lire vos données. Si le côté distant est exploité par quelqu'un d'autre, la question est ce que cette personne peut lire, pas si le lien était chiffré.

Pour une image, cela signifie protéger le matériel de clé du conteneur séparément de l'image elle-même. Perdre l'en-tête, c'est perdre le volume, alors sauvegardez l'en-tête ailleurs que là où se trouve l'image :

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

Pour un dépôt au niveau des fichiers, vérifiez que l'outil chiffre et authentifie le contenu et les métadonnées avant qu'ils quittent l'hôte, et déterminez qui détient les clés. La documentation de conception de Restic indique clairement qu'il suppose un hôte source de confiance et que le chiffrement n'empêche pas quelqu'un ayant accès au stockage de supprimer les sauvegardes. Les deux réserves comptent : un dépôt peut être confidentiel et malgré tout détruit.

Vérification 3 : la copie est-elle cohérente ?

Une sauvegarde qui capture un système de fichiers en cours de modification est une copie, pas un point de restauration. Pour une image, utilisez la méthode prise en charge par l'outil de volumes pour un instantané stable, ce qui signifie généralement une opération d'instantané ou un démontage plutôt que la lecture d'un gros fichier pendant qu'il change :

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

Pour les fichiers montés, utilisez la procédure de cohérence prise en charge par l'application pour les bases de données actives et les autres données coordonnées. Une copie au niveau du système de fichiers et un point de restauration cohérent avec l'application sont des descriptions différentes, et la différence ne devient visible que lorsque vous essayez de démarrer l'application depuis la copie restaurée.

Gardez le matériel de restauration sur une voie protégée indépendante. Perdre la machine d'origine ne doit jamais faire perdre aussi l'unique identifiant qui ouvre sa sauvegarde, et c'est exactement ce qui se passe quand le fichier de clé réside sur le volume sauvegardé. Testez cette séparation délibérément : restaurez sur un hôte qui n'a jamais vu l'original, en n'utilisant que ce que le plan déclare disponible.

Vérification 4 : la détection des changements tient-elle pour cet objet ?

Un conteneur chiffré ressemble à un gros fichier opaque pour la plupart des outils de transfert, si bien qu'une petite modification en clair peut provoquer une grande relecture ou un téléversement complet selon l'outil et le format. Le découpage en blocs de taille variable et la déduplication, comme le documente restic, peuvent réduire cela, mais c'est une propriété de cet outil et non des conteneurs chiffrés en général.

Mesurez au lieu de supposer. Comparez une première exécution avec une seconde après une petite modification inoffensive, et notez les octets transférés ainsi que le temps écoulé. Conservez une sauvegarde connue comme bonne pendant vos essais, afin qu'un test ne consomme pas votre seul point de restauration.

Terminez ensuite la liste par le seul test qui compte : restaurer sans la machine d'origine. Ouvrez un conteneur restauré, ou restaurez des fichiers choisis avec leurs métadonnées, et confirmez que l'application ou l'utilisateur peut se servir du résultat. Un transfert rapide et bien chiffré qui ne peut pas répondre à ce test est une copie de vos données, pas une sauvegarde.