Can I access a fully functional version of Duplicity from Deja Dup?

Applications
1

I understand that Deja Dup uses Duplicity. I am using Deja Dup 42.7 (flatpak) and I can find these references to duplicity:

find . -iname duplicity
./.local/share/flatpak/app/org.gnome.DejaDup/x86_64/stable/2002eb71ae52f806113aba497608a65d9ca9db6f6321cb16b643065ee6846773/files/lib/python3.8/site-packages/duplicity
./.local/share/flatpak/app/org.gnome.DejaDup/x86_64/stable/2002eb71ae52f806113aba497608a65d9ca9db6f6321cb16b643065ee6846773/files/bin/duplicity

However, I cannot run Duplicity from the command line. Is there a way to do that other than installing Duplicity separately? I am concerned about having two, potentially conflicting, instances of Duplicity – one of Duplicity itself and the other from Deja Dup. Is that concern unnecessary?

1 Like
2

Hello!

The released flatpak doesn’t let you easily run duplicity from outside. But you can get inside the flatpak and run duplicity:

flatpak run --command=bash org.gnome.DejaDup

That command should give you a new prompt inside the flatpak environment, where duplicity is all set up and can be run fine.

Alternatively, I wouldn’t worry about installing Duplicity from your distro and thus having two versions of duplicity. They won’t conflict. The one inside the flatpak can’t see the one outside it.

And Duplicity’s file format is compatible backwards for almost forever, so you don’t have to worry about that kind of conflict.

1 Like
3

Thanks. That worked great to access Duplicity. However, when I tried your suggestion from issue #168 in the Deja Dup repository – duplicity collection-status pydrive://stevez@gmail.com/path/to/backup, I got an exception asking me to set an environmental variable for either GOOGLE_DRIVE_ACCOUNT_KEY or GOOGLE_DRIVE_SETTINGS. I found instructions on how to do either of these in the man page for duplicity, but I am wondering if that is necessary. Obviously, Deja Dup succeeds in authenticating on a daily basis, so I am thinking that this must be “baked into” Deja Dup already. Perhaps a .pem file that I can set as a value for GOOGLE_ACCOUNT_KEY? I see there are several in the local flatpak directory.

1 Like
4

Ah yeah, connecting to Google through duplicity is a pain actually. Deja Dup does do it on a daily basis as you say, but it makes a temporary file with a bunch of technical token details each time.

Honestly, might be easiest to install rclone and run rclone config and rclone mount to make your Google drive look like a normal folder, then run duplicity against that (or copy the files locally or whatever - you have options once your drive just looks like any other folder).

https://rclone.org/drive/

2 Likes
5

Thanks again. I have a couple of questions (a symptom of being in the steep part of the learning curve):

  1. The Duplicity man page describes this procedure for using pydrive. Assuming I would use the second example – passing a file name to the GOOGLE_DRIVE_SETTINGS environment variable, what are the disadvantages versus using rclone?
    – Maybe that I would have my Client ID and Client Secret in plain text in a file?
    – And that I would have to register with Google cloud console to obtain a client ID and client secret?
  2. The same man page also describes how to use the rclone backend. It sounds as if one might be able to access Google Drive directly, without having to use rclone mount. Any experience with that method?
    I really appreciate all your help.

UPDATE: I read more of the rclone docs and realized they recommend creating your own Client ID and Client Secret so not to have to share rate limits with the general rclone client ID. So that makes my second bullet under question 1 moot.

1 Like
6
  1. If you get far enough that you have a client id/secret, and can follow those instructions, that’s a fine way.
  2. Ah yeah, I forgot they have a rclone backend. That would work fine too.

Rclone recommends your own client id/secret yes, but if you are just doing a one-time thing, I wouldn’t worry about it. I’d just use their shared one.

Actually, speaking of shared keys - you could also use GNOME’s Online Accounts to connect to google, then run Duplicity with:
gio+google-drive://myaddress@gmail.com/path/to/files

2 Likes
7

I ended up installing rclone and duplicity. I also got a client ID and secret from Google – perhaps overkill, but it doesn’t hurt. It all seems to work as advertised except for one small wrinkle…

If I password protect my rclone remote, ~/.config/rclone/rclone.conf is no longer in plain text which is great, but the duplicity backend for rclone no longer works (unless I am missing something).

The solution is to first do rclone mount... and then point duplicity [command] file:///path/to/mounted/remote/duplicity-backup-folder. That is basically what @mterry first suggested so full circle :slightly_smiling_face:

1 Like
8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.