I am attempting to complete a full system backup of my Librem 5. Can I utilize Déjà Dup to back up my entire system? Deja Dup is preinstalled on the system as 'Backups'. I want to include app data—everything if possible.

I'm running on Debian 11 and have used Deja Dup so far to backup the most important stuff. I've connected the app to my gdrive that finished backups are automatically uploaded. As of lately the backup fails. Apparently there is some issue in granting access / valid request to gdrive. I've tried to remove app form gdrive and grant fresh access via Deja Dup. However, I'm still running into the same error message on gdrive: **Access blocked: Déjà Dup Backups’s request is invalid** In more detail the message says: The loopback flow has been blocked in order to keep users secure. Follow the Loopback IP Address flow migration guide linked in the developer docs below to migrate your app to an alternative method. Request details: flowName=GeneralOAuthFlow It points to a google developer site, which dates back to 2022. - https://developers.google.com/identity/protocols/oauth2/resources/loopback-migration So i'm not sure if that is the issue. Does someone know how to resolve this? Happy to provide any further information if it helps.

The question title is vague partly because the documentation / help and UI are, but below I say what I need to know. Three days ago (2024-05-13, Mon) I started using Déjà Dup, got it to make a full backup of my home directory tree on a USB stick and told it to make weekly backups. Today (2024-05-16, Thu) I thought I had probably accidentally permanently deleted a file or even directory (Shift-Delete on the wrong side of a split screen in Dolphin!), and that this was a good chance to try out the restore function. I inserted the stick and started Déjà Dup from the (OpenSuse Leap) start menu, I do not know which I did first) and was surprised to see it said it was backing up, though I do not recall having said it should back up on Thursdays. I presumed it would be an incremental backup, and it did indeed take nothing like as long as the original backup. Once it was finished it exited, so I started it again and asked it to restore one directory sub-tree, worth about 28 out of 400 Gb, by selecting it in the appropriate dialogue. It stomped around silently for quite a while, asked for a password, stomped around a little more, then started saying it was restoring ... more or less everything, it seemed! Since I had just spent quite a long time tidying up, reorganising and freeing up space, I was alarmed, and eventually sent it a TERM signal, as I could find no way to stop it in its UI. Of course I specified to restore from the full backup, as I had already (probably) deleted before the incremental backup. This leaves me with a few relatively urgent questions: * Is there a chance that it has left something corrupt in the tree it was working on? * I.e. does it handle TERM cleanly? * Is there a log somewhere of what it actually did? * Was it really restoring all the files it said it was? * Was it going to revert some or all of my system to the state at the time of the full backup, losing recent changes? and a few more fundamental ones: * Is it possible to specify several files / directories to be restored, or select on other criteria such as time? — I saw no such options. * Is it possible to specify a policy when a file to be restored would overwrite a later change? * If not, how can one restore files to a directory on which one has worked? * What is its policy when a file to be backed up is in use? * Is there a good way of getting more insight into what it does, apart from reading the code? * Is there a good way or getting more control over the process? * Is there perhaps a different GUI tool offering me full control of the underlying functionality? (I am prepared but reluctant to learn `rsync and/or duplicity` and roll my own.) At first I quite liked the minimal nature of the UI, but now it seems to me to lack many essential options. I know one should RTFM, but this FM was F vague on many points. I have now turned off automatic backup, and may even deinstall this tool.

I used Deja Dup on Ubuntu since years with an remote NFS share. Now I have a new home server, which also runs an rsync daemon. How can I connect deja Dup to this daemon instead of NFS? I found out how to connect duplicity from the command line of the client to the remote rsync daemon: duplicity --no-encryption testfile.txt rsync://server::module/backupfolder/ This works fine, the client gives out plausible Backup Statistics, no errors and the backup arrives on the server, so I consider my rsync server running and configured correctly and reachable by the client. But when I put rsync://server::module/backupfolder/ into the client's Deja Dup settings as backup location, it says after starting a backup "location cannot be mounted" or similar. Is the URL syntax wrong? What else am I doing wrong? Isn't Deja Dup supposed to work the same way as duplicity, since it uses duplicity? *edit: I corrected the paths, but still no luck connecting with deja dup

I am having difficulty restoring a backup with deja-dup. I am also having difficulty understanding the advice given in the help documentation that comes with the software. I think the problem I am having is that I did not have write permissions for any of the files when I was backing up the folders.. The particular files that are displayed weren't screencaptured for any particular reason: none of the files in the backup were restored. The part of the help documentation I am having problems understanding is the following. The help documentation states "Some versions of Déjà Dup will not correctly restore files stored in a folder that you did not have write access to when you backed them up" and the advice it gives is to try to create a temp file and restore the files there. But I don't understand, since no matter where I restore the files to now, the files still did not have write permissions when I first backed them up. So, why won't the same problem recur? I am not going to try this solution, yet, since it takes 4 hours for deja-dup to restore before it tells me it cannot do anything (is there some kind of test run I can do on just a portion of the backup?). I want to make sure there is nothing else I can do before proceeding. For what is meant to be a simple program it does not really make it easy to restore your files. Which newbie is going to know how to get write permissions for the entire file structure before they back it up? Am I just misunderstanding? I hope some one can help, because everything of mine is on that hard drive and I need access to those files.

