support system backups (set up a backup run by root)

[ceg]

It would be great if you could "fix Deja Dup to ask for permission to read things it can't." (From answer to question #67726).

Also from that thread:
---
This is what I'm using now:

sudo duplicity / scp://username@host/backupdirectory/duplicity/ --asynchronous-upload --exclude /tmp --exclude /proc --exclude /media --exclude /mnt --exclude /cdrom --exclude /sys --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9' -v5

I can *almost* do this via [deja-dup], but when I run it as root it I don't have access to the typical Nautilus style "Connect to Server" options. It seams there isn't a way to specify an scp destination. Then there's also the scheduling issue mentioned above.
---

Deja-dup might not have to run as root just to go through the GUI to configure the system backup (profile). It might be enough to be able to trigger backups from the command line as root (su, sudo), or by dropping a script into /etc/cron.daily.

OTOH with backintime you run it as root to create the config files for root.

[Michael Terry (mterry)]

I agree this would be nice. But since Deja Dup's focus is really simple home backups, I'm marking this wishlist.

There are some technical challenges here too. Duplicity tells us when we can't read a file. But then we'd need to be able to go back with sudo and get them. And if we try to run duplicity under sudo, we can't use GIO. So maybe we'd need to move the files ourselves to a place that the user can read before backing them up...

[ceg (ceg)]

In any case I think it is quite important that the user gets a notice about the files that could not be read and are thus not backed up.

What to do if that case is detected while selecting the include dirs in deja-dup or when duplicity runs as a user?
Offer to ask for root permissions for future runs?

Not sure. What is the problem with GIO under gksu / gksudo?
Executing "su-to-root -X -c deja-dup" correctly uses gksu here, but no ssh etc. is available.

To schedule system backups we would just need to be able to run "deja-dup --now" or the generated duplicity command from /etc/cron.daily/deja-dup.

[Michael Terry (mterry)]

With 22.0, the user does get notified about files that couldn't be read during a backup.

The problem with GIO under root is that root doesn't have access to the user's gvfs daemons over dbus. So you can't use ftp, ssh, samba, or dav mounts.

That problem will be fixed by the long-term plan to move to always-local backups that are then optionally synchronized to a remote location. So duplicity wouldn't need to talk ssh directly.

[ceg (ceg)]

Good to hear about that feature in 22.0!

Did your consult or report that GIO issue upstream? Multi-user, multi-seat and super user features make up an important part in *nix based systems. The superuser (more precisely any user with enough permissions) should always be able to do things for other (less privileged) users. (i.e. use a running deamon and start one if not already running)

NB: One reason to do backups as root is also related to multiple users on a system: backing up /home containing the files of all users of a simple home desktop with one simple central setup.

[ceg (ceg)]

Actually, the backup process that runs as root should be able to send desktop notifications about the backup beeing run to all users that are logged in.

[ceg (ceg)]

Can't root start its own gvfs?

[ceg (ceg)]

BTW duplicity doesn't need gvfs to run remote backups right? Thus, I currently don't understand why deja-dup couldn't just put the resulting duplicity command into a file in /etc/cron.daily/daja-dup. Deja-dup could create the file as the running user and move it using su-to-root (letting it ask for whatever credentials necessary).

Deja-dup could save the configuration for the backup done by root either in comments contained in /etc/cron.daily or by additionally copying a second file (a regular config file) into root's home directory.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.