Re: [Duplicity-talk] empty cache folder

[Druzee]

Nope... no cleaning.

Like i said, duplicity stopped responding (after resuming from a notebook suspend, moved to a different network), i killed it, when i reran the command line i suddently saw that it starts running from volume 1 again...

On Tue, Dec 25, 2012 at 4:44 PM, <address@hidden> wrote:

On 25.12.2012 15:34, Druzee wrote:
>>does that backup (1000+) verify? ..ede
>>
>>On 25.12.2012 14:50, Druzee wrote:

>>>/ Ineed the folder on S3 does not have a "manifest" (or "sigtar") file like i /
>>>/ have in a different one. I am 100% sure that i did not erase any file from /
>>>/ S3. What even more worries me is that on a different, currently active backup /
>>>/ set that i have with over 1000 volumes the manifest file is also missing./

>
> I am no where near that machine and the backup is still active. but i did try listing the files and it doesn't look good.
>
> Using archive dir: /home/xxxx/.cache/duplicity/146a0d0ed53e8c25f4437132c5de0087
> Using backup name: 146a0d0ed53e8c25f4437132c5de0087
> Import of duplicity.backends.localbackend Succeeded
> Import of duplicity.backends.webdavbackend Succeeded
> Import of duplicity.backends.ftpbackend Succeeded
> Import of duplicity.backends.sshbackend Succeeded
> Import of duplicity.backends.tahoebackend Succeeded
> Import of duplicity.backends.cloudfilesbackend Succeeded
> Import of duplicity.backends.ftpsbackend Succeeded
> Import of duplicity.backends.botobackend Succeeded
> Import of duplicity.backends.gdocsbackend Succeeded
> Import of duplicity.backends.hsibackend Succeeded
> Import of duplicity.backends.imapbackend Succeeded
> Import of duplicity.backends.u1backend Failed: No module named httplib2
> Import of duplicity.backends.rsyncbackend Succeeded
> Main action: list-current
> ================================================================================
> duplicity 0.6.20 (October 28, 2012)
> Args: /usr/bin/duplicity list-current-files s3://bucket/Pictures/ -v9
> Linux null 3.6.10-1-ARCH #1 SMP PREEMPT Tue Dec 11 09:40:17 CET 2012 x86_64
> /usr/bin/python2 2.7.3 (default, Dec 12 2012, 07:12:24)
> [GCC 4.7.2]
> ================================================================================
> Local and Remote metadata are synchronized, no sync needed.
> 0 files exist on backend
> 0 files exist in cache
> Extracting backup chains from list of files: []
> Last full backup date: none
> Collection Status
> -----------------
> Connecting with backend: BotoBackend
> Archive dir: /home/xxxx/.cache/duplicity/146a0d0ed53e8c25f4437132c5de0087
>
> Found 0 secondary backup chains.
> No backup chains with active signatures found
> No orphaned or incomplete backup sets found.
> Using temporary directory /tmp/duplicity-obOjuZ-tempdir
> Traceback (most recent call last):
>   File "/usr/bin/duplicity", line 1403, in <module>
>     with_tempdir(main)
>   File "/usr/bin/duplicity", line 1396, in with_tempdir
>     fn()
>   File "/usr/bin/duplicity", line 1334, in main
>     list_current(col_stats)
>   File "/usr/bin/duplicity", line 599, in list_current
>     sig_chain = col_stats.get_signature_chain_at_time(time)
>   File "/usr/lib/python2.7/site-packages/duplicity/collections.py", line 979, in get_signature_chain_at_time
>     raise CollectionsError("No signature chains found")
> CollectionsError: No signature chains found
>

nothing to worry for now. the metadata is only there so incrementing and listing files can be done without downloading the *big* volumes again.
if the volumes are proper you should be able to restore perfectly.

did you by any chance ran cleanup --extra-clean or something like that?

..ede

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk