Vérifier la restauration d’un ZIP : repérer les défauts malgré le même nombre de fichiers
Un essai reproductible sur huit fichiers artificiels distingue fichier absent et contenu modifié à taille égale, avec comparaison SHA256, CSV et script.
Un ZIP existe et son extraction est terminée. Son contenu correspond-il à l'original ? Comparez chemin relatif, taille en octets et SHA256 avec l'inventaire original. SHA256 est une longue empreinte calculée à partir du contenu. Elle peut révéler un changement même si nom et taille restent identiques.
Le but est un petit essai sans écraser l'original et une lecture des résultats distinguant absence et modification. La rédaction MillionsCode a créé 8 fichiers artificiels, les a réellement compressés et restaurés, puis a introduit deux défauts pour vérifier leur détection. Aucun fichier personnel ni sauvegarde client n'a été utilisé.
Mesure et méthode sur 8 fichiers
L'essai a été exécuté le 28 septembre 2026 sous Windows, avec PowerShell 7.6.0-rc.1 et Microsoft.PowerShell.Archive 1.2.5. Ce n'est pas une comparaison de compatibilité entre versions stables. Il comprend un fichier vide, un nom coréen avec espaces, deux fichiers différents de 4 octets chacun, des fichiers homonymes dans des sous-dossiers distincts, un binaire de 256 octets et une note. Total : 8 fichiers, 372 octets.
L'inventaire initial contient le chemin depuis le dossier, par exemple nested/level2/sample.txt, la taille et SHA256. Le dossier est compressé en ZIP puis extrait dans un nouveau dossier. On compare taille et empreinte pour chaque même chemin relatif. Le seul nom confondrait potentiellement deux sample.txt de dossiers différents.
| Condition | Fichiers originaux | Fichiers comparés | Identiques | Différence |
|---|---|---|---|---|
| Restauration normale dans un dossier neuf | 8 | 8 | 8 | Aucune |
| Nouvelle copie avec un fichier délibérément omis | 8 | 7 | 7 | Fichier imbriqué de 15 octets absent |
| AAAA remplacé par ZZZZ dans une copie distincte | 8 | 8 | 7 | SHA256 différent pour un fichier de 4 octets |
Le premier cas est normal. Les deux autres contrôlent la détection de défauts introduits volontairement. Ils ne démontrent pas une perte ou une corruption provoquée par l'outil ZIP. La rédaction a omis le fichier pendant la copie et modifié le contenu dans une copie séparée après extraction.
Dans le troisième cas, le nombre reste 8 et la taille du fichier reste 4 octets. Nombre et taille totale pourraient donc sembler corrects, mais l'empreinte identifie le fichier modifié. Le contrôle du contenu constitue une étape distincte des contrôles rapides de nombre et de taille.
Lire les CSV
restore-summary.csv résume les trois cas. restore-comparison.csv contient au total 24 lignes de comparaison au niveau des fichiers. Case désigne le scénario, RelativePath l'emplacement relatif, ExpectedBytes et ActualBytes les tailles originale et comparée. Les deux colonnes SHA256 contiennent les empreintes.
MATCH: taille et empreinte identiques à ce chemin.MISSING: un chemin original manque ; la taille réelle vide signifie absence, pas zéro octet.HASH_MISMATCH: même taille, empreinte différente ; fichier à restaurer de nouveau et vérifier.- Le script prévoit
SIZE_MISMATCHsi la taille change etUNEXPECTEDpour un fichier supplémentaire. Ces deux branches n'ont pas fait l'objet d'une injection de défaut dans ces trois essais.
Pour same_size_change, same-a.txt mesure 4 octets des deux côtés. Son empreinte originale commence par 63C1DD95…, celle modifiée par 96741164…. Les 64 caractères complets ont été comparés, pas seulement le début. empty.txt était déjà vide et conserve son empreinte après restauration normale. Déclarer tout fichier vide corrompu serait donc erroné.
Reproduire sans risque pour ses données
Lisez le texte du script, puis enregistrez-le dans un dossier d'exercice sous restore-lab.ps1. Vérifiez que l'extension n'est pas restée .ps1.txt. Le script n'accepte aucun chemin de fichier utilisateur. Il crée à chaque lancement un nouveau dossier à côté de lui et ne compresse, restaure et modifie que ses fichiers artificiels. Il n'efface pas d'originaux et n'utilise pas d'option forçant l'écrasement d'une restauration existante. Placez-le dans un dossier d'exercice vide, lisez-le puis exécutez-le dans PowerShell. Si une politique d'entreprise interdit les scripts, ne la désactivez pas de votre propre initiative ; le parcours manuel ci-dessous permet aussi de comprendre.
Depuis le dossier où le script est enregistré :
& '.\restore-lab.ps1'
zip_restore doit être PASS, les deux défauts volontaires FAIL. Si ControlBehavedAsExpected est True dans les trois lignes, ces contrôles se sont comportés comme prévu. Le FAIL volontaire ne signifie pas qu'une vraie sauvegarde a échoué. Dans le nouveau dossier indiqué, ouvrez CSV et results.json pour retrouver date, versions et empreintes entières.
Pour une vraie sauvegarde, utilisez l'inventaire original datant de la création du ZIP. Des fichiers actuels modifiés depuis peuvent faire apparaître une différence avec une ancienne sauvegarde pourtant correcte. Commencez avec des copies de documents importants et restaurez dans un dossier neuf sans données existantes, jamais à l'emplacement original.
Les chemins suivants sont des exemples pour votre exercice. La première commande compresse l'original d'essai, la deuxième restaure ailleurs, les deux dernières affichent les empreintes des fichiers correspondants. Le niveau supplémentaire source vient de la compression du dossier lui-même.
Compress-Archive -LiteralPath '.\source' -DestinationPath '.\trial.zip'
Expand-Archive -LiteralPath '.\trial.zip' -DestinationPath '.\restore-new'
Get-FileHash -LiteralPath '.\source\notes.txt' -Algorithm SHA256
Get-FileHash -LiteralPath '.\restore-new\source\notes.txt' -Algorithm SHA256
Get-FileHash documente la comparaison du contenu et SHA256 par défaut. Expand-Archive distingue destination et écrasement. L'exemple n'utilise pas -Force.
Ce qu'un résultat positif ne vérifie pas
Q. PASS signifie-t-il que toute la sauvegarde est sûre ?
Ici, PASS signifie seulement que chemins, tailles et contenus de 8 fichiers artificiels concordent. Ni vitesse SSD, ni durée de vie, ni succès de synchronisation cloud, ni fiabilité des grandes sauvegardes n'ont été mesurés. Une seule configuration a été utilisée. Droits, propriétaires, clés de chiffrement, paramètres d'applications et bases ouvertes n'ont pas été testés. Ouvrez aussi tableaux et photos dans leurs applications et vérifiez les données liées nécessaires aux logiciels de travail.
Q. La même méthode couvre-t-elle fichiers cachés et volumineux ?
La documentation Compress-Archive signale l'omission de fichiers/dossiers cachés et une limite de taille. N'étendez pas ce petit essai à une sauvegarde complète du système et de ses configurations cachées. Aucun fichier caché ni fichier de 2 Go ou plus n'était présent.
Q. Une empreinte identique termine-t-elle la vérification ?
Un inventaire erroné ou altéré en même temps ne garantit pas l'authenticité de l'original. Vérifiez une copie de référence conservée séparément et sa date. En cas d'absence ou d'écart, restaurez de nouveau le chemin avant d'effacer l'original. Inventaire, empreintes et ouverture des documents nécessaires rendent la suite de la récupération bien plus concrète que la seule présence d'un ZIP.
Connexe
Distinguez bande passante et vitesse des fichiers. Calculez pour 100 GB, vérifie...
Choix de produitsClavier pour programmer : tester disposition, bruit et connexionComparez raccourcis, frappe, bruit, sortie de veille et réglage des touches dans...