Tecnativa/docker-duplicity

No restore option when container is lost

Closed this issue · 3 comments

juriansluiman commented

A best practice of docker containers is to be ephemeral, meaning the container can be lost and recreated from image without lost functionality. I use the tecnativa/duplicity image to have long-running containers and I have set a PASSPHRASE docker env variable to supply duplicity with the GPG passphrase.

However, I found out that recreating the container (with identical passphrase), this new container is not able to read backup data. Duplicity breaks with "no signature chains found". This means that you can restore data from backup when your (host) system is still intact. If your host crashed and you lost the container, you have no option to restore the data from backup, kinda the reason you run the backups...

I am just submitting this issue as I found out and can confirm the behavior, I have no root cause or fix yet. I tried "fixing" the container by importing files from /root/.gnupg, random_seed and pubring.kbx to be specific. Binary files are transferred via base64 and validated via md5, so their content is equal to be sure. However, the problem still persist.

$ docker exec duplicity dup list-current-files file:///mnt/backup/dst/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Traceback (innermost last):
  File "/usr/local/bin/duplicity", line 117, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 103, in with_tempdir
    fn()
  File "/usr/local/lib/python3.9/site-packages/duplicity/dup_main.py", line 1535, in main
    do_backup(action)
  File "/usr/local/lib/python3.9/site-packages/duplicity/dup_main.py", line 1617, in do_backup
    list_current(col_stats)
  File "/usr/local/lib/python3.9/site-packages/duplicity/dup_main.py", line 691, in list_current
    sig_chain = col_stats.get_signature_chain_at_time(time)
  File "/usr/local/lib/python3.9/site-packages/duplicity/dup_collections.py", line 1026, in get_signature_chain_at_time
    raise CollectionsError(u"No signature chains found")
 duplicity.dup_collections.CollectionsError: No signature chains found

In my case, /mnt/backup/dst is a webdav mounted folder (duplicity can't handle my webdav source somehow so I use fuse). The container does mount the source correctly, I can browse /mnt/backup/dst.

$ docker exec duplicity ls /mnt/backup/dst/ | wc -l
128

Also, the container name and hostname matches with the original container, so no hostname mismatch errors occurred.

$ docker exec duplicity hostname
duplicity

So, is there any other file persistency required?

juriansluiman commented

Some more research. A check on the healthy (original) container:

$ docker exec duplicity dup collection-status file:///mnt/backup/dst/
Last full backup date: Sun Jan 24 01:00:02 2021
Collection Status
-----------------
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/1d2fbd14f3201590330c4cfbaae44a63

Found 5 secondary backup chains.
Secondary chain 1 of 5:
-------------------------
Chain start time: Thu Dec 10 19:56:37 2020
Chain end time: Sat Dec 26 02:00:01 2020
Number of contained backup sets: 13
Total number of contained volumes: 13

/// cut here -- lots of info on the chains

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Sun Jan 24 01:00:02 2021
Chain end time: Wed Feb  3 12:37:29 2021
Number of contained backup sets: 2
Total number of contained volumes: 3
 Type of backup set:                            Time:      Num volumes:
                Full         Sun Jan 24 01:00:02 2021                 2
         Incremental         Wed Feb  3 12:37:29 2021                 1
-------------------------
No orphaned or incomplete backup sets found.

And on the new container (again, webdav mount is still there, passphrase is the same):

$ docker exec duplicity dup collection-status file:///mnt/backup/dst/
Last full backup date: none
Collection Status
-----------------
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/1d2fbd14f3201590330c4cfbaae44a63

Found 0 secondary backup chains.
No backup chains with active signatures found
No orphaned or incomplete backup sets found.
yajo commented

Did you follow these instructions?
https://github.com/Tecnativa/docker-duplicity#set-a-custom-hostname

If so, please provide outputs of docker container inspect your_duplicity_container on both hosts, to see differences.

juriansluiman commented

Did you follow these instructions?
https://github.com/Tecnativa/docker-duplicity#set-a-custom-hostname

Yup :)

$ docker container inspect duplicity | grep -A2 "\"Config\": {"
        "Config": {
            "Hostname": "duplicity",
            "Domainname": "",
$ docker container inspect duplicity | grep -A2 "\"Config\": {" 
        "Config": {
            "Hostname": "duplicity",
            "Domainname": "",

If so, please provide outputs of docker container inspect your_duplicity_container on both hosts, to see differences.

However, diffing the complete inspect output showed my "test restore container" did not have all the OPTIONS_EXTRA as with the backup container itself:

- "OPTIONS_EXTRA=--metadata-sync-mode partial --full-if-older-than 1M --file-prefix-archive archive-$(hostname -f)- --file-prefix-manifest manifest-$(hostname -f)- --file-prefix-signature signature-$(hostname -f)- --s3-use-ia",
+ "OPTIONS_EXTRA=--metadata-sync-mode partial",

Hardcoding archive, manifest and signature prefixes with archive-duplicity- etc did solve the trick! I am not sure how this difference appeared, but it seems I can list my collection-status in the restore container.

My backup containers are all based on a custom Dockerfile (where I base my image on tecnativa/duplicity:docker). My restore test is a docker-compose, building custom Docker image again based on tecnativa/duplicity:docker. But that's something I will try to find our on my own now :)

  • 👍1