I'm trying to restore a VDI file for VirtualBox from a Duplicity backup. The VDI file is about 40 GB. I have 189 GB (including ~/.cache/duplicity that is fully synced) of free space when I start the restore in the drive I try to restore the file to. I'm running the following command: duplicity -t [date] --file-to-restore "[path_to_file_i_like_restore]" "sftp://[path_backup_location]" "[path_to_where_i_like_to_restore_the_file" --tempdir=~/.cache/tmp which returns: Local and Remote metadata are synchronized, no sync needed. Error '[Errno 28] No space left on device' patching . Why is it running out of space? Is there anything I can do to make it not running out of space? I'm only running the restore command when I'm trying to restore the file to make sure that there is as much space as possible available. I'm running Ubuntu 18.04.4

When using "Backups" (a.k.a. deja-dup) - it doesn't find duplicity, although it's installed: I have been trying to backup using "Backups" (a.k.a. deja-dup), and it turns out that the current duplicity (which deja-dup uses) still has the "Unicode bug" (it fails when dealing with Unicode strings). (I have "Backups" (a.k.a. deja-dup) installed on my system: "deja-dup backup tool" v 37.0, and had duplicity v 0.7.17). My system: ~$ lsb_release -a Description: Ubuntu 18.04.3 LTS; Release: 18.04; Codename: bionic So, I then removed the existing installation of duplicity, and installed duplicity 0.8 from source: https://launchpad.net/duplicity . It installs duplicity at: /usr/local/bin. It's in PATH: ~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin After loading and installing all the requirements, duplicity 0.8 itself runs fine: ~$ duplicity -V duplicity 0.8.05 But, when running "Backups" (deja-dup), it doesn't find it. A window pops up, saying: > INSTALL PACKAGES > In order to continue, the following package needs to > be installed: duplicity I installed dconf-editor, found /org/gnome/deja-dup, but I don't see there any settings for the duplicity path. nautilus and "apt list --installed" don't see it, either. Note: cross posted here

Every day when I have a scheduled backup running, I see this error: Error processing remote manifest (duplicity-inc.20190724T191929Z.to.20190726T191408Z.manifest.gpg): GPG Failed, see log below: ===== Begin GnuPG log ===== gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect gpg: AES encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key ===== End GnuPG log ===== How can I resolve this?

On a fresh Ubuntu 18.04 system I decided to give Deja-Dup a go. It's just a GUI for Duplicity (which uses rsync). About 850GB of data needed to be backed up. Source SSD was NVMe. Destination SSD was SATA. Initial (full) backup took about 7 hours. The next day I did nothing more than check mail and install an application — which added ~230MB — before running Deja-Dup again. Deja-Dup ran for ~39 minutes loading a single core at 35–70% for the entire duration. Duplicity was invoked three times: - The Scanning phase pegged a core at 100% for 18 minutes. - The Backing Up phase pegged a core at 100% for 16 minutes. - The Verifying phase pegged a core at 100% for 5 minutes. This is on a new computer with plenty of RAM. The backup was *not* encrypted. Now, I expect initial (full) backups to take a while, and that's fine. What I *don't* expect is for ~230MB of new data to take ~39 minutes to be backed up (and consume over a collective core-hour of CPU time). **Is something wrong or broken? Should incremental backups of a couple of hundred megabytes take that much time to perform?** I was expecting something under 5 minutes, not ~39. **Why is it taking so long?** (If I had a spare 1TB SATA SSD I'd hook it up and just rsync the data straight across to see if that is noticeably faster — but unfortunately I do not.) Update 1: I ran a manual backup after negligible changes (a few KB of new mail) and the time taken was the same (~39 minutes). Thus the time taken seems to have little to do with the amount of new data that needs to be backed up. Update 2: Monitoring with iotop revealed that the Scanning phase reads 7.36GB from the drive. Now that's obviously not the whole 850GB... but it's not far removed from the number you get if you multiply the number of files on the source drive (1174000) by the block/cluster size (4096) — i.e. 4.81GB. Not sure how to account for the remaining 2.5GB though, if this were the case.

This evening, I had to hard shut down my computer after some kind of kernel panic. When I rebooted, I noticed my ~/.ssh/id_rsa had been replaced with an empty file. Rebooting to a USB and running fsck on my home partition reported that the filesystem was in good shape. This alone is not a problem. I access to the original key. However, I am concerned that other files may have been similarly truncated. My last backup, using deja-dup, was three days ago, so I could just do a full roll-back, but I would rather just ask deja-dup what files have changed since then and look for "suspicious" files. This seems to be exactly the purpose of duplicity verify, so after some man page skimming, I tried:

