La réponse ci-dessus n'a pas fonctionné pour moi, car le disque qui avait été sauvegardé à l'origine avait été supprimé. Je partage la procédure que j'ai suivie ci-dessous :

• Dans un terminal, tapez :

duplicité liste-courant-f file:///[chemin_vers_le_dossier_de_sauvegarde] > /home/[votre_nom_d'utilisateur]/list.txt

Attention au format "file:///..." dans lequel duplicity s'attend à recevoir le chemin d'accès à l'archive. Vous devez indiquer le chemin complet du dossier contenant votre sauvegarde.

• Créer un dossier pour la restauration :

mkdir [PATH ET NOM DE FICHIER DU FICHIER RESTAURÉ]

• Recherchez le fichier/dossier que vous souhaitez restaurer dans le fichier "list.txt" que nous avons créé précédemment (dans le dossier personnel). Copiez juste le nom du fichier et le chemin d'accès au fichier et non la date. Exécutez ce qui suit :

duplicity restore --no-encryption --file-to-restore [PASTE RESULTATS DE L'ETAPE PRECEDENTE] file:///[LOCATION DE LA SAUVEGARDE] [CHEMIN D'ACCES ET NOM DE FICHIER DU FICHIER RESTAURE]

Veuillez noter que les commandes seront différentes pour une sauvegarde cryptée. Consultez la référence ci-dessous.

Référence de duplicité

Utilisateur de Caja ici, (Mate sur 16.04.3). Problèmes avec ces solutions pour moi, FWIW.

"Backup" a.k.a. "deja dup" (note aux développeurs : standardiser un nom est une bonne chose) vraiment utile lorsqu'un débutant doit chercher des réponses) ne me permet pas de faire autre chose qu'une extraction complète de toute ma sauvegarde vers un emplacement de mon choix. Je veux juste un petit répertoire pour une VM qui fonctionne mal...

1. Nautilus d'occasion. Cependant, il n'a pas accès au répertoire dont j'ai besoin (VBox. Moi : "huh ?"), donc pas de restore via l'interface graphique.

2. deja-dup --restore FILE1 FILE2 ne fonctionne pas. Il se plaint :

   ** (deja-dup:3343): CRITICAL **: deja_dup_config_location_add_volume_full: assertion 'uuid != NULL' failed

Bien sûr, je suppose que FILE1 est la sauvegarde et FILE2 la cible de la restauration. Si ce n'est pas le cas, je me suis trompé.

Quoi qu'il en soit, cela a lancé l'interface utilisateur graphique dans un mouvement de "deja-dup" - c'est une erreur.

3. Plusieurs tentatives de la méthode de Wilson Canda, ainsi

$ duplicity restore --no-encryption file:///media/b/be5f7aad-aa52-47ea-8e64-4352111f66af/home/b/'VirtualBox VMs'/'Green Machine' 'VirtualBox VMs'/'Green Machine'

Local and Remote metadata are synchronised, no sync needed.
Last full backup date: none
Traceback (innermost last):
  File "/usr/bin/duplicity", line 1559, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1545, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1394, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1473, in do_backup
    restore(col_stats)
  File "/usr/bin/duplicity", line 729, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/bin/duplicity", line 751, in restore_get_patched_rop_iter
    backup_chain = col_stats.get_backup_chain_at_time(time)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 984, in get_backup_chain_at_time
    raise CollectionsError("No backup chains found")
 CollectionsError: No backup chains found

Un moteur de recherche de votre choix vous permettra de constater que d'autres personnes ont également rencontré ce problème au fil des ans.

Ma solution : "restaurer" tout vers un "dossier d'attente" sur mon disque externe via l'interface graphique, j'y vais manuellement et je saisis le répertoire que je veux, puis je remplis ce dossier de zéro.