Re: Contributing code to Deja Dup

[Michael Terry <mike mterry name>]

Hello, thanks for the email!  I'm not 100% opposed to the idea.  But I fear it may be more complicated than we may initially think.  Here are some quick thoughts.

1) Did you have any thoughts on how the UI would look?  I suppose we could just add a "+" button to the "Backup locations" tab and let users set more...  One problem is that user's might reasonably then want different values for other preferences to apply to each location.  Like the "how long to keep files in your backup" setting.  The complexity could easily grow.

2) It's a real bummer that we wouldn't be able to re-use the efforts of the first backup to help with the second backup.  We couldn't directly copy any backup tarballs over because the backup locations might have different contents.  And we couldn't re-use duplicity's idea of what's on disk, because it doesn't offer any way to save/re-use that state between runs.

3) Meaning we'd just kick off two entire backups back-to-back I guess when the scheduled time hit?  If we wanted to stagger them, we could keep separate schedules for them (even if we continued to only expose one schedule option like "weekly", we could have them kick off on different days...).  I'm not sure whether staggering is better or worse than just doing them both immediately.

4) You ask about the timing of when to do full backups.  That we'd get for free.  Deja Dup looks at what's in the backup location already and decides if it has been too long since the last full backup.

5) Reporting errors to the user needs some care, if we're backing up both locations back-to-back.  Do we delay errors from backup A until we see how backup B went?  Let's say that backup A fails for some reason.  I suspect we should still try backup B in that case, but maybe only report an error if we can't back up for a *different* reason -- avoiding complaining about a lack of internet connection twice for example.  Other issues would be files that we couldn't back up (permission error or whatever).  If they happen to be different between runs, I guess we should merge the lists.  But there is a whole set of questions like that.  (Or we could report the two separate errors as they happen -- or only back up to location B if A went well?)

6) We'd have to make the gsettings schema for the backup location pathless (if that means anything to you, not sure how intimate you are with gsettings).

7) One thought is that we could get most of what you want "for free" for a certain class of users if we simply looked at the mount path instead of the UUID (which as you guessed is what we currently do).  The UUID logic was written back before most distros automounted by UUID (how widespread is that now?).  My original goal was just to make sure that you never accidentally triggered a backup by plugging in some thumb drive, instead of your backup drive.  But if we used mount path, we'd get UUID logic for free nowadays, but we'd also cater to people that had custom fstabs that put both drives in the same mount, right?  That's what you originally tried to do, before realizing Deja Dup was using UUIDs?  Only really a solution that unblocks the technical users.  But a far easier fix at least.  Also wouldn't help with any other kind of backup locations (like remote), but I think that's a less common request than "multiple backup drives" which seems to be fairly common -- I guess people take one drive off-site and rotate every now and then.

-mt

On 1 December 2014 at 00:04, David Cook <kingandcaptain gmail com> wrote:

Hey all!

My name is David Cook and I'm new to the Deja Dup list. I'm a systems librarian at Prosentient Systems in Sydney, Australia where I provide support for library technology. I primarily develop in Perl for the open source library management system Koha, but occasionally write in PHP, read Java from the open source digital repository DSpace, and read C from the open source indexing engine Zebra.

I've been using Deja Dup to make encrypted backups for my desktop at home for about a year, but I've recently started thinking about doing rotating backups where I'd keep one drive at home throughout the week and the other at the office, then swap once a week. 

However, I noticed that swapping out the drives at the same mount point wouldn't work as Deja Dup was using something more unique than that (perhaps the UUID, I couldn't tell at a glance). 

So I started thinking about possibilities for using multiple target locations. Naturally, I found the bug for "Profiles for different target locations" (https://bugs.launchpad.net/deja-dup/+bug/324631). I agree with Michael Terry that having different profiles might be over complicating things. However, I think it makes sense to be able to have the same settings but backup to multiple locations. Michael mentioned that Time Machine doesn't offer profiles, and that might be right, but my friend who uses it mentions that it can back-up to multiple locations (he backs up to a pair of drives). While maintaining separate profiles could make the UI overly complex, specifying more than one location could be very straightforward.

That's all I'd want. I'd specify two USB hard drives (or rather their mount points that I specify in /etc/fstab) and then Deja Dup would backup to them if they're available. If one wasn't available (ie it's at the office), it would just do a backup for the drive that is available. Judging from the comments on the bug, it seems like the kind of thing that a lot of people would be interested in. 

Honestly, I've thought about writing my own scripts to utilize Duplicity, but that leads to a few different problems. So my friend suggested that I fork Deja Dup. Not a bad idea, but I figure... why fork it when I can contribute code back?

I suppose the problem might not be as simple as I see it. The timing of when to do full backups is one thing I haven't thought about too much. Is that done weekly or based on a set number of previous incremental updates? I suppose I can go look...

In any case... I've taken a look at https://wiki.gnome.org/Apps/DejaDup/GettingInvolved/Coding. I'm willing to set up my environment and learn Vala. I suppose I'm just curious... if I do make this change... would it be something that people would be interested in? Michael, would you be willing to merge it back in?

I don't think it would be very complex, and I think it would help Deja Dup to meet the needs of even more people than it already does. Personally, why I am a developer for work, I don't really do much technical stuff at home. I'm just someone who wants to backup his personal data in the event of a robbery (it's already happened once, although fortunately they didn't take my backup drive :P), meteor, or whatever else.

Anyway, sorry for the long email. I just wanted to give some context, and note that I am willing to contribute, rather than just saying "please give me this feature". 

Cheers,

-David Cook

_______________________________________________
deja-dup-list mailing list
deja-dup-list gnome org
https://mail.gnome.org/mailman/listinfo/deja-dup-list