IDrive ne figure actuellement pas parmi les intégrations de services cloud documentées de ZimaOS. Considérez-le donc comme non pris en charge par le flux natif Fichiers/Sauvegarde, à moins qu’IceWhale ne l’ajoute à la liste des fournisseurs. Une réponse d’IceWhale publiée en 2025 indiquait que des plug-ins cloud tiers plus larges étaient prévus, mais une déclaration concernant la feuille de route ne constitue pas une intégration publiée.
Si IDrive est indispensable à votre politique de sauvegarde dès aujourd’hui, la conception la plus propre consiste généralement à conserver ZimaOS sur des chemins de sauvegarde pris en charge et à confier l’envoi vers IDrive à une autre machine ou à un autre NAS. Cela évite d’installer des logiciels hôtes non pris en charge sur la couche système protégée de ZimaOS.
IDrive est-il pris en charge nativement par ZimaOS ?
Le guide des services cloud de ZimaOS actuel répertorie les fournisseurs disponibles dans le flux de connexion cloud de ZimaOS. IDrive n’y figure pas.
La demande de fonctionnalité initiale a reçu une réponse d’IceWhale indiquant que des plug-ins de stockage cloud tiers plus larges étaient à l’étude. Cela confirme un intérêt, et non une disponibilité, une compatibilité ou une date de sortie.
Pourquoi l’installation du client Linux IDrive sur l’hôte est risquée
ZimaOS n’est pas conçu pour fonctionner comme un serveur Debian polyvalent sur lequel des paquets hôtes arbitraires peuvent être installés durablement. Sa couche système est protégée et ses mises à jour sont conçues autour d’un système d’exploitation de type appliance.
Un agent de sauvegarde Linux peut nécessiter des gestionnaires de paquets, des chemins système accessibles en écriture, des services au démarrage, des bibliothèques ou un comportement du noyau que ZimaOS n’expose pas de la même manière. Même si vous parvenez à le faire fonctionner temporairement, vous devez vous demander s’il survivra à une mise à jour du système d’exploitation et s’il pourra être restauré proprement.
Des moyens plus sûrs de combiner ZimaOS et IDrive
Option 1 : ZimaOS vers un autre NAS, puis le NAS vers IDrive
Si vous possédez déjà un Synology, un QNAP, un serveur Windows, un serveur Linux ou une autre plateforme prenant en charge les logiciels IDrive, utilisez Sauvegarde ZimaOS pour copier les dossiers importants sur le réseau local. Laissez ensuite la seconde machine envoyer ces copies vers IDrive.
Option 2 : ZimaOS vers une clé USB, puis protection de la copie USB
Pour les ensembles de données de petite taille, créez une sauvegarde USB planifiée ou avec rotation. Cette copie pourra ensuite être traitée par un ordinateur sur lequel IDrive est officiellement pris en charge. Cette solution est moins automatique, mais elle préserve la propreté de l’hôte ZimaOS.
Option 3 : utiliser un fournisseur cloud déjà pris en charge par ZimaOS
Si votre besoin est simplement une « sauvegarde cloud hors site » plutôt qu’IDrive en particulier, choisissez un fournisseur disponible dans le flux ZimaOS actuel. Le guide de sauvegarde 3-2-1 de ZimaOS montre comment intégrer le cloud à une stratégie 3-2-1.
Et si IDrive publie une image Docker ?
Un conteneur maintenu et documenté s’intégrerait beaucoup mieux que la modification du système d’exploitation hôte, car il conserverait les dépendances dans Docker. Vous devrez toutefois vérifier que le conteneur prend en charge le mode de sauvegarde souhaité, que les chemins de données sont montés en lecture seule ou en lecture-écriture selon les besoins et que les identifiants sont stockés de manière sécurisée.
Ne supposez pas que « peut fonctionner dans Docker » signifie « officiellement pris en charge par ZimaOS ». Il s’agirait toujours d’une intégration gérée par un fournisseur en amont ou par la communauté, à moins qu’IceWhale ne la fournisse et ne la maintienne.
Comment protéger les données des applications avant leur envoi hors site
Sauvegardez les dossiers hôtes utilisés par les applications, et pas seulement les images de conteneurs. La page actuelle sur les chemins de données des applications ZimaOS explique où les applications de l’App Store stockent leurs données persistantes.
La vue d’ensemble des sauvegardes ZimaOS peut vous aider à choisir la destination du premier saut, tandis que le guide de persistance Docker explique la limite de persistance.
Comment déterminer si une solution de contournement est suffisante
Pour un serveur personnel, un conteneur communautaire ou une sauvegarde en second saut peut être acceptable. Pour des données critiques pour l’entreprise, exigez une procédure de restauration documentée, une authentification prise en charge, le chiffrement, une politique de rétention et des alertes. La question n’est pas seulement de savoir si une tâche de sauvegarde s’exécute, mais si vous pouvez restaurer vos données après une défaillance de disque, de serveur ou de compte.
FAQ
IceWhale a-t-il promis la prise en charge native d’IDrive ?
Non. IceWhale a indiqué que des intégrations de stockage cloud tiers plus larges figuraient sur la feuille de route. La discussion ne fournissait ni version de sortie ni implémentation spécifique à IDrive.
Puis-je installer directement le client Linux IDrive standard sur ZimaOS ?
Il est peut-être possible de faire des essais, mais ce n’est pas la conception prise en charge la plus propre. Les agents installés au niveau de l’hôte peuvent entrer en conflit avec le modèle de système protégé de ZimaOS et pourraient ne pas survivre aux mises à jour.
Quelle est la solution de contournement IDrive la plus sûre ?
Sauvegardez les données ZimaOS sur le réseau local vers une machine ou un NAS prenant en charge IDrive, puis laissez cette plateforme effectuer l’envoi hors site.
La synchronisation cloud remplace-t-elle une sauvegarde locale ?
Non. Conservez plusieurs copies. Une destination cloud est plus fiable lorsqu’elle est associée à des sauvegardes locales ou sur le réseau local dans le cadre d’un plan 3-2-1.
