Backup cannot be restored (no signature chains found)

duplicity list-current-files file://media/alain/My\ Book/duplicity-15.10
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : aucune
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1519, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1513, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1370, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1451, in do_backup
    list_current(col_stats)
  File "/usr/bin/duplicity", line 689, in list_current
    sig_chain = col_stats.get_signature_chain_at_time(time)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 984, in get_signature_chain_at_time
    raise CollectionsError("No signature chains found")
CollectionsError: No signature chains found

duplicity --version
duplicity 0.7.02

Ubuntu 15.10 64 bits

duplicity --file-to-restore backups/mysql --time 2D file://media/alain/My\ Book/duplicity-15.10 /restore
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : aucune
Phrase de passe GnuPG
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1519, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1513, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1370, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1447, in do_backup
    restore(col_stats)
  File "/usr/bin/duplicity", line 715, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/bin/duplicity", line 737, 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 960, in get_backup_chain_at_time
    raise CollectionsError("No backup chains found")
CollectionsError: No backup chains found

Starting this morning duplicity cannot list current files or verify on both my Ubuntu desktop at home and CentOS 6.5 server at OVH. I have made updates on my Ubuntu machine but no updates on my CentOS server unless OVH is doing some updates on it but I don't think so. Before today al was fine on both machines. I event did some tests with small backups and I have the same problem.

