Duplicity fails while trying to restore

Hi,
I have a hard time finding a simple backup application for filebased storage (SMB mounted drive), very likely I have misunderstood how this is supposed to work.

Any and all pointers appreciated.

Well, I tried duplicity:

As root:
zypper install duplicity
made a backup “duplicity bu /usr/local/ file:///media/backup/”
mkdir foo && cd foo
ran “duplicity file:///media/backup/ ./”

files and directories is in “.” , looks okay.

changed a file in /usr/local/etc

ran backup again, files added to backupdir, looks ok.

when issuing restore command again, duplicity balks with:


GnuPG passphrase for decryption:
Traceback (innermost last):
File “/usr/bin/duplicity”, line 62, in
with_tempdir(main)
File “/usr/bin/duplicity”, line 53, in with_tempdir
fn()
File “/usr/lib64/python3.11/site-packages/duplicity/dup_main.py”, line 1561, in main
do_backup(action)
File “/usr/lib64/python3.11/site-packages/duplicity/dup_main.py”, line 1642, in do_backup
restore(col_stats)
File “/usr/lib64/python3.11/site-packages/duplicity/dup_main.py”, line 810, in restore
if not patchdir.Write_ROPaths(config.local_path, restore_get_patched_rop_iter(col_stats)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib64/python3.11/site-packages/duplicity/patchdir.py”, line 577, in Write_ROPaths
ITR(ropath.index, ropath)
File “/usr/lib64/python3.11/site-packages/duplicity/lazy.py”, line 360, in call
self.process_w_branch(index, branch, args)
File “/usr/lib64/python3.11/site-packages/duplicity/lazy.py”, line 317, in process_w_branch
robust.check_common_error(branch.on_error, branch.start_process, args)
File “/usr/lib64/python3.11/site-packages/duplicity/robust.py”, line 40, in check_common_error
return function(*args)
^^^^^^^^^^^^^^^
File “/usr/lib64/python3.11/site-packages/duplicity/patchdir.py”, line 611, in start_process
assert index == (), index
^^^^^^^^^^^
AssertionError: (b’bin’,)

Sorry, no experience with Duplicity, but it appears to duplicate rsync funtionalty, which has been around for ages and well documented (I only use rsync).

Maybe I missed it, but you should include the Duplicity command you executed in the Preformatted Text output. (wild guess is a wrong argument).

Thanks for your answer,
My NAS (the mounted backup disk) messes with file ownership/permissions and I have not understood how to make rsync cope with that on restore.

Yes I should have included all output although the command given was a key “up, up…” recall of the previous successful command, will triple check - who knows…

AFAIK you will never solve the permissions problem when saving to an MS Partition. You would be best to create a Linux partition on that device, probably ext4 would work best. Then, you have multiple choices for backing up and restoring, including rsync, duplicity, and my personal favourite Unison.

Gnome has a new backup utility called Pika Backup based on the well-known borgbackup:

What is “bu”?

It uses librsync. But as it does incremental backups you can restore files giving a date/time to get the file from that date.

Duplicity uses tar. Ownerships and permissions are in the tar-file and not in the destination filesystem.

Ahhh, I see. Can’t help here, then, since I do not know Duplicity at all. Good luck.

Thanks to all who responded.

@myswtest:
command used for attempted restore: " duplicity file:///media/backup/ ./ "
there’s no difference using " duplicity restore file:///media/backup/ ./ "

@Fraser_Bell:
NAS is a fairly modern Synology offering a btrfs volume over SMB. Maybe badly configured…
I’d rather use something super simple like rsync but I’m out of ideas there.
Will take a look at Unison.

@pavinjoseph:
Thank you for making me have a second look at borg and borgmatic, looks like it will work, don’t know why I dismissed it previously.
Will also take a look at Pika Backup.

@waspo:
“bu” is shorthand for “backup” :slight_smile:

My duplicity (0.8.21) doesn’t accept “bu”: “Expected 2 args, got 3”
Accepted are:

Usage: 
  duplicity [full|incremental] [options] source_dir target_url
  duplicity [restore] [options] source_url target_dir
  duplicity verify [options] source_url target_dir
  duplicity collection-status [options] target_url
  duplicity list-current-files [options] target_url
  duplicity cleanup [options] target_url
  duplicity remove-older-than time [options] target_url
  duplicity remove-all-but-n-full count [options] target_url
  duplicity remove-all-inc-of-but-n-full count [options] target_url
  duplicity replicate source_url target_url

Well, duplicity 2.1.4 does.
BTW, it’s not backing up that troubles me, it’s the restore and only if files are about to be overwritten.

My (Leap 15.5) duplicity never overwrites directories or files when restoring except if “--force” is used. The error message for duplicity 0.8.21 is (using “.” as the destination directory)

Restore destination directory . already exists.
Will not overwrite.

Whoa! I actually made an successful restore with “–force”, thank you waspo for your persistence!
Think I tried --force before - must have botched it somehow…

Some more testing ahead.

Thank’s to all who responded!

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