4 votes

Problème de restauration de mon fichier de sauvegarde .ab

Je sais que cela peut faire double emploi mais je n'ai pas trouvé de solution pertinente moi-même.

Aujourd'hui, j'ai essayé d'être aventureux et d'installer Ubuntu Touch sur mon Nexus 7 et ce fut un échec. Par mesure de sécurité, j'ai sauvegardé les données de mon appareil en utilisant la commande suivante sur un système d'exploitation Windows 7 :

adb backup all -f ./nexus.ab -shared -apk

Cela a pris une éternité et a créé un fichier de 1,6 Go (ce qui me semble raisonnable). Mais le problème, c'est que lorsque c'était terminé, même si l'écran de sauvegarde sur mon appareil avait disparu, la commande ne revenait pas dans Windows et je devais appuyer sur ctrl+c.

J'ai donc poursuivi mon aventure et, au cours du processus, j'ai dû déverrouiller mon bootloader, ce qui a entraîné l'effacement de toutes mes données (j'ai lu que cela pouvait arriver et j'étais d'accord puisque j'avais déjà sauvegardé mes données). Une fois que j'ai terminé mon aventure (et échoué), j'ai essayé de restaurer mes données en utilisant la commande suivante (sur la même machine que celle où j'ai créé la sauvegarde) :

adb restore ./nexus.ab

Cela prend des heures et une fois que c'est fait, il n'y a aucun message (ni succès ni échec). Je peux dire que c'est terminé car l'écran de restauration sur l'appareil disparaît et la commande revient dans Windows. Mais lorsque j'allume mon appareil, il est identique à celui qui est sorti de la boîte. Y a-t-il encore un espoir ? Comment puis-je savoir si mon fichier de sauvegarde est corrompu ou si tout va bien ? Dois-je faire quelque chose après la restauration de mon fichier de sauvegarde ?

3voto

Milner Points 533

Essayez de regarder le logcat sortie. J'ai eu un problème similaire avec plusieurs appareils (tous du même fabricant, mais pas le vôtre) - et il s'est avéré qu'ils avaient manifestement un bogue dans la mise en œuvre de l'ADB ( logcat a montré une erreur d'analyse pour le fichier de sauvegarde).

Si votre situation est comparable (un bug ADB sur le firmware de votre appareil), vous pouvez oublier de restaurer cette sauvegarde. en utilisant ADB. Pourtant, il existe des alternatives :

Comme vous pouvez le lire dans le tag-wiki ou notre sauvegarde tag, il existe d'autres applications qui peuvent lire et restaurer des sauvegardes ADB. Comme par exemple Sauvegarde en titane . Je ne sais pas si cette fonctionnalité est réservée à la version Pro, mais elle vaut au moins la peine d'être essayée avec la version gratuite. Et même si c'est le cas, cette application vaut la peine d'être achetée. Notez cependant que votre appareil doit être enraciné pour ça.

Copiez votre nexus.ab sur la carte SDCard de votre Nexus (je sais qu'il n'a pas de slot microSD, mais la SD interne devrait faire l'affaire). Ensuite, utilisez TiBu pour restaurer à partir de ce fichier de sauvegarde. Il se peut que vous ne puissiez pas restaurer tout (Je n'ai jamais essayé, donc je ne sais pas jusqu'où cela va) -- mais au moins vos applications et leurs données devraient pouvoir être restaurées.

Une deuxième méthode (à utiliser pour les autres choses) consiste à décompresser manuellement l'archive de sauvegarde. Les détails peuvent être trouvés ici :

Vous pouvez également consulter d'autres questions étiquetées "adb+backup" pour de plus amples informations.

1voto

tomasz Points 111

Utilice adb logcat pour vérifier le journal du système pour les exceptions pendant le processus de restauration. Essayez de rechercher des messages de BackupManagerService comme ceux-ci :

I/BackupManagerService(  716): Reusing existing agent instance
D/BackupManagerService(  716): Invoking agent to restore file fbreader.ui.xml
E/BackupManagerService(  716): Unknown tar entity type: 76
E/BackupManagerService(  716): Parse error in header: Unknown entity type 76
W/BackupManagerService(  716): io exception on restore socket read
W/BackupManagerService(  716): java.io.IOException: Unknown entity type 76
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.readTarHeaders(BackupManagerService.java:4117)
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.restoreOneFile(BackupManagerService.java:3406)
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.run(BackupManagerService.java:3282)
W/BackupManagerService(  716):  at java.lang.Thread.run(Thread.java:841)
D/BackupManagerService(  716): Killing host process
I/BackupManagerService(  716): Full restore processing complete.
D/BackupManagerService(  716): Full restore pass complete.

Dans l'exemple ci-dessus, vous trouvez un message E/BackupManagerService: Unknown entity type 76 . Cela signifie que l'archive .tar contenue dans le fichier .ab a été créée avec la version GNU de l'outil tar et a utilisé GNUTYPE_LONGNAME ('L') dans le champ header.typeflag d'un fichier, ce qui n'est pas compris par le BackupManagerService de votre Android. Utilisation de tar --format=posix devrait régler le problème.

0voto

Derpy Dash Points 1

Comme indiqué dans tomasz réponse, cela peut avoir à voir avec le format de l'archive tar, mais en utilisant posix ne m'a pas aidé et j'ai toujours des erreurs, après avoir essayé différents formats j'ai découvert que --format=ustar (qui est un ancien format posix) fonctionne très bien, puisqu'il ne crée pas de PaxHeaders qui casseraient la structure de l'archive.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X