Backup solution - Deja-dup is not reliable?

Help
21

I did a restore with DEJA_DUP_DEBUG=1 deja-dup.

The restore is from an ext4 external drive to an internal ext4 drive.

Here is the error I got.

DUPLICITY: ERROR 30 KeyError
DUPLICITY: . Traceback (innermost last):
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/bin/..duplicity-wrapped-wrapped", line 88, in <module>
DUPLICITY: .     with_tempdir(main)
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/bin/..duplicity-wrapped-wrapped", line 71, in with_tempdir
DUPLICITY: .     fn()
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/dup_main.py", line 1580, in main
DUPLICITY: .     do_backup(action)
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/dup_main.py", line 1663, in do_backup
DUPLICITY: .     restore(col_stats)
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/dup_main.py", line 748, in restore
DUPLICITY: .     if not patchdir.Write_ROPaths(config.local_path,
DUPLICITY: .            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/patchdir.py", line 587, in Write_ROPaths
DUPLICITY: .     ITR(ropath.index, ropath)
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/lazy.py", line 364, in __call__
DUPLICITY: .     robust.check_common_error(last_branch.on_error,
DUPLICITY: .   File "/nix/store/fq2s2vjvksivwwrq6i5gzlbxkbqsh1a5-duplicity-0.8.23/lib/python3.11/site-packages/duplicity/robust.py", line 49, in check_common_error
DUPLICITY: .     errno.errorcode[exc.errno] in
DUPLICITY: .     ~~~~~~~~~~~~~~~^^^^^^^^^^^
DUPLICITY: .  KeyError: None
DUPLICITY: .

What can we do from there? I don’t understand what the error is.

1 Like
22

Unfortunately, it appears that a bug in error handler obscures the actual error here because it expects error number when there is none. It looks like our duplicity version was until recently over a year old and unmaintained. Could you please try again with duplicity: 0.8.23 -> 2.2.3 by corngood · Pull Request #299405 · NixOS/nixpkgs · GitHub (hoping the error handling got fixed in the meantime).

1 Like
23

Sure. What would be the procedure?

I check out the PR you mentioned.

Then, what should I do with that to properly test again?

24

It is already part of nixos-unstable so no need to check the PR branch, just nixos-unstable. You should quit deja-dup, checkout the nixos-unstable branch in Nixpkgs repo (git pull just to be sure it is recent enough), then nix-build -A deja-dup and run result/bin/deja-dup.

1 Like
25

I just tried with the new version, but I get the same error. :frowning_face:

26

I think at this point you should talk to the deja-dup people.

1 Like
27

Duplicity in this case: Issues · duplicity / duplicity · GitLab

2 Likes
28

tar can do incremental backups: https://www.gnu.org/software/tar/manual/tar.html#Incremental-Dumps

I’m using tar to make hourly backups, which are piped through gpg for encryption and through curl for on-the-fly transfer to a remote server over sftp.

The incrementals are based on the last full which means that a full restore only requires the last full backup and the last incremental backup.

A nice feature of tar is that incrementals also contains deletions.

1 Like
29

Could you please add a question mark to the title of this post? (Like “… is not reliable?”)

When you search for “NixOS and Deja-dup” on the Web you currently get this title displayed suggesting that “NixOS and Deja-dup” is a bad combination or that Deja-dup in general is unreliable, which it doesn’t seem to be according to what has been said here.

Thank you for your understanding! (… and respect for the Open Source developers)

30

I would like, but I don’t know how or even if I can.

Edit(jtojnar): Did that.

31

deja-dup also failed me, i opened an issue and (from memory) the maintainer explained to me the likely cause but it could not be recovered. Also, there is no way to verify the integrity of your backups via deja-dup, which aggravated the situation as i was not notified that i had this problem until i actually wanted to restore.

I’m now using rustic + rclone for online backups and kopia for offline backups. Both are great (kopia only supports some rclone backends, that’s why i can’t use it for online backups in my case) and verify the integrity of your backups so you’ll get a warning if there is a problem.

32

I decided to make a script to backup my stuff.

Please don’t hesitate to share or comment.

33

Verifying the backup via the tool’s own verification tool is good but not sufficient to be confident in a backup’s integrity. You must actually attempt to restore the backup and verify that it produces the expected data.

1 Like
34

I really prefer bupstash