First and foremost, thank you very much for dedicating some of your precious time to developing / maintaining this very useful and important application! Having a functioning GUI backup tool on Linux is a god-sent to anyone using this OS as daily driver.
I set up my system’s backup as follow:
TimeShift to backup the system while excluding the home folder
Deja-Dup Backups to backup the home folder.
I created a restore/recovery USB flash drive with persistent partition based on Kali Linux and installed TimeShift and Dejà-Dup Backups on it to test the restore functions of both applications. TimeShift restored the backup archive I selected flawlessly. But I got stuck on Deja-Dup because of a permission issue. Should restoring a Deja-Dup backup from a live OS be at all possible in your opinion and is the issue I encountered a bug? or should I consider this permission problem to be a feature? What I aim at is the ability to restore a full system when it is not bootable and I have to format the partitions.
Thank you again and in advance for your attention and reply.
Hello! Thank you for the report, and sorry that Deja Dup gave you a hassle.
What was the permission error? And where were you restoring to/from?
The way you describe your setup, I would expect it to work. Deja Dup does run as your current user, so maybe that user on the Live OS didn’t have access to your restore location…?
I didn’t take a screenshot of the dialog I got stuck at. There was no error code per se, just the list of all the folders and files that were to be restored and a message stating that Deja-Dup indeed did not have access to the restore location. The button that should have enabled me to start the restore process remained grayed.
I was restoring through a live Kali Linux OS loaded from a USB flash drive, with both the external disk where the backups are stored and the internal disk where my daily driver OS is located - ie Zorin OS 16.1 - both mounted onto this live session as source and target drives. The user name on this live Kali Linux session is different as the one I intended to restore the home folder for on the internal disk.
Since Zorin OS was not running (was not loaded in the RAM), I was surprised that the only active OS, ie Kali Live, and Deja Dup were prevented from restoring a backup on my computer’s internal disk. That is usually how backup solutions work: they rely on a bootable USB version of their software to restore a backup onto the internal disk. But perhaps Linux’ permissions do not allow Deja Dup to be used this way for security reasons? Cannot Deja’s restore function operate at the root level thereby bypassing any permission restrictions?
Did you ever try flashing Kali Live OS with persistent partition onto a USB stick, installing Deja Dup Backup on it and restore a backup from a separate source drive to a separate target drive?
I hope I did reply your questions in a clear fashion. Otherwise, please let me know.
Ah got it - yeah I know the dialog you’re talking about - we do a pre-restore check for permissions to know whether we can write to the location you ask.
If you navigate to the paths Deja Dup talks about not being able to restore in Files (nautilus), can you make new files/folders there? If not, Deja Dup won’t be able to either. That’s what the dialog is saying.
You can run Deja Dup as root - it’s not a recommended path for backing up, since we can’t really integrate with your desktop that way. For one-off restoring, it should probably work fine. Restored files will likely be owned by root if you do that, heads up.
Also when you restore, you get two choices: original location & specific folder. Which are you choosing? Specific folder, then navigating to the mounted drive?
I wil try to create a file and a folder on the internal disk/drive, then let you know…
I have to select the internal disk/drive as specific target location since Deja Dup would consider Kali Live’s file system as the “original location” which would not be correct.
Would you happen to have a plan in a more or less remote future to create a bootable USB restore media for Deja-Dup that could bypass permission limitations? Is the fact a Live OS like Kali Live enforces the permissions of a partition (the internal disk) that is not even active a normal feature in Linux? And what about the fact that TimeShift does seem to restore the entirety of a backup archive onto this same internal disk without encountering a permissions issue? I only assign it the backing up of the system excluding home folders and files for now, but I do intend to do a test where I have it back up everything including those folders and files to see how it handles the home folder’s content…
I do not mean to take up too much of your time answering my questions on your free time and mainly meant to report Deja Dup’s behaviour while attempting a restore from a recovery bootable media…
I did perform further testing and here are my observations.
The issue of Deja-Dup being unable to restore certain files/folders is indeed due to certain files and folders being locked for writing on the target drive / disk.
As described in one of my previous messages, I use Deja-Dup Backups for the home folders only and TimeShift for the OS excluding the home folders, I also create full disk images from time to time as backup for the disks’partitioning.
When I attempt to restore users’ home folders’ backups over home folders that are not empty, I typically get permissions issues (please check the attached screenshots).
I tried formatting the root partition of my internal disk, restoring the system through TimeShift, then restoring the backup of one of my user account’s home folders (I have two) onto an empty home folder, In this case, Deja’s restore function did work. However, I noticed it changed the ownership of this folder - and I think also its group - from root to kali – which is Kali Live’s default user. Do not know if this was to be expected but I am guessing it may be a problem when booting from the internal disk’s restored system.
To my surprise, the restore of the second user account encountered a permission issue despite being empty. It was perhaps due to the fact its ownership was not root’s in the first place.
