L’objectif architectural est pertinent : utiliser des SSD en RAID 0 uniquement pour les charges de travail qui nécessitent réellement un débit maximal, puis protéger cet espace de travail à haut risque avec des sauvegardes indépendantes sur disques durs et conserver au moins une copie hors site. Le RAID 0 n’offre aucune redondance ; la défaillance d’un seul SSD peut rendre toute la grappe de travail indisponible.
La réponse de la communauté en 2025 recommandait des disques durs autonomes en rotation avec un rsync nocturne, mais l’auteur du message initial soulevait une objection importante : ZimaOS disposait déjà d’un mode Auto dans Backup, et il voulait savoir si le remplacement d’un ancien disque dur dans la même baie serait détecté automatiquement. La discussion s’est terminée avant que ces questions ne trouvent une réponse. La documentation actuelle d’IceWhale fournit désormais une base prise en charge plus claire : l’application Backup prend en charge les tâches planifiées, plusieurs destinations indépendantes, la reprise et la tolérance aux erreurs, ainsi que des points de restauration versionnés — mais la documentation publique actuelle ne décrit pas de procédure garantie permettant d’insérer à chaud n’importe quel ancien disque dur dans la même baie et de le réconcilier automatiquement en fonction de son identité.
Le RAID 0 nécessite un véritable plan de sauvegarde
Le RAID 0 combine des SSD pour augmenter la capacité et les performances, sans parité ni miroir. La défaillance d’un seul membre peut détruire la grappe. Pour un usage professionnel, la sauvegarde doit être considérée comme une partie intégrante de la conception, et non comme un ajout ultérieur.
Des disques durs de sauvegarde autonomes conviennent mieux à la rotation que le RAID 1
La communauté recommandait de conserver chaque disque dur de 26 To indépendamment plutôt que d’en associer deux en RAID 1. Ainsi, chaque disque constitue une copie complète, amovible et stockable hors site, tout en évitant de reconstruire un miroir à chaque rotation d’un disque.
Il s’agit d’une recommandation de conception de la communauté, et non d’une exigence d’IceWhale. Le RAID 1 peut améliorer la disponibilité tant que les deux disques durs restent installés, mais il est peu pratique comme mécanisme de rotation physique et de stockage hors site.
La version actuelle de ZimaOS Backup prend en charge le flux de travail 3-2-1 essentiel
La documentation actuelle d’IceWhale indique qu’une seule application Backup peut utiliser des sources et destinations Zima, USB, LAN ou cloud, exécuter des tâches selon un calendrier, reprendre les transferts interrompus, conserver des versions et des points de restauration, et gérer plusieurs tâches depuis une même source vers différentes destinations.
Utilisez le modèle Backup actuel de ZimaOS.
Ne figez pas l’interprétation de 2025 selon laquelle « Auto » signifie instantanément à chaque modification
L’auteur du message initial citait une indication de l’interface selon laquelle les sources Zima/USB pouvaient s’exécuter instantanément lorsque des fichiers étaient modifiés. Une autre discussion officielle de la communauté datant de la même période décrivait le mode Auto de ZimaOS Backup comme s’exécutant à des heures précises, généralement tôt le matin. La source elle-même n’a jamais concilié ces deux descriptions.
La documentation publique actuelle décrit une sauvegarde planifiée et ne promet pas de réplication déclenchée par les événements du système de fichiers après chaque modification. Pour la planification en production, utilisez le calendrier documenté actuellement plutôt que de vous fier à une ancienne formulation de l’interface.
rsync est un outil de miroir et de transfert, pas automatiquement une sauvegarde versionnée
Le script de la communauté utilisait :
rsync -avh --delete ...L’option --delete fait en sorte que la destination reproduise les suppressions effectuées sur la source RAID 0. Cela peut être utile pour un miroir, mais peut aussi propager une suppression accidentelle vers le disque de sauvegarde.
Si vous utilisez rsync, commencez sans options destructrices, utilisez --dry-run, vérifiez le chemin cible et concevez séparément les instantanés et la gestion des versions si la récupération après des suppressions est importante.
La rotation des disques nécessite une identité stable et une vérification explicite
Insérer des disques dans une même baie physique ne garantit pas que chaque disque inséré recevra toujours le même nom ou chemin de montage. Un processus de rotation robuste doit identifier le disque au moyen d’une identité de périphérique ou de stockage stable, confirmer que la cible attendue est montée, puis démarrer la sauvegarde.
Ne lancez pas une tâche de miroir destructive simplement parce que « quelque chose » est monté à l’ancien chemin cible.
Faites tourner les copies hors site plus souvent que tous les quelques mois pour les travaux critiques
Une rotation tous les trois ou quatre mois laisse un important intervalle sans point de récupération si l’espace de travail sur site et la sauvegarde locale sont perdus simultanément. L’intervalle approprié dépend du rythme des modifications et de la tolérance de l’entreprise, mais les données professionnelles importantes justifient généralement une rotation hors site plus fréquente.
Testez la restauration avant de faire confiance à la rotation
Pour chaque disque dur de sauvegarde, restaurez un projet ou un fichier représentatif, vérifiez les sommes de contrôle ou la lisibilité avec l’application concernée, puis notez la date de la dernière sauvegarde réussie avant d’emporter le disque hors site.
FAQ sur les sauvegardes de RAID 0
Le RAID 1 sur les disques durs de sauvegarde est-il équivalent à la rotation de sauvegardes indépendantes ?
Non. Le RAID 1 améliore la disponibilité tant que les deux disques font partie du miroir ; des disques indépendants sont plus faciles à retirer et à stocker hors site comme copies séparées.
La documentation actuelle de ZimaOS promet-elle une véritable réplication en temps réel à chaque modification ?
La documentation publique actuelle de Backup décrit des tâches planifiées, la reprise et la tolérance aux erreurs, ainsi que la gestion des versions, plutôt qu’un miroir garanti déclenché par les événements du système de fichiers.
rsync --delete est-il automatiquement plus sûr que ZimaOS Backup ?
Non. Il reproduit intentionnellement les suppressions et nécessite une validation rigoureuse de la cible ainsi qu’une gestion séparée des versions si vous souhaitez pouvoir récupérer des erreurs.