-sh
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}

which ran to completion without reporting changes. At a minimum, I expected my ~/.ssh/id_rsa to be detected, but I have added, removed, and changed other files. My next try was then the same, but with the --compare-data flag:

-sh
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}

Which seems to report that every file in my home folder is new, starting like:

-none
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File . has permissions 1000:1001 700, expected 0:0 555
Difference found: New file .AndroidStudio2.3
Difference found: New file .AndroidStudio2.3/config
Difference found: New file .AndroidStudio2.3/config/inspection
Difference found: New file .AndroidStudio2.3/config/inspection/Default.xml

I have had Android Studio installed for months, so it was most certainly in my backup from three days ago, and ls reports that Default.xml still exists and is 108 bytes long. As a final effort, I changed the target directory to /, since that seemed to be the root when using duplicity list-current-files, which required adding some regular expressions to limit duplicity to only consider my home folder:

-sh
duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/${USER}/\.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /

Which had the interesting effect of reporting that my home folder doesn't exist:

-none
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File home is missing
Difference found: File home/${USER} is missing
Difference found: File home/${USER}/.AndroidStudio2.3 is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml is missing

At this point, I am certainly just misunderstanding how I should use duplicity. How can I verify a backup generated by deja-dup? duplicity list-current-files has output starting:

-none
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Tue Feb  6 19:36:56 2018 .
Wed Aug  2 17:32:09 2017 home
Tue Feb  6 00:38:20 2018 home/${USER}
Sat May 13 18:49:24 2017 home/${USER}/.AndroidStudio2.3
Thu Jun 22 19:42:14 2017 home/${USER}/.AndroidStudio2.3/config
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml

I've been using the Déjà Dup backup tool with Linux Mint for a while now and just decided to investigate whether it actually works (short of trying to restore, as I only have one machine and don't want to break it!). In snooping around, I have two questions that I was hoping someone might be able to shed light on: 1. It backs up once per week, but inside the backup location folder the last backup only has around 5 .gpg files on that date (4th April), the many many other files (490-ish .gpg files) are from other dates, with the most being from February this year... why are so few from the recent backup? Why so many (390ish) from one date in February? 2. The total size of the backup files (including all dates) is only 20.5GB (and the files from the last backup are only 176MV)... but the home directory it is supposed to be backing up is about 45GB... why so much difference? Now, I don't know much about the tool but obviously these two issues make me wonder if it's actually working... of course, maybe the files are very compressed, but why so little from the last backup and why just 176MB from these five files compared to the size of what's supposed to be backed up? If anyone can offer some clues as to why 1 and 2 might be the case (and if maybe it shouldn't be this way and maybe it isn't working!) I'd be super grateful :)

I backup my data on an external drive using Deja-Dup. I chose to encrypt the backup. Now, every time I start my PC, Mint asks me to unlock my Keyring. How can I grant my PC automatic access to the encryption password (and only to that)?

I installed Deja dup by sudo apt-get install deja-dup but I cannot find it in Search. It appears in commandline, but not like in Ubuntu like here . I did not find any GUI for deja-dup in apt-cache search/apt-file search. I only find the application backups in GUI Search but it is not apparently deja-dup. How can you install GUI of Deja-dup in Debian 8.1?

I'm keeping a copy of all my Deja Dup backup in my Dropbox. To conserve disk space, I'm wondering if I can delete the local copy of the duplicity-full.*.difftar, keeping only .sigtar to allow future incremental backup. I did try move away duplicity-full.*.difftar, Deja Dup end up prompting for back up password, so assuming it's going to do another full backup instead of incremental.

I am interested in image the internal HDD and backup just the filesystem file as backups. My external HDD is 2TB while 100 GB is only used in my internal HDD. Both methods are welcome here. Code and situation $ ls -la /dev/sdb brwx---rwx 1 root disk 8, 16 Jul 13 10:44 /dev/sdb $ sudo chmod 777 /dev/sdb I start the Backups program in GUI of Debian 8.1 which is probably Deja Dup. I set the Buffalo 2TB disc the back file disc. I run backup but I get this window about permission denied although I have 777 as permissions. The command mount gives this output /dev/sdb1 on /media/masi/_linuxDisc type xfs (rw,nosuid,nodev,relatime,attr2,inode64,noquota,uhelper=udisks2) Changing permissions after mjturner's answer --- $ ls -la /media/masi/_linuxDisc/ total 4 drwxr-xr-x 2 root root 6 Jul 12 19:42 . drwxr-x---+ 3 root root 4096 Jul 13 10:44 .. $ sudo chmod 755 /media/masi/_linuxDisc/ [sudo] password for masi: $ ls -la /media/masi/_linuxDisc total 4 drwxr-xr-x 2 root root 6 Jul 12 19:42 . drwxr-x---+ 3 root root 4096 Jul 13 10:44 .. which shows no effect of chmod. Why? How can you set correct permissions for the backup in Debian 8.1?