La page 2 de ce tutoriel communautaire fait passer la question de « comment exécuter dd ? » à « qu’est-ce qui mérite réellement d’être protégé ? ». L’utilisateur disposait déjà d’un grand NVMe en production et se souciait bien davantage de perdre les DONNÉES que de perdre le système d’exploitation amorçable. Le conseil de gelbuilding était d’éviter de repartitionner le NVMe de démarrage en production, de protéger d’abord les DONNÉES et les données d’application, et de ne conserver un clone brut du système que si le gain en temps de récupération justifie l’espace de sauvegarde supplémentaire.
Cette priorité correspond à l’architecture actuelle de ZimaOS. Le système d’exploitation dispose d’emplacements système A/B pour une récupération rapide, tandis que les données utilisateur irremplaçables, les données d’application et les métadonnées de stockage se trouvent en dehors de ces images système immuables. Un clone de disque complet peut restaurer rapidement la machine à un état précis, mais il ne remplace pas des sauvegardes indépendantes et versionnées des DONNÉES.
dd clone l’intégralité du périphérique, pas seulement les petits emplacements système
Le tutoriel d’origine utilise une commande conceptuellement similaire à :
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzSi le système se trouve sur un NVMe de 1 To, le processus d’imagerie brute lit tout le périphérique bloc. La compression peut réduire la taille du fichier, mais la cible et le processus de sauvegarde restent liés à la disposition physique du disque, et non aux seuls quelques gigaoctets utilisés par les partitions système de ZimaOS.
Ne repartitionnez pas un système sain en production uniquement pour réduire la taille de dd
gelbuilding a qualifié le repartitionnement du NVMe de démarrage en production de très risqué, car une erreur peut entraîner une interruption de service ou une perte de données. Si la disposition actuelle fonctionne, effectuez des sauvegardes de données vérifiées avant de modifier les limites des partitions.
Protégez les DONNÉES et les données d’application avant le clone du système d’exploitation
Si votre priorité est la récupérabilité, sauvegardez :
- les fichiers utilisateur et les pools de stockage ;
- les données d’application, bases de données et configurations difficiles à recréer ;
- les exports importants propres aux applications ;
- les métadonnées de stockage de ZimaOS, telles que
local-storage.db, lorsque cela est pertinent ; - puis, éventuellement, l’intégralité du disque système.
Les recommandations actuelles de ZimaOS concernant la règle 3-2-1 prennent en charge les sauvegardes planifiées vers des destinations indépendantes ainsi que les points de restauration versionnés.
Utilisez le modèle actuel de sauvegarde 3-2-1 de ZimaOS.
ZimaOS dispose déjà d’une récupération système A/B
ZimaOS utilise deux emplacements système d’environ 6 Go. Si l’un d’eux tombe en panne, le guide de récupération actuel permet à l’utilisateur de démarrer sur l’autre emplacement depuis GRUB.
Utilisez le parcours actuel de récupération système A/B.
Une réinstallation propre peut recréer le système d’exploitation, mais pas automatiquement votre configuration exacte
Comme l’a indiqué constgen, un système d’exploitation immuable peut souvent être simplement réinstallé. Le contre-argument de gelbuilding concernait le temps de récupération : un clone de disque peut restaurer exactement les applications, la configuration et l’état du système tels qu’ils ont été capturés, tandis qu’une réinstallation peut nécessiter de remapper les données d’application, de réinstaller les applications et de reconnecter les métadonnées de stockage.
Les deux méthodes sont des stratégies de récupération valables ; elles optimisent des objectifs différents.
Un petit disque de démarrage dédié simplifie le clonage de l’intégralité du disque
gelbuilding a finalement recommandé de déplacer ZimaOS vers un périphérique dédié de petite capacité, compris entre 32 et 64 Go, et de conserver le grand stockage NVMe/RAID pour les DONNÉES et les données d’application. La capacité minimale exacte requise pour l’installation actuelle de ZimaOS est d’au moins 25 Go.
Cela sépare le système d’exploitation remplaçable du grand stockage de données et rend l’image système complète beaucoup plus petite.
Les commandes de restauration brutes sont destructrices
La restauration d’une image dd écrit directement sur le disque de destination. La sélection de la mauvaise cible /dev/... peut détruire un autre disque. Le tutoriel d’origine a été explicitement partagé à des fins de test, et ces commandes ne doivent être utilisées qu’après avoir identifié les disques par leur modèle et leur numéro de série, et après avoir conservé les DONNÉES ailleurs.
Testez le processus de récupération, pas uniquement la création de la sauvegarde
Une sauvegarde n’est utile que si vous savez comment la restaurer. Pour les DONNÉES, restaurez des fichiers représentatifs. Pour une image système brute, testez si possible le processus sur un support de rechange plutôt que de découvrir les problèmes liés aux périphériques ou aux chemins lors d’une véritable panne.
FAQ sur le clonage et la sauvegarde de ZimaOS
Un clone complet du disque système est-il nécessaire pour protéger les données de ZimaOS ?
Non. Les sauvegardes des DONNÉES et des données d’application ainsi que les métadonnées de stockage sont indépendantes des partitions système A/B et constituent la priorité pour les informations irremplaçables.
Pourquoi conserver malgré tout un clone brut du système d’exploitation ?
Il peut réduire le temps de récupération en restaurant exactement la configuration du système et des applications capturée, au lieu de devoir la reconstruire manuellement.
Dois-je repartitionner un NVMe en production uniquement pour réduire la taille d’un clone ?
La recommandation d’origine était non : sauvegardez d’abord les DONNÉES et évitez les modifications inutiles des partitions en production.
