Classement

Bonjour, Merci pour toutes ces informations. J'ai pris mon courage à deux mains et mon NAS dans l'autre, et me suis lancé (je suis sur la dernière version de DSM, 7.4 quelque chose - possiblement 7.4.1-90080), il y a quand même pas mal de boulot mais ça se passe pas trop mal pour le moment. Moins pénible que redouté. Je confirme que Docker (Container Manager) tourne sans problème sur un DS920+ quel que soit la configuration du système de fichiers, ext4 ou Btrfs. Si ça peut aider, voilà ce que j'ai fait/je fais en synthétique : Backups à la fois des fichiers, et un backup spécifique avec les applications. A noter que ce backup 'des applications seulement' prend aussi les données de certains répertoires partagés à cause des applications incluses dedans : Synology Photo donc il prend /homes et /photo, Audio Station donc il prend /music, etc. Un backup du paramétrage du panneau de configuration (fichier .DSS) + il y a un backup sur mon compte Synology. Je ne savais pas que chaque Hyper Backup le faisait aussi ! Backup de tous les packets Docker dans Container Manager (via export vers fichier .txz) et aussi copier/coller des docker-compose.yml lorsque le package a été créé en mode 'projet Docker' Réinitialisation de DSM depuis le panneau de configuration. Accepter d'appuyer sur le gros bouton rouge qui dit que tout va être effacé - stress maximal Connexion au NAS et il faut faire toute la phase d'initialisation (installation DSM, etc.) Création du groupe de stockage. Création du volume (crypté + Btfrs). Lancer test de 'nettoyage des données' (?). Restauration de la configuration système = panneau de configuration (via .DSS créé au point 2). Permet de recréer tous les users, les groupes, les dossiers partagés, etc. Restauration du backup 'applications' seulement pour File Station et Hyper Backup --> permet de récupérer dans Hyper Backup le paramétrage des backups, ce qui facilite les restaurations ultérieures. Ne jamais mettre de restaurer la configuration système. Ne rien cocher sur la page "restauration des données" pour les dossiers partagés. Restauration du backup 'applications' pour toutes les autres applications. Ne jamais mettre de restaurer la configuration système. Cocher la restauration des données sur tous les répertoires partagés + toutes les applis sauf celles ci-dessus --> long ! On peut aussi faire cette étape plus tard. Restauration des fichiers dans /docker (dossier partagé de tous les packages Docker) Container Manager : le rechargement des packages Docker par import des .txz n'est pas idéal car il ne recrée pas les 'projets' dans Container Manager. Par contre cela fonctionne bien ensuite, on retrouve le package comme on l'avait laissé avec tout son paramétrage interne. Pour certains packages je suis en cours de recréation via docker-compose.yml plutôt : à voir si lors de la relance cela reprend bien le paramétrage interne du package (restauré au point 10). Il faut créer manuellement les répertoires (vides) dans les points de montage définis dans le docker-compose (hors ce qui est dans /docker, car normalement déjà restauré en 10), que la création du projet se fasse. Faire cette re-création des projets mais ne pas démarrer les packages afin qu'ils n'essaient pas de lire les répertoires des données partagées - car ces données ne sont pas encore restaurées, les répertoires sont vides. En parallèle de 11 : restauration de tous les répertoires partagés hors /docker (déjà fait en 10) ou /photo ou /music (déjà fait en 9). Selon la volumétrie, très à très très long (perso c'est restauré à 100Mo/s environ, donc par ex. ça donne 3 heures par Go environ). A priori démarrage des packages Docker restaurés en 11 - qui devraient retrouver leurs data Derniers contrôles ; notamment reprendre toutes les captures d'écran avant upgrade et repasser sur tous les paramètres Forcer le démarrage des backups réguliers sans attendre leur date de planification. On pourrait aussi lancer de nouveau le test de 'nettoyage des données' dans le gestionnaire de stockage. Ouf!