On My CentOS 6.5 machine I tried that:
duplicity --full-if-older-than 1M /backups/mysql-backups/ file:///mnt/nfs/toto/mysql
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : aucune
La dernière sauvegarde complète est trop ancienne, forçage d’une nouvelle sauvegarde complète
Phrase de passe GnuPG
Veuillez retaper la phrase de passe pour confirmer :
--------------[ Statistiques de sauvegarde ]--------------
StartTime 1457720231.30 (Fri Mar 11 13:17:11 2016)
EndTime 1457720237.78 (Fri Mar 11 13:17:17 2016)
ElapsedTime 6.48 (6.48 seconds)
SourceFiles 71
SourceFileSize 122610486 (117 MB)
NewFiles 71
NewFileSize 122610486 (117 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 71
RawDeltaSize 122606390 (117 MB)
TotalDestinationSizeChange 122582819 (117 MB)
Errors 0
----------------------------------------------------------

[root@ns519500 backups]# duplicity list-current-files file://mnt/nfs/toto/mysql/
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : aucune
Traceback (most recent call last):
  File "/bin/duplicity", line 1532, in <module>
    with_tempdir(main)
  File "/bin/duplicity", line 1526, in with_tempdir
    fn()
  File "/bin/duplicity", line 1380, in main
    do_backup(action)
  File "/bin/duplicity", line 1461, in do_backup
    list_current(col_stats)
  File "/bin/duplicity", line 696, in list_current
    sig_chain = col_stats.get_signature_chain_at_time(time)
  File "/usr/lib64/python2.7/site-packages/duplicity/collections.py", line 994, in get_signature_chain_at_time
    raise CollectionsError("No signature chains found")
CollectionsError: No signature chains found

duplicity collection-status file://mnt/nfs/toto/mysql
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : aucune
État de la collection
-----------------
Connexion au serveur central : BackendWrapper
Dossier d’archive : /root/.cache/duplicity/0dddd627ac205962ddf0d456682d4d9e

0 chaîne secondaire de sauvegarde a été trouvée.
Aucune chaîne de sauvegarde avec les signatures actives n’a été trouvée
Aucun jeu orphelin ou incomplet de sauvegarde n’a été trouvé.

Status changed to 'Confirmed' because the bug affects multiple users.

FreeBSD 10.3

root@rose:/usr/ports/net/syncthing # duplicity --version
duplicity 0.7.06

root@rose:/usr/ports/net/syncthing # python2 --version
Python 2.7.11

"duplicity collection-status --no-encryption file:///mnt/darkstar/backups/rose" - works but list0current-files not.

root@rose:/usr/ports/net/syncthing # duplicity list-current-files --no-encryption file:////mnt/darkstar/backups/rose
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Traceback (most recent call last):
  File "/usr/local/bin/duplicity", line 1532, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 1526, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 1380, in main
    do_backup(action)
  File "/usr/local/bin/duplicity", line 1461, in do_backup
    list_current(col_stats)
  File "/usr/local/bin/duplicity", line 696, in list_current
    sig_chain = col_stats.get_signature_chain_at_time(time)
  File "/usr/local/lib/python2.7/site-packages/duplicity/collections.py", line 994, in get_signature_chain_at_time
    raise CollectionsError("No signature chains found")
CollectionsError: No signature chains found

0.6.18 was a buggy release. It is possible that it produced a backup that
was incomplete. This looks like the case in your report above. I don't
have it in front of me, but there is a method to manually restore files as
long as the difftar files are complete. Look for answers by edso (Edgar
Soldin) in the duplicity-talk archives.

On Fri, May 27, 2016 at 12:02 AM, Holm <email address hidden> wrote:

> FreeBSD 10.3
>
> root@rose:/usr/ports/net/syncthing # duplicity --version
> duplicity 0.7.06
>
> root@rose:/usr/ports/net/syncthing # python2 --version
> Python 2.7.11
>
> "duplicity collection-status --no-encryption
> file:///mnt/darkstar/backups/rose" - works but list0current-files not.
>
> root@rose:/usr/ports/net/syncthing # duplicity list-current-files
> --no-encryption file:////mnt/darkstar/backups/rose
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: none
> Traceback (most recent call last):
> File "/usr/local/bin/duplicity", line 1532, in <module>
> with_tempdir(main)
> File "/usr/local/bin/duplicity", line 1526, in with_tempdir
> fn()
> File "/usr/local/bin/duplicity", line 1380, in main
> do_backup(action)
> File "/usr/local/bin/duplicity", line 1461, in do_backup
> list_current(col_stats)
> File "/usr/local/bin/duplicity", line 696, in list_current
> sig_chain = col_stats.get_signature_chain_at_time(time)
> File "/usr/local/lib/python2.7/site-packages/duplicity/collections.py",
> line 994, in get_signature_chain_at_time
> raise CollectionsError("No signature chains found")
> CollectionsError: No signature chains found
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1086374
>
> Title:
> Backup cannot be restored (no signature chains found)
>
> Status in Duplicity:
> New
> Status in duplicity package in Ubuntu:
> Confirmed
>
> Bug description:
> I get:
>
> [root@ ]# duplicity list-current-files scp://
> 192.168.11.2/backup/caw-server1
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: none
> Traceback (most recent call last):
> File "/usr/bin/duplicity", line 1391, in <module>
> with_tempdir(main)
> File "/usr/bin/duplicity", line 1384, in with_tempdir
> fn()
> File "/usr/bin/duplicity", line 1322, in main
> list_current(col_stats)
> File "/usr/bin/duplicity", line 598, in list_current
> sig_chain = col_stats.get_signature_chain_at_time(time)
> File "/usr/lib64/python2.6/site-packages/duplicity/collections.py", line
> 977, in get_signature_chain_at_time
> raise CollectionsError("No signature chains found")
> CollectionsError: No signature chains found
>
> when trying to list files from my backup. But the files seem ok outside
> of duplicity,
> This affects multiple servers backing up to different locations.
>
> OS is CentOS 6.2 x86
> Duplicity 0.6.18 from the repos
>
> ---
> Using archive dir:
> /root/.cache/duplicity/1dc0bb65e1eb97582ca301487786e1b1
> Using backup name: 1dc0bb65e1eb97582ca301487786e1b1
> Import of duplicity.backends.ftpsbackend Succeeded
> Import of duplicity.backends.u1bac...

Kenneth Loafman (kenneth-loafman): Unfortunately I'm experiencing that problem with duplicity v. 0.7.06 trying to read backup winch done by same version just minutes ago.

It seems that bug still not fixed in duplicity 0.7.06.

I am seeing this behavior with duplicity 0.7.08 on Ubuntu 16.04.1 LTS. The Backups GUI in System Settings reports that it is running backups successfully and new backup files are being created in the remote location. However, the duplicity command line is unable to run collection-status or list-current-files without error when pointed to the same remote as specified in the System Settings GUI.

I deleted my previous remote backup collection and created a new one using the GUI tools. I then verified the backup using duplicity command line and it worked as expected.

It seems that the remote backup collection can become corrupted while the GUI will continue to run daily backups reporting that it verified them and that the backup completed successfully. This is a critical defect as it will lead to end-user data loss. Users will believe they have valid backups even when they are corrupted.

I am adding Unity Control Center to this bug report to address the interaction effect between the GUI in System Settings reporting that backups are succeeding and the state of a corrupted backup in duplicity.

Hello, I am also having this issue, under specific circumstances. I have duplicity 0.7.11 on two machines. From the first, I run

    duplicity --exclude /proc --exclude /tmp --exclude /sys --exclude /run rsync://scott@remote_machine/ destination/folder

It initializes the connection and requests the GPG key:

Command line warning: Selection options --exclude/--include
currently work only when backing up,not restoring.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase for decryption:

But when I enter the GPG key and hit enter, I get the following error, which is similar to the above, with different line numbers due to the age of this bug.

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1553, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1547, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1398, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1475, in do_backup
    restore(col_stats)
  File "/usr/bin/duplicity", line 738, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/bin/duplicity", line 760, 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 971, in get_backup_chain_at_time
    raise CollectionsError("No backup chains found")
CollectionsError: No backup chains found

Now this is interesting to me because it's somewhat different from this bug in that it occurs on backup as opposed to on restore, and only occurs when using the 'rsync' protocol.

I encountered this backtrace when I had the wrong remote path. It would be better to have an error message for that case such as "No backup chains found. Did you specify correct remote path?"

Thanks!
C.

I got this error when attempting to list files with 0.7.18.2.

The root cause in my case was a bad path in an "sftp://" URL. It was important that the absolute path after the host name started with two slashes, and that the URL point to a folder that contains "duplicity-full..."files. My correct URL also ended in a slash.

It's a scary error message and it should give you a hint if the folder is wrong or there's really some other problems. For example, one message could say "No duplicity files found at the provided URL. Confirm the path to your backup folder is correct."