CapordiaEspace client Définir l’état à retrouver avant de choisir les fichiers
Commencez par une phrase vérifiable : reprendre les tâches non terminées, relire les résultats acceptés ou poursuivre un entraînement depuis un état enregistré. Ces objectifs n’exigent pas le même paquet. Nommez la version de l’application, le jeu d’entrées, les paramètres et l’instant de référence. Une date de fichier récente n’indique pas à elle seule que toutes les composantes représentent le même état du travail.
Pour un entraînement PyTorch, la documentation distingue les paramètres du modèle et un checkpoint de reprise comprenant notamment l’état de l’optimiseur. Déterminez les éléments nécessaires à votre propre protocole : progression, ordonnanceur éventuel, données et autres états applicatifs. Un export destiné uniquement à l’inférence peut être valable pour cet usage tout en étant insuffisant pour poursuivre l’apprentissage au même point.
Rendre l’essai indépendant du répertoire de travail
Préparez une destination distincte, avec l’espace et les permissions nécessaires. Identifiez clairement la sauvegarde choisie et protégez sa copie de référence. Le test ne doit pas écraser le travail en cours ni publier ses résultats à la place des sorties acceptées. Désactivez ou redirigez les actions externes de l’application : envoi de notifications, écriture dans un dossier partagé ou lancement d’une campagne supplémentaire.
Utilisez la fonction de restauration de votre outil dans ce périmètre. Restic permet par exemple de choisir une destination avec --target et de prévisualiser une restauration avec --dry-run. Sa documentation avertit qu’une restauration sur place peut laisser un état partiel si elle est interrompue. Ces possibilités illustrent la méthode ; elles ne signifient pas que Restic ou une sauvegarde gérée sont fournis avec une location Capordia.
Vérifier successivement la copie, l’état et l’usage
Contrôlez d’abord que le paquet correspond à l’inventaire attendu et que les fichiers n’ont pas été altérés. Passez ensuite à l’ouverture réelle : droits, chemins relatifs, dépendances, lecture des données et chargement de l’état. Un paquet peut réussir son contrôle d’intégrité tout en omettant un fichier qui n’a jamais figuré dans l’inventaire. Le contrôle fonctionnel répond à cette seconde question.
Lancez enfin une opération bornée dans un processus neuf, sans accès implicite au répertoire d’origine. Notez ce qu’elle lit, ce qu’elle produit et ce qui autorise son acceptation. Pour une reprise de lot, vérifiez qu’elle ne republie pas les tâches déjà validées. Un test sur quelques entrées démontre seulement ce périmètre ; il ne garantit ni toute la campagne ni sa durée complète.
| Niveau | Question | Élément à conserver |
|---|---|---|
| Intégrité | Le paquet reçu correspond-il au paquet prévu ? | Inventaire et résultat du contrôle |
| État restauré | Les fichiers et dépendances permettent-ils le chargement ? | Versions, chemins et écarts relevés |
| Usage | Une opération représentative donne-t-elle le résultat attendu ? | Entrées d’essai, sorties et décision |
Exemple résolu : une archive intacte qui ne reprend pas
Cas entièrement fictif : une campagne comprend 240 dossiers. Au point sauvegardé, 180 sont acceptés et 60 restent à traiter. L’équipe restaure l’archive dans un espace séparé. Tous les fichiers répertoriés passent le contrôle d’intégrité, mais l’application ne retrouve pas une table de correspondance chargée jusqu’alors depuis le poste d’un collègue. La restauration est refusée : l’état ne peut pas être repris de façon autonome.
L’équipe ajoute la version exacte de cette table au paquet et documente son chemin. Elle recommence la restauration dans une nouvelle destination, puis vérifie le registre : 180 + 60 = 240 identifiants, sans doublon. Sur dix dossiers d’essai parmi les soixante restants, le traitement produit les vingt fichiers attendus, soit deux par dossier. Leur contenu est accepté selon les critères fixés. Ces dix essais restent séparés des résultats de production ; le registre initial n’est pas avancé par l’exercice.
Mesurer une durée complète et savoir ce qu’elle prouve
Chronométrez depuis le début de la préparation nécessaire jusqu’au résultat accepté, en distinguant attente, restauration, configuration et contrôle. Dans notre exemple fictif, ces étapes prennent respectivement 15, 75, 20 et 25 minutes : le total atteint 135 minutes, soit 2 h 15. Pour une fenêtre interne de trois heures, la réserve restante vaut 180 − 135 = 45 minutes. Ce calcul ne décrit aucune performance de service.
Consignez les conditions qui rendent cette mesure réutilisable : taille du paquet, destination, versions, disponibilité des personnes et périmètre du contrôle. L’âge de la sauvegarde répond à une autre question : quel travail postérieur faut-il éventuellement refaire ? Une restauration rapide d’un état trop ancien peut rester inacceptable. Définissez les deux critères avec le responsable du projet, sans les confondre.
| Étape | Temps |
|---|---|
| Préparer la destination | 15 min |
| Restaurer le paquet | 75 min |
| Configurer l’application | 20 min |
| Accepter le résultat d’essai | 25 min |
| Total / réserve sur 3 heures | 135 min / 45 min |
Conclure l’exercice et conserver une prochaine action claire
Le compte rendu tient sur une page : sauvegarde choisie, objectif, environnement d’essai, écarts, résultat accepté et limites. Si un élément manque, attribuez sa correction puis rejouez le contrôle concerné. Ne remplacez pas un échec par une formule vague comme « archive disponible ». Après l’exercice, identifiez les sorties de test et retirez-les selon votre procédure, sans toucher aux copies retenues pour la conservation.
Refaites l’essai lorsque le format de sauvegarde, le logiciel ou une dépendance importante change, et avant une échéance qui rendrait la récupération difficile. La cadence dépend du projet ; elle n’est pas un engagement automatique de la location. Sur une période de 3, 7 ou 30 jours, prévoyez un créneau pour vérifier la reprise et transmettre son résultat à la personne qui exploitera la suite.
Questions pour décider
Une empreinte correcte suffit-elle à accepter une sauvegarde ?
Elle vérifie la concordance des fichiers concernés, pas la complétude du projet ni sa capacité à redémarrer. Ajoutez un chargement dans un espace distinct et une opération représentative. Le compte rendu précise la portée de chacun de ces contrôles.
Faut-il reproduire toute la production pour chaque essai ?
Pas nécessairement. Choisissez un périmètre qui couvre les dépendances et les critères essentiels, puis indiquez ses limites. Un petit essai est utile pour détecter un fichier manquant ; il ne mesure pas la capacité à restaurer un volume beaucoup plus grand.
Que faire si l’essai réussit seulement avec l’ancien répertoire accessible ?
Cherchez la dépendance implicite : configuration, donnée, bibliothèque ou chemin externe. Ajoutez-la au paquet ou documentez comment la retrouver, puis recommencez sans ce raccourci. Tant que ce besoin reste inconnu, la reprise demeure dépendante de l’environnement d’origine.