Le « script d’instantané Premium de ZimaOS » n’est pas un instantané ZimaOS au sens d’un instantané de système de fichiers ou de machine virtuelle. Il ne crée ni instantané Btrfs ni image de sauvegarde. Il s’agit d’un script Bash communautaire qui collecte un rapport de diagnostic : version du système, utilisation des ressources, températures, systèmes de fichiers, état du RAID, état de santé SMART, conteneurs Docker, taille d’AppData, configuration réseau et processus principaux.
Cela peut le rendre utile pour le support, mais signifie également que le texte généré peut contenir des informations sur votre environnement que vous ne souhaitez peut-être pas publier. Zima-Giorgio a salué l’idée et suggéré d’enregistrer les fichiers de rapport produits au fil des itérations dans /DATA car cet emplacement est plus facile à consulter depuis Fichiers. Dans ce fil, IceWhale n’a ni adopté ni certifié le script comme outil de diagnostic intégré.
Le script génère un rapport système unique et lisible par l’utilisateur
Le script source collecte :
- la version de ZimaOS, la variante, la date de compilation, le nom d’hôte, le fabricant et le modèle ;
- la charge du CPU, la mémoire, le swap et les températures ;
- l’utilisation du système de fichiers et la disposition des disques ;
- l’état de RAID et de Btrfs ;
- l’état de santé SMART des disques ;
- les conteneurs Docker en cours d’exécution et arrêtés ;
- la taille des répertoires AppData et Main-Storage ;
- les interfaces IPv4, les ponts et la route par défaut ;
- les processus utilisant le plus de CPU et de mémoire.
Un rapport de diagnostic n’est ni une sauvegarde ni un instantané du système de fichiers
Le terme « instantané » peut être trompeur. Le script écrit les informations système dans un fichier texte ; il ne capture pas les bases de données des applications, les fichiers, les couches de conteneurs ni l’état du stockage à un instant donné pour permettre une restauration.
Utilisez la sauvegarde ZimaOS, des exports tenant compte des applications, une protection RAID ou de véritables outils d’instantanés du système de fichiers ou des machines virtuelles à des fins de récupération.
Le script d’origine écrivait dans Main-Storage
Le script V1 créait :
/media/Main-Storage/Zima_snapshot/et y enregistrait des rapports texte datés. Ce chemin suppose que l’espace de stockage de l’utilisateur s’appelle réellement Main-Storage.
Sur un autre système, coder ce chemin en dur peut échouer ou écrire à un emplacement inattendu si le point de montage est indisponible.
Zima-Giorgio a suggéré /DATA pour faciliter l’accès
Dans la réponse source finale, Zima-Giorgio a indiqué que si le projet continuait d’évoluer, il suggérerait de stocker les fichiers de sortie dans /DATA car ce répertoire est plus facile à consulter depuis l’application Fichiers.
Il s’agissait d’un retour officiel sur le projet communautaire, et non d’une annonce indiquant qu’IceWhale avait intégré le script.
La sortie SMART nécessite une interprétation par périphérique
Le rapport d’exemple affichait des champs SMART traditionnels de disque dur, tels que la température, les secteurs réalloués, les secteurs en attente, les erreurs CRC et le nombre d’heures de fonctionnement. Il affichait également « SMART non disponible » pour les périphériques NVMe, car l’analyse simple du script ne produisait pas de sortie NVMe équivalente.
N’interprétez pas « non disponible » dans ce script comme la preuve que le NVMe ne dispose d’aucune télémétrie de santé.
Le script a été conçu autour de la configuration RAID 5 de l’auteur
L’exemple indique explicitement md0 et affiche une section « État du RAID5 ». Une autre installation de ZimaOS peut utiliser un RAID 1, un RAID 6, JBOD, ZFS, des disques individuels ou des périphériques md nommés différemment.
Avant de réutiliser le script, vérifiez chaque périphérique, chemin de montage et hypothèse de système de fichiers codés en dur.
Les sorties Docker peuvent révéler l’inventaire des applications
Le rapport inclut les noms des images de conteneurs et des applications. Cela est utile au personnel d’assistance, mais une publication publique peut révéler les services que vous exécutez, les versions installées et, potentiellement, les applications obsolètes.
Masquez les noms de services inutiles lorsque le rapport est publié en dehors d’un canal d’assistance de confiance.
Les sorties réseau peuvent révéler la topologie interne
L’exemple de rapport répertorie les noms d’interfaces, les adresses IP du réseau local, les réseaux virtuels, les ponts Docker et les routes par défaut. L’auteur de la source a masqué manuellement une partie des informations IP dans l’exemple publié.
Avant de partager publiquement un rapport, vérifiez :
- les adresses IP et les sous-réseaux ;
- les noms d’hôte ;
- les noms des interfaces VPN/de superposition ;
- les noms des points de montage et des partages ;
- les noms des applications/conteneurs ;
- tous les chemins qui contiennent des identifiants personnels.
Privilégier les diagnostics en lecture seule
L’intérêt de ce type de script est que la plupart des données utiles au dépannage peuvent être recueillies à l’aide de commandes en lecture seule, telles que les informations système, l’utilisation des disques, les requêtes SMART, la liste Docker et l’inspection des processus.
Un script de diagnostic ne doit pas redémarrer discrètement des services, nettoyer Docker, modifier les métadonnées RAID ni supprimer des journaux. Séparez la collecte des éléments de preuve des actions de réparation.
ZimaOS fournit déjà davantage de diagnostics sur le stockage et les applications
La section Paramètres actuels > Applications affiche l’utilisation du stockage et les commandes du cache pour chaque application, tandis que Stockage présente l’état des disques et les informations sur les baies. Commencez par utiliser les outils de visibilité intégrés, puis ajoutez un rapport communautaire lorsque le support a besoin d’un instantané système plus large dans un seul fichier.
Les outils actuels de visibilité du stockage des applications peuvent répondre à de nombreuses questions liées à l’espace sans script personnalisé.
FAQ sur les instantanés de diagnostic
Ce script crée-t-il un instantané récupérable du système ?
Non. Il crée un rapport de diagnostic textuel.
IceWhale a-t-elle officiellement adopté le script ?
Non. Zima-Giorgio l’a salué et a suggéré de stocker les rapports sous /DATA, mais le code reste créé par la communauté.
Le rapport doit-il être publié publiquement sans vérification préalable ?
Non. Il peut exposer les adresses IP, la topologie, les noms des espaces de stockage, l’inventaire des applications et d’autres détails de l’environnement.
